On Mon, Mar 8, 2021 at 1:17 PM Dan Harkins <[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. > - 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) <sfluhrer= > [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] >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing [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] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
