incorrect shared secret entry authenticates successfully for freerradius
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
sanjeev.kumarroy@wipro.com 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
Phil Mayers wrote:
If your NAS supply Message-Authenticator, you could refuse packets without one:
Edit the "client" section and set "require_message_authenticator = yes". The recommendations of RFC 5080 have been implemented in FreeRADIUS. Sometimes years before any other RADIUS server. Apparently Radiator didn't do duplicate detection until RFC 5080... see their changelog for the 4.x series. Alan DeKok.
Alan DeKok wrote:
Phil Mayers wrote:
If your NAS supply Message-Authenticator, you could refuse packets without one:
Edit the "client" section and set "require_message_authenticator = yes".
Ah thanks - I didn't know about that
The recommendations of RFC 5080 have been implemented in FreeRADIUS. Sometimes years before any other RADIUS server.
Apparently Radiator didn't do duplicate detection until RFC 5080... see their changelog for the 4.x series.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi Phil, Do you mean the clients.conf file? I don't see require_message_authenticator there. If it is some other file then please let me know the details. I am a new user so not much aware of the configuration files. Thanks -----Original Message----- From: freeradius-users-bounces+sanjeev.kumarroy=wipro.com@lists.freeradius.org [mailto:freeradius-users-bounces+sanjeev.kumarroy=wipro.com@lists.freera dius.org] On Behalf Of Phil Mayers Sent: Tuesday, March 18, 2008 10:25 PM To: FreeRadius users mailing list Subject: Re: incorrect shared secret entry authenticates successfully forfreerradius Alan DeKok wrote:
Phil Mayers wrote:
If your NAS supply Message-Authenticator, you could refuse packets without one:
Edit the "client" section and set "require_message_authenticator = yes".
Ah thanks - I didn't know about that
The recommendations of RFC 5080 have been implemented in FreeRADIUS. Sometimes years before any other RADIUS server.
Apparently Radiator didn't do duplicate detection until RFC 5080... see their changelog for the 4.x series.
Alan DeKok. - List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html - 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
sanjeev.kumarroy@wipro.com wrote:
Do you mean the clients.conf file? I don't see require_message_authenticator there. If it is some other file then please let me know the details. I am a new user so not much aware of the configuration files.
It's in 2.0. Alan DeKok.
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: freeradius-users-bounces+sanjeev.kumarroy=wipro.com@lists.freeradius.org [mailto:freeradius-users-bounces+sanjeev.kumarroy=wipro.com@lists.freera 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 sanjeev.kumarroy@wipro.com 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
NTRadPing is a very bad client to test real authentication. While it says it has an Access-Accept packet it isn't doing any proper checking of the packet. All Access-Accept packets are signed by the server using the shared secret. A good client will check that signature. A packet with a bad signature is rejected by a proper client even though the server sent an Access-Accept. Your test and discussion are pointless because the client NTRadPing is not telling you that the packet is invalid. It's just displaying the packet's contents. PAP is the only authentication method where you would get an Access-Reject with a bad secret. sanjeev.kumarroy@wipro.com wrote:
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: freeradius-users-bounces+sanjeev.kumarroy=wipro.com@lists.freeradius.org [mailto:freeradius-users-bounces+sanjeev.kumarroy=wipro.com@lists.freera 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
sanjeev.kumarroy@wipro.com 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
sanjeev.kumarroy@wipro.com wrote:
- 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.
The key word is "ideally". RADIUS isn't ideal. This weakness has been known for over 10 years in RADIUS. All RADIUS servers are vulnerable to this issue. It isn't news. RFC 5080 (of which I am co-author) suggests that all RADIUS clients add a Message-Authenticator to the Access-Request. This additional enables the RADIUS server to catch the case of an incorrect shared secret. Alan DeKok.
participants (4)
-
Alan DeKok -
Michael Lecuyer -
Phil Mayers -
sanjeev.kumarroy＠wipro.com