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.
On 07.08.20, 07:45, "Fabian Mauchle" <fabian.mauchle(a)switch.ch> wrote:
It took way too long, but finally I can announce the release of radsecproxy-1.8.0.
Oops... of course radsecproxy-1.8.2 was released!
--
Fabian
Dear radsecproxy community,
It took way too long, but finally I can announce the release of radsecproxy-1.8.0. Get it on https://radsecproxy.github.io
It's just some bugfixes for now, but 1.9 is already in the works and hopefully will be ready in the not too distant future.
A big thank you to all contributors!
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
fabian.mauchle(a)switch.ch, http://www.switch.ch
