Hi Phil,
I checked the issue with MSCHAP v1 and v2 as well. Even there the
authentication passes for an incorrect secret key

Thanks

-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
dius.org] On Behalf Of Phil Mayers
Sent: Tuesday, March 18, 2008 7:24 PM
To: FreeRadius users mailing list
Subject: Re: incorrect shared secret entry authenticates successfully
forfreerradius

[EMAIL PROTECTED] wrote:
> 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.

Only certain radius AVPs are encrypted with the shared secret:

fgrep encrypt /usr/share/freeradius/dictionary*

User-Password is one, so PAP fails if the shared secret is wrong. The 
CHAP attributes are not, so the request succeeds. The MS-CHAP-MPPE-Keys 
or MS-MPPE-Send-Key/MS-MPPE-Recv-Key reply attributes are encrypted, so 
MS-CHAP will fail.

Many recent radius clients support the Message-Authenticator attribute, 
which is a signature over the entire packets AVPs encrypted with the 
shared secret. This will cause incorrect shared secrets to reject an 
entire packet. See section 3.2 of RFC3579.

If your NAS supply Message-Authenticator, you could refuse packets 
without one:

DEFAULT Message-Authenticator !* ANY, Auth-Type := Reject


-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html

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


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to