MS-CHAP-V2 with no retry

[Phil Mayers]

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.