J***@wheaton.edu
2011-04-06 20:42:11 UTC
Date: Wed, 9 Mar 2011 01:25:10
Reply-To: FreeRadius users mailing list
Subject: Re: MS-CHAP-V2 with no retry
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.Reply-To: FreeRadius users mailing list
Subject: Re: MS-CHAP-V2 with no retry
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
=== 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//length = 4 + MSCHAPV2_FAILURE_MESSAGE_LEN;
length = 4 + reply->length-1;
< 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
asciiversion of the challenge C=...
*/
memcpy((eap_ds->request->type.data + 4),
(reply->vp_strvalue+1),*/
memcpy((eap_ds->request->type.data + 4),
(reply->length-1));
//MSCHAPV2_FAILURE_MESSAGE, MSCHAPV2_FAILURE_MESSAGE_LEN);
487a495,505//MSCHAPV2_FAILURE_MESSAGE, MSCHAPV2_FAILURE_MESSAGE_LEN);
/*JCH added - is this is an ack of a failure message */
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_OPTIONif (data->code != PW_EAP_MSCHAPV2_FAILURE) {
radlog(L_ERR, "rlm_eap_mschapv2: Unexpected FAILURE received");
return 0;
}
//JCH needed??? handler->request->options &=
_PROXY_EAP;
eap_ds->request->code = PW_EAP_FAILURE;
return 1;
break;
658a677,680return 1;
break;
/* JCH this is in response to the failure ack - return
failure packet - don't return yet need to send
*/
660,662c682failure packet - don't return yet need to send
*/
< 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...
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
