Sending periodic keep-alive test requests to check server liveness is strongly discouraged. Since a RADIUS request fits in one datagram, any real request simultaneously tests reachability; polling without a real request adds load without benefit. SNMP is recommended for server monitoring.

radius

UDP was chosen over TCP for RADIUS because: (1) the NAS must keep requests above the transport layer for failover to alternate servers anyway, making TCP retransmission redundant; (2) TCP's aggressive retransmission timing is neither needed nor appropriate—users tolerate several seconds but not minutes; (3) the stateless nature of RADIUS eliminates connection management complexity; (4) UDP simplifies multi-threaded server implementation by allowing separate processes to respond directly via simple datagrams.

radius, udp

For CHAP authentication in proxy scenarios, if no CHAP-Challenge attribute is present in the forwarded packet, the forwarding server MUST leave the Request Authenticator untouched or copy it to a CHAP-Challenge attribute, because the CHAP challenge verification depends on it.

radius, security

The officially assigned UDP port for RADIUS is 1812, but early deployments used port 1645, which conflicts with the 'datametrics' service. Implementations may need to support both ports for backward compatibility.

radius

A forwarding proxy MAY add at most one Proxy-State attribute per request (MUST NOT add more than one), and the added Proxy-State MUST appear after any other Proxy-States. When forwarding the response, it MUST remove its own Proxy-State and re-sign the Response Authenticator.

radius, security

A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service, and MUST treat a RADIUS Access-Accept authorizing an unavailable service as an Access-Reject instead.

radius

A RADIUS server MUST use the source IP address of the UDP packet to select the shared secret, not the NAS-IP-Address attribute, so that proxied RADIUS requests are handled correctly.

radius, security

A request from a client for which the RADIUS server does not have a shared secret MUST be silently discarded.

radius, security

An Access-Request MUST contain either a User-Password or a CHAP-Password or a State attribute. It MUST NOT contain both a User-Password and a CHAP-Password. It MUST also contain either a NAS-IP-Address or a NAS-Identifier (or both).

radius, security

If a NAS does not support challenge/response, it MUST treat an Access-Challenge as though it had received an Access-Reject. Similarly, if a NAS cannot forward a Reply-Message to the PAP dialing client, it MUST treat the Access-Challenge as an Access-Reject.

radius

If a RADIUS packet is shorter than its Length field indicates, it MUST be silently discarded. Octets outside the range of the Length field MUST be treated as padding and ignored.

radius, security

If a RADIUS server is unable to perform the requested authentication (e.g., CHAP requires cleartext password that is unavailable), it MUST return an Access-Reject.

radius, security

If any Proxy-State attributes are present in an Access-Request, they MUST be copied unmodified and in order into the response packet. A forwarding server MUST treat Proxy-State attributes as opaque data and MUST NOT modify any Proxy-State attributes, nor change the order of attributes of the same type.

radius, security

Text and string attribute values of length zero MUST NOT be sent; the entire attribute MUST be omitted instead. Implementations MUST be able to deal with embedded nulls in attribute values and MUST NOT use strcpy() when handling strings.

radius

The Identifier 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 to the same server with unchanged attributes, the Identifier MUST remain unchanged and the same Request Authenticator and source port MUST be used.

radius

The order of Attributes with the same Type MUST be preserved by proxies. A RADIUS server or client MUST NOT have dependencies on the ordering of attributes of different types, and MUST NOT require attributes of the same type to be contiguous.

radius

The Request Authenticator value SHOULD be unpredictable and unique over the lifetime of a secret, exhibiting global and temporal uniqueness, to prevent replay attacks and prevent an attacker from tricking the server into responding to a predicted future request.

radius, security, crypto

The shared secret MUST NOT be empty (length 0), as this would allow trivial packet forgery. The secret SHOULD be at least 16 octets and as unguessable as a well-chosen password to resist exhaustive search attacks.

radius, security, crypto

RADIUS defines four authentication packet types: Access-Request (Code=1), Access-Accept (Code=2), Access-Reject (Code=3), and Access-Challenge (Code=11). Codes 4 and 5 (Accounting) are defined elsewhere. Packets with invalid Code fields are silently discarded.

radius, security

The challenge/response flow: the server returns an Access-Challenge with a Reply-Message and optional State attribute. The NAS prompts the user, then sends a new Access-Request with a new ID, the user's encrypted response in User-Password, and the State attribute from the challenge. The server replies with Access-Accept, Access-Reject, or another Access-Challenge.

radius, security

The State attribute (Type=24) is used in challenge/response authentication to correlate an Access-Challenge with the subsequent Access-Request. Only 0 or 1 instances of State SHOULD be present in a request; it is passed opaquely and MUST NOT be modified by forwarding servers.

radius, security

The Vendor-Specific attribute (Type=26) provides a mechanism for vendors to extend RADIUS by encapsulating vendor-defined attributes. This allows proprietary extensions without requiring IANA allocation of new standard attribute types.

radius

This document defines RADIUS Attribute Type values 1-63 and establishes their assignment policy. Values 192-223 are reserved for experimental use, 224-240 for implementation-specific use, and 241-255 are reserved and should not be used. Values 40-59 are reserved for accounting attributes.

radius, registry

Forwarding servers should carefully consider which Service-Type values they are willing to pass in a proxied Access-Accept. Passing Service-Types of NAS-Prompt or Administrative in a proxied accept could grant elevated privileges unintentionally; implementers should consider blocking those service types at proxy boundaries.

radius, security

RADIUS transactions between client and server are authenticated using a shared secret never sent over the network, and user passwords are encrypted using MD5-based hiding. However, the protocol cannot protect against theft of authenticated sessions via real-time active wiretapping; generation of unique unpredictable Request Authenticators protects against a wide range of active attacks.

radius, security, crypto

The CHAP-Password attribute (Type=3, Length=19) contains a 1-octet CHAP Identifier followed by a 16-octet String holding the CHAP Response. The CHAP challenge is taken from the CHAP-Challenge attribute (Type=60) if present, otherwise from the Request Authenticator field.

radius, security

The RADIUS attribute format is Type (1 octet), Length (1 octet, inclusive of Type and Length), and Value (0 or more octets). Value data types are: text (UTF-8, 1-253 octets), string (binary, 1-253 octets), address (32-bit), integer (32-bit unsigned), and time (32-bit unsigned seconds since epoch).

radius, security

The RADIUS packet format consists of a 1-octet Code, 1-octet Identifier, 2-octet Length, 16-octet Authenticator, and variable-length Attributes field. The minimum packet length is 20 and maximum is 4096 octets. One RADIUS packet is encapsulated per UDP datagram on destination port 1812.

radius, security

The Response Authenticator in Access-Accept, Access-Reject, and Access-Challenge packets is an MD5 hash computed as MD5(Code+ID+Length+RequestAuth+Attributes+Secret), binding the reply to the original request and the shared secret.

radius, crypto, security

The User-Password attribute (Type=2, Length 18-130) encodes the password using iterated MD5: b1=MD5(S+RA), c(1)=p1 XOR b1; bi=MD5(S+c(i-1)), c(i)=pi XOR bi, chaining through up to 128-character password in 16-octet blocks. The shared secret and Request Authenticator seed the first hash.

radius, crypto, security