# RADIUS end to end: one 802.1X login, packet by packet

> What a switch and a RADIUS server actually say to each other when a laptop plugs in: the packet fields and codes of RFC 2865, the attributes that carry the identity and the policy, the EAP conversation relayed in EAP-Message attributes, the VLAN assignment of RFC 3580, the Start and Stop records of RFC 2866, the server-initiated Change of Authorization of RFC 5176, the proxy chain, and the two things the shared secret does and does not protect. Every number from the RFC it comes from.

Source: https://ronutz.com/en/learn/radius-end-to-end  
Updated: 2026-10-06

---

## Why a protocol for modems still decides who gets on the network

RADIUS (Remote Authentication Dial-In User Service) was specified for terminal servers answering telephone calls, and the name has never been updated because the job has not changed: a device at the edge of the network has somebody on the other end of a connection and needs an answer from a server about whether, and how, to let them in. RFC 2865, published in June 2000 by Rigney, Willens, Rubens and Simpson and obsoleting RFC 2138, is still the base specification. Its client is the network access server, the NAS, which today is a switch, an access point, a wireless controller, a VPN (virtual private network) concentrator or a broadband gateway; its server is the thing with the policy. Every 802.1X port, every enterprise SSID and most VPN logins run this protocol, so a conversation worth understanding in detail is a wired 802.1X login, which exercises nearly every part of it.

## The packet

A RADIUS packet is five things in order: a Code of one octet, an Identifier of one octet, a Length of two octets, an Authenticator of sixteen octets, and a list of attributes. RFC 2865 says the Identifier "aids in matching requests and replies", and that the packet's "minimum length is 20 and maximum length is 4096". The codes a login uses are 1 Access-Request, 2 Access-Accept, 3 Access-Reject and 11 Access-Challenge; RFC 2866 adds 4 Accounting-Request and 5 Accounting-Response. The transport is UDP, port 1812 for authentication and 1813 for accounting; the RFCs note that the earlier ports, 1645 and 1646, conflicted with other services and were replaced.

Attributes are type-length-value triples, and the type numbers appear in every capture and every server log. The ones this login will use, with their RFC 2865 numbers: User-Name (1), User-Password (2), NAS-IP-Address (4), NAS-Port (5), Service-Type (6), Framed-IP-Address (8), Reply-Message (18), State (24), Class (25), Vendor-Specific (26), Session-Timeout (27), Idle-Timeout (28), Termination-Action (29), Called-Station-Id (30), Calling-Station-Id (31), NAS-Identifier (32), Proxy-State (33) and NAS-Port-Type (61). RFC 3579 added EAP-Message (79) and Message-Authenticator (80). RFC 2868 added the tunnel attributes, of which three matter here: Tunnel-Type (64), Tunnel-Medium-Type (65) and Tunnel-Private-Group-ID (81).

## Step one: the switch asks

A laptop is plugged into a port configured for 802.1X. The switch, acting as the authenticator, has been sending EAP-Request Identity frames to the port, and the laptop's supplicant answers with its identity. The switch now builds an Access-Request. It puts the identity in User-Name (1), the raw EAP packet in one or more EAP-Message (79) attributes, its own address or name in NAS-IP-Address (4) or NAS-Identifier (32), the port in NAS-Port (5), and NAS-Port-Type (61) set to Ethernet (15), the value RFC 3580 names for wired 802.1X; a wireless controller would send Wireless-IEEE 802.11 (19). Calling-Station-Id (31) carries the laptop's MAC address, which RFC 3580 says is sent "in ASCII format (upper case only), with octet values separated by a '-'", as in 00-10-A4-23-19-C0; Called-Station-Id (30) carries the switch port's or access point's MAC in the same form, with the SSID appended after a colon on wireless.

Because the request contains an EAP-Message, RFC 3579 requires that it also contain a Message-Authenticator (80): "the Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets containing an EAP-Message attribute." That attribute is, in RFC 3579's definition, an HMAC-MD5 over the type, identifier, length, request authenticator and attributes with the shared secret as the key, and it is the only thing that authenticates the request as a whole; a receiver "MUST silently discard the packet if it does not match", and a server that receives an EAP-Message with no Message-Authenticator "SHOULD" discard that too.

## Step two: the challenge rounds

The server does not answer yes or no. It answers with an Access-Challenge (11), carrying its own EAP-Message with the next step of the EAP method it wants to run, and a State (24) attribute. State is the server's handle on the conversation: the client returns it unmodified in the next Access-Request, which is how a stateless-looking UDP exchange carries a multi-round exchange. The switch extracts the EAP packet from the challenge, sends it to the laptop in an EAPOL frame, waits for the laptop's EAP response, wraps that in a new Access-Request with the same State and sends it back.

For a method such as EAP-TLS or PEAP this happens many times, because a TLS handshake carrying certificates does not fit in one EAP packet; RFC 5216 defines the fragmentation and the empty acknowledgements, and RFC 3579 says that where several EAP-Message attributes are needed in one RADIUS packet "they MUST be in order and they MUST be consecutive attributes" and are concatenated into a single EAP packet. The switch never interprets any of it. In the words of RFC 3579, the NAS "forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes". The article on 802.1X and the EAP methods covers what happens inside those packets; for the switch the method is opaque, which is why changing it never requires touching the switches.

## Step three: the answer, and the policy riding on it

When the EAP method completes, the server sends an Access-Accept (2) or an Access-Reject (3), with the final EAP Success or Failure inside an EAP-Message. The Accept is where the policy travels, and the attributes in it are what a policy engine's rules actually produce.

VLAN (virtual local area network) assignment uses the three tunnel attributes together, exactly as RFC 3580 writes them: Tunnel-Type set to VLAN (13), Tunnel-Medium-Type set to 802 (6) and Tunnel-Private-Group-ID carrying the VLAN identifier, a number from 1 to 4094, as a string. The switch places the port in that VLAN for the session. Session-Timeout (27) together with Termination-Action (29) set to RADIUS-Request tells the port, in RFC 3580's words, "the maximum number of seconds of service provided prior to re-authentication". Class (25) is a tag the server attaches, and RFC 2865 says it "SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported", which is how a session's accounting records can be tied back to the policy that admitted it. Filter-Id (11) names an access list on the switch; Vendor-Specific (26) carries whatever the vendor defined. Reply-Message (18) carries text for the user, which an 802.1X supplicant has nowhere to show but a web-authentication portal does.

A Reject carries the EAP Failure and nothing else the switch will use. The port stays closed, or moves to whatever the switch is configured to do next: a guest VLAN, MAC Authentication Bypass, web authentication, or nothing.

## What the shared secret protects, and what it does not

Every pair of client and server shares a secret, which RFC 2865 says "SHOULD be as unguessable as a well-chosen password" and "MUST NOT be empty". It is used in three places. The User-Password (2) attribute, where present, is hidden by XOR with an MD5 stream computed from the secret and the request's Authenticator, sixteen octets at a time; in an 802.1X login there is no User-Password, because the credential travels inside EAP. The Authenticator of every reply is an MD5 over the code, identifier, length, request authenticator, attributes and secret, which lets the client confirm the reply came from a holder of the secret. And the Message-Authenticator attribute is a keyed hash over the packet, protecting the EAP exchange from tampering.

Everything else is in clear text: the username, the MAC addresses, the switch's identity, the EAP messages themselves (the TLS inside them is encrypted, the EAP framing is not), and every attribute of the Accept, including the VLAN the user landed in. Cisco's comparison document states it plainly: "RADIUS encrypts only the password in the access-request packet, from the client to the server. The remainder of the packet is unencrypted." RFC 6614, the RadSec specification, adds the verdict on the cryptography: "RADIUS security is based on the MD5 algorithm, which has been proven to be insecure." Its remedy "wraps the entire RADIUS packet payload into a TLS stream" over TCP port 2083, with both ends authenticated by X.509 certificates and the shared secret fixed to the literal string radsec, which is there only so the MD5 arithmetic can still be performed. Where switches and servers support it, RadSec is how the conversation above stops crossing the network in the clear.

## Step four: accounting

Once the port opens, the switch sends an Accounting-Request (4) to port 1813 with Acct-Status-Type set to Start (1), and the server answers with an Accounting-Response (5). RFC 2866 recommends that "the client continue attempting to send the Accounting-Request packet until it receives an acknowledgement, using some form of backoff", so a brief server outage delays records rather than losing them. The Start carries the User-Name, the station identifiers, an Acct-Session-Id that will identify every record of this session, and the Class the server sent in the Accept. Interim-Update (3) records follow at the interval the switch is configured for, with the running counters: Acct-Input-Octets and Acct-Output-Octets, Acct-Input-Packets and Acct-Output-Packets, Acct-Session-Time in seconds. When the laptop is unplugged or the session is terminated, a Stop (2) record carries the final counters and Acct-Terminate-Cause. Accounting-On (7) and Accounting-Off (8) are sent when the switch itself starts or stops serving, which tells the server to close every session it still believes is open on that device.

The Request Authenticator of an accounting packet is an MD5 over the packet with sixteen zero octets in the Authenticator's place and the secret appended, which lets the server reject records from a client that does not know the secret. The records themselves are clear text. The article on who did what and when describes what to do with them.

## Step five: the server changes its mind

Base RADIUS gives the server no way to speak after the Accept. RFC 5176, the Dynamic Authorization Extensions of January 2008, adds two requests the server side sends to the switch: Disconnect-Request (40), answered by Disconnect-ACK (41) or Disconnect-NAK (42), and CoA-Request (43), Change of Authorization, answered by CoA-ACK (44) or CoA-NAK (45). The RFC specifies the destination: "for either Disconnect-Request or CoA-Request packets UDP port 3799 is used as the destination port". The roles are named the other way round from the login above, the Dynamic Authorization Client being the policy server and the Dynamic Authorization Server being the switch, which is why a packet capture shows the switch answering on 3799.

A CoA identifies the session with the same attributes the session was built from, User-Name, Calling-Station-Id, Acct-Session-Id, and carries the attributes to change, most often a new Tunnel-Private-Group-ID to move the device to a quarantine VLAN, a new filter, or an instruction to re-authenticate. If the switch cannot apply an attribute it answers CoA-NAK with an Error-Cause, and the RFC assigns 401 to Unsupported Attribute. This is the mechanism under every posture check, every guest expiry and every "isolate this endpoint" button, and it requires two things the original flows never needed: the switch configured to accept dynamic authorization from the specific servers, and the reverse direction open through any firewall between them.

## Proxies, realms and federations

The server the switch talks to is often not the server that knows the user. RFC 2865 allows a server to act as a proxy, forwarding the request to another server and relaying the reply; each proxy appends its own Proxy-State (33) attribute so the reply can be routed back along the path, and the RFC warns that loops must be avoided. Routing is usually by realm, the part of the User-Name after an @ sign, which is how a visitor's credentials are checked by the visitor's own organisation. Chains of proxies across organisations are the setting RFC 6614 names as RadSec's main use, since a shared secret per pair of organisations does not scale and clear-text attributes crossing the public Internet are unacceptable. Inside a single organisation the same mechanism lets one set of switches reach several policy servers through a local proxy, with the secret configured once.

## Where RADIUS stops and TACACS+ begins

Cisco's comparison, written by the company that developed TACACS+ after it "seriously evaluated RADIUS as a security protocol", lists the differences that still decide which protocol does which job: "RADIUS uses UDP while TACACS+ uses TCP"; "RADIUS combines authentication and authorization", whereas TACACS+ separates the three exchanges; "RADIUS does not allow users to control which commands can be executed on a router", whereas TACACS+ "provides two methods to control the authorization of router commands on a per-user or per-group basis". The consequence is the division every estate ends up with: RADIUS for network access, the user or device being admitted at a port, an SSID or a VPN, where 802.1X and the EAP methods live; TACACS+ for device administration, where an engineer's commands must be authorised one by one and recorded. The companion article on TACACS+ device administration walks that side.

## A troubleshooting list, from the fields above

Most RADIUS failures are visible in the fields this article has named. A request that gets no reply at all is usually a secret mismatch, because a server whose Message-Authenticator check fails must silently discard the packet rather than reject it, or a firewall closing 1812. A method that fails after several challenge rounds, on a path that works for short exchanges, is fragmentation or a packet-size problem somewhere between the switch and the server, since EAP-TLS needs many large packets where a password method needs few. A user who authenticates but lands in the wrong network has an Accept whose tunnel attributes name a VLAN the switch does not have, or a Tunnel-Medium-Type other than 6. A policy engine that believes it quarantined a device the switch still serves has a CoA that was never accepted, which the CoA-NAK and its Error-Cause explain if anyone reads them. And a session with no accounting records has a switch that was never told where to send them, which is the oldest finding in the field and the subject of the accounting article.

## Sources

- [RFC 2865, Remote Authentication Dial In User Service (RADIUS), Rigney, Willens, Rubens, Simpson, June 2000: the packet fields, the codes, the attribute numbers, the User-Password hiding, the response authenticator, the shared secret rules, the Identifier's role, the 20 to 4096 octet length, Class in accounting, Proxy-State and proxy chains (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc2865)
- [RFC 2866, RADIUS Accounting, Rigney, June 2000: port 1813, the Acct-Status-Type values, the accounting attributes, the zeroed request authenticator and the retry recommendation (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc2866)
- [RFC 3579, RADIUS Support For Extensible Authentication Protocol (EAP), Aboba and Calhoun, September 2003: EAP-Message (79) and Message-Authenticator (80), the pass-through NAS, consecutive EAP-Message attributes (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc3579)
- [RFC 3580, IEEE 802.1X RADIUS Usage Guidelines, Congdon, Aboba, Smith, Zorn, Roese, September 2003: VLAN assignment with the three tunnel attributes, the station identifier formats, NAS-Port-Type 15 and 19, Session-Timeout and Termination-Action (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc3580)
- [RFC 2868, RADIUS Attributes for Tunnel Protocol Support, June 2000: Tunnel-Type (64), Tunnel-Medium-Type (65) and Tunnel-Private-Group-ID (81), medium type 6 for 802 (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc2868)
- [RFC 5176, Dynamic Authorization Extensions to RADIUS, Chiba, Dommety, Eklund, Mitton, Aboba, January 2008: codes 40 to 45, UDP port 3799, the client and server roles, Error-Cause 401 (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc5176)
- [RFC 6614, Transport Layer Security (TLS) Encryption for RADIUS, Winter, McCauley, Venaas, Wierenga, May 2012: the MD5 verdict, the TLS stream on TCP 2083, the fixed secret and the roaming use case (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc6614)
- [RFC 5216, The EAP-TLS Authentication Protocol, March 2008: fragmentation with the L and M bits and the empty acknowledgement (read 2026-10-06)](https://www.rfc-editor.org/rfc/rfc5216)
- [Cisco, TACACS+ and RADIUS Comparison, document 13838: UDP against TCP, only the password encrypted, authentication and authorization combined, per-command control, Cisco's evaluation of RADIUS before developing TACACS+ (read 2026-10-06)](https://www.cisco.com/c/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/13838-10.html)