From: TLS <[email protected]> On Behalf Of Joseph Salowey Sent: 09 March 2021 23:47 To: Dan Harkins <[email protected]> Cc: <[email protected]> <[email protected]> Subject: Re: [TLS] Comments on draft-friel-tls-eap-dpp-01
On Mon, Mar 8, 2021 at 1:17 PM Dan Harkins <[email protected]<mailto:[email protected]>> 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). - 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. [Joe] Technically, I think it would be possible for the supplicant to take on the TLS server role and the server the TLS client role. This would be counter to the way all TLS based EAP protocols work today, but there is nothing fundamental to EAP that prevents it. [ofriel] This would be a huge change for EAP, require a lot of standards work, and be massive task to get deployed across the EAP installed base. As you say, it is counter to everything EAP today, and it doesn’t seem practical. - 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 (this is modeled on the "Resurrecting Duckling" paper). regards, Dan. -Ekr On Mon, Mar 8, 2021 at 7:09 AM Scott Fluhrer (sfluhrer) <[email protected]<mailto:[email protected]>> wrote: Again, last minute reviews… It would appear that the exact computations that both the client and the server need to perform needs to be explicitly spelled out, as there are several possibilities. Here is the one I could see that appear to have the security properties that you appear to be looking for: Variable names: g – Well known group generator h – The secret generator that is private to the client and the server z – The secret value known to the client; g^z = h x – The client’s ephemeral DH private value y – The server’s ephemeral DH private value: Client keyshare: This is the value g^x When the server receives this, he selects y (and retrieves the value h); he then transmits (as his keyshare) the value: h^y and stirs the value (g^x)^y into his KDF When the client receives this (h^y), he computes: (h^y) ^ (x z^-1) (where z^-1 is the modular inverse of z modulo the group order), and stirs that value into his KDF. With this protocol, it appears that the client needs to know not only h, but also the value z. However, this really needs to be spelled out (and run past the CFRG to check for subtle issues) _______________________________________________ TLS mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tls -- "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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
