incorrect shared secret entry authenticates successfully for freerradius

[sanjeev.kumarroy at wipro.com]

Hi,
I am using the following configuration:

O/S: rhel4_u5_i386
Freeradius 1.1.7 
Client to test: NTRadPing 1.5

Steps undertaken:
--------------------
- Installed a fresh system with rhel4_u5_i386
- Build and compile freeradius 1.1.7 on it.
- Update the clients.conf file to add the client entries for the machine
that uses NTRadPing 1.5 (IP of the client machine and the shared secret)
- Start the radiusd daemon in debug mode (radiusd -X)
- Now generate a simple PAP authentication request using NTRadPing.
(Port is 1812, also provide the shared secret correctly). The
authentication passes successfully as it should. Now give a junk secret
key in the NTRadPing utility. The access is rejected.
- However when the same cases are tried for CHAP we can see the
difference. In the first case the authentication is successful; however
when we give a junk shared secret the authentication should ideally have
been rejected. However the authentication passes successfully.
NOTE: I tried the same for MSCHAPv1 and MSCHAPv2 authentication using
VPN client. There I can see clearly that the access is not granted to
the VPN client. However when we look at the radius logs it can be seen
that the Authentication requests responds with a Successful message.

Any help or info in this regards would be highly appreciated.
Thanks.

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com