Re: Certificate patches for EAP TLS module
I think I understand the concern as to part 2 of Michael's patch proposal, but would that apply to incorporating part 1, extending the "check_cert_cn" functionality? Would it be useful rework and submit a patch that just addressed that? A first step? -Keith On May 18, 2007, at 1:17 PM, Alan DeKok wrote: > Keith Moores wrote: >> In trying to come up with a our own solution to the same problem I >> discovered the following previous patch proposal by Michael Joosten >> from 2005. >> >> Incorporating this functionality would be greatly appreciated: > ... >> I couldn't find any comments on this (other than another person >> interested in seeing it adopted), any chance this could make it into >> a future version? 2.0? > > I had some discussion with him off-list at the time. My main > concern > is that it always adds these attributes, even if they're not needed. > > I would prefer that the patch register dynamic callbacks for these > attributes, so that they cost nothing if they're not used. > > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ > users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Certificate patches for EAP TLS module
In trying to come up with a our own solution to the same problem I
discovered the following previous patch proposal by Michael Joosten
from 2005.
Incorporating this functionality would be greatly appreciated:
> configurable checking of user identity (i.e. what the supplicant
> tells via EAP Identity) and the actual client/user certificate.
I couldn't find any comments on this (other than another person
interested in seeing it adopted), any chance this could make it into
a future version? 2.0?
-Keith
> From [EMAIL PROTECTED] Thu Mar 10 05:16:40 2005
> From: [EMAIL PROTECTED] (Michael Joosten)
> Date: Thu, 10 Mar 2005 06:16:40 +0100
> Subject: certificate patches for EAP TLS module, plus some questions..
> Message-ID: <[EMAIL PROTECTED]>
>
> This is a multi-part message in MIME format.
> --010606020309030200040704
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Hello,
>
> due to internal demand I'm providing a patch that provides the
> following
> new functionality for EAP TLS:
>
> 1) configurable checking of user identity (i.e. what the supplicant
> tells via EAP Identity) and the actual client/user certificate.
> There is
> already a check for commonName, but in many cases "Joe User" isn't
> unique enough - and some PKIs even uses different X509 attributes,
> like
> those who want to implement a Microsoft SmartCard Login compatible
> infrastructure. And yes, stuff from Subject Alternative Name is also
> supported.
>
> This patch is implemented as additional config options for the EAP TLS
> module section in eap.conf, providing plain text names for attributes
> and even search lists, in case two different versions/generations of
> user certificates must be supported:
>
> use_as_cert_cn = email,UPN,TCGID,CN
> # search the user cert for email (both in Subject Alt. Name and
> Subject), Microsoft Universal Principal Name, Trust Center Global ID
> (Guardeonic thingy), and commonName, in this order and return first
> hit.
>
> check_cert_cn = %{User-Name}
> # kept from previous impl., uses CN if use_as_cert_cn is not set,
> otherwise whatever was found above first
>
> 2) for accounting and informing the gateway/NAS, the most relevant
> X509
> attributes of a verified user certificate can be exported as AV pairs.
> Similar to 1), a list can be specified or all defined attributes are
> 'exported':
> export_cert_attributes = *
> - or -
> export_cert_attributes = CN,email,UPN,TCGID
>
> This will end up as
> UserCert-CN = "Joe User"
> UserCert-Email = "[EMAIL PROTECTED]"
> UserCert-UPN = "[EMAIL PROTECTED]"
> UserCert-TCGID = "USERJ0001234"
>
> and some other usual X.509 attributes. If I'm not mistaken, this has
> been requested a few times in the mailing lists, hasn't it ?
>
> These avpairs are created at the end of eaptls_authenticate() and
> added
> to the reply list - I hope that's the right place?!
>
> My question is now under which namespace these attributes should go.
> They are not really company-specific and could go into the common
> range
> < 255, but there are currently about 20 defined. I could also use some
> Siemens enterprise ID to fix them, though. Currently, I added a new
> dictionary file (dictionary.siemens) and put them there under some
> Siemens IANA enterprise number.
>
> And the prefix 'UserCert-' is also changeable, by using, e.g.,
> cert_attributes_prefix = X509-Attr-
>
> The patch adds a new file in the rlm_eap_tls directory and maked some
> minor mods to the existing files, and is therefore completely
> restricted
> to rlm_eap_tls. Except of the changes in share/dictionary and
> share/dictionary.siemens and an update of the EAP TLS documentation
> in doc/rlm_eap.
>
> Adding additional X509 attributes is very simple, usually just adding
> them to an internal table in cert.c is sufficient. With some more
> work/time, this mapping table could even be read from a
> configuration file.
>
> Looking forward for some comments,
>
> Michael
>
>
>
>
>
> --010606020309030200040704
> Content-Type: text/plain;
> name="freeradius102-patch1.txt"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename="freeradius102-patch1.txt"
>
> diff -urN -x '*~' ../orig/freeradius-1.0.2/doc/rlm_eap ./doc/rlm_eap
> --- ../orig/freeradius-1.0.2/doc/rlm_eap Tue Dec 16 04:50:34 2003
> +++ ./doc/rlm_eap Wed Mar 9 00:35:59 2005
> @@ -155,6 +155,96 @@
>
>EAP-SIM will send WEP attributes to the resquestor.
>
> +EAP TLS server
> +
> + EAP TLS, TTLS and PEAP use public key based certificates for the
> server,
> + while TLS even uses them for authentication of the client (aka
> + supplicant). Consequently, TLS is usually employed for
> deployments that
> + intend or already have an organization-wide PKI (Public Key
> + Infrastructure). Currently, provided that the supplicant (user
> client)
> + has a valid certificate, ANY identity that it provides in the
> + EAP-Id
Re: free radius 1.1.6 -eap-tls authentication
CRL's are not the best way to conduct authorization for EAP-TLS,
their control is too coarse when the goal is to enable/disable the
use of valid certificates use for different purposes and don't let
you assign other authorization info like what VLAN a user should be
assigned to.
The only option that currently works for access to real authorization
with EAP-TLS is to use the:
check_cert_cn = %{User-Name}
option in the tls section of eap.conf so you can be sure the outer
identity (User-Name) matches the inner identity in the certificate,
its then valid to check User-Name against another source for
authorization. If you don't perform this check you can't be sure the
outer identity (User-Name) has any relation to the the identity
represented by the certificate. This is only an option if your user
certificates contain the unique "user id" you will lookup for
authorization in the Common Name field, not in the Subject
Alternative Name - Principle Name field (which many organizations use
as their User certificate Common Names are not unique user identifiers).
-Keith
On May 17, 2007, at 1:49 AM, Alan DeKok wrote:
> [EMAIL PROTECTED] wrote:
>> 1 Where will i find the log of the authentication like
>> username login ok...or login failed
>
> It's in "radius.log"
>
>> 2 One user\'s certificate if I installed in other user\'s laptop
>> it works.I want one user certificate should work in one laptop only.
>
> There's no real way of doing that. You *could* put the MAC address
> into the certificate, and have the RADIUS server check that against
> the
> MAC address in the RADIUS request, but there's no guarantee that will
> work. It can be spoofed, and it can break valid configurations.
>
>> 3 In users file i havn\'t added any certificate name as it is
>> eap-tls.So if i want to remove the user from n/w i don\'t have
>> control.Is ther any method like i can add the certificate names in
>> users file then only it should work
>
> Certificate revocation lists.
>
> Alan DeKok.
> --
> http://deployingradius.com - The web site of the book
> http://deployingradius.com/blog/ - The blog
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/
> users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-TLS Inner/Outer identity
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?= <[EMAIL PROTECTED]>
> 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:[EMAIL PROTECTED]>
Network Systems
ITC-Communications and Systems Division
University of Virginia, ITC-2015 Ivy RdPhone (434) 924-0621
Box 400324, Charlottesville, VA 22904-4324 Fax(434) 982-4715
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
How to handle EAP/LDAP or files with same server
I'm trying to finally rid myself of Cisco ACS with FR 1.1.3 and
mostly having great success (performance is so much better!) but
can't seem to figure out how to handle two different types of
wireless authentication in separate non-overlapping ways.
Case 1 is EAP/TLS where user ID (email address from cleint cert) is
also looked up via LDAP.
Case 2 is MAC authentication using the users file.
I have both of these working with one issuse, MACs that are not in
the users file are being sent to LDAP server adding unnecessary load.
authorize {
preprocess
files
ldap {
notfound = return
}
eap
}
The solution I can think of is to only send user name's that are
email addresses to ldap. Is this something that can be done with a
proxy conf and realms? I'm having trouble understanding if/how those
can influence the authorize section.
Thanks,
-Keith
--------
Keith Moores <mailto:[EMAIL PROTECTED]>
Network Systems
ITC-Communications and Systems Division
University of Virginia, ITC-2015 Ivy RdPhone (434) 924-0621
Box 400324, Charlottesville, VA 22904-4324 Fax(434) 982-4715
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
LDAP authorization for EAP-TLS authentication
I'm trying to understand the relationship between the modules in the
authorize {} and authenticate {} sections and how it relates to the
directives defined in users. EAP-TLS works fine, but I can't seem to
figure how to get make the ldap authorization reject a user.
DEFAULT Auth-Type := eap, Autz-Type := ldap
authorize{
preprocess
ldap
eap
}
authenticate {
eap
}
ldap {
server = "our-server.itc.virginia.edu"
identity = "uid=uva-all,ou=ITC-User,ou=It,o=University of
Virginia,c=US"
password = "our-password"
basedn = "o=University of Virginia,c=US"
filter = "(wirelessAccess=%{Stripped-User-Name:-%{User-Name}})"
base_filter = "(objectclass=Person)"
start_tls = no
access_attr = "wirelessAccess"
ldap_connections_number = 5
timeout = 4
timelimit = 3
net_timeout = 1
access_attr_used_for_allow = yes
}
In the ldap server logs show multiple queries, which are not
returning anything.
This can be confirmed with:
ldapsearch -b "o=University of Virginia,c=US" wirelessAccess=kmm6b
wirelessAccess
which returns nothing. If nothing is returned shouldn't the
authorization fail? I'm missing something, hopefully not too obvious...
Keith Moores <mailto:[EMAIL PROTECTED]>
Network Systems
ITC-Communications and Systems Division
University of Virginia, ITC-2015 Ivy RdPhone (434) 924-0621
Box 400324, Charlottesville, VA 22904-4324 Fax(434) 982-4715
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
