EAP-TLS Inner/Outer identity

[Keith Moores]

I'm trying to find a solution to a wireless authorization issue.

Background

When using EAP-TLS both Windows (XP/Vista) and Mac OS supplicants by  
default set the outer identity equal to the user certificate Subject  
Alternative Name - Principle Name (OID 1.3.6.1.4.1.311.20.2.3) when  
it exists (not the Common Name).  This is somewhat similar to S/MIME  
using the Subject Alternative RFC822 Name (not the Common Name).   
This is significant usability benefit as users don't have to enter a  
separated user name to connect, which in my experience a lot of  
supplicants require.

During authentication the outer identity becomes the User-Name in  
FreeRadius and can be used for authorization (such as LDAP).   
Independently the certificate (which contains the inner identity) can  
be validated.

We use client certificates for access to multiple services (web sites  
and more than one wireless networks), thus need the ability to  
control access to each independently.  i.e. One class of users does  
not have any access to a particular wireless network with their user  
certificate but does have access to another wireless network (and/or  
web resources) with their user certificate.  CRL are not the solution  
in this case as they invalidate the user certificate for all uses.

Problem

The outer identity can be set by the user to anything the user wants,  
meaning it shouldn't be trusted/used for an authorization lookup.  In  
FreeRadius it does not appear possible to directly lookup  
authorization based on the inner identity, only to check the inner  
identity Common Name against a the outer identity, i.e. check_cert_cn  
= %{User-Name}

Our Common Names are not unique (which seems typical of other CAs as  
well) so there may be two certs for different users that have the  
Common Name "John A. Smith" which is why our CA populates the Subject  
Alternative Name - Principle Name (among other fields) with the users  
unique user ID.
http://middleware.internet2.edu/hepki-tag/pki-lite/hepki-tag-pkilite- 
profile-current.html#PrincipalName
http://support.microsoft.com/default.aspx?scid=kb;en-us;281245

In Cisco ACS land we could accomplish this with "Certificate SAN  
Comparison"
http://www.cisco.com/en/US/products/sw/secursw/ps2086/ 
products_configuration_guide_chapter09186a0080721d80.html#wp999517

Questions

Is there a way to perform an authorization lookup based on the EAP- 
TLS inner identity Subject Alternative Name - Principle Name?

Any chance for adding support for checking the outer identity against  
the Subject Alternative Name - Principle Name, i.e. check_cert_san = % 
{User-Name}

I found this old comment in list archives, does the same answer still  
hold on access to other certificate fields?


> Alan DeKok freeradius-users at lists.freeradius.org
> Fri, 08 Apr 2005 12:46:31 -0400
>
> =?iso-8859-1?Q?Alejandro_Mart=EDnez_Marcos?= <almartinez at sgi.es>  
> wrote:
> >     I would need an option "check_cert_uid" instead of  
> "check_cert_cn",
> > because my client certificates don't have a cn.  Is it possible  
> at the
> > moment? In other case, how can we achieve it?
>
>   Source code edits.
>
>   The TLS module should really export a way to check all fields in the
> certificate, via something like %{tls:....}.  That way the
> "check_cert_foo" stuff could go away.
>
>   Alan DeKok.


Thanks in advance,
-Keith

------------------------------------------------------------------------
Keith Moores                                 <mailto:kmm6b at virginia.edu>
Network Systems
ITC-Communications and Systems Division
University of Virginia, ITC-2015 Ivy Rd            Phone  (434) 924-0621
Box 400324, Charlottesville, VA 22904-4324         Fax    (434) 982-4715