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@lists.freeradius.org Fri, 08 Apr 2005 12:46:31 -0400
=?iso-8859-1?Q?Alejandro_Mart=EDnez_Marcos?= <almartinez@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@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