On Jan 27, 2020, at 10:54 AM, Joe Garcia <joe27256@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.
so 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. Alan DeKok.