Remote Authentication Dial In User Service (RADIUS)
obsoleted by
- rfc-2138 — Remote Authentication Dial In User Service (RADIUS)
Extracted elements (26)
RADIUS uses UDP rather than TCP for four reasons: (1) failover to a secondary server requires retransmission state above the transport layer anyway; (2) TCP's aggressive retransmit timing is neither needed nor wanted — users can wait seconds but not minutes; (3) the stateless nature of the protocol eliminates TCP connection management complexity; (4) UDP enables simple multi-threaded server implementations where each request can be handled by a separate process responding directly.
User-Password is encrypted using a chained MD5-XOR scheme rather than transmitted in cleartext or with a symmetric cipher, so the shared secret is never exposed on the wire. The chain links each 16-octet block to the previous ciphertext block (not to RA), preventing an attacker who knows one block from decrypting others without the secret.
For PAP, the NAS sends the PAP ID and password as User-Name and User-Password in an Access-Request. For CHAP, the NAS generates a 16-octet random challenge, sends it to the user, and forwards the CHAP username, CHAP ID, and CHAP response (as CHAP-Password) to the RADIUS server; the CHAP challenge goes in the CHAP-Challenge attribute or, if exactly 16 octets, in the Request Authenticator.
A NAS MUST treat an unknown or unsupported Service-Type value in an Access-Accept as though an Access-Reject had been received instead. This prevents silent misconfiguration when new service types are introduced.
A NAS that does not support challenge/response MUST treat an Access-Challenge as though it had received an Access-Reject. On receipt of a valid Access-Challenge, a supporting NAS SHOULD send a new Access-Request with a new ID and Request Authenticator.
An Access-Request MUST contain a User-Name attribute (Type 1) and MUST contain either a User-Password attribute or a CHAP-Password attribute. It SHOULD contain either NAS-IP-Address or NAS-Identifier (or both), and SHOULD contain NAS-Port or NAS-Port-Type unless not applicable.
If an Attribute is received in an Access-Request with an invalid Length, an Access-Reject SHOULD be transmitted. If received in an Access-Accept, Access-Reject, or Access-Challenge with an invalid length, the packet MUST either be treated as an Access-Reject or silently discarded.
If the RADIUS server cannot perform CHAP authentication (e.g., because it does not have the user's cleartext password), it MUST send an Access-Reject to the client. CHAP requires the cleartext password to be available at the server to encrypt the challenge and compare to the response.
The Identifier field MUST be changed whenever the content of the Attributes field changes and whenever a valid reply has been received for a previous request. For retransmissions, the Identifier MUST remain unchanged. The Request Authenticator MUST also be changed each time a new Identifier is used.
The Request Authenticator SHOULD be unpredictable and unique over the lifetime of the shared secret; reuse of a value with the same secret would allow an attacker to replay a previously intercepted response. The value SHOULD exhibit global and temporal uniqueness.
The shared secret SHOULD be at least 16 octets long and as unguessable as a well-chosen password, to protect against exhaustive search attacks. A RADIUS server SHOULD use the source IP address of the UDP packet to select which shared secret to apply, enabling proxy support.
Upon receipt of an Access-Request from a valid client, the RADIUS server MUST transmit an appropriate reply. A request from a client for which the server does not have a shared secret MUST be silently discarded.
RADIUS defines four primary packet codes: Access-Request (1), Access-Accept (2), Access-Reject (3), and Access-Challenge (11). Codes 4 and 5 (Accounting) are defined in a companion document. Packets with invalid Code fields are silently discarded.
The challenge/response flow uses Access-Challenge to issue an unpredictable number to the user, who encrypts it with their device. The NAS re-submits an Access-Request with a new ID, the encrypted response in User-Password, and the State attribute from the challenge (if any) copied unmodified.
The Proxy-State attribute (Type 33) is added by a proxy server when forwarding an Access-Request and MUST be returned unmodified in the Accept/Reject/Challenge response. The proxy MUST remove it before forwarding the response to the originating NAS, and MUST re-sign the packet because the Response Authenticator covers the full packet contents.
The Request Authenticator in an Access-Request is a 16-octet random number that SHOULD be globally and temporally unique over the lifetime of the shared secret. It serves as an anti-replay nonce and as input to the User-Password encryption algorithm.
The Response Authenticator in Access-Accept, Access-Reject, and Access-Challenge packets is computed as MD5(Code+ID+Length+RequestAuth+Attributes+Secret), where RequestAuth is taken from the corresponding Access-Request. This authenticates the server's reply to the NAS.
The State attribute (Type 24) is sent by the server in an Access-Challenge or qualifying Access-Accept and MUST be returned unmodified by the NAS in the subsequent Access-Request. A packet may contain at most one State attribute; its contents are opaque to the client.
The Vendor-Specific attribute (Type 26, minimum Length 7) carries a 4-octet Vendor-Id (SMI Private Enterprise Code, high octet 0) followed by vendor-defined sub-attributes. Servers that do not recognize vendor-specific data MUST ignore it; it MUST NOT affect RADIUS protocol operation.
This document defines the RADIUS Attribute Type registry (values 1-63 assigned; 192-223 reserved for experimental use; 224-240 reserved for implementation-specific use; 241-255 reserved). Up-to-date assignments are maintained in the Assigned Numbers RFC. Unknown attribute types MAY be ignored by both clients and servers.
RADIUS does not protect against theft of an authenticated session via realtime active wiretapping. However, generating unique unpredictable Request Authenticators protects against a wide range of active attacks, including attackers tricking a server into responding to a predicted future request and using that response to masquerade as the server.
Transactions between NAS and RADIUS server are authenticated via a shared secret that is never sent over the network. User passwords are encrypted with MD5-XOR using the shared secret and Request Authenticator. The shared secret should be at least 16 octets and unguessable to protect against exhaustive search.
Each RADIUS Attribute is encoded as a Type-Length-Value triple: Type (1 octet), Length (1 octet, includes Type and Length fields), and Value (0 or more octets). Value data types are string (0-253 octets), address (32-bit), integer (32-bit), and time (32-bit seconds since epoch).
The CHAP-Password attribute (Type 3, Length 19) contains a 1-octet CHAP Identifier followed by a 16-octet CHAP Response string. The CHAP challenge is taken from the CHAP-Challenge attribute (Type 60) if present, otherwise from the Request Authenticator field.
The RADIUS packet header consists of Code (1 octet), Identifier (1 octet), Length (2 octets, minimum 20 maximum 4096), and Authenticator (16 octets), followed by variable-length Attributes. The packet is encapsulated in a single UDP datagram on destination port 1812.
The User-Password attribute (Type 2, Length 18-130) encrypts the password using a chained MD5-XOR scheme: b1=MD5(S+RA), c(1)=p1 XOR b1; bi=MD5(S+c(i-1)), c(i)=pi XOR bi, where S is the shared secret and RA is the Request Authenticator. Passwords are padded to a multiple of 16 octets; maximum 128 characters.