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

[Arran Cudbard-Bell]

> On 28 Jan 2020, at 05:20, Joe Garcia <joe27256 at gmail.com> wrote:
> 
> Alan DeKok <aland at deployingradius.com> wrote:
> 
>> 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.
> 
> It does if it's being used as a generic EAP-TTLS authentication
> mechanism and the client just has a username+password, i.e. the RADIUS
> shared secret is the same as the password used with EAP-TTLS.

The RADIUS shared secret is a PSK known to the NAS (Network Access Server - Usually a WAP (Wireless Access Point) in the case of EAP/802.1X), and the RADIUS server.  It has absolutely nothing to do with the credentials submitted by the user.  There are no User-Name and User-Password attributes in the outer RADIUS tunnel when performing EAP, only EAP-Message attributes.

The Diameter content in the EAP-TTLS tunnel does not use a shared secret for protection.  Confidentiality and Integrity are provided by the TLS tunnel.

> In other
> words the client
> is being told to authenticate with EAP-TTLS

The NAS is not told to authenticate with EAP-TLS.  The 802.1X supplicant (software running on the authenticating device) is requested to perform EAP-TTLS by the EAP server (FreeRADIUS' rlm_eap module).

The NAS doesn't care which EAP-Method is being performed.  The only thing it can do is passively observe which method was negotiated by the 802.1X supplicant and the EAP Server.

> and given
> a username + password, they don't have,

The user of the 802.1X supplicant provides with username and password, or the credentials are retrieved from a local credential cache.

> or even know, that there's a
> second, different password to use with RADIUS vs. whatever they're
> running over EAP-TTLS.

The 802.1X supplicant doesn't know what the RADIUS shared secret is, and doesn't care, it doesn't speak RADIUS.

The NAS speaks RADIUS, it has a shared secret statically configured against a particular RADIUS server.

The RADIUS server has that same shared secret statically configured against a client entry representing the NAS.

>> 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.
> 
> See above, that's for the specific case of eapol_test, or an
> equivalent that uses two different passwords/shared secrets/whatever.
> In this case there's only a single username+password available to auth
> with.

The scenario represented by eapol_test is contrived and is not what is done in real world production environments.

The 802.1X supplicant and the NAS are very rarely the same device.  I can't think of a single real world scenario I've seen where the device authenticating has knowledge of both the RADIUS shared secret and the EAP-TTLS credentials, other than in test environments, or maybe for something like an RDP or Telnet terminal service, where the basic Integrity and Confidentiality provisions of RADIUS were considered insufficient, and a stronger authentication protocol was required.

Even in that instance it would be incredibly stupid to require the shared secret to be identical to the TTLS credentials because it would make the RDP/Terminal server incompatible with every single commercial and open source RADIUS/EAP server I'm aware of.  Even in FreeRADIUS v4.0.x this would not be something we'd even consider adding support for.  The highest shared secret mapping granularity we'll ever support is src/dst port src/dst IP, and even that is done specifically to work with RADIUS clients behind NAT gateways.

There is no instance where the 802.1X supplicant should be speaking RADIUS directly to the RADIUS server, that is the role of the NAS.

> I realize the answer is probably "don't do that, then", but the server
> is a third-party service that can't be changed.

I think you're misunderstanding the requirements of the third-party service.

-Arran