From: TLS <tls-boun...@ietf.org> On Behalf Of Eric Rescorla Sent: 09 March 2021 06:27 To: Dan Harkins <dhark...@lounge.org> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] Comments on draft-friel-tls-eap-dpp-01
On Mon, Mar 8, 2021 at 1:18 PM Dan Harkins <dhark...@lounge.org<mailto:dhark...@lounge.org>> wrote: Hi Eric, On 3/8/21 8:00 AM, Eric Rescorla wrote: Taking a step back from the crypto, I'm trying to make sure I understand the desired security properties. As I understand the situation: - the client has a preconfigured key pair (X_c, Y_c) - the server is anonymous (i.e., doesn't have a valid TLS cert). [ofriel]Its not true that the server does not have a valid TLS cert, the EAP server will have a cert but the client will have no way of verifying it. Its more https://tools.ietf.org/html/rfc8446#appendix-C.5. - the server is preconfigured with information about each client (in this case, Y_c). And the desired property you are looking for is that: 1. The client authenticates to the server using X_c 2. The client will only connect to servers that know the per-client information Is this correct? Yes. Assuming it is, it seems like we could accomplish this with less change to TLS. Here is one proposal (warning: not at all analyzed so may be totally broken). - Have the client take on the TLS server role, and use RFC 7250 raw public keys. This addresses requirement 1. This breaks the use of (T)EAP. In the case of EAP, the server is the one that grants access to the network and the client is the one that asks for access (which is why it's known as the "supplicant"). The EAP roles match the TLS roles so it wouldn't be possible for an EAP client to act as a TLS server in the EAP method. Thanks for the clarification. This is party of why it's helpful to understand the requirements. - Store a separate per-client value K_c (this can be derived from the X_c to ease the burden on the client) and use RFC 8773 external PSK with cert authentication to inject K_c into the key schedule. There's no certs involved here. There is trust by the server in a raw public key and there's an assurance (not quite authentication) of the client based on who knows that public key To clarify, what I was proposing was that that you replace knowledge of the pubkey with knowledge of the PSK and have the client (acting as the server) present its public key in the RFC 7250 Raw Public Key mode. The reason certs come into play is that TLS 1.3 prohibits the use of certificate based exchanges (which should include Raw Public Key) with PSKs, and 8773 relaxes that. However, if you can't have the client act as the server, then we'll need to find another approach. As I indicated on the call, what would be helpful to me would be a description of the externally visible invariants that we need to satisfy. [ofriel] Another requirement is that the full public key Y_c is not transmitted as part of TLS handshake from client to server. We cannot not use RFC 7250 as is. Instead, something like the Known Certificates proposal in cTLS https://tools.ietf.org/html/draft-ietf-tls-ctls-01#section-5.1.3 would work. Something like this could work: Setup: Client has X_c, Y_c Server is provisioned with Y_c (the bootstrap RPK) Both sides could derive (using some suitable hashing algorithm): keyID = H1(Y_c) PSK = H2(Y_c) Server keeps a map of keyID to Y_c. keyID could be common or unique for the PSK and RPK. C->S: Client sends the keyID for the derived PSK ClientHello +tls_cert_with_extern_psk +pre_shared_key identity=keyID S->C: Server looks up the Y_c, derives PSK, and injects into key_schedule. Server sends its PKI Certificate/CertificateVerify which client ignores. Server requests client cert so that client can prove it knows X_c. ServerHello +pre_shared_key selected_identity=keyID {EncryptedExtensions} {CertificateRequest} {Certificate} {CertificateVerify} {Finished} C->S: Ignores server Certificate/CertificateVerify. If handshake reaches here, at this stage, server has proven knowledge of Y_c via derived PSK. {Certificate, cert_data does not include RPK, but instead keyID as per cTLS} {CertificateVerify} {Finished} Server verifies Finished. At this stage, client has proven knowledge of X_c. I believe this meets the requirements that: - server proves knowledge of Y_c - client proves knowledge of X_c - Y_c is not send over the wire in cleartext - reuse existing RFCs, aligns better with existing TLS flows, no new extensions (well we need to do something for Certificate including keyID) -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
