How and where RADIUS and EAP combine?

Question

I have been reading a little bit about authentication methods. I have read about RADIUS and about EAP. I just don't understand the connection between them.

RADIUS is a authentication protocol which uses shared secret and other methods to make a safe authentication, and EAP is more of a generic protocol. I know that EAP doesn't do anything on its own (that it's just a framework), and and a more specific type (like EAP-TLS) is used to perform the authentication.

I just don't understand if a authentication process with a client -> authenticator -> authentication server, is supposed to pick one of the protocols or if they are somehow combined.

I am sure I am just getting it completely wrong and would like if someone just briefly explain what I am missing.

Thank you!

Solution

Overview

EAP is always carried by another protocol. The most common transports between the supplicant (the authenticating user's device) and the NAS (Network Access Server) are IEEE-802.1X EAPOL (EAP Over Lan), PPP (Point to Point Protocol), and IKEv2.

For the link between the NAS (also known at the authenticator in 802.1X parlance) and the RADIUS server, the EAP packets are fragmented on 253-byte boundaries and split into multiple EAP-Message attributes. How EAP is transported over RADIUS is defined by RFC3579.

The NAS will not usually snoop on the EAP conversation. For EAP methods providing privacy such as EAP-TLS, EAP-PEAP and EAP-TTLS, snooping will not be productive anyway, as a TLS tunnel will be established between the supplicant and RADIUS server.

Authentication

When a NAS receives an EAP packet from the supplicant, it will strip off the encapsulation (EAPOL/PPP/IKEv2) and fragment the EAP data into 253-byte chunks. It will then insert the EAP data chunks into a RADIUS Access-Request packet as multiple EAP-Message attributes. The NAS will then send the RADIUS Access-Request packet to the RADIUS server.

The RADIUS server uses the presence of EAP-Message attributes as an indication that it should perform EAP authentication, just like it uses User-Password as a hint that it should perform PAP and CHAP-password as a hint that it should perform CHAP.

The RADIUS server will concatenate the EAP-Message attributes in the order they were received (which is why it's important that proxies not re-order EAP-Message attributes) and will pass the concatenated data off to the code that initialises the EAP state machine.

The EAP code will then formulate its response and encode it as an EAP packet, split that packet up into EAP-Message attributes, and send those attributes back to the NAS in a RADIUS Access-Challenge packet.

A State attribute will also be sent in the challenge. This State attribute will be included in the next Access-Request by the NAS. The state attribute allows the RADIUS server to restore EAP authentication state between multiple rounds of Access-Requests/Access-Challenges. It is usually used as a key into a store of ongoing EAP sessions.

When the NAS receives the Access-Challenge it will re-assemble the EAP-Message attributes, encapsulate the EAP data in EAPOL/PPP/IKEv2, and send the encapsulated data back to the supplicant.

Multiple rounds of Access-Request/Access-Challenge exchanges take place with the NAS acting as a translator.

When the RADIUS server has enough information to make a decision about accepting or rejecting a user, it will send back an EAP-Message containing an EAP-Success/EAP-Failure. The RADIUS server will send this EAP-Message back to the NAS in an Access-Accept or Accept-Reject packet. RFC3579 mandates that EAP-Successes be returned in Access-Accept packets, and EAP-Failures be returned in Access-Reject packets.

When keying material needs to be distributed to the NAS and the supplicant, the keying material for the NAS is provided in the MS-MPPE-Recv-Key and MS-MPPE-Send-Key RADIUS attributes included in the Access-Accept. The supplicant will have received (or derived) the same keying material during the progression of the EAP method. How this keying material is derived differs between EAP methods.

When an Access-Accept packet is sent, it is common to include attributes that tell the NAS how to configure the session. For 802.1X/wireless environments common attributes returned to the NAS are Session-Timeout, which sets a maximum limit on session time, and Tunnel-Private-Group-ID et al (RFC3580), which specifies the untagged VLAN for a session.

In conclusion, RADIUS can be seen as a transport and control (for the NAS) protocol, and EAP can be seen as the actual authentication/authorization protocol running over the top of RADIUS.

Hope this helps!

Comments

[ipStack]

Hello, I do not understand the use of the state attribute in the RADIUS protocol. If I understood correctly, the NAS must put in its RADIUS requests, the value it received from the RADIUS server during the first response. What should the NAS do if it receives a different value from the RADIUS server than the one it received initially? What does this mean on the part of the server? Can the NAS itself change this value (in what cases?)? If the NAS receives a challenge from the RADIUS server without the state attribute, it must consider this request as an error.

[Arran Cudbard-Bell]

The state value is used for a single round, i.e. a pair of Access-Challenge, Access-Request packets. The server creates a new state value for each Access-Challenge packet it sends. The NAS should never modify the state value itself, and should always use the state value from the last Access-Challenge packet it received in the next Access-Request.

[ipStack]

Hello, I have an another question. Can 802.1X support multiple supplicants for the same port with some VLANs? This port can be a TRUNK port or it must be an ACCESS port? It is possible to have some supplicants in the same VLAN ? Also I see, VLAN can be defned dynamically : what is the RADIUS attribute to configure it (I don't find it in RFC)? Is it a standardized method or a manufacturer specific implementation?

[Arran Cudbard-Bell]

Supplicants will perform 802.1X using untagged frames. It doesn't matter how the port is setup. Assigning untagged VLANs is described in datatracker.ietf.org/doc/html/rfc3580 section 3.31. Assigning tagged VLANs is described by datatracker.ietf.org/doc/html/rfc4675. What combination of VLAN assignments is allowed depends on the authenticator's capabilities. Some HP ProCurve switches for example allow(ed) multiple untagged VLANs to be assigned to different supplicants on the same physical port using mac address filtering.

[ipStack]

I did some tests with a CISCO SG300-10 : If I insert a non-managed ethernet switch between SG300-10 and 802.1X supplicant, I can access to the network with an another computer (802.1X disabled) if I connect it to the non-managed switch. Is it normal ?... I thought the access would be filtered with source MAC address. What is the point to not filtrate by MAC Address ?... is it un bug ?

[Arran Cudbard-Bell]

On the old HP ProCurve gear there were different port modes you could configure. One opened the port fully after auth, the other did per-mac based authentication. I suggest you look at the docs for your Cisco and see if there's something similar. There's really different requirements for things like switch/switch auth or switch/ap auth and edge port authentication.

[ipStack]

Hello, When I read "Authenticator PACP state machine" of IEEE 802.1X-2020 standard (figure 8-7). If auth.failed is set to TRUE, state machine is blocked to state "UNAUTHENTICATED" indefinitely... the only thing to reinit the state machine is to disable/enable 802.1X or link-down/link-up the port because auth.failed is cleared only in the state "INITIALZE"... is it normal ? (CISCO SG300-10 doesn't work in this way)