On Feb 18, 2021, at 4:03 AM, John Mattsson <[email protected]> wrote: > 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."
The issue is that HTTPS has (generally) a hostname available: "go to www.example.org". Hmm.. does the presented cert contain "www.example.org" ? That's easy to check. There's a field for that. We don't have this with EAP. EAP may contain an identity, "@example.com", and the server will present a certificate with DNS name "radius.example.com". Is this OK? We're not sure. It is widely used, but the field which says "my DNS name is radius.example.com" does not necessarily help with comparisons to an NAI of "@example.com". > 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." The issue is "how". :( There have been prior discussions about this in EMU. See "EAP/EMU recommendations for client cert validation logic" in early 2020. That was a _long_ discussion. The conclusion largely was that there's no real way to do this safely with existing certificate fields. > 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. Implementations largely fixed that years ago via a few methods: * on initial connection to SSID, prompting the user to see if the certificate is OK (historical, and less permitted these days) * pre-provisioning SSID / CA certificate / user credentials to each machine * certificate pinning so that the EAP server certificate is cached and associated with an SSID / user credentials. i.e. not just the CA cert. This caching prevents bad actors from getting their own certificate from the same CA, and setting up their own "mirror" malicious SSID. The result is that this works for most situations, and is reasonably secure. > 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. Unfortunately there doesn't seem to be a clear way to do this. Even if we added a new certificate field, many public CAs will only sign certs which contain a very limited subset of OIDs. So you can't just add an OID and get it used. The current implementations seem to be OK, inter-operable, and secure. But it would be good to document this behavior, and explain why it's necessary. I'll see if I can suggest some text. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
