Can an EAP-over-RADIUS request ever result in an Access-Reject?
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, 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. 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? JG.
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.
Alan DeKok <aland@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. In other words the client is being told to authenticate with EAP-TTLS and given a username + password, they don't have, or even know, that there's a second, different password to use with RADIUS vs. whatever they're running over EAP-TTLS.
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. I realize the answer is probably "don't do that, then", but the server is a third-party service that can't be changed. JG.
On Jan 28, 2020, at 5:20 AM, Joe Garcia <joe27256@gmail.com> wrote:
Alan DeKok <aland@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. In other words the client is being told to authenticate with EAP-TTLS and given a username + password, they don't have, or even know, that there's a second, different password to use with RADIUS vs. whatever they're running over EAP-TTLS.
I'm not sure I understand that run-on sentence. But from what I do, the configuration is *deliberately* broken. Plus, if you're asking questions, it helps to ask the RIGHT questions. It's annoying to discover that the question you asked isn't *really* the question you want answered. No, RADIUS and EAP-TTLS aren't broken. No, they're not designed by idiots. Yes, if you *deliberately* break them, they will break. Don't throw rocks through your office windows and then complain that they're broken.
I realize the answer is probably "don't do that, then", but the server is a third-party service that can't be changed.
Tell them they're idiots, and that their idiotic decisions have made it impossible to do anything intelligent. Alan DeKok.
On 28 Jan 2020, at 05:20, Joe Garcia <joe27256@gmail.com> wrote:
Alan DeKok <aland@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
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Joe Garcia