MS-CHAP-V2 with no retry

[John.Hayward at wheaton.edu]

On Wed, 9 Mar 2011, Alan DeKok wrote:

> Date: Wed, 9 Mar 2011 01:25:10
> From: Alan DeKok <aland at deployingradius.com>
> Reply-To: FreeRadius users mailing list
>     <freeradius-users at lists.freeradius.org>
> To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
> Subject: Re: MS-CHAP-V2 with no retry
> 
> John Hayward wrote:
>> Any idea of the time frame?
>
>  A long time.
>
>> Should I spend my time looking at the code and proposing a patch?
>
>  Sure.
>
>  Alan DeKok.
> -
> 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:
=== rlm_mschap.c (from src/modules/rlm_mschap/)
1242,1252c1242
< /* JCH - changes to include challenge and message */
<                         char msg[100];
<                         strcpy(msg, "E=691 R=0 C=");
<                         int i, offset = strlen(msg);
<                         char *ptr = &msg[offset];
<                         for (i=0; i<16; i++, ptr+=2) {
<                            sprintf(ptr, "%02X", response->vp_octets[i+2]);
<                         }
<                         *ptr = 0;
<                         strcat(msg, " V=3 M=May Need to reset cashed password"
);
<                       mschap_add_reply(request, &request->reply->vps,
---
>                       mschap_add_reply(request, &request->reply->vps,
1254c1244
<                                        "MS-CHAP-Error", msg, strlen(msg));
---
>                                        "MS-CHAP-Error", "E=691 R=1", 9);
1299d1288
< /* JCH should we check for MS-CHAPV2 and modify the reply to include challenge
? */
====

==== from /src/modules/rlm_eap/types/rlm_eap_mschapv2/rlm_eap_mschapv2.c
198c198,200
<               length = 4 + MSCHAPV2_FAILURE_MESSAGE_LEN;
---
> /* JCH need to be change length to work with full v2 message  */
>               //length = 4 + MSCHAPV2_FAILURE_MESSAGE_LEN;
>                 length = 4 + reply->length-1;
215c217,222
<               memcpy((eap_ds->request->type.data + 4), 
MSCHAPV2_FAILURE_MESSAG
E, MSCHAPV2_FAILURE_MESSAGE_LEN);
---
> /* JCH need to copy the failure message from mschapv2 - it contains 
ascii
>    version of the challenge C=...
> */
>               memcpy((eap_ds->request->type.data + 4), 
(reply->vp_strvalue+1),
>                     (reply->length-1));
> //MSCHAPV2_FAILURE_MESSAGE, MSCHAPV2_FAILURE_MESSAGE_LEN);
487a495,505
> /*JCH added - is this is an ack of a failure message */
>         case PW_EAP_MSCHAPV2_FAILURE:
>               if (data->code != PW_EAP_MSCHAPV2_FAILURE) {
>                       radlog(L_ERR, "rlm_eap_mschapv2: Unexpected FAILURE received");
>                       return 0;
>               }
>               //JCH needed??? handler->request->options &= 
~RAD_REQUEST_OPTION
_PROXY_EAP;
>                 eap_ds->request->code = PW_EAP_FAILURE;
>                 return 1;
>                 break;
>
658a677,680
>                 /* JCH this is in response to the failure ack - return
>                    failure packet - don't return yet need to send
>                  */
>
660,662c682
<               return 1;
< #if 0
<               pairmove2(&handler->request->reply->vps, &response
---
>               pairmove2(&response, &handler->request->reply->vps,
665d684
< #endif
======

==== 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.

johnh...