Hello World! In the previous post, you have learnt that to secure an enterprise network various standards and tools are employed by the network admins. But what exactly are those components and tools? What do they do? Why different schemes and methods are implemented? So many questions and that too are interlinked (I hate it the most).

If you have any of these questions and want to learn more about them, you are on right track, I will be discussing the most important component that is widely used in the Enterprise Wireless Security today in this post which implements Authentication, Authorisation and Accounting service, RADIUS server.

Of, let's starts with a question, that will give you an idea of what RADIUS and why it is used.

You are developing a cool e-commerce website, would you focus more on building the authentication and authorisation logic for onboarding your users or rather delegate this to another service like Auth0, Google Identity Platform and AWS Cognito and focus more on the things that are more business oriented?

Yes! The correct answer is focus on business oriented feature.

If you aren't a developer or didn't get it anyhow, I will explain it under specific sections below.

RADIUS is an abbreviation of Remote Authentication Dial-In User Service which was created long time ago for point-to-point (PPP) links, even before the existence of the very first WiFi standard.

As the internet grew, more endpoints existed on the network and ISPs came into the picture who had to install the point of presence near their customer's locations for which a centralised single source of truth was needed where all the authentication credentials would be stored. Users can now access the internet from any location where the ISP's point of presence (POP) is available by entering their login credentials. These credentials are verified by the RADIUS authentication server, which then instructs the Network Access Server to permit the user to transmit packets to the internet.

1. A user first notified the authenticator to initiate the login session.
2. Authenticator asks for the identity (username) and proof (password) from the user
3. User (supplicant) responds with the information asked.
4. The authenticator takes that response and pass it transparently to the RADIUS server.
5. Upon verifying the details, RADIUS will return a successful or failure response.

Is it a Protocol or Product?

Understanding this aspect can be difficult for many users, as it is frequently misunderstood online. Here's a simple explanation: In this context, a server refers to software that implements specific logic and provides an interface for interaction.
RADIUS serves two primary functions. For starters, it establishes a standard set of capabilities that authentication servers must provide. Second, it defines a protocol that allows devices to use these capabilities. When we say RADIUS server, we mean the component of the authentication server that supports RADIUS capabilities. When we talk about RADIUS, we typically mean the protocol used to communicate with the server.

Motivation to Incorporate this in WiFi World

The architecture of the WLAN is somewhat similar to that of wired/Ethernet world. The extension of PPP protocol to Ethernet, PPPoE, can be used for carrying the wireless frames. Therefore, instead of creating everything from scratch, transmitting the existing packets through wireless frame seems to be the most appropriate and efficient decision given the situation at that time.

Using the unicast transmissions based on Transmitter and Receiver MAC addresses in the frame, the IEEE team treats each wireless connection between the device and the access point as if it were an independent connection. That means, After the first device is authenticated, the second device must repeat the process, even if you use the same user credentials on both devices. Similar to database normalisation, this approach centralises repeated data to a single source of truth.

As per 3.3 section of RFC 3748, IEEE 802.1X encapsulates EAP over LAN protocols, not point-to-point protocols, therefore it is not possible to negotiate non-EAP authentication mechanisms, like PAP or CHAP, which were possible in plain old PPP protocol during authentication phase.

In previous discussions, we established that EAP frames only contain authentication-related information, including status, and must be carried over some Layer 2 transmission protocol. The challenge is to transmit these frames over a LAN between the supplicant and the authenticator.

IEEE 802.1X addresses this issue by defining a protocol called EAP over LAN (EAPOL) to facilitate the passing of EAP messages between the supplicant and the authenticator. Beyond just carrying EAP messages, the committee decided to enhance EAPOL to perform additional management tasks related to authentication, such as notifying the authenticator to initiate the authentication session with EAPOL-Start. Consequently, more messages were added to support these functions.

The EAPoL-Start Frame

When the supplicant wants to connect to the network, it first needs to know whether the network is reachable in its proximity or not. For this purpose, the supplicant broadcasts multicasts EAPOL-Start frame to the IEEE 802.1X reserved MAC address (01:80:C2:00:00:03). If the authenticator receives this frame, it then responds with EAP-Request/Identity to ask for the supplicant identity, which can be a username.

The RADIUS packets encapsulated in the UDP packets and the ports are reversed in the response packets.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         Authenticator                         |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

• Code field is used to identify the intent of the packets in the RADIUS, for example the associated value of the Access-Request, Access-Response and etc goes here
• Identifier field usually increments for each request-response cycle to associate the response for the request. This helps in making the transmission asynchronous and handle concurrent requests (earlier RADIUS was single-threaded)
• Length field, as you may know, contains the length of the RADIUS packet including the Code, Identifier, Length, Authenticator and Attribute fields.
• Authenticator field is 16 octet (bytes) is used to authenticate the reply from the RADIUS server, and is used in the password hiding algorithm. It is the shared secret between client (authenticator here) and the server to provide further encryption in the transmission for the authentication process.
• Attributes field contains additional authentication-related information such as usernames from EAP-Request/Identity packets, passwords, and challenges. They can also include EAP-related details and vendor-specific information. It is similar (not exactly) to the Tagged parameters in the Beacon/Probe frames.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+

The data field can be sub-divided into Type and Type-Data fields for Request and Response values in the Code field.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Type-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

• Code field is used to convey the intent of the packet to the port access entity it is destined to. Since EAP only defines Codes 1-4, EAP packets with other codes MUST be silently discarded by both all PAEs.

• Identity field here has same role as in RADIUS packet, to match the request and response. It MUST be kept same when retrying the same packet.
• Length field is the total length of the EAP packet including Code, Identifier, Length and Data.
• Data field may carry the information related to the EAP method that is being used to negotiate the authentication details like identity, password and etc. If the Code is 3 or 4, this field is not populated at all because the status codes are sufficient to deduce the meaning of the packet.
  • Type field is used to classify what information is being requested by the authenticator and sent by the supplicant. Some of the values are defined in the Section 5 of EAP RFC 3748 and others (that came after the RFC) are assigned by IANA.
  • Type-Data field contains the actual authentication data related to the selected EAP-Type (method).

The RADIUS protocol is used alongside EAP, with EAP providing the authentication mechanisms and RADIUS handling the encapsulation of EAP packets and accounting services. While RADIUS includes built-in support for authentication, it is limited in incorporating various existing or emerging authentication methods such as LDAP and OTP.

Currently, RADIUS functions as a data repository for user accounts, storing user credentials and access list entries. These entries are retrieved through the implementation of an EAP method and verified against the database; if they match, RADIUS responds with an accept message, otherwise, it responds with a reject message. The presence of EAP-Message in the forwarded frames tell the RADIUS server to EAP method.

In the RFC 3579, a new attribute called EAP-Message was added which was used to encapsulate the EAP messages for the RADIUS without authenticator knowing the underlying format of the EAP method. This same thing was incorporated in the wireless LAN.

Think of EAP as a Passport.js implementation for the RADIUS authentication system.

The supplicant sends the EAP packet to the authenticator because RADIUS server is generally accessible only to authenticator via wired link and authenticator then extract the EAP payload can then extract the EAP payload and forward it to the authentication server transparently, typically inside a RADIUS packet.

Different EAP methods have unique steps during authentication. I will now outline the generic steps common to most EAP methods using the analogy of a visitor as a supplicant, your kid as an authenticator and you as authentication server.

1. EAPOL-Start is broadcasted by a supplicant if it didn't get EAP-Request/Identity from the authenticator as. This is similar to the visitor coming at your door and ringing the bell, notifying to start the authentication session.

   The Packet-Type value of this frame is 0x1.

2. EAP-Request/Identity is sent by the authenticator to the supplicant in response to EAPOL-Start to request the identity for the connecting client. Similar to how your kid would ask the visitor to tell his/her name.

   It will be sent as EAP-Packet type and in the Code is set to 1. This is mainly used for selecting the EAP method to use for the supplicant.

3. EAP-Response/Identity is sent by the supplicant to the authenticator providing its identity in the packet. It is when the visitor tells his/her name to your kid.

   Note $\to$ In the tunnelled authentication method, a supplicant may choose to send anonymous identity before tunnel is being initiated.

4. Radius-Access-Request is sent from the authenticator to the authentication server, that is generally encapsulated on the Ethernet frames transparently passing value of the Identity from the EAP-Response/Identity packet. This is when your kid tells you that there is a person called John (assumed name) asking to join for the dinner.

5. Radius-Access-Challenge is sent by the authentication server to the authenticator, including a plain text random message to be encrypted by the supplicant using the chosen EAP method. Since the supplicant cannot communicate directly with the server, this message is sent to the authenticator. The authenticator then extracts the information, encapsulates it into an EAP-Request/Auth, and sends the challenge to the supplicant. This is when you want to know more about the person so you tell your kid to ask the visitor which John he is.

6. EAP-Response/Auth is then sent by the supplicant to the authenticator with excrypted message or the information proving the identity of itself, which is then relayed to the authentication server by the authenticator in the Radius-Access-Request packet. This is same as the visitor shares his surname or some exclusive information with you, via your kid.

7. If the authentication server sends a Radius-Access-Accept message, the authenticator will respond with EAP-Success to the supplicant and initiate the four-way handshake by setting the Type field in EAPOL frames to 0x3 (EAPOL-Key). Conversely, If the server sends a Radius-Access-Reject message, the authenticator will respond with EAP-Reject, terminating the session immediately. This prevents any further interaction and denies network access to the supplicant.

With this analogy, the 4-way handshake occurs when John enters the hall and shakes hands with your child. Your child now remembers John, and the next time John comes, the child can allow him access to the hall without asking you. This is how the caching of the state of authentication of the supplicant in the authenticator to expedite the mobility of wireless devices as they move from one BSS to another.

All the packets exchanges (name starting with Radius-) that happen between authenticator and the authentication server are private and supplicant has zero knowledge of that.

Recall that the access point connects to the main router via Ethernet, requiring PPPoE to transmit frames. Therefore, Access-Request packets set Service-Type to Framed. This signals to the RADIUS server that the NAS believes the user prefers authentication and then enabling the controlled port.

This is what I believe at time of writing the post, if you find any other convincing information (with citations), please reach me out.

Simple Authentication using EAP-Identity

Imagine telling your kid that if Uncle John shows up or if the visitor says his name is John and has the secret password, they can let him into the hall. This way, checking his name and then granting access is like your kid playing security guard and allowing him access based on identity.

Similarly, EAP-Identity can be thought of as a very simple authentication method. Because it is the first packet transmitted by the supplicant, the authentication server can decide to allow the access without asking supplicant to prove its identity. For example, Guest login on windows, since the identity of guest is unknown it is often left password-less account. There would be at max 3 packets flow

1. EAP-Request/Identity from the authenticator
2. EAP-Response/Identity (sending John) from the supplicant
3. EAP-Success from the authenticator

This way the supplicant can send a random or special identity masquerading its original identity to prevent it from the being stolen by the sniffing of wireless packets by the attacker. In fact, Protected-EAP (PEAP) uses EAP-Identity to send an anonymous identity initially (Outer/First Phase). Authentication then occurs within an encrypted TLS tunnel, ensuring that even the authenticator cannot see the details of the communication between the supplicant and the authentication server. Then it sends the real identity (Inner/Second Phase) and further authentication packets.

I shared your initial doubts about the role of accounting in RADIUS. Initially, it seemed logical to use RADIUS solely for authentication while handling accounting and logging with an external server. However, RADIUS was specifically designed to simplify the operations of ISPs by facilitating user authentication on PPP links. This need for integrated billing and resource management led to the inclusion of accounting features in RADIUS, providing a comprehensive one-stop solution for authentication, authorisation and accounting.

After successful authentication and enabling the controlled port for the supplicant, the authenticator may send Radius-Accounting-Request packet to the authentication server including the supplicant information to start the accounting session for it. On success, the server must respond with Radius-Accounting-Response as acknowledgement.

• https://www2.rivier.edu/journal/ROAJ-Fall-2009/J286-RADIUS-Sood.pdf
• https://support.huawei.com/enterprise/en/doc/EDOC1100279023/4df860f5/8021x-port-based-authentication-configuration