Can an EAP-over-RADIUS request ever result in an Access-Reject?
aland at deployingradius.com
Mon Jan 27 17:06:00 CET 2020
On Jan 27, 2020, at 10:54 AM, Joe Garcia <joe27256 at gmail.com> wrote:
> The reason for that question is based on RFC 3579, section 3.2:
> It [Message-Authenticator] MUST be used in any Access-Request, Access-
> Accept, Access-Reject or Access-Challenge that includes an EAP-Message
> attribute. A RADIUS server receiving an Access-Request with a Message-
> Authenticator attribute present MUST calculate the correct value of the
> Message-Authenticator and silently discard the packet if it does not match
> the value sent.
> What this would mean in practice is that any EAP authentication
> request with an incorrect password will be silently dropped,
No. The Message-Authenticator is calculated from the RADIUS shared secret. i.e. the secret shared between the RADIUS client and server.
It has nothing to do with the users password.
> there's no possibility of ever seeing an Access-Reject. I know what
> the Message-Authenticator is meant for, but since I'm just using EAP
> as a transport layer for a TLS tunnel its presence is irrelevant.
No, it's not. The presence of the Message-Authenticator protects the RADIUS packets. That's what it's there for.
> Is this behavior really how it works? How can you use an
> authentication mechanism for which the behavior for an incorrect
> password is indistinguishable from a network error?
That's not how it works, so your conclusions are wrong.
All you need to do is *try* it. Run eapol_test with an incorrect password, and see what happens. You will see that the RADIUS shared secret is NOT the same as the users password. And that an Access-Reject is returned when the users password is wrong.
More information about the Freeradius-Users