MS-CHAP-V2 with no retry

[John.Hayward at wheaton.edu]

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.

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.mayers at imperial.ac.uk>
> Reply-To: FreeRadius users mailing list
>     <freeradius-users at lists.freeradius.org>
> To: freeradius-users at lists.freeradius.org
> Subject: Re: MS-CHAP-V2 with no retry
> 
> On 04/21/2011 04:03 PM, John.Hayward at wheaton.edu wrote:
>> 
>> 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.
> -
> List info/subscribe/unsubscribe? See 
> http://www.freeradius.org/list/users.html
>