How and where RADIUS and EAP combine?

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.

Overview
How EAP is carried in 802.1X

For the link between the NAS 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 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.

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!