Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes
updates
Extracted elements (26)
During server overload, dropping packets with equal probability across all sessions causes high failure rates for multi-round protocols like EAP. Servers should preferentially accept Access-Request packets containing a valid State attribute so that in-progress authentication conversations are more likely to complete, reducing retry-induced load.
FreeRADIUS uses the tuple (EAP Identifier, State attribute, source IP address) as the key to uniquely identify EAP sessions rather than NAS-IP-Address or other NAS-controlled attributes. Because the State attribute is under the server's control, session uniqueness is controlled by the server, not the NAS, avoiding proxy-modification problems. This algorithm SHOULD be used in preference to any other method.
RFC 2866 inconsistently describes Acct-Session-Id as type 'String' in the attribute format figure but as UTF-8 encoded text in the prose, while RFC 2865 defines Text as UTF-8 encoded. This is a typographical error; Acct-Session-Id is of type Text, not String. Similarly, Acct-Multi-Session-Id SHOULD be treated as Text.
RFC 2869 Section 5.19 incorrectly places Password-Retry in the Reject column (0-1) of the attribute table. The correct placement is in the Challenge column (0-1) with Reject = 0. Additionally, Password-Retry in EAP authentications is deprecated per RFC 3579; it is only valid for ARAP authentication.
RFC 2866 restricts Acct-Input-Octets, Acct-Output-Octets, Acct-Session-Time, Acct-Input-Packets, Acct-Output-Packets, and Acct-Terminate-Cause to Accounting-Stop records, but RFC 2869 Section 2.1 allows all except Acct-Terminate-Cause in Interim-Update records. RFC 5080 clarifies that the RFC 2869 interpretation is authoritative and these attributes are allowable in Interim Accounting records.
The Framed-IPv6-Prefix attribute's Prefix-Length field allows values from 0 to 128, but prefixes more granular than /64 have unclear semantics at the NAS. A /64 or larger prefix is intended for the NAS-to-CPE link (via Router Advertisement); a delegated prefix for CPE internal use should use the Delegated-IPv6-Prefix attribute (RFC 4818).
A NAS SHOULD NOT use a link-scope (IPv6 link-local or IPv4 link-local) address in a NAS-IPv6-Address or NAS-IP-Address attribute because link-local addresses are not unique beyond the local link. A RADIUS server receiving such an attribute SHOULD NOT count it toward satisfying the NAS identification requirements of RFC 3162 Section 2.1.
A RADIUS server MUST NOT respond to an authorization check with confidential information (such as Tunnel-Password) about any user unless the Access-Request contains a State attribute tying it to an earlier authentication. The server MUST NOT respond with confidential information about any other user.
Access-Request packets containing Service-Type = Authorize Only (17) MUST contain a State attribute. Any other Access-Request that performs authorization checks MUST also contain a State attribute. For an authorization-check Access-Request that does not contain a State attribute, the server MUST respond with an Access-Reject.
Each duplicate-detection cache entry SHOULD be purged after no less than 5 seconds and no more than 30 seconds. Cache entries MUST also be purged when a valid Access-Request arrives matching source address, source port, Identifier, and socket but with a different Request Authenticator.
For Accounting-Request packets, the default values for MRC, MRD, and MRT SHOULD be zero, allowing the client to continue sending until acknowledged. If any of these are non-zero, accounting information could be silently discarded without being recorded.
In non-network-access contexts (VoIP, HTTP, FTP, OS login), an Access-Reject sent to a RADIUS client MUST be interpreted as a rejection of the request for service, and the RADIUS client MUST NOT offer that service to the user. Where a NAS offers independent services, RADIUS sessions for those services MUST be treated as independent.
New RADIUS specifications and implementations MUST NOT use Access-Reject where the semantics of Access-Challenge are intended. Access-Reject MUST mean denial of access to the requested service. In response to an Access-Reject, the NAS MUST NOT send any additional Access-Request packets for that user session.
On receiving an Access-Accept that includes an attribute of known Type for an unimplemented service, a RADIUS client MUST treat it as an Access-Reject. On receiving an Access-Accept with an unknown-Type attribute, a RADIUS client SHOULD assume it is a potential service definition and treat the packet as an Access-Reject. Unknown VSAs SHOULD be ignored.
RADIUS clients MUST NOT reuse Identifiers for a given source IP address and source UDP port until a valid response has been received or the request has timed out. Clients SHOULD allocate Identifiers via a least-recently-used (LRU) method. Client implementations SHOULD include a Message-Authenticator attribute in every Access-Request.
RADIUS clients SHOULD incorporate jitter (uniform random factor between -0.1 and +0.1) and congestive backoff into their retransmission algorithm. The recommended defaults are IRT=2s, MRC=5, MRT=16s, MRD=30s. MRD MUST be set and SHOULD be between 5 and 30 seconds.
RADIUS servers MUST implement duplicate detection for Access-Request packets as described in RFC 2865 Section 3. Servers MUST cache responses sent to Access-Requests and, upon receiving a valid duplicate, MUST resend the cached response without reprocessing. Servers MUST silently discard duplicates for which no response has yet been sent.
The contents of Access-Request packets SHOULD NOT be changed during retransmissions. If attributes must change (e.g., due to Event-Timestamp), responses to earlier transmissions MUST be silently discarded, and any response to the current transmission MUST be treated as definitive.
The Request Authenticator field in an Accounting-Request MUST contain the correct MD5 hash value. Invalid packets MUST be silently discarded by new RADIUS server implementations. New RADIUS client implementations MUST use the proper algorithm to calculate the Request Authenticator; the legacy practice of setting it to all zeros is prohibited.
The State attribute MUST be sent unmodified from the client to the server in any new Access-Request reply to an Access-Challenge. An Access-Request sent as a result of a new or restarted authentication run MUST NOT include the State attribute, even if a State attribute was previously received for the same user and port.
When a NAS has more than one global address and cannot determine which is used for identification in a particular request, it is RECOMMENDED that the NAS include the NAS-Identifier attribute in Access-Requests. A RADIUS server MUST use the source IP address of the RADIUS UDP packet to select the shared secret, so a separate shared secret must be configured for each source address used.
When a NAS receives an EAP-Response/Identity with a zero-length Type-Data field, it is RECOMMENDED to either omit the User-Name attribute in the Access-Request or include Calling-Station-Id in User-Name along with a Calling-Station-Id attribute. A zero-length EAP identity MUST NOT be construed as a request for privacy or anonymous NAI.
Where an EAP-Message attribute is included in an Access-Challenge or Access-Accept, RADIUS servers SHOULD also include a State attribute. Access-Requests that are part of an ongoing Access-Request/Access-Challenge authentication process SHOULD contain a State attribute.
The duplicate-detection cache described in Section 2.2.2 is vulnerable to cache-poisoning attacks when Access-Request packets lack a Message-Authenticator attribute, since such packets can be trivially forged to forcibly expire cache entries. Mitigation requires following RFC 3579 Section 4 guidance or requiring Message-Authenticator in all Access-Request packets.
The State attribute content is visible to RADIUS clients and network observers. Server implementations must ensure the State attribute does not disclose sensitive information to unauthorized parties.
Using the same value for User-Name and User-Password (e.g., a MAC address) in a Call Check request is NOT RECOMMENDED because it gives an attacker both the cleartext and ciphertext of the User-Password field, enabling offline dictionary attacks and potentially compromising the shared secret and the entire RADIUS protocol.