MS-CHAP-V2 with no retry
James J J Hooper
jjj.hooper at bristol.ac.uk
Thu Apr 7 20:51:29 CEST 2011
On 07/04/2011 13:33, James J J Hooper wrote:
>
>
> --On Wednesday, April 06, 2011 15:42:11 -0500 John.Hayward at wheaton.edu wrote:
>
>>> List info/subscribe/unsubscribe? See
>>> http://www.freeradius.org/list/users.html
>> I don't know if this should be sent to the developers list instead.
>>
>> === Background ===
>> When there is a failure of the client to match the challenge of the
>> server:
>>
>> According to rfc2759 a failure packet in section 6 a failure packet
>> includes a message like:
>> "E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv M=<msg>"
>> where E is the error code, R 1/0 allow/disallow retry C an ascii version
>> of the challenge V=3 and M= some text message.
>>
>> After this mschap failure message is sent by the server an acknowledgment
>> which seems to be have a failure code should be returned from the client.
>>
>> At that point the server can close the eap connection with a failure.
>>
>> What the 2.1.10 code (and earlier) appears to do is after mschap is
>> detected immediately close the eap connection with a failure.
>>
>> The effect for windows XP/7 machines connecting wirelessly using mschapv2
>> is that they are presented with a dialog box and can enter new
>> credentials.
>>
>> What happens with mac/iphones/androids/ubuntu is that they appear to be
>> confused and time out and re-send (at various rates) authentication
>> attempts without presenting a dialog box to the user.
>>
>> For some environments (such as using Novell NDS to authenticate) if
>> configured modules/ldap edir_account_policy_check=yes then these repeated
>> failures result in account lock outs.
>>
>> Scenario: Institution requires periodic change of password - user uses a
>> web site to change password - user forgets to update their
>> mac/iphone/android - user turns on their mac/iphone/android - shortly
>> after user cannot access any resources (such as blackboard/portal etc)
>> because their account is locked out.
>>
>> ====== proposed fix ====
>> Modify freeradius to follow rfc2759.
>>
>> This requires patches to two source files:
>> o src/modules/rlm_mschap/rlm_mschap.c to include a message which conforms
>> to rfc2759
>> o src/modules/rlm_eap/types/rlm_eap_mschapv2/rlm_eap_mschapv2.c to use the
>> response created by rlm_mschap.c and send that back, also accept an
>> authentication failure acknowledgment before sending eap failure
>> packet.
>>
>> Below are the diffs:
>
>> ======
>>
>> ==== Comments ====
>> o Results:
>> We have implemented this patch (along with the configuration change
>> edir_account_policy_check=no) and observe:
>> 1) no more lockouts
>> 2) Mac/Iphones users are now presented with a dialog box where they
>> can update their password.
>> o Code:
>> a) I don't like the 100 character msg variable - there is probably a
>> better way to do this.
>> b) There is probably a function in free radius library to do the
>> sprintf
>> which should be used.
>> c) samba locked accounts should probably have a similar message
>> generated if they are mschapv2.
>>
>> I would be happy if someone could look over these patches and incorporate
>> the ideas into freeradius for future releases.
>
>
> Hi John,
> I had trouble applying the patches to 2.1.x git -- maybe because they got
> mushed during the email process.
>
> Adding the bits by hand seemed to work, and I can confirm the result is as
> you describe on an iPhone (that's all I had to hand to test).
>
> Attached are the two 'git diff' that I ended up with.
Hi John,
It works on Mac OS and iOS, but I havn't been able to get it to work as
expected on XP or Win7:
* Win7 does as it did before
* XP: The [builtin] supplicant gets stuck at the 'tryng to authenticate'
message.
Could you forward your patches gzipped [so they don't get mangled] so I
can verify I have patched the source correctly?
Regards,
James
More information about the Freeradius-Users
mailing list