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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
