Using X.509 Cert. subject and issuer for authorization with EAP-TLS

[Alan DeKok]

Arnaud Ebalard wrote:
> Regarding the identity privacy argument: usually, the certificate leaks
> more information (DN, issuer, ...) than the User-Name itself. As it sent
> in clear during the TLS handshake, there is simple way to provide
> identity privacy. If someone has access to the EAP-Response/Identity, it
> also has access to client and server certificates.

  That's what I had thought...

> IMHO, the design is not that easy to deal with:
> 
> - this basically imply doing an additional step of authorization *after*
>   authentication, which is not the way freeradius expects it to be.

  No.  The "post-auth" section exists for precisely that purpose.

> - TLS session context is freed at the end of authentication. Making
>   associated information available after that point will probably
>   require extracting them during authentication (in cbtls_verify() in in
>   rlm_eap_tls.c for instance) and store them somewhere. The "somewhere"
>   part is still unknown to me -).

  Yes.  But the SSL context can be removed from the EAP handler, and
placed elsewhere.  See request_data_add() and request_data_get().  This
can make the SSL context available until the current request has
finished being processed.

> - elements extracted from the TLS session (including certificates info)
>   are not RADIUS attributes. Should they be seen by the administrator as
>   radius attributes to make their use transparent? It looks like a
>   hack. 

  That's what xlat is for.  %{Certificate:foo} can be dynamically
expanded to the relevant field of the certificate.

  These changes are probably only about 300 lines of code.  Most of that
will be the parsing of the certificate field names, and calling of the
correct OpenSSL function.

  Alan DeKok.