rlm_rest learnings - PAP and PEAP/MSCHAPv2
Thanks to Arran for his hints on calling a REST API from FreeRADIUS. rlm_rest is working, doing authentication for WPA2-Personal (PAP via captive portal) and WPA2-Enterprise Wi-Fi clients (PEAP/MSCHAPv2). Using FreeRADIUS 3.0.16 (Ubuntu 18.04). PAP is handled in the default site, while the MSCHAP2 part of PEAP/MSCHAP2 is handled in the inner-tunnel. The trick is preventing the REST API from being called in the default site with EAP outer messages, which would result in 9 unwanted API calls. The authorize REST API code does pre-authentication and if it passes it returns the NT-Password or Cleartext-Password as appropriate. To find out if the user was authenticated, a post-auth REST API is used to log success/failure. rest module configuration: authorize { uri = "RADIUS_API_PATH/radius?action=authorize" method = 'post' body = 'json' auth = 'basic' username = 'RADIUS_API_USER' password = 'RADIUS_API_PASSWORD' } post-auth { uri = "RADIUS_API_PATH/radius?action=post-auth&result=%{control:Post-Auth-Type}" # result is either '' or 'Reject' ... } API pseudo code for authorize: if pre-authenticated if mschap return { "control:NT-Password": {"type":"octets","value":[ "0x0123456789ABCDEF0123456789ABCDEF" ]}}, 200 else return { "control:Cleartext-Password": {"type":"string","value":[ "clear-text-password-here" ]}}, 200 else: return {}, 401 default site config: authorize { mschap eap { ok = return } if (!ok && !updated) { # Only call rest if not handled by EAP rest } pap } post-auth { ... if (!&reply:EAP-Message) { # Only call rest if not EAP rest } ... } inner-site config: authorize { mschap eap { ok = return } if (!ok && !updated) { # Only call rest if not already handled rest } pap } post-auth { ... rest ... } Issues: When doing PEAP/MSCHAPv2, the authorize REST API gets called twice in the inner-tunnel, for two different EAP messages. Wastes a few milliseconds, but only a minor issue. Using radtest -t mschap valid-user@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"
Issues: When doing PEAP/MSCHAPv2, the authorize REST API gets called twice in the inner-tunnel, for two different EAP messages. Wastes a few milliseconds, but only a minor issue.
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.
Using radtest -t mschap valid-user@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"
Hm, feel free to track it down and submit a PR :) Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Jan 19, 2020, at 9:29 PM, Lang, Russell <Russell.Lang@team.telstra.com> wrote:
Using radtest -t mschap valid-user@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"
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.
radtest -t mschap valid-user@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@lists.freeradius.org> On Behalf Of Alan DeKok Sent: Thursday, 23 January 2020 11:13 To: FreeRadius users mailing list <freeradius-users@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@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
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Lang, Russell