# freeradius -v freeradius: FreeRADIUS Version 2.1.12 We have a puzzling issue with CHAP Authentication: Using radtest like this works: radtest -d /etc/freeradius/ -t chap "6064191000@ev.myawi.com" "6D464023735E40604457225169645C69" 127.0.0.1 1812 xxxxxx But when a real live device request comes in, it fails: This should be allowed but is rejected: Using md5 hashing, we have confirmed that it is accurate: Radius Protocol Code: Access-Request (1) Packet identifier: 0x51 (81) Length: 145 Authenticator: dbad48a07b45dc16a42806283bfa3432 [The response to this request is in frame 2] Attribute Value Pairs AVP: l=25 t=User-Name(1): 6064191000@ev.myawi.com User-Name: 6064191000@ev.myawi.com AVP: l=19 t=CHAP-Password(3): a7737618eb2d4f46a3945215a989923560 CHAP-Password: a7737618eb2d4f46a3945215a989923560 CHAP Ident: 0xa7 CHAP String: 737618eb2d4f46a3945215a989923560 AVP: l=6 t=NAS-IP-Address(4): 10.xxx.2.1 NAS-IP-Address: 10.xxx.2.1 (10.xxx.2.1) AVP: l=18 t=CHAP-Challenge(60): 5072685c0183c07d006ff00c160671a0 CHAP-Challenge: 5072685c0183c07d006ff00c160671a0 AVP: l=12 t=Vendor-Specific(26) v=3rd Generation Partnership Project 2 (3GPP2)(5535) VSA: l=6 t=3GPP2-HRPD-Access/Terminal-Authentication-and-1x-Access-Authorization(60): 1 3GPP2-HRPD-Access/Terminal-Authentication-and-1x-Access-Authorization: 1 AVP: l=23 t=Vendor-Specific(26) v=3rd Generation Partnership Project 2 (3GPP2)(5535) VSA: l=17 t=3GPP2-AT-Hardware-Identifier(61): [unhandled integer length(15)] AVP: l=18 t=Message-Authenticator(80): 8ce6cfeb0d0ef6a09bd3dbbdd7495226 Message-Authenticator: 8ce6cfeb0d0ef6a09bd3dbbdd7495226 AVP: l=4 t=Proxy-State(33): 3834 Proxy-State: 3834 Here is the users file we are using for testing: 6064191000@ev.myawi.com Cleartext-Password := "6D464023735E40604457225169645C69" Callback-Id = "000006064191000", Fall-Through = Yes Here is the debug on freeradius -X Thu Apr 10 15:21:22 2014 : Info: Ready to process requests. rad_recv: Access-Request packet from host 10.xx.xx.32 port 1814, id=81, length=145 User-Name = "6064191000@ev.myawi.com" CHAP-Password = 0xa7737618eb2d4f46a3945215a989923560 NAS-IP-Address = 10.xxx.2.1 CHAP-Challenge = 0x5072685c0183c07d006ff00c160671a0 3GPP2-Attr-60 = 0x00000001 3GPP2-Attr-61 = 0x010600000001020935799505892280 Message-Authenticator = 0x8ce6cfeb0d0ef6a09bd3dbbdd7495226 Proxy-State = 0x3834 Thu Apr 10 15:24:22 2014 : Info: # Executing section authorize from file /etc/freeradius/sites-enabled/default Thu Apr 10 15:24:22 2014 : Info: +- entering group authorize {...} Thu Apr 10 15:24:22 2014 : Info: ++[preprocess] returns ok Thu Apr 10 15:24:22 2014 : Info: ++[auth_log] returns ok Thu Apr 10 15:24:22 2014 : Info: [chap] Setting 'Auth-Type := CHAP' Thu Apr 10 15:24:22 2014 : Info: ++[chap] returns ok Thu Apr 10 15:24:22 2014 : Info: [suffix] Looking up realm "ev.myawi.com" for User-Name = "6064191000@ev.myawi.com" Thu Apr 10 15:24:22 2014 : Info: [suffix] No such realm "ev.myawi.com" Thu Apr 10 15:24:22 2014 : Info: ++[suffix] returns noop Thu Apr 10 15:24:22 2014 : Info: [files] users: Matched entry 6064191000@ev.myawi.com at line 1 Thu Apr 10 15:24:22 2014 : Info: ++[files] returns ok Thu Apr 10 15:24:22 2014 : Info: [pap] WARNING: Auth-Type already set. Not setting to PAP Thu Apr 10 15:24:22 2014 : Info: ++[pap] returns noop Thu Apr 10 15:24:22 2014 : Info: Found Auth-Type = CHAP Thu Apr 10 15:24:22 2014 : Info: # Executing group from file /etc/freeradius/sites-enabled/default Thu Apr 10 15:24:22 2014 : Info: +- entering group CHAP {...} Thu Apr 10 15:24:22 2014 : Info: [chap] login attempt by "6064191000@ev.myawi.com" with CHAP password Thu Apr 10 15:24:22 2014 : Info: [chap] Using clear text password "325C7727326B6176362A324754623247" for user 6064191000@ev.myawi.com authentication. Thu Apr 10 15:24:22 2014 : Info: [chap] Password check failed Thu Apr 10 15:24:22 2014 : Info: ++[chap] returns reject Thu Apr 10 15:24:22 2014 : Info: Failed to authenticate the user. Thu Apr 10 15:24:22 2014 : Auth: Login incorrect (rlm_chap: Wrong user password): [6064191000@ev.myawi.com/<CHAP-Password>] (from client radiusxx port 0) Thu Apr 10 15:24:22 2014 : Info: Using Post-Auth-Type Reject -- respectfully, Joseph | IT
Joseph Showalter wrote:
# freeradius -v freeradius: FreeRADIUS Version 2.1.12
<sigh> I wish vendors would use a recent version.
We have a puzzling issue with CHAP Authentication:
Using radtest like this works:
radtest -d /etc/freeradius/ -t chap "6064191000@ev.myawi.com" "6D464023735E40604457225169645C69" 127.0.0.1 1812 xxxxxx
It uses the same library as the server. So that isn't much of a test.
But when a real live device request comes in, it fails:
This should be allowed but is rejected: Using md5 hashing, we have confirmed that it is accurate:
What does that mean? The CHAP algorithm requires specific steps done in a specific order. Are you sure you did them all correctly? What values did you use?
Apr 10 15:24:22 2014 : Info: [chap] Using clear text password "325C7727326B6176362A324754623247" for user 6064191000@ev.myawi.com authentication. Thu Apr 10 15:24:22 2014 : Info: [chap] Password check failed
That's pretty definitive. You can believe (a) FreeRADIUS is wrong, and therefore millions of people can't use CHAP, or (b) the vendor got it wrong, or (c) you mis-typed the password on one or both ends. (c) is most likely. (b) much less so. (a) is almost impossible. I've seen vendors get basic RADIUS concepts wrong, and take years to fix them. But FreeRADIUS works with thousands of vendors equipment, for hundreds of millions of users, every single day. It's pretty much impossible for it to get the CHAP calculation wrong. I tried your packet as a test case with radclient: # file "chap" User-Name = "6064191000@ev.myawi.com" CHAP-Password = 0xa7737618eb2d4f46a3945215a989923560 CHAP-Challenge = 0x5072685c0183c07d006ff00c160671a0 $ /radclient -d ../../share/ -f chap -xx localhost auth testing123 And version 3 says (after some minor editing of output) chap : Login attempt by "6064191000@ev.myawi.com" with CHAP password chap : Comparing with "known good" Cleartext-Password "6D464023735E40604457225169645C69" chap : chap challenge dbad48a07b45dc16a42806283bfa3432 chap : client sent b39a3d7fb573cdf16e506df74cd4cbe0 chap : we calculated a7487911f7f12c921538b4af618f6396 chap : Password is comparison failed: password is incorrect It doesn't match. So the passwords are wrong, or the vendor doesn't calculate the CHAP-Password correctly. And WHY is everyone so quick to publicly blame FreeRADIUS, but then keep the vendors name a secret? WHICH vendor is it? What equipment? Make, model firmware? All that could be helpful. Alan DeKok.
Thanks for your answerers - see comments below: On Apr 10, 2014, at 9:20 PM, Alan DeKok <aland@deployingradius.com> wrote:
Joseph Showalter wrote:
# freeradius -v freeradius: FreeRADIUS Version 2.1.12
<sigh> I wish vendors would use a recent version.
I am willing to do that... But running the latest version that Debian stable gives me :) Anything newer requires a compile and that takes a bit of study for me.
We have a puzzling issue with CHAP Authentication:
Using radtest like this works:
radtest -d /etc/freeradius/ -t chap "6064191000@ev.myawi.com" "6D464023735E40604457225169645C69" 127.0.0.1 1812 xxxxxx
It uses the same library as the server. So that isn't much of a test.
OK, good to know...
But when a real live device request comes in, it fails:
This should be allowed but is rejected: Using md5 hashing, we have confirmed that it is accurate:
What does that mean? The CHAP algorithm requires specific steps done in a specific order. Are you sure you did them all correctly? What values did you use?
Well, I am no expert here, but in this case, the SIM vendor has taken pcap files, and double checked this.
Apr 10 15:24:22 2014 : Info: [chap] Using clear text password "325C7727326B6176362A324754623247" for user 6064191000@ev.myawi.com authentication. Thu Apr 10 15:24:22 2014 : Info: [chap] Password check failed
That's pretty definitive.
You can believe (a) FreeRADIUS is wrong, and therefore millions of people can't use CHAP, or (b) the vendor got it wrong, or (c) you mis-typed the password on one or both ends.
(c) is most likely. (b) much less so. (a) is almost impossible.
We love FR. And don't want to think thats the problem. But we are very puzzled. I am putting the exact same password in the SIM as you see in the users file. And then testing with radtest and testing with winntrad test, it seems so strange that only the SIM is failing. It is definitely using challenge/response when using the SIM.
I've seen vendors get basic RADIUS concepts wrong, and take years to fix them. But FreeRADIUS works with thousands of vendors equipment, for hundreds of millions of users, every single day. It's pretty much impossible for it to get the CHAP calculation wrong.
I tried your packet as a test case with radclient:
# file "chap" User-Name = "6064191000@ev.myawi.com" CHAP-Password = 0xa7737618eb2d4f46a3945215a989923560 CHAP-Challenge = 0x5072685c0183c07d006ff00c160671a0
$ /radclient -d ../../share/ -f chap -xx localhost auth testing123
And version 3 says (after some minor editing of output)
chap : Login attempt by "6064191000@ev.myawi.com" with CHAP password chap : Comparing with "known good" Cleartext-Password "6D464023735E40604457225169645C69" chap : chap challenge dbad48a07b45dc16a42806283bfa3432 chap : client sent b39a3d7fb573cdf16e506df74cd4cbe0 chap : we calculated a7487911f7f12c921538b4af618f6396 chap : Password is comparison failed: password is incorrect
It doesn't match. So the passwords are wrong, or the vendor doesn't calculate the CHAP-Password correctly.
And WHY is everyone so quick to publicly blame FreeRADIUS, but then keep the vendors name a secret? WHICH vendor is it? What equipment? Make, model firmware? All that could be helpful.
Alan DeKok.
The vendor here is an 3G handset, using a Gemalto SIM card, with a backbone of Ericsson equipment. Shall I do a new pcap and test? Do you think FR 3 would make any difference? I figured CHAP is around long enough there would not be any changes in newer releases? -- respectfully, Joseph | IT
Joseph Showalter wrote:
I am willing to do that... But running the latest version that Debian stable gives me :)
We're working with Debian to fix that... the FreeRADIUS package seems to have been ignored for years.
Anything newer requires a compile and that takes a bit of study for me.
Go to http://wiki.freeradius.org, type "debian" into the search box. Follow the instructions.
Well, I am no expert here, but in this case, the SIM vendor has taken pcap files, and double checked this.
The same people who got the CHAP calculation wrong in the first place? Hmm.. that doesn't make much sense. My next guess was that the vendor was treating the password as a hex string, and converting it to binary before doing the password checks. The Cleartext-Password converts to the string: mF@#s^@`DW"Qidiawi.com Which does look interesting, but that doesn't work, either.
We love FR. And don't want to think thats the problem.
It's not.
But we are very puzzled. I am putting the exact same password in the SIM as you see in the users file. And then testing with radtest and testing with winntrad test, it seems so strange that only the SIM is failing.
Then the SIM is wrong.
The vendor here is an 3G handset, using a Gemalto SIM card, with a backbone of Ericsson equipment.
<shrug> Something there is broken.
Shall I do a new pcap and test? Do you think FR 3 would make any difference?
Version 3 will be the same as version 2.
I figured CHAP is around long enough there would not be any changes in newer releases?
Yes. But vendors will still get things wrong. Alan DeKok.
participants (2)
-
Alan DeKok -
Joseph Showalter