(RADIATOR) MSCHAPv2 Authentication Bug

[Terry Simons]

Hmmm interesting...

At least now I understand why Panther was failing MSCHAPv2 
authentications!  ;-)

This isn't problematic for me, but at least I understand what's going 
on now.

Thanks for your help Hugh.

- Terry

On Mar 4, 2004, at 10:55 PM, Hugh Irvine wrote:

>
> Hello Terry -
>
> Here is the comment block from the beginning of "Radius/MSCHAP.pm":
>
>
> # MSCHAP.pm
> # Implements MSCHAP algorithms as described in
> # draft-ietf-pppext-mschap-00.txt and RFC3079
> # Requires Digest-MD4-1.0 or better, available from CPAN and
> # ActiveState
> #
> # The basic algorithms and how they are used by MS
> #
> #  PeerChallenge          Username       Password
> #       |    AuthChallenge   |             |
> #       |               |    |             |0-256
> #       ------------    |    |0-256        v
> #                  |    |    |      ASCIIToUnicode
> #                  |16  |16  |             |
> #                  |    |    |       ------ 0-256
> #                  v    v    v       v
> #  MSCHAPV2-->      GenerateNTResponse
> #                  |    |    |       |
> #                  |16  |16  |0-256  |0-256
> #                  v    v    v       |
> #                  ChallengeHash     |
> #                       |            |
> #                       |8           |
> #                       |            |
> #                       v            v
> #  MSCHAP-->           NtChallengeResponse
> #                       |            |
> #                       |8           |0-256
> #                       |            |
> #                       |         NTPasswordHash
> #                       |            |
> #                       -------      |16
> #                             |      |
> #                             v      v
> #                            ChallengeResponse
> #                                 |
> #                                 |24
> #                                 v
> #
> # Author: Mike McCauley (mikem at open.com.au)
> #
> # This code is offered on the same terms as 
> draft-ietf-pppext-mschap-00.txt
> # $Id: MSCHAP.pm,v 1.7 2003/12/23 22:40:17 mikem Exp $
>
>
> As you can see, you cannot really use a RewriteUsername because the 
> algorithm uses the full username as entered by the user.
>
> In other words, you must match the same username string as is entered 
> by the user.
>
> regards
>
> Hugh
>
>
> On 5 Mar 2003, at 16:43, Terry Simons wrote:
>
>> Hello,
>>
>> I have discovered a bug in Radiator that causes MSCHAPv2 
>> authentications to fail in certain circumstances.
>>
>> I don't understand how MSCHAPv2 actually hashes, but based on the way 
>> the bug manifests itself, here is what I *believe* may be happening:
>>
>> When using a handler that distinguishes by Realm, if the 
>> authentication needs to be done against a stripped username the 
>> authentication will fail.
>>
>> For instance...
>>
>> If the user terry at library.utah.edu authenticates, but the users file 
>> only contains the name "terry", the authentication fails for me, even 
>> though I strip the realm.
>>
>> Does MSCHAPv2 use the username to hash against?  If so, I believe 
>> that Radiator may be using the unstripped name to hash against, when 
>> it should be using the stripped name, if one exists (since there 
>> would be no reason to strip the name, unless it is required to 
>> sucessfully authenticate, I think...)
>>
>> Does that make any sense whatsoever?  8-)
>>
>> If not, maybe my traces and configurations can help ;-)
>>
>> I've included my user file, a "broken" configuration, a "working" 
>> configuration, and the output (trace 4) of both configurations from 
>> my tests.
>>
>> For the broken configuration, I used a fully-qualified username 
>> during authentication.  For the working configuration I did not use a 
>> fully qualified name...  (So:  terry at library.utah.edu for the broken 
>> authentication, terry for the working authentication).
>>
>>
>> <RADIATOR_MSCHAPv2_BUG.tar.gz>
>
> NB: have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
>
> -- 
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
>

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.