Re: MS-CHAP-V2 with no retry
Alan DeKok
> It works on Mac OS and iOS, but I havn't been able to get it to work
> as expected on XP or Win7:
> * Win7 does as it did before
That's not all bad.
> * XP: The [builtin] supplicant gets stuck at the 'tryng to authenticate'
> message.
That's not good.
> Could you forward your patches gzipped [so they don't get mangled] so I
> can verify I have patched the source correctly?
I'll put some fixes into git "v2.1.x" branch later today, I think.
Changing the EAP-MSCHAP state machine worries me. It works now, so
doing something *different* is a potential source of problems.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Phil Mayers
> James J J Hooper wrote:
>> It works on Mac OS and iOS, but I havn't been able to get it to work
>> as expected on XP or Win7:
>> * Win7 does as it did before
>
> That's not all bad.
>
>> * XP: The [builtin] supplicant gets stuck at the 'tryng to authenticate'
>> message.
>
> That's not good.
>
>> Could you forward your patches gzipped [so they don't get mangled] so I
>> can verify I have patched the source correctly?
>
> I'll put some fixes into git "v2.1.x" branch later today, I think.
>
> Changing the EAP-MSCHAP state machine worries me. It works now, so
> doing something *different* is a potential source of problems.
+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...
I also think that, if we're aiming to make the behaviour "better" we
should take a careful look at what IAS/NPS does; we maintain a "for
comparison" server for just such cases, and I'll try to have a look today.
Alan DeKok
> +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.
Alan DeKok.
John Hayward
o It was my impression based on comments from our support area that the unpatched code (which does not follow the rfc) serving a windows client presented the user with a dialogue box on failure. I have not tested this. I assumed that if windows could deal reasonably with a server which did not follow the rfc they could also work with one that did (possibly wrong assumption - but they are the ones which wrote the rfc).
o It is known that various versions of the mac client fail in different respects - however they seem to fail consistently in that if retry is allowed they fail to increment the ID when retrying - on the MS radius server discards the retry because it is not following the protocol. You can get macs to play by configuring the server to not allow retries. So if you are going to test macs on the MS radius server you might try both with retry and without retry.
o In this case it appears that in this case there have been more issues with mac wpa_clients than windows wpa_clients.
o Testing of both windows and mac with out the patch and with the patch need to be done.
johnh...
________________________________________
From: freeradius-users-bounces+john.hayward=wheat...@lists.freeradius.org [freeradius-users-bounces+john.hayward=wheat...@lists.freeradius.org] on behalf of Alan DeKok [al...@deployingradius.com]
Sent: Friday, April 08, 2011 2:54 AM
To: FreeRadius users mailing list
Subject: Re: MS-CHAP-V2 with no retry
James J J Hooper
> 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
...as per attached diff?
-James
Alan DeKok
> Failure packet, should be an EAP *request* (currently it's EAP failure)??
Yes, thanks.
I've deleted the setting of the EAP code. It's set in the "compose"
function to "eap request".
Phil Mayers
> 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,
>
> Failure packet, should be an EAP *request* (currently it's EAP failure)??
>
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.
James J J Hooper
> James J J Hooper wrote:
>> 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)??
>
Also, args to pairmove2 are wrong way around, as attached.
-James
James J J Hooper
After that last change (p4.txt.gz), I think it's now doing the right thing:
* wpa_supplicant output matches Phil's (against W2k8 NPS), with the
exception that M=... is always present.
* With allow_retry = no, XP pop's up the usual 'enter credentials...'
bubble, and box.
* With allow_retry = yes, XP pops a "click to process credentials" bubble,
then a "type your password again" box:
http://www.wireless.bris.ac.uk/gfx/random/xp--retry-is-yes.png
-James
--
James J J Hooper
Network Specialist, University of Bristol
http://www.wireless.bristol.ac.uk
--
James J J Hooper
> On 10/04/2011 12:16, James J J Hooper wrote:
>> On 10/04/2011 07:03, Alan DeKok wrote:
>>> James J J Hooper wrote:
>>>> 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)??
>>>
>>> Yes, thanks.
>>
>>
>> Also, args to pairmove2 are wrong way around, as attached.
>>
>
>
> After that last change (p4.txt.gz), I think it's now doing the right thing:
>
> * wpa_supplicant output matches Phil's (against W2k8 NPS), with the
> exception that M=... is always present.
>
> * With allow_retry = no, XP pop's up the usual 'enter credentials...'
> bubble, and box.
>
> * With allow_retry = yes, XP pops a "click to process credentials" bubble,
> then a "type your password again" box:
> http://www.wireless.bris.ac.uk/gfx/random/xp--retry-is-yes.png
...Although, when you correct the password in the 'allow_retry = yes"
popup, I don't think FR has got the bit to handle that yet:
Found Auth-Type = eduroamalieneap-bris-sha-ca
# Executing group from file
/usr/local/etc/raddb/sites-enabled/eduroamalien-inner
+- entering group eduroamalieneap-bris-sha-ca {...}
[eduroamalieneap-bris-sha-ca] Request found, released from the list
[eduroamalieneap-bris-sha-ca] EAP/mschapv2
[eduroamalieneap-bris-sha-ca] processing type mschapv2
rlm_eap_mschapv2: Unexpected response received << ***
[eduroamalieneap-bris-sha-ca] Handler failed in EAP/mschapv2
[eduroamalieneap-bris-sha-ca] Failed in EAP select
++[eduroamalieneap-bris-sha-ca] returns invalid
Failed to authenticate the user.
Login incorrect: [jh17...@bris.ac.uk] (from client JamesJJ port 256 cli
00-1a-4d-35-b0-5a via TLS tunnel)
} # server eduroamalien-inner
[peap] Got tunneled reply code 3
EAP-Message = 0x040c0004
Message-Authenticator = 0x00000000000000000000000000000000
[peap] Got tunneled reply RADIUS code 3
EAP-Message = 0x040c0004
Message-Authenticator = 0x00000000000000000000000000000000
[peap] Tunneled authentication was rejected.
[peap] FAILURE
-James
Alan DeKok
> Also, args to pairmove2 are wrong way around, as attached.
Applied, thanks.
Alan DeKok.
Alan DeKok
> popup, I don't think FR has got the bit to handle that yet:
>
> Found Auth-Type = eduroamalieneap-bris-sha-ca
> # Executing group from file
> /usr/local/etc/raddb/sites-enabled/eduroamalien-inner
> +- entering group eduroamalieneap-bris-sha-ca {...}
> [eduroamalieneap-bris-sha-ca] Request found, released from the list
> [eduroamalieneap-bris-sha-ca] EAP/mschapv2
> [eduroamalieneap-bris-sha-ca] processing type mschapv2
> rlm_eap_mschapv2: Unexpected response received << ***
Ah... it's supposed to try the MS-CHAP stuff again. Nice!
I'm travelling to networkshop soon, but I'll see if I poke at it this
week. If I'm right, the fix should be pretty simple. But it will need
to be tested by people.
James J J Hooper
> On 10/04/2011 12:39, James J J Hooper wrote:
>> On 10/04/2011 12:16, James J J Hooper wrote:
>>> On 10/04/2011 07:03, Alan DeKok wrote:
>>>>> Failure packet, should be an EAP *request* (currently it's EAP
>>>>> failure)??
>>>>
>>>> Yes, thanks.
>>>
>>>
>>>
>>
>>
>>
>> * wpa_supplicant output matches Phil's (against W2k8 NPS), with the
>> exception that M=... is always present.
>>
>> * With allow_retry = no, XP pop's up the usual 'enter credentials...'
>> bubble, and box.
>>
>> * With allow_retry = yes, XP pops a "click to process credentials" bubble,
>> then a "type your password again" box:
>> http://www.wireless.bris.ac.uk/gfx/random/xp--retry-is-yes.png
>
>
> popup, I don't think FR has got the bit to handle that yet:
>
> Found Auth-Type = eduroamalieneap-bris-sha-ca
> # Executing group from file
> /usr/local/etc/raddb/sites-enabled/eduroamalien-inner
> +- entering group eduroamalieneap-bris-sha-ca {...}
> [eduroamalieneap-bris-sha-ca] Request found, released from the list
> [eduroamalieneap-bris-sha-ca] EAP/mschapv2
> [eduroamalieneap-bris-sha-ca] processing type mschapv2
> rlm_eap_mschapv2: Unexpected response received << ***
> [eduroamalieneap-bris-sha-ca] Failed in EAP select
> ++[eduroamalieneap-bris-sha-ca] returns invalid
> Failed to authenticate the user.
> Login incorrect: [jh17...@bris.ac.uk] (from client JamesJJ port 256 cli
> 00-1a-4d-35-b0-5a via TLS tunnel)
> } # server eduroamalien-inner
> [peap] Got tunneled reply code 3
> EAP-Message = 0x040c0004
> Message-Authenticator = 0x00000000000000000000000000000000
> [peap] Got tunneled reply RADIUS code 3
> EAP-Message = 0x040c0004
> Message-Authenticator = 0x00000000000000000000000000000000
> [peap] Tunneled authentication was rejected.
> [peap] FAILURE
I think it needs two things now:
1)
Something like:
@@ -433,8 +433,8 @@ static int mschapv2_authenticate(void *arg,
EAP_HANDLER *handler)
* a challenge.
*/
case PW_EAP_MSCHAPV2_RESPONSE:
- if (data->code != PW_EAP_MSCHAPV2_CHALLENGE) {
- radlog(L_ERR, "rlm_eap_mschapv2: Unexpected
response received");
+ if ((data->code != PW_EAP_MSCHAPV2_CHALLENGE) &&
(data->code != PW_EAP_MSCHAPV2_FAILURE)) {
+ radlog(L_ERR, "rlm_eap_mschapv2: Unexpected
response received: %d", data->code);
return 0;
}
... because the response to our MSCHAPV2_FAILURE seems to be a
MSCHAPV2_FAILURE
2)
if (inst->retry_msg) {
snprintf(buffer + 9, sizeof(buffer), " C=");
for (i = 0; i < 16; i++) {
snprintf(buffer + 12 + i*2,
sizeof(buffer), "%02x",
fr_rand() & 0xff);
}
This C=<random> needs to be saved and eventually make it's way in to
data->challenge so that the line lower down:
memcpy(challenge->vp_strvalue, data->challenge, MSCHAPV2_CHALLENGE_LEN);
has the correct challenge, and can then process the clients "retry" correctly?
(help, I havn't managed to work out the mechanism from the current
challenge generation bits yet!)
-James
Phil Mayers
>
> This C=<random> needs to be saved and eventually make it's way in to
> data->challenge so that the line lower down:
> memcpy(challenge->vp_strvalue, data->challenge, MSCHAPV2_CHALLENGE_LEN);
It's actually a bit more complex; the new challenge is being generated
inside rlm_mschap as part of the error, but AFACIT rlm_eap_mschapv2
needs to know it, so that it can add it to the fake request which it
then passes *back* into rlm_mschap as an MS-CHAP-Challenge attribute.
This would also get us part of the way there to password change via
mschap (Samba currently lacks the specific API call to do this, with the
values available in an MSCHAP CPW packet, but it might be possible to
compile a C helper which does it...)
Phil Mayers
>
> I'll spin up an SSID and give it a try with real clients later today.
Regrettably I can report that this does not work with Symbian.
With "send_error = no", incorrect username/password reports "EAP/PEAP
authentication failed"
With "send_error = yes", the client just hangs (and in fact crashed my
phone several times)
:o(
Alan DeKok
> With "send_error = yes", the client just hangs (and in fact crashed my
> phone several times)
Nice to know!
Alan DeKok.
John.H...@wheaton.edu
weekend.
There have been some fixes and extensions to my original patches and I
saw a commit on Friday before some fixes and extensions were in place.
Can someone point me to exactly what I need to "git" to get the current
version of freeradius with the patches so I can do some testing at our
site?
TIA.
johnh...
On Mon, 11 Apr 2011, Phil Mayers wrote:
> Date: Mon, 11 Apr 2011 08:45:13
> From: Phil Mayers <p.ma...@imperial.ac.uk>
> Reply-To: FreeRadius users mailing list
> <freeradi...@lists.freeradius.org>
> To: freeradi...@lists.freeradius.org
> Subject: Re: MS-CHAP-V2 with no retry
>
> The attached patch against git v2.1.x branch makes EAP-MSCHAPV2 retry work
> for me.
>
> It needs a bit of work, specifically there should be a:
>
> num_retries
>
> ...parameter, and the EAP module should keep track of retry attempt counts,
> and stop when either:
>
> try_number > num_retries
>
> or
>
> R=0 in the MS-CHAP-Error attribute
>
> Also, I pulled the EAP-MSCHAPV2 state machine to bits, so I'm not sure it
> should go into 2.1.11 - there's probably not enough testing time.
>
> It works for a Windows XP SP3 client here, as well as with a jury-rigged
> eapol_test/wpa_cli combo.
>
> I'll spin up an SSID and give it a try with real clients later today.
>
> Of note: this gets us nearer to MS-CHAP change-password functionality; I've
> looked into this a couple of times recently and Samba has almost all the bits
> required to make it work... However, that would require some infrastructure
> for the server to override the MS-CHAP error code, currently hard-coded at
> 691 - 648 is "password expired" and would need to be set, either by parsing
> the output of ntlm_auth (for those that use it) or from some SQL/database
> attribute (for those using Cleartext/NT-Password)
Alan DeKok
> Can someone point me to exactly what I need to "git" to get the current
> version of freeradius with the patches so I can do some testing at our
> site?
Grab the v2.1.x branch. Read raddb/modules/mschap, and
raddb/eap.conf, the "mschapv2" section.
Alan DeKok.
John.H...@wheaton.edu
related to error and retires.
There are two items I observed with testing:
1) If I sent a HUP signal to the server it appears to re-read the
configuration files but for some reason does not re-read the mschap module
- so changing this module while testing seemed to require a restart on the
server. Is that the expected behavior?
2) If retry=yes then on Windows-7 on failure a notification is given if
they click they are presented with a message indicating their username or
password are incorrect and given an opportunity to re-enter only a
password. If they enter the correct password the authentication fails and
they have to re-connect to get a duologue box where they can enter both
the username and password. I have not traced down to determine why the
client thinks there is a failure (eg need to see if FRS thinks it is a
failure or not). This I believe is not what should be happening.
johnh...
On Wed, 13 Apr 2011, John.H...@wheaton.edu wrote:
> Date: Wed, 13 Apr 2011 16:19:26
> From: John.H...@wheaton.edu
> To: FreeRadius users mailing list <freeradi...@lists.freeradius.org>
> Subject: Re: MS-CHAP-V2 with no retry
>
> First - thanks to the free radius group for all the work on this over the
> weekend.
>
> There have been some fixes and extensions to my original patches and I saw a
> commit on Friday before some fixes and extensions were in place.
>
> Can someone point me to exactly what I need to "git" to get the current
> version of freeradius with the patches so I can do some testing at our site?
>
Phil Mayers
> I have been able to do some testing with the adjustments for MS-CHAP-V2
> related to error and retires.
>
> There are two items I observed with testing:
>
> 1) If I sent a HUP signal to the server it appears to re-read the
> configuration files but for some reason does not re-read the mschap
> module - so changing this module while testing seemed to require a
> restart on the server. Is that the expected behavior?
rlm_mschap doesn't implement a HUP handler AFAICT. It probably wouldn't
be terribly hard to write one - the module is fairly stateless. It's
probably best to just restart the server though.
> 2) If retry=yes then on Windows-7 on failure a notification is given if
> they click they are presented with a message indicating their username
> or password are incorrect and given an opportunity to re-enter only a
> password. If they enter the correct password the authentication fails
> and they have to re-connect to get a duologue box where they can enter
> both the username and password. I have not traced down to determine why
> the client thinks there is a failure (eg need to see if FRS thinks it is
> a failure or not). This I believe is not what should be happening.
I think this is probably because the EAP-MSCHAP modules needs to parse
and store the new challenge in the error message. If it doesn't, the
server and client will disagree on the challenge/response value and auth
will fail
This patch implements the required behaviour (as part of the "support
password change" code):
https://github.com/philmayers/freeradius-server/commit/44a81366fb0b909d9165ec5650004bd979c0f9d9
John.H...@wheaton.edu
tomorrow.
On the re-reading of config I can live without the HUP not causing mschap
to re-read it's config - just assumed that it would.
johnh...
On Wed, 20 Apr 2011, Phil Mayers wrote:
> Date: Wed, 20 Apr 2011 17:53:42
> From: Phil Mayers <p.ma...@imperial.ac.uk>
> Reply-To: FreeRadius users mailing list
> <freeradi...@lists.freeradius.org>
> To: freeradi...@lists.freeradius.org
> Subject: Re: MS-CHAP-V2 with no retry
>
Alan DeKok
> rlm_mschap doesn't implement a HUP handler AFAICT. It probably wouldn't
> be terribly hard to write one - the module is fairly stateless. It's
> probably best to just restart the server though.
I think it's safe just to mark the module HUP-safe. It wasn't marked
that way before because it had code to read a "smbpasswd" file. That
has since been removed.
Alan DeKok.
John.H...@wheaton.edu
In addition to Windows-7 behavior on Windows-XP, Macs and Iphones are as
expected with this retry patch - user is presented with a password
dialog box and the connection is not aborted - user only needs to enter
the correct password to be connected and no "contact your network
administrator" or other messages occur.
Our support people are thrilled.
johnh...
On Thu, 21 Apr 2011, John.H...@wheaton.edu wrote:
> Date: Thu, 21 Apr 2011 10:03:30
> From: John.H...@wheaton.edu
> Reply-To: FreeRadius users mailing list
> <freeradi...@lists.freeradius.org>
> To: FreeRadius users mailing list <freeradi...@lists.freeradius.org>
> Subject: Re: MS-CHAP-V2 with no retry
>
>
> Thanks again for your work on this facility.
>
> I built and installed with the new patches.
> Unfortunately things did not quite work - however with a small change I could
> get the retry to work properly on a windows7 machine.
>
> The problem is that when we do a retry in addition to setting the challenge
> value we also need to change the data->code to challenge rather than failure.
> When the response comes back we can correctly deal with it.
>
> ==== original patch -- with suggested changes **** ====
> 678 - pairmove2(&response, &handler->request->reply->vps,
> 679 - PW_MSCHAP_ERROR);
> 678 + pairmove2(&response, &handler->request->reply->vps,
> 679 + PW_MSCHAP_ERROR);
> **** add failure code by default
> data->code = PW_EAP_MSCHAPV2_FAILURE;
> ****
> 680 + if (response) {
> 681 + int n,err,retry;
> 682 + char buf[34];
> 683 + 684 + DEBUG2(" MSCHAP-Error: %s", response->vp_strvalue);
> 685 +
> 686 + /*
> 687 + * parse the new challenge out of the MS-CHAP-Error, so if the
> client
> 688 + * issues a re-try, we'll know the challenge value they used
> 689 + */
> 690 + n = sscanf(response->vp_strvalue, "%*cE=%d R=%d C=%32s", &err,
> &retry, &buf);
> 691 + if (n==3) {
> 692 + DEBUG2(" Found new challenge from MS-CHAP-Error: err=%d
> retry=%d challenge=%s", err, retry, buf);
> 693 + fr_hex2bin(buf, data->challenge, 16);
> **** Set code to challenge if we find a challenge
> data->code = PW_EAP_MSCHAPV2_CHALLENGE;
> ****
> 694 + } else {
> 695 + DEBUG2(" Could not parse new challenge from MS-CHAP-Error: %d",
> n);
> 696 + }
> 697 + }
> 680
> **** remove this code since set above
> 698 data->code = PW_EAP_MSCHAPV2_FAILURE;
> ****
> ==== END OF original patch ===
>
> johnh...
Phil Mayers
>
> Thanks again for your work on this facility.
>
> I built and installed with the new patches.
> Unfortunately things did not quite work - however with a small change I
> could get the retry to work properly on a windows7 machine.
>
> The problem is that when we do a retry in addition to setting the
> challenge value we also need to change the data->code to challenge
> rather than failure. When the response comes back we can correctly deal
> with it.
Hmm. I don't see that behaviour. That is probably due to the later
changes I made in the EAP-MSCHAPv2 state machine, here:
https://github.com/philmayers/freeradius-server/commit/8e3eece6e3c397f3a4b0c06a37a80bc8964997fd
Specifically, the old code compares client current opcode against server
last opcode; the patch I wrote above does a switch over server last
opcode, then permits one or more valid client opcodes. Response is
specifically permitted after failure, as it change-password (opcode 7).
>
> ==== original patch -- with suggested changes **** ====
> 678 - pairmove2(&response, &handler->request->reply->vps,
This patch is a bit "magic" for my tastes. The only reason it works is
because eapmschapv2_compose completely ignores data->code - it chooses
the EAP-MSCHAPv2 opcode based on the 2nd VALUE_PAIR* argument.
So essentially you're setting data->code to trick the state machine in
mschapv2_authenticate, but to someone unfamiliar with the code it would
read like you're sending a challenge back, which you're not - you're
sending a failure back.
An alternative approach would be:
--- rlm_eap_mschapv2.c~ 2010-10-13 13:34:16.000000000 +0100
+++ rlm_eap_mschapv2.c 2011-04-21 18:08:19.000000000 +0100
@@ -424,10 +424,6 @@
* a challenge.
*/
case PW_EAP_MSCHAPV2_RESPONSE:
- if (data->code != PW_EAP_MSCHAPV2_CHALLENGE) {
- radlog(L_ERR, "rlm_eap_mschapv2: Unexpected response received");
- return 0;
- }
/*
* Ensure that we have at least enough data
i.e. remove the check for "client opcode 'response' only valid if we
sent a 'challenge'". Or of course, widen the check to:
challenge
or
failure
Anyway, they're more or less equivalent. A matter of taste I guess.
John.H...@wheaton.edu
each failure could be counted and send a R=0 after a certain number of
failures.
I had briefly looked at the other area and decided it would take more
changes work with a response from a failure code than adjust it over when
sending the failure with a challenge.
Do we know if the password change (and adjustments to retry which make it
work) will be included in 2.1.11?
johnh...
On Thu, 21 Apr 2011, Phil Mayers wrote:
> Date: Thu, 21 Apr 2011 12:17:55
> From: Phil Mayers <p.ma...@imperial.ac.uk>
> Reply-To: FreeRadius users mailing list
> <freeradi...@lists.freeradius.org>
> To: freeradi...@lists.freeradius.org
> Subject: Re: MS-CHAP-V2 with no retry
>
Alan DeKok
> I like your changes better. It allows to in the future add a retry max
> so each failure could be counted and send a R=0 after a certain number
> of failures.
The EAP module already does *some* checking of this. If there are
more than ~40 or so round trips, it discards the session.
However, it may be useful to limit the retries here to no more than 2.
> Do we know if the password change (and adjustments to retry which make
> it work) will be included in 2.1.11?
If enough people test it and say it works.
2.1.11 is a "stable" release, so breaking things is very, very, bad.
Alan DeKok.
Alan Buxey
> > Do we know if the password change (and adjustments to retry which make
> > it work) will be included in 2.1.11?
>
> If enough people test it and say it works.
do we have a direct single known patch now for application to a 2.1.10
source? (theres been a lot of subtle updates flying around)
alan
Phil Mayers
> Hi,
>
>>> Do we know if the password change (and adjustments to retry which make
>>> it work) will be included in 2.1.11?
>>
>> If enough people test it and say it works.
>
> do we have a direct single known patch now for application to a 2.1.10
> source? (theres been a lot of subtle updates flying around)
The patch I wrote is against the v2.1.x development branch (i.e. against
2.1.11-pre, really) and comes in the form of 5 separate commits (an
attempt at making it "easy" to review ;o)
So no - not a single source patch to 2.1.10. It would be a bit tricky to
generate without pulling in lots of the unrelated stuff that's going
into 2.1.11, and I'm on holiday at the moment so would like to skip
generating one!
https://github.com/philmayers/freeradius-server/tarball/v2.1.x-mschap-changepass
...might give you the full source; it's not a feature of github I've
used before.