rlm_rest learnings - PAP and PEAP/MSCHAPv2

[Lang, Russell]

>> radtest -t mschap valid-user at domain invalid_password 127.0.0.1 0 radius_secret 
>>  replied with  MS-CHAP-Error = "\000E=691 R=1 C=ad8367a70f809d72 V=2"
>> My reading of the MS-CHAP-V2 RFC2759 and PPP CHAP RFC1994 is that this 
>> should have been  MS-CHAP-Error = "E=691 R=1 C=ad8367a70f809d72 V=2"

Alan wrote:
>  RFC 1994 Section 4 states that the packet format contains a one-octet identifier.  In this case, the leading "\000".
>  RFC 2433 and 2759 say that the Failure packet is identical in formation to the normal CHAP message format.  i.e. with the identifier.
>  Further, FreeRADIUS interoperates with all MS-CHAP implementations, which add the 1-octet identifier, and which look for it.

Thanks.  My confusion was that I was reading the PPP CHAP/MSCHAP RFCs, but I needed to read RFC 2548, 
Microsoft Vendor-specific RADIUS Attributes.
PPP and RADIUS store the fields differently for MS-CHAP-Error.
PPP MSCHAP packet contains a code, identifier, length, message.
RADIUS MSCHAP VSA contains vsa_attribute, length, identifier, message.
Radtest is showing everthing after the length, which in this case is identifier+message.

Arran wote:
> Add NT-Password to the session-state: list.  Only call the rest module if session-state:NT-Password isn't set, 
> otherwise copy session-state:NT-Password to the control list.

I did something similar, which is now working.
I added outer.session-state:NT-Password, because this was restored, while the session-state:NT-Password was not.
Since the real password is in control:NT-Password, we don't need the real password in session-state.
The inner-tunnel authorize config is now:
       if (!ok && !updated && !outer.session-state:NT-Password) {
                rest
                if (control:NT-Password) {
                        # Store "NT-Password" in the outer session state, so we know not to call REST API again
                        update outer.session-state {
                                &NT-Password = "Yes"
                        }
                }
        }


Regards,
Russell Lang


-----Original Message-----
From: Freeradius-Users <freeradius-users-bounces+russell.lang=team.telstra.com at lists.freeradius.org> On Behalf Of Alan DeKok
Sent: Thursday, 23 January 2020 11:13
To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
Subject: Re: rlm_rest learnings - PAP and PEAP/MSCHAPv2

[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

On Jan 19, 2020, at 9:29 PM, Lang, Russell <Russell.Lang at team.telstra.com> wrote:
> Using
> My reading of the MS-CHAP-V2 RFC2759 and PPP CHAP RFC1994 is that this 
> should have been  MS-CHAP-Error = "E=691 R=1 C=ad8367a70f809d72 V=2"

   RFC 1994 Section 4 states that the packet format contains a one-octet identifier.  In this case, the leading "\000".

  RFC 2433 and 2579 say that the Failure packet is identical in formation to the normal CHAP message format.  i.e. with the identifier.

  Further, FreeRADIUS interoperates with all MS-CHAP implementations, which add the 1-octet identifier, and which look for it.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html