CHAP authentication fails when radtest communicates with freeradius 3.0.4 server through radsecproxy 1.6.2

[Alan DeKok]

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.