FW: MSCHAP Authentication Issue

[Alan DeKok]

Garber, Neal wrote:
> I constructed a test program by extracting challenge_hash from rlm_mschap.c (and all supporting functions).  I then extracted the peer challenge, authenticator challenge and NT-Response from the debug output of a failed request (User-Name was all lowercase, Name field was mixed case).  I called challenge_hash with the all lowercase userid (to ensure it generated the same challenge as the failed request) - the challenge was identical.  I then generated another challenge with the userid from the Name field in the response.  Then, I executed ntlm_auth manually with the original challenge and the new challenge.  The original failed (as I expected) and, low and behold, the new challenge (created using the Name field's userid) succeeded!

  OK.  That warrants a fix.

> I will now proceed to create a patch.  I was planning to do a strncasecmp to ensure the only difference between the userid part of User-Name and the userid part of the Name field is case.  If there are non-case differences, do you think a RLM_REJECT is in order or do you think it should just warn and use whatever is present (I can't think of a normal case where this would occur, but if you think this is better, then I would definitely use the Name field for the username parameter too)?  I was thinking of rejecting the request, in this case, so this couldn't be used to bypass authorization.

  I think that if the NAME and User-Name fields are substantially
different, the module should return a reject.  This gets hard when you
have DOMAIN\user, user at domain, and various kinds of realm stripping.

> Interestingly, I copied the challenge and response from a successful and failed attempt and manually called ntlm_auth varying the case of the --username parameter and it didn't affect the results.  In other words, --username=MYUSER or --username=myuser or --username=MyuseR all behave the same if the --challenge and --nt-response are correct).

  Because ntlm_auth does little more than hand the data to Active
Directory.  Presumably Active directory has some way of working around
this issue.

  Alan DeKok.