Check the subject and issuer in the EAP-TLS

[Phil Mayers]

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.