Hi, I don't think any additional information in the key derivation is needed.
I do think that the requirements for server identity verification in RFC 5216 is a bit vague. HTTPS (RFC 2818) for example has much more stricter requirement regarding this: "If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks." I started an issue regarding this. https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/47 My suggestion would be to add something like the following to EAP-TLS 1.3: "The EAP-TLS peer MUST check that the identity in the EAP-TLS server's Certificate is appropriate and authorized for the link. If a NAI was used in the identity response, the EAP-TLS peer MUST check the realm in the identity response against the identity in the EAP-TLS server's certificate." I am sure most EAP implementations are secure, but I have recently seen prototype usage (not EAP) of TLS where the identity in the certificate was never checked, resulting in nothing more than group authentication where any cert signed by any of the trust anchors was accepted. I think implementors need guidance on that verifying the identity is essential for getting authentication. Otherwise implementors might easily miss this, thinking that TLS and certificate chain validation alone gives authentication. Cheers, John -----Original Message----- From: Emu <[email protected]> on behalf of Alan DeKok <[email protected]> Date: Monday, 8 February 2021 at 13:42 To: Joseph Salowey <[email protected]> Cc: EMU WG <[email protected]>, Martin Thomson <[email protected]>, Benjamin Kaduk <[email protected]> Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3 On Feb 7, 2021, at 9:27 PM, Joseph Salowey <[email protected]> wrote: > > I'd like to get feedback from the working group on the EAP-TLS 1.3 key > derivation. Does this improve the security of the system? Are there any > implementation barriers? > > The key derivation for TLS 1.3 uses the key exporters defined for TLS 1.3. A > few reviews have pointed out that the exporter master secret for TLS > exporters includes server identity information, but does not include > information about the peer/client identity. > > Both Martin and Ben proposed adding the peer identity into the context > parameter for the TLS exporter key derivation. This binds the peer identity > into the key derivation for EAP-TLS keys that are used in lower layer > protocols. This explicit binding strengthens the resulting authentication > implied by the key and should make formal analysis of the system easier. > > For example, if the EAP-TLS server is requesting a certificate from the peer > then the key derivation would look something like: > > Key = TLS-Exporter(label, peerID/peer certificate, 64) What format is used for then peer certificate? The EAP-TLS application doesn't necessarily have access to the "on the wire" format of the certificate. It may only have access to a decoded / high-layer representation of the certificate. For that reason, I would prefer to avoid using the certificate in any key derivation. The peer ID may be more, if we just a field in a certificate (e.g. subjetAltName). It is simple, and can be exported as an opaque blob. > Where the label is the label defined for the key and the peer ID is identity > information for the peer. Since the peer ID in EAP-TLS has some potential > ordering issues, it may be better to use the end entity certificate of the > peer as the peerID. > > In the case where the peer is not asked for a certificate then the derivation > would not include the peerID. The TLS resumption key derivation is derived > using both the peer and server identity from the original exchange so adding > the peerID into the EAP-TLS key derivation in the resumption is not > necessary. I would prefer to define a consistent key derivation. The more if / then / else cases are defined, the more opportunity for error. TBH, just leaving it as draft-13 or -14 is fine. The main important change for me is to mandate the use of TLS alert as a secure altReject indicator, and a delayed close_notify / commitment message (after the client cert) was a secured altAccept indicator. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
