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). > - 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. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
