Hi, Martin Thompson wrote:
>What I was concerned about was the information that is exchanged in EAP >*before* the TLS handshake >begins that might affect the choice of certificate to offer. As this is not >authenticated at all, >there are trivial attacks if a client uses that information to guide its >choice of certificate. For >that problem, including the certificate as context in the key exporter doesn't >help, but including >any information that might appear outside could, if you get all of it. That seems more interesting to discuss. I think the only only interesting information exchanged before the TLS handshake is the identity in the identity response. It will typically be an anonymous NAI @realm but it may be an encrypted username xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm and formally it does not even need to be a NAI. EAP-TLS 1.3 mandates a "privacy-friendly" identity. An encrypted username may not protect against spoofing. I don't think RFC 5216 states anything about how the client choses it's certificate. In some implementation I have seen the user picks a certificate. The realm does of course very much determine the server certificate as the response would be send to different servers. On one hand, the realm could be considered routing information just like the IP address. Changing the sever IP address in any use of TLS might change the server certificate. On the other hand the guidance in RFC 5216 on how to verify the server identity is very vague. Once a TLS session is established, EAP-TLS peer and server implementations MUST validate that the identities represented in the certificate are appropriate and authorized for use with EAP-TLS. The authorization process makes use of the contents of the certificates as well as other contextual information. While authorization requirements will vary from deployment to deployment, it is RECOMMENDED that implementations be able to authorize based on the EAP-TLS Peer-Id and Server-Id determined as described in Section 5.2. There are no hard rules like the one in RFC 2818 about comparing hostname with subjectAltName. Not sure that putting the identity response in the exporter context improves anything. Might be more useful with guidance/requirements on how to chose certificates and which identities to allow. Cheers, John -----Original Message----- From: Emu <emu-boun...@ietf.org> on behalf of Martin Thomson <m...@lowentropy.net> Date: Monday, 8 February 2021 at 04:47 To: Joseph Salowey <j...@salowey.net>, EMU WG <emu@ietf.org>, 'Benjamin Kaduk' <ka...@mit.edu> Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3 On Mon, Feb 8, 2021, at 13:27, Joseph Salowey wrote: > Both Martin and Ben proposed adding the peer identity into the context > parameter for the TLS exporter key derivation. So I wasn't suggesting the client certificate, as that is covered by the client key confirmation and (I think) the results we have from the exported authenticator work indicates that this isn't necessary for the security of the protocol; validating the Finished is what provides the assurances there. What I was concerned about was the information that is exchanged in EAP *before* the TLS handshake begins that might affect the choice of certificate to offer. As this is not authenticated at all, there are trivial attacks if a client uses that information to guide its choice of certificate. For that problem, including the certificate as context in the key exporter doesn't help, but including any information that might appear outside could, if you get all of it. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
