- 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

Missing SSL Change Cipher Spec in EAP-TLS with Client Certificate verify failed
by yuqiang 08 Jul '11

08 Jul '11

Oh,I am sorry. But the problem i meet just like the event descibed in mailinglist here. I downloaded the new version of freeradius(2.1.10) and run it on LINUX.When the certificate is expired or invalid,I found the data sent by server were missed. The log is as followed.The exchange between client and server is not conformed to RFC5216 described as italic text. RFC 5216 Section 2.1 Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type=EAP-TLS (TLS server_hello, TLS certificate, [TLS server_key_exchange,] TLS certificate_request, TLS server_hello_done) EAP-Response/ EAP-Type=EAP-TLS (TLS certificate, TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=EAP-TLS -> /<- EAP-Request EAP-Type=EAP-TLS (TLS Alert message) / EAP-Response/ EAP-Type=EAP-TLS -> <- EAP-Failure (User Disconnected) the log: +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/tls [eap] processing type tls [tls] Authenticate [tls] processing EAP-TLS TLS Length 225 [tls] Length Included [tls] eaptls_verify returned 11 [tls] <<< TLS 1.0 Handshake [length 0b8c], Certificate [tls] chain-depth=2, [tls] error=0 [tls] --> User-Name = test [tls] --> BUF-Name = ZJRoot,2.5.4.1 [tls] --> subject = /C=\x00C\x00N/ST=mYl_w\x01/L=gm]\xDE^\x02/O=mYl_w\x01ep[W\x8B\xA4\x8B\xC1N-_\xC3/CN=\x00Z\x00J\x00R\x00o\x00o\x00t [tls] --> issuer = /C=\x00C\x00N/ST=mYl_w\x01/L=gm]\xDE^\x02/O=mYl_w\x01ep[W\x8B\xA4\x8B\xC1N-_\xC3/CN=\x00Z\x00J\x00R\x00o\x00o\x00t [tls] --> verify return:1 [tls] chain-depth=1, [tls] error=0 [tls] --> User-Name = test [tls] --> BUF-Name = ZJCA,2.5.4.1 [tls] --> subject = /C=\x00C\x00N/ST=mYl_w\x01/L=gm]\xDE^\x02/O=mYl_w\x01ep[W\x8B\xA4\x8B\xC1N-_\xC3/CN=\x00Z\x00J\x00C\x00A [tls] --> issuer = /C=\x00C\x00N/ST=mYl_w\x01/L=gm]\xDE^\x02/O=mYl_w\x01ep[W\x8B\xA4\x8B\xC1N-_\xC3/CN=\x00Z\x00J\x00R\x00o\x00o\x00t [tls] --> verify return:1 --> verify error:num=10:certificate has expired [tls] >>> TLS 1.0 Alert [length 0002], fatal certificate_expired TLS Alert write:fatal:certificate expired TLS_accept: error in SSLv3 read client certificate B rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned SSL: SSL_read failed in a system call (-1), TLS session fails. TLS receive handshake failed during operation [tls] eaptls_process returned 4 [eap] Handler failed in EAP/tls [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. Using Post-Auth-Type Reject -- View this message in context: http://freeradius.1045715.n5.nabble.com/Missing-SSL-Change-Cipher-Spec-in-E… Sent from the FreeRadius - Dev mailing list archive at Nabble.com.

3 6

Re: [PATCH] Fix broken EAP-TLS (bug introduced 2008/08/24 by b51a3a82)
by Phil Mayers 08 Jul '11

08 Jul '11

The post is two years old. The bug is fixed. Upgrade to the latest version. Sent from my mobile, please excuse brevity and typos. ----- Reply message ----- From: "yuqiang" <yuqiang1973(a)163.com> To: <freeradius-devel(a)lists.freeradius.org> Subject: [PATCH] Fix broken EAP-TLS (bug introduced 2008/08/24 by b51a3a82) Date: Tue, Jul 5, 2011 15:12 Hi. Why not look at the mailing list,I want to your help! Best regards -- View this message in context: http://freeradius.1045715.n5.nabble.com/Missing-TLS-Change-Cipher-Spec-and-… Sent from the FreeRadius - Dev mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

2 1

Re: Patch to fix PPTP CHAP failure due to unknown-attribute problem
by freeradius developer/user identity 07 Jul '11

07 Jul '11

> You can find the current freeradius dictionaries at > https://github.com/alandekok/freeradius-server/tree/v2.1.x/share > You can see that dictionary.microsoft and dictionary.merit are there.... > ... > It includes attributes 11 (MS-CHAP-Challenge) and 25 (MS-CHAP2-Response). Thank you for your prompt reply! It turns out that the dictionary files for *radiusclient* are different from those for freeradius *server* in subtle ways. Specifically, the server version uses the type "octet" while radiusclient recognizes only "string", "integer", "ipaddr", and "date" (see radiusclient's lib/dict.c, which is what parses the dictionaries). You are completely correct that the freeradius server distribution comes with a whole bunch of dictionaries, and that the dictionary.microsoft one does define the attributes 11 and 25. Unfortunately, radiusclient does not read these and cannot process them correctly if it did read them. The radiusclient distribution (even the latest development version at cvs -d :pserver:anoncvs@cvs.freeradius.org:/source login CVS password: anoncvs cvs -d :pserver:anoncvs@cvs.freeradius.org:/source checkout radiusclient (c/o http://wiki.freeradius.org/Radiusclient) does not include any dictionary files other than "dictionary". Hence the problem. It certainly would be helpful to include radiusclient versions of dictionary.microsoft (and, I suppose, dictionary.merit) with the radiusclient distribution. Also, the current source of the radiusclient versions of dictionary.microsoft and dictionary.merit at http://wiki.freeradius.org/PopTop which is the source of the buggy version of dictionary.microsoft that has a space at the start of each line, could be updated to remove the spaces, and text could be inserted that explains that the errors rc_avpair_new: unknown attribute 11 rc_avpair_new: unknown attribute 25 may go away if these files are replaced with the revised versions. A good place for the text to be updated would be at the paragraph beginning, "That's not working. Ok, so you've followed the above steps and it's still not working. So lets double check things before you post to FreeRADIUS mailing lists: ...." I was hoping that my patches could be accepted in any case because there may be people who won't notice the changes in the web page above, and/or may have troubles with new dictionaries that they are developing. Another approach would be to modify radiusclient so that it reads the dictionaries used by freeradius server. That would make a lot of sense, and would be easy to do. Please let me know if you would like me to do that. Please let me know if I need to patch up the style in the patches. I tried to mimic the C-style of the original code, but may have missed spacing and such here and there. Thanks again for maintaining this important project. Please let me know how I can help. - Larry Widman

4 6

Re: Patch to fix PPTP CHAP failure due to unknown-attribute problem
by freeradius developer/user identity 06 Jul '11

06 Jul '11

On Wed, Jul 06, 2011 at 12:00:13PM +0200, freeradius-devel(a)lists.freeradius.org wrote: > Oh I see. Sorry, I wasn't even aware of that, and I've no idea if it's even > supported any more. > > I notice that the 'snapshots' link on that page points to an ftp server in > Turkey which doesn't have any content: > .... > All freeradius (server) development has moved to git - it's currently at > version 2.1.11. Sounds like a maintainer is needed under the auspices of the freeradius project: (from http://wiki.freeradius.org/Radiusclient) "Development of the radiusclient-ng and FreeRADIUS client were proceeding in parallel during 2006-2007,... until in early 2008 it has been decided to merge both projects ... and discontinue radiusclient-ng project.... All developers from the radiusclient-ng project joined FreeRADIUS team and few remaining fixes from the radiusclient-ng have been merged into FreeRADIUS client package. Development of the codebase is ongoing." The current latest version is on cvs.freeradius.org according to the page cited above. I was able to download a copy from there that was a tad more recent than the stable 1.1.6 version. Meanwhile, a search of github.com shows one project with "radius" and "client" in the name that is not related to Ruby or perl. It is "elagin / RadiusClient", and has just a few files. Interestingly, it was committed recently (2/18/2011). The size is 250K but most of the files are private and cannot be downloaded. The main.cpp file refers to radiusclient library functions but itself is not radiusclient. So, I'm not sure what this is but it does not appear to be the main site for radiusclient. So, it looks like radiusclient is currently not well supported within the freeradius project, and the name "radiusclient" is taken on github.com. If a maintainer is needed, I am willing to volunteer at least for now. Since the name "radiusclient" on github is taken, would it make sense to include radiusclient in the freeradius server source tree? That would be handy for those who want both, and it's not very large so people who don't want it wouldn't be bothered much. It could even be configured not to compile by default. Once the housekeeping (file transfer to github, updating the make files) is done, the first thing I would do is merge the dictionaries with the ones that come with the server! If there is a (dormant) maintainer already, I will be happy to work with him/her to do what is needed. Thanks - Larry Widman

2 1

radmin - infinite loop
by Brian Candler 06 Jul '11

06 Jul '11

This is with freeradius 2.1.10 The server is running as root (yes I know, but I can't change that easily right now). radmin works fine with: listen { type = control socket = ${run_dir}/${name}.sock uid = root mode = rw } Now, in order to step towards interfacing to a web app, I changed this to uid = www-data Of course, I can't yet connect from www-data because the server is running as root, and the socket is owned by 0/0 mode 550. But the strange thing is, if I run radmin as root, it no longer works; it doesn't even display the startup banner. strace shows that it's going into an infinite loop: ... set_tid_address(0x7f2fd45419d0) = 7688 set_robust_list(0x7f2fd45419e0, 0x18) = 0 futex(0x7fff3b496cdc, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x7fff3b496cdc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7f2fd4541700) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0x7f2fd3abd870, [], SA_RESTORER|SA_SIGINFO, 0x7f2fd3ac78f0}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x7f2fd3abd900, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f2fd3ac78f0}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_FILE, path="/var/run/freeradius/freeradius.sock"}, 37) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 read(3, "", 8) = 0 ... etc forever I presume it's stuck here: /* * Read initial magic && version information. */ for (size = 0; size < 8; size += len) { len = read(sockfd, buffer + size, 8 - size); if (len < 0) { fprintf(stderr, "%s: Error reading initial data from socket: %s\n", progname, strerror(errno)); exit(1); } } And this I imagine is because of the uid test failing in the server, and the connection being dropped. Normally read() returning 0 would indicate an end-of-file condition, but for some reason that I don't understand, the socket is being set into non-blocking mode, so it's not as simple as that. However, I thought that if no data was available you'd get -1 and EAGAIN or EWOULDBLOCK? But as the code is currently written, it aborts on any condition where len < 0. I'm no expert in this area, but I suggest something like this (untested): for (size = 0; size < 8; ) { len = read(sockfd, buffer + size, 8 - size); if (len < 0) { if (errno == EAGAIN || errno == EWOULDBLOCK) continue; fprintf(stderr, "%s: Error reading initial data from socket: %s\n", progname, strerror(errno)); exit(1); } if (len == 0) { fprintf(stderr, "%s: Connection dropped by server\n", progname); exit(1); } size += len; } A couple of other suggestions. (1) When checking the uid of the socket peer, if you find it's 0 (root) you may as well let them in anyway. (2) When starting the control server, if the 'uid' or 'gid' values are set, it could try chown'ing or chgrp'ing the socket to that value. Thanks, Brian.

2 8

Patch to fix PPTP CHAP failure due to unknown-attribute problem
by freeradius developer/user identity 04 Jul '11

04 Jul '11

Since at least 2005, the combination of PPTP and radiusclient has led to failure of CHAP authentication with the following errors appearing in syslog: rc_avpair_new: unknown attribute 11 rc_avpair_new: unknown attribute 25 I have posted an analysis of the problem and a link to patch set against the CVS tree that fixes it (at least in my hands) at http://www.cardiothink.com/downloads/ The patches also add my name to the copyright: if this is not correct to do please take my name out. Also, I made the library able to use "INCLUDE" as well as "$INCLUDE", fixed what appeared to a problem with high-level directory specifications appearing after (but in alphabetical order) the subsidiary specifications in which they appeared in /Makefile.in, and added a simple program "radlistdictionary" that takes arguments to show the loading and processing of the dictionary and its included subdictionaries, at one of two levels of detail and in one of two forms of output (stdout, syslog). My hope is that this program will be helpful to others in debugging problems of this sort. In this case, the problem because obvious as soon as I ran it although it had been completely opaque before. Please let me know if it would be better for me to post the patches to this list directly rather than to refer to a web link. I don't want to clutter up the mailing list. The patch is 27K uncompressed and 7K compressed.

2 1

For your help about RADIUS SERVER EAP-TLS
by yuqiang 04 Jul '11

04 Jul '11

Hi, The BUG i meet just like Arnaud EBALARD's question "Missing TLS Change Cipher Spec and TLS Finished in EAP-TLS exchanges " i found in the maillist JAN 24,2009. I want to know how to solve it. for your reply! -- View this message in context: http://freeradius.1045715.n5.nabble.com/For-your-help-about-RADIUS-SERVER-E… Sent from the FreeRadius - Dev mailing list archive at Nabble.com.

2 1

Fix message-authenticator attribute check for rfc 5997
by Frederic Leroy 01 Jul '11

01 Jul '11

Hello, I have a device which adds message-authenticator attribute (80) in its accounting-response. If I understand correctly, it follows rfc5997 ( see section 5 ) which is informational. Using radclient, it rejects the accounting-response of my device. So here is a patch to libfreeradius to make it works. Regards, -- Frederic Leroy

2 3

Repeatable problem with Client-Shortname
by Brian Candler 30 Jun '11

30 Jun '11

Here's a strange problem: the Client-Shortname attribute won't match a regexp unless it's inside a string expansion. Simple example: # Fails if (Client-Shortname =~ /./) { update reply { Reply-Message += "XXX" } } # Succeeds if ("%{Client-Shortname}" =~ /./) { update reply { Reply-Message += "YYY" } } (Uncomment "shortname = localhost" from clients.conf). The first test fails to match, but the second one matches. Debug output: ... [files] users: Matched entry steve at line 76 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop ++? if (Client-Shortname =~ /./) (Attribute Client-Shortname was not found) ? Evaluating (Client-Shortname =~ /./) -> FALSE ++? if (Client-Shortname =~ /./) -> FALSE ++? if ("%{Client-Shortname}" =~ /./) expand: %{Client-Shortname} -> localhost ? Evaluating ("%{Client-Shortname}" =~ /./) -> TRUE ++? if ("%{Client-Shortname}" =~ /./) -> TRUE ++- entering if ("%{Client-Shortname}" =~ /./) {...} +++[reply] returns noop ++- if ("%{Client-Shortname}" =~ /./) returns noop ++[pap] returns updated Found Auth-Type = PAP ... This is built from the latest code on the v2.1.x branch. If I try with a different request attribute, like Client-IP-Address, it works fine. It's not a big issue, because I can just put the attribute in a string expansion to resolve it, but it was a bit confusing. Thanks, Brian.

5 21