9:24 p.m.
Hi Stefan,
On 20.08.20, 17:24, "Stefan Winter" <stefan.winter(a)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