(RADIATOR) Server and Client verification in RADSEC

[Mike McCauley]

On Tuesday 22 November 2005 20:39, Jan Tomasek wrote:
> Hello,
>
> sorry for being that straightforward, but actual code code in Radiator
> handling RADSEC server/client verification is completly wrong.
>
> It's needed to start use subjectAltName certificate at first place and
> forgot any hostlookup by DNS. I will try to describe how it should be done:

Both client and server use TLS_ExpectedPeerName as a pattern to check the CN 
of the certificate from the peer.

The _default_ TLS_ExpectedPeerName is the DNS name or IP address of the peer. 
As you say, client and server should know the names of the certificates of 
their peers, and the certificates must at least be issued by a CA whose root 
certificate is in Radiator.
Therfore I would expect you to set TLS_ExpectedPeerName to such a name or 
pattern.

TLS_ExpectedPeerName only defaults to the DNS name or IP address of the peer, 
because we thought that was the most reasonable thing to do.

Does anyone else have views on this topic?

Cheers.


>
> Server side
> ===========
>  - server trust to it's store of certs and verify client by one
>    of posible ways:
>      - no verification (not all client's necesary need cert)
>      - accept client if it has certificate signed by one
>        of trusted CA's (most common way)
>      - accept only client whith certificate stored in cert store
>
> that above is minimum set of needed features. Note here is no reverse
> lookup in insecure DNS. It's not needed trust lay on PKI!
>
> Client side
> ===========
>  - client has also it's store of certs and has same options to verify
>    server's certificate as server itself.
>  - BUT! client knows to what server it is connecting (given from admin
>    by Host directive in <AuthBy RADSEC> section, or by an <unspecified>
>    peer location service), so client can check if server has in
>    certificate expected name.
>
>    That check is done against values in dNSName of subjectAltName
>    extension. There is posible that in dNSName is also * as wild card.
>    For example: *.cesnet.cz is good for www.cesnet.cz, foo.cesnet.cz but
>    not for cesnet.cz.
>
>    If there is no subjAltName than you do check agains CN, but using CN
>    for this purpose is deprecated!
>
>    If there is iPAddress in subjAltName you have check that IP address
>    too. This apply to server also.
>
> Maybe some variaton to "TLS_ExpectedPeerName" might be interesting. But
> that regular expression should be better to applied to whole normalized
> subject. But I suggest just to drop this and provide hook to SSL
> verication callback from OpenSSL.
>
> Of course both client and server have to check CRL - I know there is
> posibility of providing TLS_CRLFile to Radiator, so this seams to be
> good enouht. I will maybe provide coments about this later.
>
> For exact informations about this I suggest to reading RFC 2595 and 2818:
> 	http://www.faqs.org/rfcs/rfc2595.html
> 	http://www.faqs.org/rfcs/rfc2818.html
>
> If you will need more info, feel free to ask. Will do my best to help
> you implement it in better way.
>
> 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.