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.