FreeRadius sends Access-Reject for MAC-AUTH, if shared secret on NAS and server differ
yvsg.phanis at gmail.com
Mon Apr 15 01:43:03 CEST 2019
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
>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.
On Sun, Apr 14, 2019 at 3:26 PM Phani Siriki <yvsg.phanis at 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
> On Sun, Apr 14, 2019 at 3:20 PM Alan DeKok <aland at deployingradius.com> wrote:
> > On Apr 14, 2019, at 6:04 PM, Phani Siriki <yvsg.phanis at 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
More information about the Freeradius-Users