MS-CHAPv2, allow_retry=yes, but no code to handle the retry?

[James J J Hooper]

On 11/04/2012 17:24, James J J Hooper wrote:
> Hi All,
>
> FR 2.1.x Git, doing PEAP against AD via ntlm_auth. I thought that with:
>
> allow_retry = yes [in modules/mschap]
> and
> send_error = yes [in modules/eap]
>
> ...FR has the functionality to take the second password attempt, and
> re-try it against AD i.e. The scenario outlined in section 9.1.4 of
> RFC2759: <http://tools.ietf.org/html/rfc2759#section-9.1.4>
>
> I can't get it to work: Configuring as above does indeed make Windows
> re-prompt for the password if the first attempt is bad, but when this
> comes back to FR, nothing seems to be done with it.
>
> I've had a look at the code. From the little I can understand of it, the
> new challenge is generated into 'buffer', and sent back to the client in
> the MS-CHAP-Error attribute (C=<new-challenge>). However the challenge in
> buffer is not then "put somewhere safe" until the client sends it's
> response against the new challenge [having re-prompted the user for the
> correct password], and when the response comes in it isn't sent to
> do_mschap()
>
> Am I mistaken and this functionality hasn't been written yet? ...or have I
> mis-configured something?

Ok - More delving into the code (rlm_eap_mschapv2.c) seems to indicate 
that the bits missing in 2.1.x are possibly there in FR3:

+
+			/*
+			 *	Pxarse the new challenge out of the
+			 *	MS-CHAP-Error, so that if the client
+			 *	issues a re-try, we will know which
+			 *	challenge value that they used.
+			 */
+			n = sscanf(response->vp_strvalue, "%*cE=%d R=%d C=%32s", &err, &retry, 
&buf[0]);
+			if (n == 3) {
+				DEBUG2("  Found new challenge from MS-CHAP-Error: err=%d retry=%d 
challenge=%s", err, retry, buf);
+				fr_hex2bin(buf, data->challenge, 16);
+			} else {
+				DEBUG2("  Could not parse new challenge from MS-CHAP-Error: %d", n);
+			}


So I'll see about getting an FR3 test instance going :)

-James