Carrying Location Objects in RADIUS and Diameter
updated by
- rfc-8559 — Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol
Extracted elements (26)
Location-specific attribute content is intentionally treated as opaque data by the RADIUS server itself; a separate location-server component is responsible for receiving, processing, and distributing location information with proper access control. This separation avoids requiring RADIUS servers to implement GEOPRIV logic.
The Extended-Location-Policy-Rules Attribute carries only a URI reference to the extended ruleset rather than embedding the full XML policy (as RFC 4119 does). This deviation is explicitly motivated by RADIUS message size limitations, which make carrying attached XML rulesets impractical.
In Diameter, RADIUS Access-Request maps to AA-Request or Diameter-EAP-Request; Access-Challenge maps to AA-Answer/Diameter-EAP-Answer with Result-Code DIAMETER_MULTI_ROUND_AUTH; Access-Accept maps to successful AA-Answer; CoA-Request maps to Re-Auth-Request; Accounting-Request maps to Diameter Accounting-Request.
When used in Diameter, all attributes defined in this specification are used as AVPs from the RADIUS compatibility code space (1–255) with no additional Diameter code values allocated. Attributes are copied as-is across RADIUS/Diameter gateways, except for header, alignment, and padding adjustments.
A RADIUS server MUST NOT challenge for location information unless the RADIUS client has previously sent a Location-Capable Attribute in an Access-Request message.
A RADIUS server supporting location attributes MUST calculate the correct value of the Message-Authenticator (80) and MUST silently discard any Access-Request packet containing location attributes if the Message-Authenticator does not match. Access-Request packets with location attributes but without a Message-Authenticator SHOULD be silently discarded.
Confidentiality protection MUST be used (e.g., via RADIUS over IPsec) to prevent eavesdroppers from accessing location information. Mutual authentication MUST be provided between neighboring RADIUS entities to prevent man-in-the-middle attacks.
If the RADIUS server sends no Requested-Location-Info Attribute, the RADIUS client MUST NOT attach location information to messages toward the RADIUS server. User authorization policies MUST be consulted before requesting location delivery.
NAS implementations supporting this specification MUST echo Basic-Location-Policy-Rules and Extended-Location-Policy-Rules Attributes unmodified in subsequent Access-Request packets. An Access-Request with Service-Type 'Authorize Only' MUST include these policy attributes if the FUTURE_REQUESTS flag was set.
The Method field in the Location-Information Attribute MUST contain the value of exactly one IANA-registered 'method' token as defined in RFC 4119.
The RADIUS server MUST attach available policy rules to the Access-Accept, Access-Reject, or Access-Challenge message when the RADIUS client is supposed to provide location information. When location information is made available to other entities, the RADIUS server MUST attach the privacy rules to the location information.
To enable mid-session on-demand location delivery, the RADIUS server MUST return a Requested-Location-Info Attribute with the FUTURE_REQUESTS flag set and instances of Basic-Location-Policy-Rules and Extended-Location-Policy-Rules in the Access-Accept. Upon receiving a CoA-Request with Service-Type 'Authorize Only', the NAS MUST include location information and echo the previously received policy rule attributes.
Whenever a Location Object leaves the RADIUS ecosystem (e.g., transferred to a SIP/PIDF-LO environment), the URI in the Note Well field MUST be expanded to human-readable text.
Location information can be correlated with user identity through MAC addresses, fixed IP addresses, EAP identity exchanges, RADIUS Class Attributes, mobility protocols, and application-layer identifiers. Preventing identity/location correlation requires suppressing identity leakage from all sources simultaneously.
Network-level location (e.g., NAS identifier or access network) already reveals approximate user location; this document describes mechanisms to convey more precise location. The RADIUS client MUST NOT disclose location information absent an out-of-band agreement or an explicit server request.
The Civic Location Profile (Code=0 in Location-Information) uses the encoding from RFC 4776 Section 3.1, omitting the first 3 octets (DHCP option code, length, and 'what' element). The Geospatial Location Profile (Code=1) uses the LCI format from RFC 3825 Section 2, starting at the third octet.
The Operator-Name Attribute (Type 126) carries an operator namespace identifier (1 octet, ASCII-encoded) followed by a variable-length operator name text field. The combined value MUST NOT exceed 253 bytes and uniquely identifies the owner of an access network.
IANA assigned Error-Cause Attribute value 509 with semantics 'Location-Info-Required' (defined in RFC 5176). This value is returned in an Access-Reject when the RADIUS server requires location information that the client did not provide.
Six new IANA registries are created: Operator Namespace Identifier (initial values TADIG=0x30, REALM=0x31, E212=0x32, ICC=0x33; Expert Review for additions), Location Profiles (civic=0, geospatial=1), Location-Capable Attribute bitmap, Entity Types (user device=0, RADIUS client=1), Privacy Flags (retransmission-allowed=bit 0), and Requested-Location-Info Attribute bitmap.
Without authentication, integrity, and replay protection between RADIUS entities, adversaries can spoof and modify transmitted location attributes. The Message-Authenticator (80) attribute can integrity-protect the entire Access-Request packet when IPsec is unavailable; RADIUS over IPsec (RFC 3579) is the preferred mechanism.
The Basic-Location-Policy-Rules Attribute (Type 129, length >= 12) encodes a 16-bit Flags field (bit 0 = Retransmission Allowed, bits 1-15 reserved and MUST be zero), a 64-bit Retention Expires NTP timestamp, and a variable-length Note Well URI field.
The Extended-Location-Policy-Rules Attribute (Type 130, length >= 3) carries a variable-length Ruleset Reference URI that SHOULD use the HTTPS URI scheme. Unlike RFC 4119, it contains only a reference to the ruleset, not an embedded XML policy, due to RADIUS size constraints.
The Location-Capable Attribute (Type 131, length 6) carries a 32-bit integer bitmap indicating NAS capabilities: bit 0 (value 1) = CIVIC_LOCATION, bit 1 (value 2) = GEO_LOCATION, bit 2 (value 4) = USERS_LOCATION, bit 3 (value 8) = NAS_LOCATION.
The Location-Data Attribute (Type 128, length >= 5) encodes a 16-bit Index linking it to a corresponding Location-Information Attribute, followed by variable-length Location data whose format depends on the location profile (civic or geospatial).
The Location-Information Attribute (Type 127, length >= 23) encodes a 16-bit Index, 8-bit Code (location profile), 8-bit Entity, 64-bit Sighting Time (NTP format), 64-bit Time-to-Live (NTP format), and a variable-length Method field that MUST contain exactly one IANA-registered 'method' token. Total length MUST NOT exceed 253 octets.
The Requested-Location-Info Attribute (Type 132, length 6) carries a 32-bit integer bitmap: CIVIC_LOCATION=1, GEO_LOCATION=2, USERS_LOCATION=4, NAS_LOCATION=8, FUTURE_REQUESTS=16, NONE=32. It is sent by the RADIUS server to specify which location information it requires.