Re: [Emu] Best practices for supplicants and authenticators

[Owen Friel (ofriel)]

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 

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[Alan DeKok]

On Nov 18, 2019, at 7:39 PM, Dan Harkins  wrote:
>>   What happens if the CA checks some things, and not others?
> 
>   Then it means the CA is certifying things it shouldn't.

  Well, that's what happens with most CA's.

>>   Define "validation" :)
> 
>   I'll pass on playing that game.

  We have a good "feel" for what validation means in casual conversation.  
We're less clear what it means as a *process*.

  How does a CA validate a field?  The answer is too often "it validates the 
field", which seems a bit circular.

  My point is that validation isn't black and white.  There are various kinds 
of validation, each of which give you different kinds of information.  My goal 
is to understand what those are, and to find out how we can use that 
information.  Your position seems to be "it's either perfectly validated or 
perfectly useless".

>>   My point for SSIDs is that validation means whatever we define it to mean. 
>>  So long as everyone agrees that the SSID field is a hint and is not 
>> validated by the CA, it's OK to use it.
> 
>   Use it how? What value do you put in an attribute that hasn't been 
> validated (and
> don't ask me what that word means since you used it)?

  RFC 4334 describes this in some detail.  See section 3 for discussion on 
SSIDs.

>>   In addition, CAs currently validate *control* of a domain.  But they don't 
>> (and can't) really validate *ownership* as such.  i.e. if I own a company, I 
>> can tell an employee to ask a CA for certificates for that domain.  He may 
>> be making that request, even if he doesn't "own" the domain.  He can 
>> convince the CA that he controls the domain.  I'm not sure how the CA would 
>> check that the owner of the domain has properly delegated the certificate 
>> request to the employee.
> 
>   Then what you can infer from a domain name in a certificate issued by such 
> a CA
> is that the holder of the corresponding private key controls that domain. 
> Nothing
> more, nothing less. But you can't infer anything from other attributes that 
> have not
> been validated (again, using a word you used yourself)

  Certificates contain serial numbers.  They haven't been validated by a CA.  
The lack of validation therefore means that you can't infer anything from that 
field?

  I would argue that you *can* make inferences from that field.

>>   The same applies for telephone numbers.  Do CAs call the numbers?  Do they 
>> check that the person answering is the same person who made the request?  
>> Maybe.
> 
>   You tell me if a CA "calls the numbers". If it doesn't then what can you 
> infer
> from a telephone number in a certificate it signs?

  This isn't difficult.  It means that the certificate owner has claimed he can 
be reached at that number.  And the CA has signed the statement, agreeing that 
it's a statement made by the certificate owner.

>>   These issues can't be answered with simple black & white statements.  If 
>> the data in a certificate is imperfect, it might still be useful.
> 
>   OK, convince me of its utility.

  See RFC 4334 and its discussion of SSIDs.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu