April 2009 - Freeradius-Devel - lists.freeradius.org

Missing TLS Change Cipher Spec and TLS Finished in EAP-TLS exchanges
by arno＠natisbad.org 09 Jul '11

09 Jul '11

Hi, I upgraded an internal freeradius server (Linux, Debian unstable, libssl 0.9.8) used for EAP-TLS (802.11 WPA2 access) from 2.0.5 to 2.1.3. With 2.1.3, client authentication fails in the following way (wpasupplicant on Debian unstable, working with 2.0.5): - the TLS exchange is completed from freeradius point of view. It even sends the Access-Accept message to the NAS. - from the clients point of view, the TLS exchange is not over, it expects some more data from the server which are never sent. I took two pcap traces (sent to you privately, Alan), one with 2.0.5, one with 2.1.3. It looks like the TLS Change Cipher and TLS Tinished elements of the TLS exchange are not in the EAP encapsulated TLS packets sent by the server. Compare packet #23 of 2.1.3 trace with packet #27 of 2.0.5 trace. If you use wireshark, you will notice that the SSL layer is dissected; this is because #27 has a small brother: #29. It is not sent by 2.1.3. Alan, if you have an idea or a patch, I can test it on monday. Cheers, a+

5 15

eap2 in freeradius
by Chanthearith HUON 04 Apr '11

04 Apr '11

Hi everyone, I am testing eap2 in freeradius. I run "radiusd -X", I got following error message " radiusd: symbol lookup error: /usr/lib/rlm_eap2-2.1.0.so: undefined symbol: eap_server_register_methods " Anyone, have any idea what might be wrong with the configuration? Thank in advance, Thierry

5 10

Re: vmps request: long attribute VQP-Ethernet-Frame
by Hermann Lauer 05 Jan '10

05 Jan '10

Alan DeKok wrote: > > 0x0c05 is VQP-Ethernet-Frame, which can of course be longer than 253 bytes, > > so there is a design issue here. One idea would be to cut the attribute to > > 253 bytes in vqp_recv(). Could this be done there without memory issues ? > > Yes, if you're not interested in the rest of the data. appended is a patch which implemeted the cutting. Seems to work. Please tell me if anybody sees any pitfall in it. Otherwise it should be cleaned up, which I probably will do in a week or so. Thanks, Hermann -- Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224 Email: Hermann.Lauer(a)iwr.uni-heidelberg.de

2 5

FreeRadius + EAP-AKA support
by Kumar, Sunil 26 Nov '09

26 Nov '09

Hi, We are trying to use FreeRadius1.1.4 as authentication server for EAP-AKA implementation with our product toolkit. As per the RFC 4187 AT_RES The value field of this attribute begins with the 2-byte RES Length, which identifies the exact length of the RES in bits. The RES length is followed by the AKA RES parameter. According to [TS33.105], the length of the AKA RES can vary between 32 and 128 bits. Because the length of the AT_RES attribute must be a multiple of 4 bytes, the sender pads the RES with zero bits where necessary. In the freeradius1.1.4 implementation, for EAP-AKA the value of RES length is always considered as constant EAPSIM_RES_SIZE (16). It doesn't take care of the values other than 16 bytes. We in our toolkit needs to support all the variable length of RES values from 32 bits (4 bytes) to 128 bits (16 bytes). So I have modified the FreeRadius implementation for the same support. The intention of writing such mail is to get the information that if somebody has already noticed and fixed this issue in the latest releases, so please share that information as well. In case it's not been fixed as yet, then may be I could contribute my patch for freeradius 1.1.4 version to support all variable length RES value varying from 32 bits to 128 bits. Thanks. Warm regards. Sunil Kumar The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

4 5

GnuTLS and FreeRADIUS
by Carolin Latze 08 May '09

08 May '09

Hi everybody, I was searching for some time now and I found a lot of messages from people who wanted to replace the OpenSSL dependencies in FreeRADIUS with GnuTLS. But so far it seems, that nobody really did that, is that right? Or has there been work on that and it failed for some reason? To be honest I have absolutely no idea how complicated that will be but at least I don't expect it to be easy. :) Regards Carolin

5 6

Cisco WLC does not respect the Expiration of a user on Radius server.
by Matthew Carriere 01 May '09

01 May '09

Hi everyone, I have a CISCO WLC that is configured to use a FreeRadius server as the authentication point. Everything is working except the Expiration. I set an Expiration value programatically from a Ruby script by entering a record into the radcheck table: UserName | Matthew Attribute | Expiration op | := Value | April 29 2009 02:14:48 Here's the scenario, before the expiration date the user authenticates to the Radius server and then is able to use the Wireless (Cisco WLC). However, when the expiration time passes, the user can no longer authenticate to the radius server (which is correct), but they are still connected to the Wireless. Does anyone have some experience with this scenario to offer some suggestions to help troubleshoot? Thanks Matthew Carriere

4 4

help with dialup_admin
by Roger Ham 30 Apr '09

30 Apr '09

hi all i am from honduras and i am try of use the dialup_admin to freeradius. and i was run with phpMyadmin the tables to the BD dialup_admin, but some pages this show me this messages: Database query failed: Table 'radius.radacct' doesn't exist Database query failed: Table 'radius.usergroup' doesn't exist Database query failed: Table 'radius.radgroupcheck' doesn't exist how or when can find the structure of the tables for this db? thanks and so sorry for my bad english. -- Saludos! roghax85

2 7

freeradiusclient and CHAP support
by Christopher Gamio 30 Apr '09

30 Apr '09

Hi, I'm having an issue with the client library and was looking for some help. I'm currently using both the freeradius server and client and I was having some issues with CHAP support. I noticed in the code that the CHAP section of the client side was commented out. I'm tried uncommenting it, noticed the password length issues and checked google. I already know that CHAP isn't the best protocol to use, and I agree. Unfortunately, I still need to use it anyway. I have been looking through the source trying to figure out what the problem is the code is. Like I said, I noticed the password length error and tried simply compensating for that, but the passwords still do not match. What puzzles me is that CHAP works just fine in the radclient packaged with the server, so I feel that it should not be impossible to implement in the client library. If someone could point me in the right direction, or possibly explain the root cause of the problem in more detail, that would be much appreciated. Any help you could offer would be great. Thanks. Chris Gamio

2 3

GIT Log for 2009-04-29 23:33 GMT
by aland＠deployingradius.com 29 Apr '09

29 Apr '09

commit 8421494db011f0402d13ca1cb3c0bfb7f4f9821f Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Apr 29 17:09:39 2009 +0200 Manually merge change from 52e7cf6 Don't force reject if the home server doesn't respond. The main event handler already does this, so there's no need for us to do it, too. Files changed: src/modules/frs_auth/frs_auth.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) ====================================================================== commit 916b0f460eaf7c41587428bfc47915416e0ff21a Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Apr 29 17:02:11 2009 +0200 When not responding, wait longer for cleanups. wait max_request_time, not cleanup_delay to clean up packets that we're not responding to. This means that we don't clean up after 5s, and the re-process the packet. Instead, we just look at the cached packet, and don't respond Files changed: src/main/event.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) ====================================================================== commit 77edb49f069fbe0d8df422befa028e3602dae9ab Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Apr 29 17:04:43 2009 +0200 Fix last commit Files changed: src/main/event.c | 10 ++++------ 1 files changed, 4 insertions(+), 6 deletions(-) ====================================================================== commit ed33f645a6bbba7e73cea1ff3cc956f6827e7a27 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Apr 29 14:34:13 2009 +0200 Cache modcallables for authorize, etc. for minor speed Files changed: src/main/modules.c | 50 ++++++++++++++++++++++++++++++++++---------------- 1 files changed, 34 insertions(+), 16 deletions(-) ====================================================================== commit f28c21cfea32b147f522505a03b21b5f51acf898 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Apr 29 13:31:03 2009 +0200 Return proper error code Files changed: src/modules/frs_control/frs_control.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ====================================================================== commit 76853195db38e8f6a906409296981bf5c0fbeba5 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Apr 29 13:26:58 2009 +0200 Print out more server {} around debugging messages Files changed: src/main/event.c | 15 +++++++++++++-- 1 files changed, 13 insertions(+), 2 deletions(-) ====================================================================== commit 317b211764b60782e04e38d050a255d053f2f30d Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Apr 29 12:13:38 2009 +0200 Set free'd pointers to NULL Files changed: src/main/realms.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) ======================================================================

1 0

FIPS feature
by William Rettig 28 Apr '09

28 Apr '09

Good morning. My boss has asked me to add a FIPS feature to FreeRADIUS. It really doesn't amount to much at this point. We think that FIPS mode requires additional two things: 1) Use of HMAC-SHA1 MAC (vendor neutral) 2) AES Key Wrap of the MSK in the Access-Accept (attribute format is vendor specific - but feature could be mostly generic). Is this something that could be supported moving forward? Would someone be willing to direct my efforts? Bill

3 3