(RADIATOR) Server and Client verification in RADSEC

[Jan Tomasek]

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:

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
-- 
--------------------------------------------------------------
Jan Tomasek aka Semik           work: CESNET, z.s.p.o.
http://www.tomasek.cz/                Zikova 4, 160 00 Praha 6
                                      Czech Republic
phone(work): +420 2 2435 5279         http://www.cesnet.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://www.open.com.au/pipermail/radiator/attachments/20051122/3988109c/attachment.bin>