-----Original Message-----
From: Emu <[email protected]> On Behalf Of Alan DeKok
Sent: 12 November 2019 16:32
To: Jan-Frederik Rieckers <[email protected]>
Cc: [email protected]
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.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
