Hello!
right now I'm looking at a use case of RADIUS/TLS peer connections which is a bit different from standard. I wonder if someone could comment on the feasilibility/desirability if one uses certificates as sketched below.
The idea is to cram EAP-specific authorization information into the certificates. They do not only contain the FQDN of the server one connects to, but also verifies whether that same server is authorized to authenticate certain realms. Both of the information elements (FQDN and NAI realm list) are to be included in the same certificate by the server.
The FQDN of the server itself would be in the Subject (CN=server.fqdn.example); the list of authoritative realms would be in an arbitrarily long set of subjectAltName:DNS extensions.
The client, when presented such a certificate from a server it connects to, should always exclusively look at the CN and abort the connection attempt when the server's name doesn't match the expectation (i.e. the discovered hostname from a NAPTR discovery). Notably, if the FQDN happens to be in the sAN:DNS list, it should still disconnect. CN is the only field that counts.
Only if the CN matches, the next step would be to check the realm that was used as a starting point for NAPTR discovery, and verify that this realm is one of the sAN:DNS in the certificate. Again, the client should disconnect if that is not true. [1]
Example:
realm to be authenticated = userrealm.example
NAPTR for userrealm.example yields FQDN server.example.com
Client connnects to server.example.com
Does server certificate have CN=server.example.com ? If not, disconnect.
Does server certificate have a sAN:DNS=userrealm.example ? If not, disconnect.
Still connected? Send RADIUS request through this connection.
Is this kind of behaviour supported in radsecproxy at the present time? Could it?
Greetings,
Stefan Winter
[1] This behaviour is "almost" like the semantically cleaner behaviour of RFC7585 - except that the list of realms is in a dedicated certificate extension called NAIRealm in the RFC, while here one would overload sAN:DNS instead.
Hi Stefan,
On 20.08.20, 17:24, "Stefan Winter" stefan.winter@restena.lu wrote: right now I'm looking at a use case of RADIUS/TLS peer connections which is a bit different from standard. I wonder if someone could comment on the feasilibility/desirability if one uses certificates as sketched below.
The idea is to cram EAP-specific authorization information into the certificates. They do not only contain the FQDN of the server one connects to, but also verifies whether that same server is authorized to authenticate certain realms. Both of the information elements (FQDN and NAI realm list) are to be included in the same certificate by the server.
I'll answer the important questions first:
Is this kind of behaviour supported in radsecproxy at the present time?
No, this is currently not supported. (for dynamic discovery that is. You can always require a specific sAN to be present for static servers, but that's not the point here)
Could it?
Yes I think it would be feasible to implement this.
The FQDN of the server itself would be in the Subject (CN=server.fqdn.example); the list of authoritative realms would be in an arbitrarily long set of subjectAltName:DNS extensions.
The client, when presented such a certificate from a server it connects to, should always exclusively look at the CN and abort the connection attempt when the server's name doesn't match the expectation (i.e. the discovered hostname from a NAPTR discovery). Notably, if the FQDN happens to be in the sAN:DNS list, it should still disconnect. CN is the only field that counts.
I'm very skeptical about this point. I can't point to any RFC or so, but my gut-feeling says that sAN:DNS is used very often for multi-domain certificates. Not allowing multi-domain certificates would violate user expectations, and might also exclude some use-cases. As you said yourself, RFC7585 provides a semantically cleaner behavior. What would be the argument against using this? In terms of implementation, this wouldn't be that much different. As it happens, I'm already looking into implementing further sAN checks (#43, #45).
Only if the CN matches, the next step would be to check the realm that was used as a starting point for NAPTR discovery, and verify that this realm is one of the sAN:DNS in the certificate. Again, the client should disconnect if that is not true. [1]
Checking the realm against sAN:DNS is a possibility, but not sure if this would create further issues if also used for multi-domain certificates.
Best regards, Fabian
-- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39
Hi Stefan
On 2020/08/20 17:24, Stefan Winter wrote:
The FQDN of the server itself would be in the Subject (CN=server.fqdn.example);
Simply looking at the subject breaks the case where a given server may have multiple valid FQDNs (i.e. the use case that subjectAlternativeName:dNSname is meant to solve), which I suspect is a fairly common use case.
For instance, we currently have certificates with subjectAlternativeName:dNSname in them:
Subject: DC = net, DC = geant, DC = eduroam, C = ZA, O = Tertiary Education and Research Network of South Africa, CN = flr-cpt.eduroam.ac.za X509v3 Subject Alternative Name: DNS:flr-cpt.eduroam.ac.za, DNS:flr-jnb.eduroam.ac.za, DNS:eduroam-cpt-01.eduroam.ac.za, email:eduroam@tenet.ac.za
This is because we run a high-availability configuration with the FLR servers' IP addresses bound on loopbacks and able to swing between physical instances. The three DNS sANs are the canonical name of this instance (matching the subject, in accordance with public CA best practices), the canonical name of the other instance that we act as standby for, and the FQDN of the underlying host.
I see a similar thing in the hosted IdP:
Subject: DC = net, DC = geant, DC = eduroam, C = NL, O = GEANT Association, CN = auth-1.hosted.eduroam.org X509v3 Subject Alternative Name: DNS:auth-1.hosted.eduroam.org, DNS:auth-2.hosted.eduroam.org, email:eduroam-ot@lists.geant.org
where the same certificate is presented whether I connect to auth-1 or auth-2.
Whether or not this is right for RadSec or indeed for the specific case of eduroam, it certainly matches user expectations which is what Fabian was getting at here:
I'm very skeptical about this point. I can't point to any RFC or so, but my gut-feeling says that sAN:DNS is used very often for multi-domain certificates. Not allowing multi-domain certificates would violate user expectations, and might also exclude some use-cases.
My gut feeling is that overloading the semantics of sAN:dNSname in anything other than very controlled circumstances with a very small community will lead to confusion, because the default interpretation of a newish person will be to match what web browsers do.
[1] This behaviour is "almost" like the semantically cleaner behaviour of RFC7585 - except that the list of realms is in a dedicated certificate extension called NAIRealm in the RFC, while here one would overload sAN:DNS instead.
I'm interested in the use case for overloading sAN:dNSname rather than using sAN:otherName:NAIRealm?
- Guy
-
Fabian Mauchle -
Guy Halse -
Stefan Winter