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

[Arnaud Ebalard]

Hi,

Jouni Malinen <j at w1.fi> writes:

> On Sat, Apr 12, 2008 at 05:41:44PM +0200, Alan DeKok wrote:
>
>>   Yes, I would use the User-Name for VLAN assignment.  I would also use
>> check_cert_cn to be sure that they didn't lie about the User-Name.
>
> There should not really be any requirement for User-Name
> (EAP-Response/Identity) to match with CN in case of EAP-TLS..

+1

> The EAP-Response/Identity is mainly for routing and it is sent in
> clear, so requiring it to match with CN would prevent identity
> privacy. 

I agree with the routing part, i.e. the User-Name allows freeradius to
decide which specific authentication method should be used for that
user. 

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.

>>   Which is why it's there.  Honestly, I don't see why you're so shocked
>> about it.  You seem to be saying that check_cert_cn is a bad idea,
>> because you have to *use* it to prevent people from lying.
>
> But check_cert_cn is indeed a bad idea in many cases.. RFC 2716bis draft
> is changing the identity verification to "SHOULD NOT" require identities
> (EAP-Identity and CN) to be identical.. Identity from
> EAP-Response/Identity is mainly for routing purposes and things like
> VLAN selection should really use information from the client certificate
> (in case of EAP-TLS) instead.

+1

> If someone is willing to write a submission for this, it would be very
> useful to be able to use information from various certificate attributes
> to decide what to do with the request after the EAP-TLS authentication
> has been completed. This would make it possible to disable check_cert_cn
> and would even allow use of groups (i.e., not just list of every
> possible identity string) for VLAN assignment.

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.

- 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 -).

- 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. 

Alan already pointed possible leads (xlat and unlang) I will follow for
some of previous items.

a+