Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol
updates
Extracted elements (25)
CoA proxying as described in RFC 5176 is impossible in practice because proxies are stateless with respect to user sessions, RFC 5176 is silent on which attributes constitute session identification, and requiring session tracking would not scale for roaming consortia handling tens of millions of users. The solution is realm-based proxying on the reverse path using Operator-Name instead of User-Name.
The Operator-NAS-Identifier attribute is defined as an opaque token rather than exposing the NAS IP address directly. The rationale is that there is no compelling reason to make NAS topology information public to upstream proxies and home servers; however, the security of the attribute is not load-bearing since modification can only result in the erroneous transaction being rejected.
Some NAS implementations currently NAK any CoA packet containing a Proxy-State attribute, based on a literal reading of RFC 5176 Section 2.3. This document corrects that behavior by specifying that NASes MUST NOT treat proxy-signaling attributes as mandatory.
This document updates RFC 5580 Section 5 to permit CoA-Request and Disconnect-Request packets to contain zero or one instance of the Operator-Name attribute. Previously RFC 5580 did not allow Operator-Name in these packet types.
A home server MUST store Operator-NAS-Identifier along with user session identification attributes and MUST include verbatim any recorded Operator-NAS-Identifier when sending a CoA packet for that session. A home server MUST NOT send CoA packets for users of other networks.
Home networks that expect to send CoA packets to visited networks MUST record the Operator-Name attribute for each user session originating from a visited network. Without this record, the home network cannot determine where to route CoA packets.
If the Operator-NAS-Identifier attribute does not match a known NAS, the CoA server MUST return a NAK packet containing an Error-Cause Attribute with value 403 ('NAS Identification Mismatch').
Proxies MUST pass Operator-Name and Operator-NAS-Identifier attributes through unchanged. All attributes added by a RADIUS proxy on the forward path MUST be removed by the corresponding CoA proxy on the reverse path, preserving symmetry of attribute editing.
Proxies MUST perform a reverse path forwarding (RPF) check to verify that a CoA packet originates from an authorized Dynamic Authorization Client, strengthening the MAY in RFC 5176 Section 6.1. Where the check fails, the proxy MUST return a NAK with Error-Cause 502.
The CoA server at the visited network MUST validate the NAI in Operator-Name against the list of realms it hosts. If not found, it MUST return a NAK with Error-Cause 502. It SHOULD also validate the User-Name NAI, and if the home network lacks permission, MUST return a NAK with Error-Cause 502.
The Operator-Name attribute MUST NOT occur more than once in a CoA or Disconnect packet. If a packet contains more than one Operator-Name, implementations MUST treat the second and subsequent attributes as 'invalid attributes' per RFC 6929 Section 2.8.
The Operator-NAS-Identifier attribute MUST NOT appear in a packet that does not also contain an Operator-Name attribute, and MUST NOT occur more than once per packet. Only the visited network may add Operator-NAS-Identifier; no other proxy or server in the network may add it.
The visited network MUST remove Operator-Name and Operator-NAS-Identifier from a CoA packet prior to sending it to the final CoA server (NAS), and MUST ensure the packet contains one of NAS-IP-Address, NAS-IPv6-Address, or NAS-Identifier before delivery to the NAS.
This document updates RFC 5176 Section 2.3: a NAS MUST NOT treat as mandatory any attribute known to not affect the user's session (e.g., Proxy-State). Proxy-State and similar proxy-signaling attributes MUST be ignored by the NAS.
Visited networks MUST use a consistent value for Operator-Name throughout a single user session. Sending different realm names (e.g., '1example.com' in Access-Request but '1example.org' in Accounting-Request for the same session) is forbidden.
When a home network sends a CoA-Request or Disconnect-Request to a visited network, it MUST include an Operator-Name attribute whose value MUST be exactly the value recorded earlier for that user session. The home network MUST look up the realm in a logical AAA routing table to find the next-hop CoA server.
Where a proxy cannot find a destination realm from Operator-Name, the proxy MUST return a NAK packet containing an Error-Cause Attribute with value 502 ('Request Not Routable'). Proxies MUST NOT use the NAI from User-Name to make CoA proxying decisions.
The Operator-Name attribute (defined in RFC 5580 Section 4.1) is reused to enable CoA proxying. It carries an ASCII '1' followed by the realm name of the visited network (e.g., '1example.com'), providing the reverse-path routing key for CoA packets analogous to User-Name on the forward path.
The Operator-NAS-Identifier attribute (Type 241.8) is a new opaque token that identifies an individual NAS within a visited network. It MAY appear in Access-Request, Accounting-Request, CoA-Request, or Disconnect-Request packets, and MUST NOT appear in any other packet types. Only the visited network (operator) may create this attribute.
IANA allocated one new RADIUS attribute from the 'short extended space' of the 'RADIUS Attribute Types' registry: Value 241.8, Description 'Operator-NAS-Identifier', Data Type 'string', Reference RFC 8559.
RADIUS uses hop-by-hop shared-secret signing, so any intermediate proxy can forge, replay, or modify packet contents. Systems receiving correctly signed packets cannot detect forgery. The security of CoA proxying therefore depends on trust relationships rather than technical enforcement, mirroring the same limitation on Access-Request and Accounting-Request proxying.
The Operator-NAS-Identifier attribute requires no integrity protection or replay detection. Modification or replay of this attribute will either have no effect or cause the erroneous transaction to be rejected. Security of the overall system is bounded by the underlying RADIUS protocol's security properties.
There are no provisions in RADIUS for end-to-end security; visited and home networks cannot communicate privately in the presence of proxies. RADIUS proxies that see Access-Request and Accounting-Request packets gain sufficient information to forge CoA packets, but this capability is equivalent to their existing ability to return Access-Accept or modify authorization attributes.
CoA proxying flow: (1) Home server looks up Operator-Name realm in AAA routing table, sends CoA-Request to next-hop CoA server. (2) Intermediate proxies perform RPF check, look up realm from Operator-Name, forward or return NAK 502. (3) Visited network receives packet, validates Operator-Name realm and Operator-NAS-Identifier, strips proxy attributes, restores NAS identity attributes, forwards to NAS. (4) NAS response propagates back up the proxy chain.
Operator-NAS-Identifier uses Type 241.8 (short extended space), Length 4–35 octets, data type 'string' as defined in RFC 8044 Section 3.5. Implementations MUST handle 1–32 octets of data; creators MUST NOT produce more than 64 octets. The value is an opaque token interpretable only by the visited network.