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.