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-Identity phase of the protocol is accepted, which clearly
make few
+ sense for accounting and authorization. Whilst the rlm_eap_tls
