On Tue, Mar 9, 2021 at 11:43 PM Owen Friel (ofriel) <ofr...@cisco.com> wrote:
> > > > > *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> 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. > Is that a primary requirement or a derived requirement? > > 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) > Yes, this might work. I think we would need analysis to demonstrate that this doesn't allow an attacker to derive Y_c. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
