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>.
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
