(RADIATOR) Server and Client verification in RADSEC

[Mike McCauley]

Hello all,

After some further discussion with Jan, the RadSec certificate validation has 
been finetuned in the latest patch set. Here is the description from the 
reference manual:

If a peer presents a certificate (TLS_RequireClientCert), then it is always 
validated using the peer certificate issuer's Root Certificate (see 
TLS_CAFile or TLS_CAPath) and any certificate revocation list (CRL) for the 
certificate's issuer (see TLS_CRLCheck, TLS_CRLFile). If that is successful, 
the contents of the peer certificate are checked:

In the RadSec server the client certificate is examined. It is accepted if:

the certificate contains a subjectAltName extension of type IPADDR that 
matches the client's IP address or,
there were no subjectAltName extensions, but the certificate Subject contains 
a Common Name (CN) that matches the client's IP address or,
the certificate Subject matches the TLS_ExpectedPeerName pattern.

In the RadSec client, the server certificate is examined. It is accepted if:

the certificate contains a subjectAltName extension of type IPADDR or DNS that 
matches the Host name used to connect to the server or,
there were no subjectAltName extensions, but the certificate Subject contains 
a Common Name (CN) that matches the Host name used to connect to the server 
or,
the certificate Subject matches the TLS_ExpectedPeerName pattern.

On Thursday 24 November 2005 17:47, Jan Tomasek wrote:
> Hello Mike,
>
> > Improvements to peer certificate verification for RadSec connections.
> >   The peer IP address (or hostname if resolvable) is verified against
> >   the certificate CNs, or against the certificate subjectAltNames. Exact
> > [...]
>
> Thanks for your work! I admire how fast you did it. But that still is
> not right. Please forgot about DNS. Real life example:
>
> My institution level radius server is named radius1.cesnet.cz but that
> is just CNAME to ldap1.cesnet.cz. Radiator ofcourse got certificate with
> radius1.cesnet.cz. If this sever will be connecting to RADSEC server:
>
>  - sever do accept and see IP => 195.113.144.226
>  - reverse IP to hostname => ldap1.cesnet.cz
>  - check of dNSName in certificate => client (radius1) refused
>
> that is not good. Server and Client can't use DNS as source of any
> autoritative information about peer. Identity of both of them is assured
> by signing CA.
>
> If you have more questions, not answered by my first mail please feel
> free to ask. I will try to provide some more real examples to show that
> those guys who were designing this and who write that RFC did realy good
> work.
>
> PS: I will be today offline, but I will try to answer at night.
>
> Best regards

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.