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

["Owen Friel (ofriel)" <[e-mail]>]

-----Original Message-----
From: Emu <[e-mail]> On Behalf Of Alan DeKok
Sent: 12 November 2019 16:32
To: Jan-Frederik Rieckers <[e-mail]>
Cc: [e-mail]
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

<snip>

> 
> The Problem with dNSNames is that they are also used in other contexts 
> (mainly HTTPS).

  They're also domain names, not realms.  A particular certificate may be valid for authenticating uses to the realm "example.org".  That same certificate may not be valid for the main web site for "example.org".

  This means that domain names are a hint, but not authoritative.  Only the NAIRealm field would be authoritative.  i.e. "this certificate really is for users authenticating to a realm".

> There would be the possibility to define a specific prefix to bind it 
> to a Realm without having the certificate being valid for the HTTPS 
> host (e.g. eap-tls.uni-bremen.de for the realm
> uni-bremen.de) but I don't see the advantage in that.
> This will probably don't really lead to a change in the supplicants 
> implementations.

  A common short-hand is for certificates to use the "radius" subdomain.  e.g. "radius.example.org".  While not perfect, it's something.

[ofriel] this seems like something reasonable, but that's more a general deployment recommendation: ensure that the identity/realm of EAP servers is different from the identity/domain of webservers within an org. Therefore in the absence of an NAIRealm or id-kp-eapOverLAN extension in a cert,  clients can still distinguish between the two. Users point their Browser clients point to 'example.org' and wi-fi supplications are configured to look for 'radius.exampe.org'.

The supplicant logic for verifying EAP server identity (assuming it already knows the root CA and a realm/domain string) could be check for NAIRealm first, then check for id-kp-eapOverLAN, then check for a dnsName.