FreeRadius sends Access-Reject for MAC-AUTH, if shared secret on NAS and server differ
Phani Siriki has sent you an email via Gmail confidential mode: Gmail logo [1]FreeRadius sends Access-Reject for MAC-AUTH, if shared secret on NAS and server differ This message was sent on Apr 14, 2019 at 1:01:48 PM PDT You can open it by clicking the link below. This link will only work for freeradius-users@lists.freeradius.org. [2]View the email Gmail confidential mode gives you more control over the messages you send. Set an expiration time, disable printing or forwarding of a message and more. [3]Learn more Gmail: Email by Google Use is subject to the [4]Google Privacy Policy Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA You have received this message because someone sent you an email via Gmail co! nfidential mode. Google logo References 1. https://confidential-mail.google.com/msg/ABTZP1zGEVczYo2ysdPSvuSn7Rhd1YYM2m6... 2. https://confidential-mail.google.com/msg/ABTZP1zGEVczYo2ysdPSvuSn7Rhd1YYM2m6... 3. https://support.google.com/mail/answer/7674059 4. https://myaccount.google.com/privacypolicy?hl=en
On Sun, 2019-04-14 at 13:01 -0700, Phani Siriki wrote:
Phani Siriki has sent you an email via Gmail confidential mode:
Bit pointless (and rather antisocial) to a public mailing list.
FreeRadius sends Access-Reject for MAC-AUTH, if shared secret on NAS and server differ
Yes. The secret needs to be the same on both. That's rather the whole point of it being a "shared" secret. -- Matthew
Hi Matthew
Bit pointless (and rather antisocial) to a public mailing list. Sorry about this. I will make sure this wont happen again.
My main question is, why does FreeRadius not send Access-Reject(if shared secret is not correct) when I try to do EAP authentication? Could you please let me know if I am missing anything? Please see req 1, 2, 3. (1) Received Accounting-Request Id 1 from 172.24.85.69:35478 to 172.24.66.67:1813 length 121 Dropping packet without response because of error: Received Accounting-Request packet from client 172.24.85.69 with invalid Request Authenticator! (Shared secret is incorrect.) Waking up in 0.3 seconds. (1) Cleaning up request packet ID 1 with timestamp +41 Ready to process requests (2) Received Access-Request Id 1 from 172.24.85.69:60091 to 172.24.66.67:1812 length 141 Dropping packet without response because of error: Received packet from 172.24.85.69 with invalid Message-Authenticator! (Shared secret is incorrect.) Waking up in 0.3 seconds. (2) Cleaning up request packet ID 1 with timestamp +44 Ready to process requests (3) Received Access-Request Id 1 from 172.24.85.69:60091 to 172.24.66.67:1812 length 141 Dropping packet without response because of error: Received packet from 172.24.85.69 with invalid Message-Authenticator! (Shared secret is incorrect.) Waking up in 0.3 seconds. (3) Cleaning up request packet ID 1 with timestamp +49 Ready to process requests Best Regards Phani On Sun, Apr 14, 2019 at 1:50 PM Matthew Newton <mcn@freeradius.org> wrote:
On Sun, 2019-04-14 at 13:01 -0700, Phani Siriki wrote:
Phani Siriki has sent you an email via Gmail confidential mode:
Bit pointless (and rather antisocial) to a public mailing list.
FreeRadius sends Access-Reject for MAC-AUTH, if shared secret on NAS and server differ
Yes. The secret needs to be the same on both. That's rather the whole point of it being a "shared" secret.
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sun, 2019-04-14 at 14:48 -0700, Phani Siriki wrote:
My main question is, why does FreeRadius not send Access-Reject(if shared secret is not correct) when I try to do EAP authentication?
Because the shared secret is wrong.
(2) Received Access-Request Id 1 from 172.24.85.69:60091 to 172.24.66.67:1812 length 141 Dropping packet without response because of error: Received packet from 172.24.85.69 with invalid Message-Authenticator! (Shared secret is incorrect.)
This should be clear enough: the request was dropped. There's nothing to process so no reply is sent. -- Matthew
Hi Matthew, Yes, you are correct. But in case of MAC-AUTH which is doing PAP authentication, Access-Reject is sent. FreeRadius should have dropped the request without sending Access-Reject right? Can we make FreeRadius not reply in case MAC-auth if shared secret is wrong. Best Regards Phani On Sun, Apr 14, 2019 at 2:57 PM Matthew Newton <mcn@freeradius.org> wrote:
On Sun, 2019-04-14 at 14:48 -0700, Phani Siriki wrote:
My main question is, why does FreeRadius not send Access-Reject(if shared secret is not correct) when I try to do EAP authentication?
Because the shared secret is wrong.
(2) Received Access-Request Id 1 from 172.24.85.69:60091 to 172.24.66.67:1812 length 141 Dropping packet without response because of error: Received packet from 172.24.85.69 with invalid Message-Authenticator! (Shared secret is incorrect.)
This should be clear enough: the request was dropped. There's nothing to process so no reply is sent.
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 14, 2019, at 6:04 PM, Phani Siriki <yvsg.phanis@gmail.com> wrote:
Yes, you are correct. But in case of MAC-AUTH which is doing PAP authentication, Access-Reject is sent. FreeRadius should have dropped the request without sending Access-Reject right?
No.
Can we make FreeRadius not reply in case MAC-auth if shared secret is wrong.
No. If there is a Message-Authenticator attribute, then the server knows that the shared secret is wrong, and drops the packet. If there is no Message-Authenticator attribute, then the server guesses that the shared secret *might* be wrong, but it's not sure. Because there's no way of knowing for sure. If you want to know why, read the RFCs. If you're not going to read the RFCs, then trust that the server does the Right Thing. It's been doing RADIUS for 20 years, which is likely longer than you've been doing it. Alan DeKok.
Hi Alan Thanks for the reply. I checked this already and NAS is not sending Message-Authenticator attribute in this case. I will further check this. Thanks. Best Regards Phani On Sun, Apr 14, 2019 at 3:20 PM Alan DeKok <aland@deployingradius.com> wrote:
On Apr 14, 2019, at 6:04 PM, Phani Siriki <yvsg.phanis@gmail.com> wrote:
Yes, you are correct. But in case of MAC-AUTH which is doing PAP authentication, Access-Reject is sent. FreeRadius should have dropped the request without sending Access-Reject right?
No.
Can we make FreeRadius not reply in case MAC-auth if shared secret is wrong.
No.
If there is a Message-Authenticator attribute, then the server knows that the shared secret is wrong, and drops the packet.
If there is no Message-Authenticator attribute, then the server guesses that the shared secret *might* be wrong, but it's not sure. Because there's no way of knowing for sure.
If you want to know why, read the RFCs. If you're not going to read the RFCs, then trust that the server does the Right Thing. It's been doing RADIUS for 20 years, which is likely longer than you've been doing it.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi Alan Need some inputs on Message-Authenticator attribute. For PAP, Is it recommended to send this attribute from NAS? RFC 3579 says it is not required but can prevent other attacks.
From RFC 2869: =============
Access-Request packets with a User-Password establish the identity of both the user and the NAS sending the Access-Request, because of the way the shared secret between NAS and RADIUS server is used. Access-Request packets with CHAP-Password or EAP-Message do not have a User-Password attribute, so the Message-Authenticator attribute should be used in access-request packets that do not have a User- Password, in order to establish the identity of the NAS sending the request.
From RFC 3579: =============
This attribute is not required in Access-Requests which include the User-Password attribute, but is useful for preventing attacks on other types of authentication. This attribute is intended to thwart attempts by an attacker to setup a "rogue" NAS, and perform online dictionary attacks against the RADIUS server. Best Regards Phani On Sun, Apr 14, 2019 at 3:26 PM Phani Siriki <yvsg.phanis@gmail.com> wrote:
Hi Alan
Thanks for the reply. I checked this already and NAS is not sending Message-Authenticator attribute in this case. I will further check this. Thanks.
Best Regards Phani
On Sun, Apr 14, 2019 at 3:20 PM Alan DeKok <aland@deployingradius.com> wrote:
On Apr 14, 2019, at 6:04 PM, Phani Siriki <yvsg.phanis@gmail.com> wrote:
Yes, you are correct. But in case of MAC-AUTH which is doing PAP authentication, Access-Reject is sent. FreeRadius should have dropped the request without sending Access-Reject right?
No.
Can we make FreeRadius not reply in case MAC-auth if shared secret is wrong.
No.
If there is a Message-Authenticator attribute, then the server knows that the shared secret is wrong, and drops the packet.
If there is no Message-Authenticator attribute, then the server guesses that the shared secret *might* be wrong, but it's not sure. Because there's no way of knowing for sure.
If you want to know why, read the RFCs. If you're not going to read the RFCs, then trust that the server does the Right Thing. It's been doing RADIUS for 20 years, which is likely longer than you've been doing it.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 14, 2019, at 7:43 PM, Phani Siriki <yvsg.phanis@gmail.com> wrote:
Hi Alan
Need some inputs on Message-Authenticator attribute. For PAP, Is it recommended to send this attribute from NAS?
RFC 5080 Section 2.2.2 (note the author) says: Client implementations SHOULD include a Message-Authenticator attribute in every Access-Request to further help mitigate this issue. Though vendors are well known for ignoring 10 year-old standards. Alan DeKok.
Hi Alan Sure. Thanks for sharing the info that clients shouId include this attribute. I will check this RFC too. I think there are many RFCs based on users experiences with Radius deployments. Have to go through all of these. Best Regards Phani Sent from my iPhone
On Apr 14, 2019, at 4:52 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Apr 14, 2019, at 7:43 PM, Phani Siriki <yvsg.phanis@gmail.com> wrote:
Hi Alan
Need some inputs on Message-Authenticator attribute. For PAP, Is it recommended to send this attribute from NAS?
RFC 5080 Section 2.2.2 (note the author) says:
Client implementations SHOULD include a Message-Authenticator attribute in every Access-Request to further help mitigate this issue.
Though vendors are well known for ignoring 10 year-old standards.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
Alan DeKok -
Matthew Newton -
Phani Siriki -
yvsg.phanis＠gmail.com