On Wed, Mar 10, 2021 at 7:12 AM Dan Harkins <dhark...@lounge.org> wrote:
> > > On 3/10/21 4:12 AM, Eric Rescorla wrote: > > > > 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? > > > I'm not sure of the distinction you're making here. > Well, once again, it seems like the technical requirement is that: 1. You want to authenticate the server to the client (as noted below, I don't think that the distinction you are making between "assurance" and "authenticate" is sufficiently crisp to be helpful). 2. The only secret information that the server shares with the client is Y_c. But this doesn't necessarily preclude the client *sending* Y_c, it merely requires that it not send it to anyone who hasn't proven they know Y_c first. For instance, if Y_c was used as a PSK (as owen suggests), then it might (again, no analysis here) allow the client to send Y_c in an RFC 7250 certificate message because it would already be being encrypted under a key that required knowing Y_c. But let me address > a misconception mentioned earlier (not by you, but mentioned nonetheless) > to hopefully clear this up: > > In DPP the public key is not secret, but the knowledge of the public key is > supposed to be restricted to those who are legitimate owners of the thing. > The more gratuitously a thing distributes it's public key the less > assurance > the thing will get that the holder of it's public key is legit. Consider > that > the Oprah level of bootstrapping-- "you get my public key!, and you get my > public key!, and you get my public key!"-- would end up being TOFU since > the > thing doesn't actually know who it ended up talking to (everyone could > theoretically have gotten the public key), but restriction of the thing's > public key to someone who purchased the thing-- consider transfer of data > in the cloud upon delivery of a paid purchase order-- can allow the thing > to have a higher level of assurance that it's talking to the legitimate > owner. > That's what we want to leverage with TLS-pok. It's not that the public key > is secret, it's that the restriction of the public key's knowledge is > directly proportional to the assurance the thing gets that it's talking to > its legitimate owner. > >From an analysis perspective, I'm not sure how to model this other than as it is a secret with a limited distribution. -Ekr > So in TLS-pok, the client is getting an assurance that he's connecting to > the right network by the server proving knowledge of its public key. If the > client starts out by saying, "here's my public key" it will eliminate any > assurance the client could've gotten from restricting access to its key > and reduce TLS-pok's client assurance to TOFU; we don't want to do that. > > regards, > > Dan. > > > >> >> 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 > > > -- > "The object of life is not to be on the side of the majority, but to > escape finding oneself in the ranks of the insane." -- Marcus Aurelius > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
