This is a partial implementation of MS-CHAP for FreeRadius.  The patch
was designed for Cistron-Radius 1.6.4, but the changes to source are
pretty minimal and should work with previous versions.  It is based on
RFC 2433, which is included with this package.

I have tested this successfully using Windows 98 and Windows 2000 with Cisco 
AS5300 terminal servers.  I have not tested it in any other environment, so 
I can't guarantee it's success everywhere.  I also don't have time to do 
much troubleshooting, though I am interested to hear about problems anyone
might have.  If you can fix a problem, then I will incorporate the fix into
the distribution.

Files included:
mschap.c        -   MS-CHAP functions
mschap.h        -   Definitions and prototypes
md4c.c, md4.h   -   RSA Data Security, Inc. MD4 Message-Digest Algorithm
desport.c,
 deskey.c,
 des.h          -   Fast DES by Phil Karn (portable C version)
rfc2433.txt     -   RFC upon which this algorithm is based


ABOUT MS-CHAP

I was driven to write this when a large customer demanded that they be
able to check "Require Encrypted Password" in their Windows Dial-up
Networking.  Testing showed me that, in Windows 2000 at least, this meant
MS-CHAP.  If you want to specify CHAP, then Windows 2000 requires you to
select "Allow unencrypted password". Duh.

MS-CHAP is similar to CHAP.  The NAS creates a challenge string and gives it 
to the client.  The client then uses the password to encrypt the challenge 
and gives it back to the NAS, who then gives them both to Radius.  Radius
performs the same encryption of the challenge string using the locally stored
password, then compares the result to the response from the client.

The difference between MS-CHAP and CHAP is in the encryption method.  CHAP
performs one MD5 hash to get the response.  MS-CHAP first encrypts the password
with MD4.  It then pads the 16-byte hash out to 21 bytes and divides this 
string into 3 parts.  Each 7-byte part is used as a key for a DES encryption
of the challenge string.  The 8-byte results are then concatonated together
into a 24-byte response.

The method just described is called NT-encryption by the RFC.  MS-CHAP is 
actually designed for compatability with Microsoft LAN Manager as well.
The response returned by the client actually contains an LM encrypted
response as well as the NT-encrypted password.  This implementation only
uses the NT-encrypted response, which seems to work fine for Windows 98
and Windows 2000.  The RFC also has a number of other specs for allowing the
user to change password and things like that.  None of that has been 
implemented here.

A useful extension of this would be in the local storage of passwords.
Theoretically you should be able to store the MD4 hash rather than the
plain text password.  Then the algorithm could pick it up at the next
step and still calculate the result.  The trouble is that MD4 produces a
binary hash.  That is, any values from 0 to 255 is a valid byte, and I
don't know how to store this in a users file.  If it can be done, then
we could add a check attribute called "MS-CHAP-Hash" instead of password
and get both an encrypted protocol and encrypted password storage at the
same time (CHAP requires plain text passwords, while Crypt-Pass requires
an unencrypted protocol).

If you find this useful, please send me a note just so I can feel good
about myself.

Jay Miller
Columbia, MO, US
jaymiller@socket.net
