Check the subject and issuer in the EAP-TLS
Hello, as I have noticed there is no possibility to check the subject and issuer of the client certificate. My idea is to use EAP-TLS authN, but allow only some of certificates issued by concrete CA. Two options which are available in EAP-TLS config are not suitable for me. I don't want to revoke the certs and the RE cannot be also used. That's why I created small patch to the freeradius 1.1.0. I've added new option check_script in config of EAP-TLS, where can be defined path to the script or application which is executed after successuf TLS authentication. The script/application will recieve in environ variables request packet with two new value pairs: X509_SUBJECT and X509_ISSUER. The EAP-TLS module decide on the returned value of the script/app if the request will be discarded or allowed. I'm open for every remark and enhancement of this patch. I'm runnig patched freeradius in our organization and till now it works good. Patch is attached if anyone is interested. Best regards, Michal -- Michal Prochazka // michalp@ics.muni.cz Supercomputing Center Brno Institute of Computer Science Masaryk University Botanicka 68a, 60200 Brno, CZ CESNET z.s.p.o. Zikova 4, 16200 Praha 6, CZ
Michal Prochazka wrote:
I'm open for every remark and enhancement of this patch. IMHO, it is very breakable script: it compare only strings (issuer name, subject, etc), which can be forged easily. IMHO, we need to check sha1/md5 signatures of CA certificates, not strings.
-- // Lev Serebryakov
IMHO, it is very breakable script: it compare only strings (issuer name, subject, etc), which can be forged easily. IMHO, we need to check sha1/md5 signatures of CA certificates, not strings.
I don't agree with you. Freeradius checks that the certificate is issued by one of the CA defined in config of EAP-TLS. And then this script compare the subject, you cannot forged it. And of course this patch can be easily enhanced to export sha1/md5 signatures. This patch is made directly for our needs. We have autogenerated file which contains the subject names of allowed certificates. Our CA is part of EUGridPMA and their policy is that there cannot be two certificates with the same subject. -- Michal Prochazka // michalp@ics.muni.cz Supercomputing Center Brno Institute of Computer Science Masaryk University Botanicka 68a, 60200 Brno, CZ CESNET z.s.p.o. Zikova 4, 16200 Praha 6, CZ
Michal Prochazka wrote:
I don't agree with you. Freeradius checks that the certificate is issued by one of the CA defined in config of EAP-TLS. And then this script compare the subject, you cannot forged it. And of course this patch can be easily enhanced to export sha1/md5 signatures. Oh, I've missed your point, sorry. This patch is against using some (for example, e-mail signing) certificate (issued by proper CA!) as wireless client's one, am I right on second try? :)
-- // Lev Serebryakov
Oh, I've missed your point, sorry. This patch is against using some (for example, e-mail signing) certificate (issued by proper CA!) as wireless client's one, am I right on second try? :)
No :-) As I have said, this script is enhancement of the EAP-TLS authentication. Radius does usual TLS authenticatioin, user must have certificate issued by CA which is defined in freeradius in eap-tls configuration (you can use every certificate, you must have the CA certificate in path where freeradius searchs for CA certificates). After successful authentication this script gets the subject name and issuer and compare it against the list of allowed certificates. That's it:-) I have gathered some comments and there is another solution: In eap authentication phase after successful authentication put whole client certificate into the request packet and write the eap-tls authorize section where the script (defined in some configuration file) will be started and whole certificate will be passed to this script. Then the script can process whole client certificate and can decide on each field in the certificate. -- Michal Prochazka // michalp@ics.muni.cz Supercomputing Center Brno Institute of Computer Science Masaryk University Botanicka 68a, 60200 Brno, CZ CESNET z.s.p.o. Zikova 4, 16200 Praha 6, CZ
BTW, here is `CA_file' parameter in `tls' module, so CA certificate know to us. And we can check this CA without any external script
I don't understand what are you meaning with this? This patch doesn't check the CA. The check script is run after the successuf TLS authentication. -- Michal Prochazka // michalp@ics.muni.cz Supercomputing Center Brno Institute of Computer Science Masaryk University Botanicka 68a, 60200 Brno, CZ CESNET z.s.p.o. Zikova 4, 16200 Praha 6, CZ
Michal Prochazka wrote:
I'm open for every remark and enhancement of this patch.
Have you considered instead having the eap-tls module add a server-private config attribute e.g. EAP-TLS-Client-Cert-Subject EAP-TLS-Client-Cert-Issuer ...which would be a bit more general. If you wanted to run an external script then, you could do something like: authorize { preprocess eap files } and in /etc/raddb/users: DEFAULT EAP-TLS-Client-Cert-Subject *= ANY Exec-Program = "somescript" ...the script will then receive the attribute as an environment variable The major difficulty I can see with that is the cert isn't available until a few packets into the EAP exchange - that is, the first few packets won't have gone far enough into the TLS setup to have obtained the cert. Also, the EAP module doesn't actually *process* any data until the "authenticate" section, so if you had: Access-Request EAP-TLS client hello series of Access-Challenge EAP-TLS fragmented(server hello, server cert) Access-Request EAP-TLS send more series of Access-Request EAP-TLS fragmented(client cert, handshake) Access-Challenge EAP-TLS send more Access-Challenge EAP-TLS change cipher Access-Request EAP-TLS zero data Access-Accept ...only that last Access-Challenge would have a meaningful client cert CN/issuer and could thus be matched on. I don't know enough about TLS and EAP-TLS to be sure if we can guarantee there'll always be one packet which that attribute can match on. I suppose another option would be to have EAP-TLS to generate a "fake" inner request which is passed through the radius server much like PEAPs inner requests are, with User-Name as the CN and another attribute for Issuer. That would remove the ambiguity and provide a very flexible way for the server to do policy checks on all manner of cert attributes.
participants (3)
-
Lev A. Serebryakov -
Michal Prochazka -
Phil Mayers