Can an EAP-over-RADIUS request ever result in an Access-Reject?

[Alan DeKok]

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.

> 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.