February 2012 - Freeradius-Devel - lists.freeradius.org

default virtual server config
by Alan Buxey 13 Feb '12

13 Feb '12

hi, the recent dictionary fix and push to repository reminded me of a small quirk with the current sites-available/* provided virtual servers...currently both the 'local test' listener in inner-tunnel and the listener in status server are using the same port 18120 - thus, should anyone just enable these default servers at the same time, then the daemon wont start. suggest that one of these ports (status VS?) is changed to another port eg 19120 ? alan

2 1

EAP-Message incorrectly decoded as LEAP?
by Stefan Winter 13 Feb '12

13 Feb '12

Hi, I've just set up a new 2.1.12 that supports only EAP-TLS & EAP-TTLS. I ran a blind-test with radtest (EAP-MD5 requested), and got: Sending Access-Request packet to host 127.0.0.1 port 1812, id=88, length=0 User-Name = "foo(a)ltett.lu" User-Password = "bar" NAS-IP-Address = 158.64.1.155 NAS-Port = 123 Message-Authenticator = 0x00 EAP-Code = Response EAP-Type-Identity = "foo(a)ltett.lu" EAP-Message = 0x0257001101666f6f406c746574742e6c75 Received Access-Challenge packet from host 127.0.0.1 port 1812, id=88, length=64 EAP-Message = 0x015800061520 Message-Authenticator = 0x735a717844469d67a2215716e090d9e2 State = 0x02e3245002bb31c7ca78f83bc6164863 EAP-Id = 88 EAP-Code = Request EAP-Type-LEAP = 0x20 The last line speaking about LEAP, which was a surprise. Decoding the EAP-Message from the server, the request payload is EAP-Type 0x15 - EAP-TTLS, just as expected. So no real problem, just a source of confusion... why does radtest decode things as EAP-Type-LEAP here? Maybe something wrong in the dictionary.freeradius.internal: # these are PW_EAP_X + 1280 ATTRIBUTE EAP-Type-Identity 1281 string ATTRIBUTE EAP-Type-Notification 1282 string ATTRIBUTE EAP-Type-NAK 1283 string ATTRIBUTE EAP-Type-MD5 1284 octets ATTRIBUTE EAP-Type-OTP 1285 string ATTRIBUTE EAP-Type-GTC 1286 string ATTRIBUTE EAP-Type-TLS 1297 octets ATTRIBUTE EAP-Type-SIM 1298 octets ATTRIBUTE EAP-Type-LEAP 1301 octets ATTRIBUTE EAP-Type-SIM2 1302 octets ATTRIBUTE EAP-Type-TTLS 1305 octets ATTRIBUTE EAP-Type-PEAP 1309 octets This gives LEAP 21 = 0x15 (which is actually TTLS!), and TTLS 25 =0x19 (which is actually PEAP!), and PEAP 29 = 0x1D (which is actually EAP-MSCHAPv2!) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473

2 3

error loading shared libraries - BOILER=yes
by Matthew Newton 11 Feb '12

11 Feb '12

Hi, HEAD of master, building with BOILER=yes (without BOILER=yes is fine), I get: freeradius-server$ echo BOILER=yes >> Make.inc.in freeradius-server$ ./configure --prefix=/opt/fr3 freeradius-server$ make freeradius-server$ build/bin/radiusd -X FreeRADIUS Version 3.0.0, for host x86_64-unknown-linux-gnu, built on Feb 11 2012 at 02:40:47 Copyright (C) 1999-2009 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License v2. Errors reading /opt/fr3/etc/raddb: No such file or directory freeradius-server$ build/bin/relink/radiusd -X build/bin/relink/radiusd: error while loading shared libraries: libfreeradius-radius.so: cannot open shared object file: No such file or directory ...OK - probably looking in /opt/fr3/lib freeradius-server$ make install ... freeradius-server$ build/bin/radiusd -X ...as above, OK freeradius-server$ build/bin/relink/radiusd -X ...also OK - makes sense, now installed. freeradius-server$ /opt/fr3/sbin/radiusd -X ...also OK freeradius-server$ cd /opt/fr3/sbin sbin$ ./radiusd -X ./radiusd: error while loading shared libraries: build/lib/relink/.libs/rlm_acctlog.so: cannot open shared object file: No such file or directory ... not good. The problem seems to be in the final 'gcc -rdynamic -o build/bin/relink/radiusd' command - if you remove all the many ' -Wl,-rpath=/opt/fr3/lib build/lib/relink/.libs/rlm_acctlog.so' arguments and run manually, then copy the resulting binary to the correct location, all is fine. The dynamic libs seem to be being added to gcc by $${${1}_R_PRLIBS} in scripts/libtool.mk:106, and previously :205, but before that I get a bit lost :-) Any ideas? Thanks, Matthew -- Matthew Newton, Ph.D. <mcn4(a)le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp(a)le.ac.uk>

2 2

I only see a old draft: Certificate Based Roaming.
by Brivaldo Junior 11 Feb '12

11 Feb '12

Hi, I really don't know and not find any information about certificate-based roaming (unless on draft[1]) on FreeRadius. Exist support for this kind of auth? [1] http://tools.ietf.org/html/draft-ietf-roamops-cert-01 If this is the wrong mailing lisft for this question, sorry I will try on another more appropriate. Best regards, Brivaldo Jr

2 1

Checking TLS-Cert-* and and accept/reject based on them
by Matthew Newton 10 Feb '12

10 Feb '12

Hi, An question came up recently on freeradius-users whether it was possible to reject a request based on the TLS-Client-Cert-* type attributes. The reply being that it would be quite hard to allow these checks to happen in the authorize section of the code. I had a look at doing that, but it does seem pretty nasty, as it would involve doing EAP-TLS things at a different place from, say PEAP or TTLS. At least, from what I could tell. However, I looked at and implemented a different solution, which seems to work really well. Taking ideas from inner-tunnels and the SoH check method, I added a virtual_server option to the tls configuration. The rlm_eap_tls code then, just before returning success, runs through this virtual server (if given) allowing it to check the TLS-Cert* vps, and reject if it wants to based on them. It turns out to be a pretty small patch, and the code path isn't touched at all if the virtual_server option is not set. I've tested with EAP-TLS and PEAP/EAP-TLS, and both work well. I think the next step would be to move the client certificate validation, ocsp and other checks as 'modules' in this virtual server, but that looks a bit harder as they are done in a openssl callback function (cbtls_verify IIRC) - but may not be past the realms of possibility. Patch below, and also pushed to github: https://github.com/mcnewton/freeradius-server/commit/fbee1e9b4ce93c15d0f074… Comments? Cheers, Matthew >From fbee1e9b4ce93c15d0f074ad3fdfb71ba095a4ed Mon Sep 17 00:00:00 2001 From: Matthew Newton <mcn4(a)leicester.ac.uk> Date: Thu, 2 Feb 2012 16:00:37 +0000 Subject: [PATCH] Add virtual-server option for EAP-TLS to allow certificate field checks Normally attributes such as TLS-Client-Cert-Common-Name can be seen in Post-Auth only, which is too late to act if the return to the client should be changed. This code adds a virtual-server option to EAP-TLS to allow these values to be examined, and the return status updated accordingly. --- raddb/eap.conf | 8 ++ raddb/sites-available/check-eap-tls | 54 +++++++++++++++ .../rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c | 69 +++++++++++++++++++- .../rlm_eap/types/rlm_eap_tls/rlm_eap_tls.h | 2 + 4 files changed, 132 insertions(+), 1 deletions(-) create mode 100644 raddb/sites-available/check-eap-tls diff --git a/raddb/eap.conf b/raddb/eap.conf index 087f7f7..81d9074 100644 --- a/raddb/eap.conf +++ b/raddb/eap.conf @@ -291,6 +291,14 @@ ecdh_curve = "prime256v1" # + # As part of checking a client certificate, the EAP-TLS + # sets some attributes such as TLS-Client-Cert-CN. This + # virtual server has access to these attributes, and can + # be used to accept or reject the request. + # + # virtual_server = check-eap-tls + + # # Session resumption / fast reauthentication # cache. # diff --git a/raddb/sites-available/check-eap-tls b/raddb/sites-available/check-eap-tls new file mode 100644 index 0000000..15dc628 --- /dev/null +++ b/raddb/sites-available/check-eap-tls @@ -0,0 +1,54 @@ +# This virtual server allows EAP-TLS to reject access requests +# based on some certificate attributes. + +# Value-pairs that are available for checking include: +# +# TLS-Client-Cert-Subject +# TLS-Client-Cert-Issuer +# TLS-Client-Cert-Common-Name +# TLS-Client-Cert-Subject-Alt-Name-Email +# +# To see a full list of attributes, run the server in debug mode +# with this virtual server configured, and look at the attributes +# passed in to this virtual server. + +server check-eap-tls { + + +# Authorize - this is the only section required. +# +# To accept the access request, set Auth-Type = Accept, otherwise +# set it to Reject. + +authorize { + if ("%{TLS-Client-Cert-Common-Name}" == "client.example.com") { + update config { + Auth-Type = Accept + } + } + else { + update config { + Auth-Type = Reject + } + update reply { + Reply-Message = "Your certificate is not valid." + } + } + +# if ("host/%{TLS-Client-Cert-Common-Name}" == "%{User-Name}") { +# update config { +# Auth-Type = Accept +# } +# } +# else { +# update config { +# Auth-Type = Reject +# } +# } + +} + + + +} + diff --git a/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c b/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c index cbe61ad..2ffd6eb 100644 --- a/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c +++ b/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c @@ -130,6 +130,8 @@ static CONF_PARSER module_config[] = { offsetof(EAP_TLS_CONF, check_cert_issuer), NULL, NULL}, { "make_cert_command", PW_TYPE_STRING_PTR, offsetof(EAP_TLS_CONF, make_cert_command), NULL, NULL}, + { "virtual_server", PW_TYPE_STRING_PTR, + offsetof(EAP_TLS_CONF, virtual_server), NULL, NULL}, #if OPENSSL_VERSION_NUMBER >= 0x0090800fL #ifndef OPENSSL_NO_ECDH @@ -1611,6 +1613,7 @@ static int eaptls_authenticate(void *arg, EAP_HANDLER *handler) tls_session_t *tls_session = (tls_session_t *) handler->opaque; REQUEST *request = handler->request; eap_tls_t *inst = (eap_tls_t *) arg; + EAP_TLS_CONF *conf = inst->conf; RDEBUG2("Authenticate"); @@ -1619,9 +1622,73 @@ static int eaptls_authenticate(void *arg, EAP_HANDLER *handler) switch (status) { /* * EAP-TLS handshake was successful, return an - * EAP-TLS-Success packet here. + * EAP-TLS-Success packet here. If a virtual-server + * is configured, check that is happy, first. */ case EAPTLS_SUCCESS: + if (conf->virtual_server) { + VALUE_PAIR *vp; + VALUE_PAIR *copy; + REQUEST *fake; + + /* create a fake request, and copy current request vps in */ + fake = request_alloc_fake(request); + rad_assert(fake->packet->vps == NULL); + + vp = pairmake("Freeradius-Proxied-To", "127.0.0.1", T_OP_EQ); + if (vp) { + pairadd(&fake->packet->vps, vp); + } + + for (vp = request->packet->vps; vp != NULL; vp = vp->next) { + if (pairfind(fake->packet->vps, vp->attribute)) { + continue; + } + copy = paircopy2(vp, vp->attribute); + pairadd(&fake->packet->vps, copy); + } + + /* copy the TLS verification vps in to the request */ + for (vp = handler->certs; vp != NULL; vp = vp->next) { + if (pairfind(fake->packet->vps, vp->attribute)) { + continue; + } + copy = paircopy2(vp, vp->attribute); + pairadd(&fake->packet->vps, copy); + } + + /* set the virtual server to use */ + if ((vp = pairfind(request->config_items, PW_VIRTUAL_SERVER)) != NULL) { + fake->server = vp->vp_strvalue; + } else { + fake->server = conf->virtual_server; + } + + RDEBUG("Processing EAP-TLS check:"); + debug_pair_list(fake->packet->vps); + + RDEBUG("server %s {", fake->server); + + rad_authenticate(fake); + + RDEBUG("} # server %s", fake->server); + + /* copy the reply vps back to our reply */ + pairadd(&request->reply->vps, fake->reply->vps); + fake->reply->vps = NULL; + + /* reject if virtual server didn't return accept */ + if (fake->reply->code != PW_AUTHENTICATION_ACK) { + RDEBUG2("EAP-TLS rejected by virtual server"); + request_free(&fake); + eaptls_fail(handler, 0); + return 0; + } + + request_free(&fake); + /* success */ + } + break; /* diff --git a/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.h b/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.h index 34c917f..6840714 100644 --- a/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.h +++ b/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.h @@ -71,6 +71,8 @@ typedef struct eap_tls_conf { char *verify_tmp_dir; char *verify_client_cert_cmd; + char *virtual_server; + #ifdef HAVE_OPENSSL_OCSP_H /* * OCSP Configuration -- 1.7.2.5 -- Matthew Newton, Ph.D. <mcn4(a)le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp(a)le.ac.uk>

3 10

Re: EAP-AKA patch not working on freeradius-1.1.4.Can any one give me the dictionary file to be used for EAP-AKA?
by Ming-Ching Tiew 10 Feb '12

10 Feb '12

--- On Thu, 2/9/12, mikeyiconoclast <shiva.tyson(a)gmail.com> wrote: > From: mikeyiconoclast <shiva.tyson(a)gmail.com> > Subject: Re: EAP-AKA patch not working on freeradius-1.1.4.Can > any one give me the dictionary file to be used for EAP-AKA? > To: "FreeRadius developers mailing list" <freeradius devel(a)lists.freeradius.org> > Date: Thursday, February 9, 2012, 5:47 PM > I have used the latest patch on 2.1.10.EAP-AKA patch is applied > successfully on freeradius 2.1.10. The patch does not work even if it applies cleanly. Somehow it simply says ACCESS-ACCEPT even without the full AKA exchange.

3 2

rlm_sql_log - directory creation
by Brian Candler 10 Feb '12

10 Feb '12

Attached is a small patch we use to rlm_sql_log to create (one level of) directories automatically. This is because we use sql_log { path = "${radacctdir}/%{%{NAS-IP-Address}:-0.0.0.1}/sql_%Y%m%d.acc" ... } and we don't want to have to remember to create new subdirectories whenever a new NAS comes online. Is this something which might be considered for a future version? Perhaps more generally, any module which writes files could have a flag which enables 'mkdir -p' type functionality? Regards, Brian.

2 2

EAP-AKA patch not working on freeradius-1.1.4.Can any one give me the dictionary file to be used for EAP-AKA?
by mikeyiconoclast 09 Feb '12

09 Feb '12

Hi All, This is with reference to the EAP-AKA patch on freeradius-1.1.4. (http://freeradius.1045715.n5.nabble.com/EAP-AKA-support-for-Freeradius-1-1-…) Modified eap.conf adding aka and sim. While starting the radiusd server,I got the following error message. /usr/local/etc/raddb/users[92]: Parse error (check) for entry akauser(a)domain.com: Unknown value AKA for attribute EAP-Type Regards shiva

2 2

TLS-*-Cert-Common-Name if no certificate subject - patch
by Matthew Newton 09 Feb '12

09 Feb '12

The client certificate on the device I'm testing with here has no Subject, and has a subjectAltName instead. This seems allowed (mandated? - the text is unclear to me) by RFC3280 s4.1.2.6. Correctly, the TLS-Client-Cert-Subject vp is _not_ added. Incorrectly, TLS-Client-Cert-Common-Name IS added, with the value of the common name from the issuer certificate. Below mini-patch only tries to add the common-name vp if it previously found a subject. Cheers, Matthew >From 921bd453c11697830b0d4871aa7aac51601a0ee5 Mon Sep 17 00:00:00 2001 From: Matthew Newton <mcn4(a)leicester.ac.uk> Date: Fri, 3 Feb 2012 13:33:26 +0000 Subject: [PATCH] rlm_eap_tls.c - only add TLS-*-Cert-Common-Name if there was a subject --- .../rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c b/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c index e548961..0132ae0 100644 --- a/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c +++ b/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c @@ -636,12 +636,12 @@ static int cbtls_verify(int ok, X509_STORE_CTX *ctx) } /* - * Get the Common Name + * Get the Common Name, if there is a subject */ X509_NAME_get_text_by_NID(X509_get_subject_name(client_cert), NID_commonName, common_name, sizeof(common_name)); common_name[sizeof(common_name) - 1] = '\0'; - if ((lookup <= 1) && common_name[0] && (strlen(common_name) < MAX_STRING_LEN)) { + if ((lookup <= 1) && common_name[0] && subject[0] && (strlen(common_name) < MAX_STRING_LEN)) { pairadd(&handler->certs, pairmake(cert_attr_names[EAPTLS_CN][lookup], common_name, T_OP_SET)); } -- 1.7.2.5 -- Matthew Newton, Ph.D. <mcn4(a)le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp(a)le.ac.uk>

2 1

Need help on installing FR with postgresql.
by artaxerxe 02 Feb '12

02 Feb '12

Hello! I installed FR in my CentOS 6.2 from source. Doing a radtest on it, works good with files authentication. I try to change the authentication to sql mode, and I get the following error when I start FR: Thu Feb 2 11:30:36 2012 : Error: Could not link driver rlm_sql_postgresql: rlm_sql_postgresql.so: cannot open shared object file: No such file or directory Thu Feb 2 11:30:36 2012 : Error: Make sure it (and all its dependent libraries!) are in the search path of your system's ld. Thu Feb 2 11:30:36 2012 : Error: /netnfork/radius-server//etc/raddb/sql.conf[22]: Instantiation failed for module "sql" Thu Feb 2 11:30:36 2012 : Error: /netnfork/radius-server//etc/raddb/sites-enabled/default[177]: Failed to load module "sql". Thu Feb 2 11:30:36 2012 : Error: /netnfork/radius-server//etc/raddb/sites-enabled/default[69]: Errors parsing authorize section. When I installed the FR, I put a --prefix=/my/path to the ./configure command. The resulted warnings, that are related to my problem, are: ... configure: WARNING: silently not building rlm_sql_postgresql. configure: WARNING: FAILURE: rlm_sql_postgresql requires: libpq-fe.h libpq. ... I want to use FR with postgresql, and I have postgresql installed on my system, and also the FR database is already well done. (I know that because I have a FR installation under the default location. I installed it via yum, and it works good). So, can anybody explain me how to resolve my issue? I tried to install libpq-fe.h, but I didn't find it. I also tried to run the following: # ./configure --prefix=/my/path/ --with-postgresql-include-dir=/usr/pgsql-9.1/lib/ | grep -i WARNING but with the same WARNING. Can anybody help me on this? Thanks! -- View this message in context: http://freeradius.1045715.n5.nabble.com/Need-help-on-installing-FR-with-pos… Sent from the FreeRadius - Dev mailing list archive at Nabble.com.

3 7