September 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

make_passwd(), rlm_perl and double quotes in the password
by Niko Tyni 28 Jan '10

28 Jan '10

Hi, we're seeing failed logins when proxying authentication requests through to another RADIUS server if the password contains a double quote ("). I've debugged the issue a bit, and what happens is that when the password does a roundtrip through the rlm_perl module, the value pair structure ends up with extra bytes at the end so that strlen(vp->data.strvalue) > vp->length. These extra bytes are the result of escaping the double quote before entering the Perl code and then unescaping it afterwards. For instance, the password abcdef" is passed as abcdef\" to the Perl code, and afterwards it becomes abcdef"" with length 7 (so the extra byte is not supposed to hurt AIUI.) Unfortunately make_passwd() rounds 'inlen' up to a multiple of 16 before copying the input string, so the extra bytes end up in the message authenticator of the proxied request. It seems to me that the escaping and unescaping done in rlm_perl via perl_store_vps() -> vp_prints_value() -> librad_safeprint() and get_hv_content() -> pairadd_sv() -> pairmake() -> pairparsevalue() is a bit unnecessary, and that the unescaping could zero out the extra bytes, but the main bug is in make_passwd() IMO. I have reproduced this with a Debian 2.0.4 freeradius package, a Fedora 2.1.3 package, and a current git.freeradius.org checkout (commit ef2a7db5e). I'm attaching a proposed patch to make_passwd(). Please let me know if you need more information, I can easily produce stack traces and the like. Thanks for your work on FreeRADIUS, -- Niko Tyni ntyni(a)cc.helsinki.fi

3 5

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

Setting Client-IP-Address in rlm_preprocess
by John Morrissey 04 Dec '09

04 Dec '09

Client-IP-Address is dynamically set by xlat_packet(). AFAICT, there's no way to trigger this in rlm_perl, so Client-IP-Address is never available in rlm_perl handlers. This leads to some interesting unlang to set Client-IP-Address in the request so rlm_perl can access it: authorize { update request { Client-IP-Address := "%{Client-IP-Address}" } } rlm_preprocess sets NAS-IP-Address if it's not set. Alan, would you accept a patch to add similar behavior for Client-IP-Address? john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

3 7

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

GIT Log for 2009-09-30 23:33 GMT
by aland＠deployingradius.com 30 Sep '09

30 Sep '09

commit 4baebf8202d7db372a9ad2ce5026ec6c986f0de7 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Sep 30 09:54:25 2009 +0200 Allow old-style dictionary formats, too src/lib/dict.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-)

1 0

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

29 Sep '09

commit 9491d6eb7b963532855ccc8a63a523a2a1e3af2b Author: Alan T. DeKok <aland(a)freeradius.org> Date: Tue Sep 29 20:24:40 2009 +0200 Use packet codes from libradius Files changed: src/modules/rlm_detail/rlm_detail.c | 60 +--------------------------------- 1 files changed, 2 insertions(+), 58 deletions(-) ====================================================================== commit 137e3759b2ffc0c4f99064dadbd7461d3e86ae2a Author: Alan T. DeKok <aland(a)freeradius.org> Date: Tue Sep 29 10:10:59 2009 +0200 Moved Ascends illegal attributes to their own file Files changed: share/dictionary | 1 + share/dictionary.ascend | 422 -------------------------------------- share/dictionary.ascend.illegal | 429 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 430 insertions(+), 422 deletions(-) ======================================================================

1 0

defunct commit?
by Alexander Clouter 29 Sep '09

29 Sep '09

Hi, Only, I'm stumped, what does 1b8881d726d96d4dacd554c3b3e2f7b4c4012a68 do? The commit log implies it's important...but the patch it's-self is cryptic. Cheers -- Alexander Clouter .sigmonster says: Fundamentally, there may be no basis for anything.

2 3

[PATCH] fix rlm_detail array
by Alexander Clouter 29 Sep '09

29 Sep '09

Fixed missing comma in rlm_detail that leads to the following entries appearing 'Packet-Type = Access-ChallengeStatus-Server'; also fixes the other packet types as the array from that point is off-by-one Signed-off-by: Alexander Clouter <alex(a)digriz.org.uk> --- src/modules/rlm_detail/rlm_detail.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/modules/rlm_detail/rlm_detail.c b/src/modules/rlm_detail/rlm_detail.c index 685fa72..8c49936 100644 --- a/src/modules/rlm_detail/rlm_detail.c +++ b/src/modules/rlm_detail/rlm_detail.c @@ -45,7 +45,7 @@ static const char *packet_codes[] = { "Password-Accept", "Password-Reject", "Accounting-Message", - "Access-Challenge" + "Access-Challenge", "Status-Server", "Status-Client", "14", -- 1.5.6.5

2 2