anoop wrote:
In process of evaluating Radsec feature, We encountered the failure with CHAP authentication. Authentication was successful with PAP, MSCHAP and eap-md5.
Version(3.0.4) of freeradius is same in Client and Server. Radsecproxy version is 1.6.2.
Wed Oct 22 19:47:17 2014 : Debug: (8) chap : Comparing with "known good" Cleartext-Password "root1234" Wed Oct 22 19:47:17 2014 : Debug: (8) chap : CHAP challenge : ad6c2dc312713a327a8aedae47a7344f Wed Oct 22 19:47:17 2014 : Debug: (8) chap : Client sent : 78dddafe77d7bb8d5d554b24d26ba2bb Wed Oct 22 19:47:17 2014 : Debug: (8) chap : We calculated : 8b672ba8589f7d0658b3b3e8e2002b09 Wed Oct 22 19:47:17 2014 : ERROR: (8) chap : Password is comparison failed: password is incorrect
That seems definitive. Radsecproxy is wrong. The debug output makes this clear: radclient: Sending Access-Request Id 80 from 0.0.0.0:35860 to 127.0.0.1:1812 User-Name = 'root' CHAP-Password = 0xdb78dddafe77d7bb8d5d554b24d26ba2bb radsecproxy: ... nothing, you didn't post this. That's fine. FreeRADIUS: Wed Oct 22 19:47:17 2014 : Debug: (8) Received Access-Request packet from host 192.168.14.56 port 2083, id=1, length=75 Wed Oct 22 19:47:17 2014 : Debug: (8) User-Name = 'root' Wed Oct 22 19:47:17 2014 : Debug: (8) CHAP-Password = 0xdb78dddafe77d7bb8d5d554b24d26ba2bb Notice that the CHAP-Password attribute is the *same*. This is completely wrong. The CHAP-Password is calculated using the CHAP-Challenge attribute. Where the CHAP-Challenge attribute doesn't exist, CHAP-Password is calculated from the Authenticator field of the packet. Which changes for every single packet. When radsecproxy sends a CHAP-Password, it should check for the existence of a CHAP-Challenge attribute. If that attribute doesn't exist, it should create a CHAP-Challenge attribute, and copy the Authenticator field from the input packet into the attribute. I've CC'd Linus on this. The fix is probably no more than 20-30 lines of code. Alan DeKok.