MS-CHAP-V2 with no retry

[Phil Mayers]

On 04/09/2011 06:18 PM, James J J Hooper wrote:
> On 08/04/2011 08:54, Alan DeKok wrote:
>> Phil Mayers wrote:
>>> +1 - In my experience it's necessary to cater for windows' weirdness
>>> *first*. Most other clients have sane behaviours. I'm concerned about
>>> the "we didn't do much windows testing" line...
>>
>> Yup.
>>
>> I've just pushed some changes to the git "v2.1.x" branch. See:
>>
>> raddb/modules/mschap
>> - allow_retry
>> - retry_msg
>>
>> raddb/eap.socn
>> - send_error
>>
>> The default is no change. See the documentation for how to test the
>> new features.
>
> Hi Alan,
>
> I've may have mis-understood the code, but I think the EAP MS-CHAP-v2
> Failure packet, should be an EAP *request* (currently it's EAP failure)??
>
> http://tools.ietf.org/html/draft-kamath-pppext-eap-mschapv2-01#page-12

All,

People might find this helpful; if you send an invalid password for an 
otherwise-active account, Windows 2008R2 NPS sends an EAP request, 
containing an MS-CHAP error with R=1 and does *not* end the EAP/PEAP 
session - I am assuming a windows client could, in this case, re-try 
MS-CHAP without restarting the PEAP session, using the challenge sent in 
the MS-CHAP error.

eapol_test shows this for the final packket:

decapsulated EAP packet (code=1 id=7 len=91) from RADIUS server: 
EAP-Request-PEAP (25)
EAPOL: Received EAP-Packet frame
EAPOL: SUPP_BE entering state REQUEST
EAPOL: getSuppRsp
EAP: EAP entering state RECEIVED
EAP: Received EAP-Request id=7 method=25 vendor=0 vendorMethod=0
EAP: EAP entering state METHOD
SSL: Received packet(len=91) - Flags 0x00
EAP-PEAP: received 85 bytes encrypted data for Phase 2
EAP-PEAP: Decrypted Phase 2 EAP - hexdump(len=53): 1a 04 06 00 34 45 3d 
36 39 31 20 52 3d 31 20 43 3d 36 37 46 43 33 44 45 32 30 38 31 30 45 33 
34 35 37 41 30 41 39 41 37 34 42 43 37 45 31 30 45 32 20 56 3d 33
EAP-PEAP: received Phase 2: code=1 identifier=7 length=57
EAP-PEAP: Phase 2 Request: type=26
EAP-MSCHAPV2: RX identifier 7 mschapv2_id 6
EAP-MSCHAPV2: Received failure
EAP-MSCHAPV2: Failure data - hexdump_ascii(len=48):
      45 3d 36 39 31 20 52 3d 31 20 43 3d 36 37 46 43   E=691 R=1 C=67FC
      33 44 45 32 30 38 31 30 45 33 34 35 37 41 30 41   3DE20810E3457A0A
      39 41 37 34 42 43 37 45 31 30 45 32 20 56 3d 33   9A74BC7E10E2 V=3
EAP-MSCHAPV2: error 691
EAP-MSCHAPV2: retry is allowed
EAP-MSCHAPV2: failure challenge - hexdump(len=16): 67 fc 3d e2 08 10 e3 
45 7a 0a 9a 74 bc 7e 10 e2
EAP-MSCHAPV2: password changing protocol version 3
EAP-MSCHAPV2: failure message: '' (retry allowed, error 691)
EAPOL: EAP parameter needed
EAPOL: EAP parameter needed

I will try with a windows client on Monday; I suspect it'll continue 
inside the existing PEAP tunnel with a retry since R=1, which means if 
we want to get the "right" behaviour as defined by the Microsoft 
implementation (PEAP is after all their protocol) we might be doing the 
wrong thing.