Port 1812: RADIUS — The Gatekeeper

The Question at the Gate

Port 1812 carries a single, ancient question: Who are you?

Every enterprise WiFi network asking for your credentials. Every VPN checking if you belong. Every router deciding whether to let a packet pass. The question travels as a UDP datagram to port 1812, and the answer comes back: Access-Accept, or Access-Reject.

RADIUS, the Remote Authentication Dial-In User Service, is the protocol that answers that question. It has been doing so since 1991, when people accessed the Internet through modems that screamed across telephone lines. The modems are gone, but the question remains, and RADIUS still answers it billions of times a day.

How RADIUS Works

The elegance of RADIUS lies in its simplicity. Three actors, one question, one answer.

The Supplicant is you. The person typing credentials into a WiFi login, or the laptop presenting a certificate to a corporate network.

The Network Access Server (NAS) is the device you are trying to connect through. A wireless access point. A VPN concentrator. A switch port. This device does not know who you are. It only knows how to ask.

The RADIUS Server is the oracle. It holds the database of identities, or knows how to reach one. When the NAS asks "is this person allowed?", the RADIUS server consults its records and delivers judgment.¹

The conversation follows a pattern:

1. You present credentials to the NAS
2. The NAS packages them into an Access-Request and sends it to port 1812
3. The RADIUS server checks its records
4. The server responds with Access-Accept (welcome), Access-Reject (denied), or Access-Challenge (prove yourself further)
5. If accepted, the response includes configuration: what kind of access you get, what VLAN you belong to, how long your session lasts

The password never travels in plaintext. It is obscured using a shared secret between the NAS and the server, hashed with MD5. The shared secret itself never crosses the network.²

The Origin Story

In 1991, the National Science Foundation faced a bureaucratic problem with profound technical implications.

NSFnet, the backbone that would become the modern Internet, needed dial-in access. Researchers across America wanted to connect their modems to this network of networks. But NSF had a rule: no proprietary systems. The dial-in infrastructure had to be commercial, standardized, open.³

Merit Network, the organization managing much of NSFnet, put out a Request for Information. They needed a way to authenticate thousands of users dialing in from across the country, using a centralized system that could work with any vendor's equipment.⁴

Six months later, a small company in Pleasanton, California responded. Livingston Enterprises proposed something new: a protocol that could sit between any network access device and any authentication database. The device would ask the question. A central server would answer. The protocol would carry the conversation.

Merit awarded Livingston the contract. In 1993, the first RADIUS-authenticated Network Access Server went live, allowing people across Michigan to dial into MichNet and reach NSFnet.⁵ Carl Rigney and Steve Willens of Livingston wrote the code and, eventually, the specification.

The protocol spread. By 1997, it was standardized as RFC 2058. Today's version, RFC 2865, was published in June 2000.⁶ Livingston was acquired by Lucent. The protocol they created now authenticates access to virtually every enterprise network on Earth.

The Port Number Story

Here is a piece of Internet trivia that network engineers still encounter: RADIUS officially uses port 1812, but many systems default to port 1645.

The reason is historical. When Livingston first deployed RADIUS, they chose port 1645 for authentication and port 1646 for accounting. These seemed available. They were not. Port 1645 was already assigned to "datametrics," and 1646 to "sa-msg-port."⁷

When RADIUS was formally standardized, IANA assigned the correct ports: 1812 for authentication, 1813 for accounting. But the early deployments were already running. The old port numbers persist in default configurations decades later, a fossil record of RADIUS's pre-standardization youth.

The Companion Port

Port 1812 handles authentication: who are you, and are you allowed?

Port 1813 handles accounting: what did you do, and for how long?

When you connect to a network, the RADIUS server on port 1812 decides whether to let you in. Then, throughout your session, the network access device sends accounting records to port 1813. Session started. Session active. Bytes transferred. Session ended.⁸

This is how ISPs know how much bandwidth you used. How enterprises track who accessed which resources. How hotels charge you by the hour for WiFi. The authentication question flows through 1812. The billing data flows through 1813.

Why UDP?

RADIUS runs over UDP, not TCP. This seems counterintuitive. Authentication is important. Should it not use a reliable transport?

The authors chose UDP deliberately. When a RADIUS server fails, the client needs to query a backup server immediately. TCP's connection establishment would add latency. With UDP, the client simply retransmits to an alternate server. The protocol handles its own reliability at the application layer.⁹

This was a reasonable design decision in 1991. It became a liability later.

The Cryptographic Flaw

RADIUS was designed before cryptographic protocol design was well understood. Its authentication mechanism is ad-hoc, built around MD5.¹⁰

MD5 was a reasonable choice in 1991. It was fast, widely available, and no one had broken it yet. The RADIUS designers used it to create a Response Authenticator, a way for clients to verify that responses actually came from the legitimate server.

The first MD5 collisions were found in 2004. The cryptographic community declared MD5 unsuitable for security applications. RADIUS kept using it.

In July 2024, researchers from UC San Diego, CWI Amsterdam, Microsoft, and BastionZero published the Blast-RADIUS attack (CVE-2024-3596). They demonstrated that an attacker positioned between a RADIUS client and server could forge valid responses, turning Access-Reject into Access-Accept without knowing the shared secret.¹¹

The attack requires a person-in-the-middle position. It cannot be exploited remotely. But it proves that RADIUS's 30-year-old cryptographic construction is fundamentally broken.

The mitigation is to wrap RADIUS in TLS, creating what is sometimes called RadSec. Or to require Message-Authenticator attributes on all packets. Or to tunnel the traffic through IPsec. The protocol itself cannot be fixed. It can only be armored.¹²

What Flows Through Port 1812 Today

The dial-up modems are gone. The protocol remains.

Enterprise WiFi: When you connect to a corporate wireless network and enter your credentials, 802.1X authentication often uses RADIUS as its backend. The access point sends your credentials to port 1812. The server checks Active Directory or LDAP. You get network access, or you do not.¹³

VPN Authentication: Remote workers connecting to corporate VPNs often authenticate through RADIUS. The VPN concentrator queries the RADIUS server. The server decides.

Network Device Access: When network administrators log into routers and switches, RADIUS can provide centralized authentication. One database of admin credentials. Thousands of devices querying it.

ISP Subscriber Management: Internet service providers use RADIUS to authenticate subscribers and track usage. When you connect to your home ISP, a RADIUS exchange may be happening in the background.

Eduroam: The global academic roaming service that lets university students and staff connect to WiFi at any participating institution worldwide uses RADIUS federation. Your home university vouches for you. The visited institution trusts that voucher. RADIUS carries the conversation.¹⁴

RADIUS vs. TACACS+

RADIUS is not the only AAA protocol. Cisco's TACACS+ is its main competitor, and understanding the difference illuminates what RADIUS is for.

RADIUS combines authentication and authorization in a single exchange. You ask "can I connect?" and the answer includes what kind of connection you get.

TACACS+ separates them. Authentication, authorization, and accounting are three distinct conversations. This makes TACACS+ better for device administration, where you want fine-grained control over what each command an admin can run.¹⁵

RADIUS encrypts only the password. TACACS+ encrypts the entire packet body.

But here is the key distinction: 802.1X was designed with RADIUS in mind. If you are authenticating users and devices connecting to a network, you use RADIUS. If you are authenticating administrators logging into network infrastructure, you might use TACACS+. Many enterprises run both.¹⁶

The Weight of the Question

Port 1812 carries a question that has been asked since the first human stood at the first gate: Who goes there?

The protocol is imperfect. Its cryptography is outdated. Its designers could not have anticipated the attacks that would emerge decades later. Yet it persists because it works, because it is everywhere, because the alternative is rebuilding authentication infrastructure that took thirty years to deploy.

Every time you tap your badge to enter a building, every time your laptop silently authenticates to corporate WiFi, every time a VPN checks your credentials before letting you into a private network, a packet travels to port 1812. The RADIUS server receives it, consults its records, and renders judgment.

Access-Accept. Access-Reject.

The gatekeeper decides. The gate opens, or it does not. The question, and the answer, flow through port 1812.

Quick Reference

Security Considerations

• Blast-RADIUS (CVE-2024-3596): Protocol-level vulnerability allowing response forgery; mitigate with RADIUS over TLS
• MD5 Weakness: The Response Authenticator uses broken MD5 cryptography
• Plaintext Attributes: Only passwords are encrypted; usernames and other attributes travel in cleartext
• Shared Secret Management: Compromise of the shared secret allows full traffic decryption
• Recommendation: Use RadSec (RADIUS over TLS) or tunnel through IPsec

Related Ports