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