[radsecproxy] RADIUS/TLS dynamic discovery peer validation extravaganza

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.