[RADIATOR] AuthBy NTLM with NoEAP = bad

[David Zych]

I'm extremely puzzled by the presence of the following code lines in AuthNTLM::checkUserAttributes:

    # Short circuit authetication in EAP requests ?
    return ($main::ACCEPT) 
        if $p->getAttrByNum($Radius::Radius::EAP_MESSAGE);

I'm not sure what the intended purpose of this was, but the practical upshot I discovered today is that setting NoEAP in an <AuthBy NTLM> is currently a very bad idea because it will automatically accept any request containing an EAP-Message attribute (without checking ntlm_auth at all!).

I have solved my immediate problem by realizing that I really didn't want to use NoEAP in an AuthBy NTLM anyway; what I actually wanted was for any attempt at EAP to be *rejected* by the AuthBy, and I could accomplish that by simply not setting EAPType.  But this is a cautionary tale to anyone else who may have misinterpreted the meaning of NoEAP as I had, and it probably (in my opinion, anyway) constitutes a bug.


Details:

I'm supporting EAP-TTLS / MSCHAPv2 for a wireless network, and as of this morning my inner handler used an
<AuthBy NTLM>
NoEAP
</AuthBy>

It turns out that if you misconfigure an Android 2.2.1 device to use
 EAP method = TTLS
 Phase 2 authentication = "None" (instead of MSCHAPv2)
then it tries to send an EAP-Message inside the TTLS tunnel.  Due to the code above, this was causing AuthNTLM to ACCEPT without even knowing what username it was looking for!

Here's a (somewhat-redacted) log fragment showing the inner transaction:

Wed Dec  8 13:17:30 2010: DEBUG: TTLS Tunnelled Diameter Packet dump:
Code:       UNDEF
Identifier: UNDEF
Authentic:  UNDEF
Attributes:
        EAP-Message = <2><0><0><9><1>dmrz

Wed Dec  8 13:17:30 2010: DEBUG: EAP TTLS inner authentication request for
Wed Dec  8 13:17:30 2010: DEBUG: Handling request with Handler DETAILS_REMOVED
Wed Dec  8 13:17:30 2010: DEBUG: Rewrote user name to
Wed Dec  8 13:17:30 2010: DEBUG:  Deleting session for , IP_ADDRESS_REMOVED,
Wed Dec  8 13:17:30 2010: DEBUG: Handling with Radius::AuthGROUP: IDENTIFIER_REMOVED
Wed Dec  8 13:17:30 2010: DEBUG: Handling with Radius::AuthNTLM: IDENTIFIER_REMOVED
Wed Dec  8 13:17:30 2010: DEBUG: Radius::AuthNTLM looks for match with  []
Wed Dec  8 13:17:30 2010: DEBUG: Radius::AuthNTLM ACCEPT: :  []
Wed Dec  8 13:17:30 2010: DEBUG: AuthBy GROUP result: ACCEPT,
Wed Dec  8 13:17:30 2010: DEBUG: Access accepted for
Wed Dec  8 13:17:30 2010: DEBUG: Returned TTLS tunnelled Diameter Packet dump:
Code:       Access-Accept
Identifier: UNDEF
Authentic:  h<210><224><131><19><158><4><20>{evp<225>[<246><187>
Attributes:
        User-Name = ""

My AuthLogs for both the inner and outer handlers logged it as a success, although the inner handler authlog recorded a blank username in the log message (which is what tipped me off to the problem).  In this particular case, the (benign) Android device was sufficiently confused by the situation that it actually thought it had failed to connect and didn't go any further, but as far as I can tell there would be nothing stopping a malicious client from exploiting this.

Once again, my workaround for the moment is to never ever ever put NoEAP in an <AuthBy NTLM>.