Assuming that NAIRealm is a registered domain as per RFC 7542, and thus public
CAs can verify ownership, the goal / where we want to get to is:
- CA may be a public CA and thus public CAs can be enabled by default in
supplicant config
- supplicant checks NAI Realm in the EAP identity cert matches that of the
user's realm
- supplicant verifies id-kp-eapOverLAN is set
And also assuming that public CAs will not issue certs with an NAIRealm or
id-kp-eapOverLAN bit. (This is certainly true for Let's Encrypt. See below for
details.) And it could be years before public CAs do.
Does that mean there is an intermediate rollout phase where the supplicant
checks that the realm the user enters matches a dNSName in the EAP cert?
The rollout / upgrade issue with this is of course if we give guidance that
supplicants
(i) check that entered realm matches NAIRealm; and id-kp-eapOverLAN is set
If that fails then (ii) check that dNSName matches entered realm
at what point in time would supplicant behaviour ever change to remove the
fallback to option (ii) and checking dNSName only?
As a data point on RFC 4985 and id-mod-dns-srv-name-93 (or RFC 6125 SRV-IDs):
Public CAs generally don't issue these either, so the same issue with
supplicants checking for NAIRealm or id-kp-eapOverLAN exists with
id-mod-dns-srv-name-93 w.r.t. Public CAs.
Owen
P.S.: Let's Encrypt implementation is at: https://github.com/letsencrypt/boulder
You can see the only allowed KeyUsage and ExtKeyUsage bits here:
https://github.com/letsencrypt/boulder/blob/master/cmd/gen-ca/main.go#L318
https://github.com/letsencrypt/boulder/blob/master/cmd/cert-checker/main.go#L303
-Original Message-
From: Emu On Behalf Of Alan DeKok
Sent: 18 November 2019 14:18
To: EMU WG
Subject: [Emu] Best practices for supplicants and authenticators
After the meeting earlier today, I made some notes on best practices for
supplicants and authenticators. I think it would be useful to have an official
WG document which gives guidance.
Background:
a) the current practice in TLS-based EAP methods is to use certificates with
"id-kp-serverAuth" OID set for Extended Key Usage.
b) many supplicants check for this OID, and refuse to perform authentication if
it is missing
c) supplicants do not check DNS names or any other field in the certificates
d) as a result of this lack of verification, supplicants ship with all known
CAs disabled for TLS-based EAP methods
If the supplicants did ship with root CAs enabled, then because of the lack
of validation in (c), the supplicants would hand over user credentials to any
authenticator who has a properly signed certificate. This is wrong, and is why
all of the root CAs are disabled.
It would be useful to simplify the user experience when working with EAP-TLS.
It would also be useful to reduce security issues. This is where a new
document is needed. I believe that the standards exist to support these goals.
However, there's a lack of guidance around using these standard. It would be
good to document current practices, and then give guidance on how to upgrade to
better practices.
I'll start off describing the end goal, and then discuss how we can get there.
The goal is to have certificates which contain the id-kp-eapOverLAN OID (RFC
4334), and either the NAIRealm OID (RFC 7585), or a similar one dedicated to
TLS-based EAP authentication. Supplicants can use these fields to verify that
the certificate is both intended to be used for TLS-based EAP authentication,
and that the certificate is for a given realm.
The end user experience *should* be something like:
* connect to a system which uses 802.1X authentication (SSID, wired, etc)
* prompt the user for full credentials (user id + realm / password)
* validate that the server certificate has the id-kp-eapOverLAN OID set, AND
that the NAIRealm OID matches the user's realm
* validate the certificate chain
If those validation steps succeed, then the supplicant could send the users
credentials over the EAP method. I think that this extra validation means that
supplicants can trust known root CAs by default. Which makes the user
experience much better.
Since the certificates do not currently contain these fields, and supplicants
don't check them, we need an upgrade path.
The first step is to suggest that admins generate certificates with the above
fields. This likely means that certificate authorities will be asked to sign
certs with the NAIRealm OID, which they might not do. This limitation is less
of a problem in a roaming federation like Eduroam, where they are their own CA.
The next step is to suggest that supplicant vendors upgrade their systems to
allow the id-kp-eapOverLAN OID, *or* the id-kp-serverAuth in server
certificates. That is a simple change, and shouldn't have any negative affects.
Supplicants can also be upgraded to check the NAIRealm. If the field does
not match the users realm, then th