[RADIATOR] TTLS with inner MSCHAPv2 vs. inner EAP-MSCHAPv2

Christian Kratzer ck-lists at cksoft.de
Tue Jun 9 07:05:54 CDT 2015 

Hi,

On Tue, 9 Jun 2015, Heikki Vatiainen wrote:
<snipp/>
> 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:

   <Handler TunnelledByTTLS=1>
       Identifier	TunnelledByTTLS
       AuthByPolicy	ContinueWhileAccept
       AuthBy		SQLauthenticate
       AuthBy		SQLauthorize ( uses NoEAP and NoCheckPassword )
   </Handler>

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 should not rewrite it for plain MSCHAPv2.
>
> Thanks,
> Heikki
>
>

-- 
Christian Kratzer                   CK Software GmbH
Email:   ck at 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/

More information about the radiator mailing list