Remote Authentication Dial In User Service (RADIUS)
obsoleted by
- rfc-2865 — Remote Authentication Dial In User Service (RADIUS)
obsoletes
- rfc-2058 — Remote Authentication Dial In User Service (RADIUS)
Extracted elements (28)
RADIUS uses UDP instead of TCP for four reasons: (1) failover to an alternate server requires retransmission state above the transport layer regardless; (2) the protocol tolerates several-second delays but not multi-minute TCP retransmit waits; (3) the stateless nature eliminates connection teardown complexity; (4) UDP allows trivially multi-threaded servers where each spawned process responds directly via a single UDP send.
Early RADIUS deployments erroneously used port 1645 (which conflicts with the 'datametrics' service). The officially assigned IANA port for RADIUS is 1812 (UDP). Implementations must be aware that legacy deployments may still use 1645.
For PAP, the NAS sends the PAP ID and password as User-Name and User-Password in an Access-Request. For CHAP, the NAS sends the CHAP username as User-Name and the CHAP ID plus response as CHAP-Password (Type 3); the 16-octet CHAP challenge may be placed in the CHAP-Challenge attribute or, if exactly 16 octets, in the Request Authenticator field.
A NAS MUST treat unknown or unsupported Service-Type values (Type 6) as though an Access-Reject had been received. Service-Type values in an Access-Request are only hints that the server is not required to honor.
A NAS that does not support challenge/response MUST treat an Access-Challenge as though it had received an Access-Reject. A NAS that does support it SHOULD send a new Access-Request with a new ID, new Request Authenticator, the encrypted user response as User-Password, and the State attribute from the challenge unchanged.
An Access-Request MUST contain a User-Name attribute and MUST contain either a User-Password or CHAP-Password attribute. It SHOULD contain NAS-IP-Address or NAS-Identifier and SHOULD contain NAS-Port or NAS-Port-Type.
If an attribute is received in an Access-Request with an invalid Length, an Access-Reject SHOULD be transmitted. If an attribute with invalid length appears in an Access-Accept, Access-Reject, or Access-Challenge, the packet MUST be treated as an Access-Reject or silently discarded.
If CHAP authentication is requested but the user's plaintext password is unavailable to the RADIUS server, the server MUST send an Access-Reject; CHAP requires cleartext password access to recompute the challenge hash.
If the order of multiple attributes of the same Type matters, that order SHOULD be preserved. The order of attributes of different Types is not required to be preserved.
Multiple Reply-Message attributes (Type 18) MAY be included in a packet, but if any are displayed to the user they MUST be displayed in the same order as they appear in the packet.
On reception of an Access-Accept or Access-Challenge, the Response Authenticator field MUST contain the correct MD5 hash computed as MD5(Code+ID+Length+RequestAuth+Attributes+Secret); packets with an invalid Response Authenticator MUST be silently discarded.
The Identifier field MUST be changed whenever the Attributes field content changes and whenever a valid reply has been received for a previous request. For retransmissions the Identifier MUST remain unchanged, and the Request Authenticator MUST be changed each time a new Identifier is used.
The RADIUS server MUST silently discard any request from a client for which it does not have a shared secret configured.
The State attribute (Type 24) received in an Access-Challenge MUST be sent unmodified in the subsequent Access-Request reply. A packet MAY contain at most one State attribute.
The Vendor-Specific attribute (Type 26) MUST NOT affect RADIUS protocol operation. Servers not equipped to interpret vendor-specific data MUST ignore it; clients that do not receive desired vendor-specific data SHOULD attempt to operate without it.
RADIUS defines four access-control packet codes: Access-Request (1), Access-Accept (2), Access-Reject (3), and Access-Challenge (11). Codes 4/5 (Accounting) are defined in a companion document; codes 12/13 are experimental; code 255 is reserved. Invalid code values cause silent discard.
The challenge/response flow uses Access-Challenge packets containing a Reply-Message prompt and optional State attribute. The client re-submits a new Access-Request (new ID, new Request Authenticator) with the encrypted user response as User-Password and the State attribute echoed unchanged. The server may respond with Access-Accept, Access-Reject, or another Access-Challenge.
The Framed-IP-Address attribute (Type 8) uses the special value 0xFFFFFFFF to indicate the NAS should allow the user to negotiate an address, and 0xFFFFFFFE to indicate the NAS should assign one from a pool; other values are the literal IP address to assign.
The Request Authenticator in an Access-Request is a 16-octet random value used as input to the password-hiding algorithm and to compute the Response Authenticator. The Response Authenticator in replies is MD5(Code+ID+Length+RequestAuth+Attributes+Secret).
The Vendor-Specific attribute (Type 26) embeds a 4-octet SMI Enterprise Vendor-Id (high octet 0, low 3 octets the IANA Private Enterprise number) followed by vendor-defined sub-TLV fields. Minimum length is 7. It is RECOMMENDED to encode sub-attributes as vendor-type / vendor-length / value triples.
RFC 2138 defines the RADIUS attribute type space: types 1–63 are assigned in this document (with 17 and 21 unassigned); types 40–59 are reserved for accounting; types 192–223 are reserved for experimental use; 224–240 for implementation-specific use; 241–255 are reserved and MUST NOT be used. Unknown attribute types MAY be ignored by both clients and servers.
The Request Authenticator SHOULD be unpredictable and globally and temporally unique over the lifetime of the shared secret; reuse with the same secret allows an attacker to replay a previously intercepted response or trick a server into responding to a predicted future request and impersonate it.
The shared secret SHOULD be at least 16 octets and as unguessable as a well-chosen password to resist exhaustive search. A RADIUS server SHOULD use the source IP address of each UDP packet to select the correct shared secret, enabling proxy support.
When a forwarding proxy adds a Proxy-State attribute to a request and removes it from a response, the MD5 signature over the full packet contents is invalidated; the proxy MUST re-sign the response packet to maintain authenticator integrity.
Each RADIUS attribute is encoded as a Type-Length-Value triple: Type (1 octet), Length (1 octet, inclusive of Type and Length), Value (0–253 octets). Value data types are string (0–253 octets), address (32-bit big-endian), integer (32-bit big-endian), or time (32-bit seconds since epoch).
Every RADIUS packet is encapsulated in a single UDP datagram to port 1812 and consists of: Code (1 octet), Identifier (1 octet), Length (2 octets, min 20 / max 4096), Authenticator (16 octets), and a variable-length Attributes field.
The CHAP-Password attribute (Type 3) carries a 1-octet CHAP Identifier followed by a 16-octet CHAP Response string; total attribute Length is fixed at 19. The CHAP challenge is taken from the CHAP-Challenge attribute (Type 60) if present, otherwise from the Request Authenticator.
The User-Password attribute (Type 2) hides the password using a chained MD5 scheme: b1=MD5(S+RA), c(1)=p1 XOR b1; bi=MD5(S+c(i-1)), c(i)=pi XOR bi. The String field is 16–128 octets (attribute Length 18–130), supporting passwords up to 128 characters in 16-octet blocks.