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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
