[RADIATOR] TTLS with inner MSCHAPv2 vs. inner EAP-MSCHAPv2
Hi, we are having an issue with authenticating TTLS when the supplicant uses plain MSCHAPv2 instead of EAP-MSCHAPv2 1. Testing with eapoltest and following config in eapol_test: - eap=TTLS phase2="auth=MSCHAPV2" produces following request when the request is reinjected into the inner handler: Code: Access-Request Identifier: UNDEF Authentic: <238>g<236>Z<18>2<187>dmM$<242><223><30><209>4 Attributes: User-Name = "" MS-CHAP-Challenge = <25><208><7><142>6Q<145>|`<157>P<251><194><203><233><156> MS-CHAP2-Response = ^<0><0><2><0>x<173><6><0> <0><0><0>;<0><0><0>h<0><0><0><0><0><0><0><0><214><233><146>R<152><167><214>xg<181><254><255>BS<175>@<204><29>=<1><225>|N<248> This fails to provide a challenge. Tue Jun 9 09:32:25 2015 986798: DEBUG: Radius::AuthSQL looks for match with X [X] Tue Jun 9 09:32:25 2015 987631: DEBUG: Radius::AuthSQL ACCEPT: : X [X] And subsequently fails. 2. Testing with eapoltest and following config in eapol_test: - eap=TTLS phase2="autheap=MSCHAPV2" produces following request when the request is reinjected into the inner handler: Code: Access-Request Identifier: UNDEF Authentic: <137>'H<220><247><247><152>z<186><145><230><133>i<216>?<227> Attributes: EAP-Message = <2><1><0>B<26><2><1><0>=1<3>A2<127><165><224>7<193><148><163>s<223><251><182><146><231><0><0><0><0><0><0><0><0>C<194><27>vv1<20><29>]h$/<149><17><159><202>I<6><128><204><246>"<186><189><0>radperf Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> User-Name = "anonymous" Here we get a challenge: Tue Jun 9 10:57:58 2015 642003: DEBUG: Radius::AuthSQL ACCEPT: : xx [anonymous] Tue Jun 9 10:57:58 2015 642696: DEBUG: EAP result: 3, EAP MSCHAP V2 Challenge: Success Any tips where to start searching. We will try next to see if we can sucessfully authenticate TTLS/PAP in order to rule out any challenge issues. Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] TTLS with inner MSCHAPv2 vs. inner EAP-MSCHAPv2
On 9.6.2015 12.44, Christian Kratzer wrote: > we are having an issue with authenticating TTLS when the supplicant uses > plain MSCHAPv2 instead of EAP-MSCHAPv2 > > 1. Testing with eapoltest and following config in eapol_test: > - > > eap=TTLS > phase2="auth=MSCHAPV2" > > produces following request when the request is reinjected into the inner > handler: > > Code: Access-Request > Identifier: UNDEF > Authentic: <238>g<236>Z<18>2<187>dmM$<242><223><30><209>4 > Attributes: > User-Name = "" > MS-CHAP-Challenge = > <25><208><7><142>6Q<145>|`<157>P<251><194><203><233><156> > MS-CHAP2-Response = ^<0><0><2><0>x<173><6><0> > <0><0><0>;<0><0><0>h<0><0><0><0><0><0><0><0><214><233><146>R<152><167><214>xg<181><254><255>BS<175>@<204><29>=<1><225>|N<248> > > This fails to provide a challenge. > > Tue Jun 9 09:32:25 2015 986798: DEBUG: Radius::AuthSQL looks for match > with X [X] > Tue Jun 9 09:32:25 2015 987631: DEBUG: Radius::AuthSQL ACCEPT: : X > [X] > > And subsequently fails. It should now return accept or reject, not a challenge. If it accepts, it will tunnel MS-CHAP2-Success back to the client with the accept. The client then compares the received value with what it expects. The value it expects depends on the response the server calculates. The username and password are included in the calculated response. The server can not just say "yes" without knowing the password, that's the v2 part. Also, the username must be the same the client uses when it calculates its expected value. You should not rewrite it for plain MSCHAPv2. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] TTLS with inner MSCHAPv2 vs. inner EAP-MSCHAPv2
Hi, On Tue, 9 Jun 2015, Heikki Vatiainen wrote: > It should now return accept or reject, not a challenge. If it accepts, > it will tunnel MS-CHAP2-Success back to the client with the accept. this seems to lead to the problem in our setup. We have following structure in the inner handler with a cascaded a second AuthSQL after the authenticating sql for authorisation: Identifier TunnelledByTTLS AuthByPolicy ContinueWhileAccept AuthBy SQLauthenticate AuthBy SQLauthorize ( uses NoEAP and NoCheckPassword ) In the EAP-MSCHAPv2 case radiator does not proceed to SQLauthorize when SQLauthenticate has produced a challenge: Tue Jun 9 13:47:36 2015 736835: DEBUG: TTLS Tunnelled Diameter Packet dump: Code: Access-Request Identifier: UNDEF Authentic: <2>3q`<242>_L<216><221><17><208><199><164>0<162>X Attributes: EAP-Message = <2><1><0>B<26><2><1> Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> User-Name = "anonymous" Tue Jun 9 13:47:36 2015 736949: DEBUG: Handling request with Handler 'TunnelledByTTLS=1', Identifier 'TunnelledByTTLS' Tue Jun 9 13:47:36 2015 737063: DEBUG: Deleting session for anonymous, 127.0.0.1, Tue Jun 9 13:47:36 2015 737161: DEBUG: Handling with Radius::AuthSQL: SQLauthenticate Tue Jun 9 13:47:36 2015 737255: DEBUG: Handling with Radius::AuthSQL: SQLauthenticate Tue Jun 9 13:47:36 2015 737356: DEBUG: Handling with EAP: code 2, 1, 66, 26 Tue Jun 9 13:47:36 2015 737425: DEBUG: Response type 26 Tue Jun 9 13:47:36 2015 737577: DEBUG: Query to Tue Jun 9 13:47:36 2015 739050: DEBUG: Radius::AuthSQL looks for match with foo [anonymous] Tue Jun 9 13:47:36 2015 739163: DEBUG: Radius::AuthSQL ACCEPT: : foo [anonymous] Tue Jun 9 13:47:36 2015 739928: DEBUG: EAP result: 3, EAP MSCHAP V2 Challenge: Success Tue Jun 9 13:47:36 2015 740019: DEBUG: AuthBy SQL result: CHALLENGE, EAP MSCHAP V2 Challenge: Success Tue Jun 9 13:47:36 2015 740222: DEBUG: Access challenged for anonymous: EAP MSCHAP V2 Challenge: Success Tue Jun 9 13:47:36 2015 740394: DEBUG: Returned TTLS tunnelled Diameter Packet dump: Radiator ultimately proceeds to the SQLauthorize clause when challenges have been exchanged and we have success. In the plain MSCHAPv2 case that is tunneled via TTLS radiator proceedes to the SQLauthorize immediately as it does not seem to recognize that this is a challenge. The SQLauthorize clause then interfereres with the challenge and the client never gets the challenge it is waiting for. Tue Jun 9 13:46:17 2015 635970: DEBUG: TTLS Tunnelled Diameter Packet dump: Code: Access-Request Identifier: UNDEF Authentic: ?<31><164>U<226><168>SC<20><173><167><242><243><128>6<8> Attributes: User-Name = "foo" MS-CHAP-Challenge = J`H<148><189>... MS-CHAP2-Response = ~<0><173>_<10><129>... Tue Jun 9 13:46:17 2015 636089: DEBUG: Handling request with Handler 'TunnelledByTTLS=1', Identifier 'TunnelledByTTLS' Tue Jun 9 13:46:17 2015 636226: DEBUG: Deleting session for foo, 127.0.0.1, Tue Jun 9 13:46:17 2015 636328: DEBUG: Handling with Radius::AuthSQL: SQLauthenticate Tue Jun 9 13:46:17 2015 636414: DEBUG: Handling with Radius::AuthSQL: SQLauthenticate Tue Jun 9 13:46:17 2015 636583: DEBUG: Connecting ... Tue Jun 9 13:46:17 2015 650334: DEBUG: Query Tue Jun 9 13:46:17 2015 652635: DEBUG: Radius::AuthSQL looks for match with foo [foo] Tue Jun 9 13:46:17 2015 656266: DEBUG: Radius::AuthSQL ACCEPT: : foo [foo] Tue Jun 9 13:46:17 2015 656490: DEBUG: AuthBy SQL result: ACCEPT, Tue Jun 9 13:46:17 2015 656601: DEBUG: Handling with Radius::AuthSQL: SQLauthorize Tue Jun 9 13:46:17 2015 656697: DEBUG: Handling with Radius::AuthSQL: SQLauthorize Tue Jun 9 13:46:17 2015 656926: DEBUG: Query ... Tue Jun 9 13:46:17 2015 665726: DEBUG: Radius::AuthSQL looks for match with foo [foo] Tue Jun 9 13:46:17 2015 665960: DEBUG: Radius::AuthSQL ACCEPT: : r After writing all this I realize that the NoEAP in SQLauthorize is what does the magic for the EAP-MSCHAPv2 case. Not sure if a different kind of AuthByPolicy would help here... Does this make sense ? Running with a single SQLauthenticate without the cascased SQLauthorize works for the plain MS-CHAPv2 case. We have no rewriting in place. Any ideas ? Greetings Christian > The > client then compares the received value with what it expects. The value > it expects depends on the response the server calculates. The username > and password are included in the calculated response. The server can not > just say "yes" without knowing the password, that's the v2 part. Also, > the username must be the same the client uses when it calculates its > expected value. You sho
Re: [RADIATOR] TTLS with inner MSCHAPv2 vs. inner EAP-MSCHAPv2
On 9.6.2015 15.05, Christian Kratzer wrote: > On Tue, 9 Jun 2015, Heikki Vatiainen wrote: > >> It should now return accept or reject, not a challenge. If it accepts, >> it will tunnel MS-CHAP2-Success back to the client with the accept. > > this seems to lead to the problem in our setup. > > We have following structure in the inner handler with a cascaded a > second AuthSQL after the authenticating sql for authorisation: > > >IdentifierTunnelledByTTLS >AuthByPolicyContinueWhileAccept >AuthBySQLauthenticate >AuthBySQLauthorize ( uses NoEAP and NoCheckPassword ) > > > In the EAP-MSCHAPv2 case radiator does not proceed to SQLauthorize when > SQLauthenticate has produced a challenge: How about adding a Handler for EAP: # Policies etc. to work with EAP # Policies to work with non-EAP requests Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] TTLS with inner MSCHAPv2 vs. inner EAP-MSCHAPv2
Hi, On Tue, 9 Jun 2015, Heikki Vatiainen wrote: > On 9.6.2015 15.05, Christian Kratzer wrote: > >> On Tue, 9 Jun 2015, Heikki Vatiainen wrote: >> >>> It should now return accept or reject, not a challenge. If it accepts, >>> it will tunnel MS-CHAP2-Success back to the client with the accept. >> >> this seems to lead to the problem in our setup. >> >> We have following structure in the inner handler with a cascaded a >> second AuthSQL after the authenticating sql for authorisation: >> >> >>IdentifierTunnelledByTTLS >>AuthByPolicyContinueWhileAccept >>AuthBySQLauthenticate >>AuthBySQLauthorize ( uses NoEAP and NoCheckPassword ) >> >> >> In the EAP-MSCHAPv2 case radiator does not proceed to SQLauthorize when >> SQLauthenticate has produced a challenge: > > How about adding a Handler for EAP: > > ># Policies etc. to work with EAP > > > ># Policies to work with non-EAP requests > yes that would help separate the cases but I would still need to solve the non eap case, i.E how to ignore SQLauthorize while SQLauthenticate is challenging the client. Would something like this work for plain MSCHAPv2 ? ContinueUntilChallenge AuthBySQLauthenticate AuthBySQLauthorize ( uses NoEAP and NoCheckPassword ) Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] TTLS with inner MSCHAPv2 vs. inner EAP-MSCHAPv2
On 9.6.2015 15.18, Christian Kratzer wrote: > yes that would help separate the cases but I would still need to solve > the non eap case, i.E how to ignore SQLauthorize while SQLauthenticate > is challenging the client. Would something like this work for plain > MSCHAPv2 ? > > ContinueUntilChallenge > AuthBySQLauthenticate > AuthBySQLauthorize ( uses NoEAP and NoCheckPassword ) Hmm, going back to your earlier message, I'd say 'AuthByPolicy ContinueWhileAccept' should be good for both EAP and non-EAP case. With plain (non-EAP) MSCHAPv2, there is no need to challenge the client. When EAP authentication is done, it does use challenge, but non-EAP does not. Radiator can immediately respond with accept or reject. If the client does not want to continue in the non-EAP case, then it may not like the response Radiator sends. This could happen when, for example, the response Radiator calculates is incorrect. If you switch to EAP-TTLS/PAP for testing, it should work similarly with one request and immediate accept/reject from Radiator. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] TTLS with inner MSCHAPv2 vs. inner EAP-MSCHAPv2
Hi, On Tue, 9 Jun 2015, Heikki Vatiainen wrote: > On 9.6.2015 15.18, Christian Kratzer wrote: > >> yes that would help separate the cases but I would still need to solve >> the non eap case, i.E how to ignore SQLauthorize while SQLauthenticate >> is challenging the client. Would something like this work for plain >> MSCHAPv2 ? >> >> ContinueUntilChallenge >> AuthBySQLauthenticate >> AuthBySQLauthorize ( uses NoEAP and NoCheckPassword ) > > Hmm, going back to your earlier message, I'd say 'AuthByPolicy > ContinueWhileAccept' should be good for both EAP and non-EAP case. > > With plain (non-EAP) MSCHAPv2, there is no need to challenge the client. > When EAP authentication is done, it does use challenge, but non-EAP does > not. Radiator can immediately respond with accept or reject. > > If the client does not want to continue in the non-EAP case, then it may > not like the response Radiator sends. This could happen when, for > example, the response Radiator calculates is incorrect. > > If you switch to EAP-TTLS/PAP for testing, it should work similarly with > one request and immediate accept/reject from Radiator. Good tip. It seems that some attributes added by SQLauthorize are interfering. We added an AllowInReplay clause to the handler for non eap cases and it seems to be working as planned. Still testing though. Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
