[RADIATOR] RADIUS/TLS dynamic discovery peer validation extravaganza

[Stefan Winter]

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 Radiator 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20200820/9076de68/attachment.sig>