Despite its dial-in name, it is widely used for wired and wireless access, virtual private networks, and other services that need centralized decisions about network admission.
A RADIUS client — often a switch, wireless controller, access point, or VPN gateway — sends an Access-Request containing identity and connection attributes. The server responds with Access-Accept, Access-Reject, or Access-Challenge and may return attributes that the client uses to configure the session. Separate accounting messages can record starts, stops, usage, and interim updates. Proxies can route requests between administrative domains.
Key points
Enforcement rolesThe RADIUS server evaluates policy or consults an identity source; the network access device enforces the returned decision and session attributes.
Attribute designControl which user, device, location, realm, and session data are sent, trusted, logged, proxied, or used in policy, and normalize vendor-specific attributes deliberately.
Transport securityClassic RADIUS over UDP relies on shared secrets and MD5-based protections that do not encrypt the whole packet. RADIUS over TLS protects transport; the newer RADIUS/1.1 profile removes MD5 use but remains experimental.
Important limitationAn Access-Accept is an instruction to the access device, not proof that it enforced policy correctly. RADIUS does not encrypt the admitted user’s traffic, and weak endpoint authentication, shared-secret handling, proxy trust, or accounting gaps can undermine the design.