Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
updated by
- rfc-6915 — Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)
Extracted elements (25)
HELD with identity extensions is explicitly not a Location Configuration Protocol (LCP). In an LCP, the source IP address provides implicit return-routability-based identity; by allowing the requestor to supply identity in the request body, that implicit guarantee is lost and explicit authorization checks become mandatory.
Subjective network views arise because NAT and private address spaces mean the same IP address string can refer to different physical devices depending on the network context of the requestor versus the LIS. A LIS must either reconcile these views or reject requests it cannot correctly interpret.
WiMAX requires an NAI for location requests because an IP address alone is insufficient for the LIS to locate a Device on that network. The WiMAX procedure verifies that the NAI belongs to the requestor by consulting the AAA server and checking that the returned IP address matches the HELD request source address, enabling LCP-style authorization for self-location.
A LIS that supports the identity extension echoes the 'device' element back in a successful location response, listing identifiers that were actually used for location determination. If the 'device' element is absent from the response, the LIS used the source IP address rather than any provided identifier.
A LIS SHOULD NOT send an HTTP 401 (Unauthorized) challenge if the Device does not include Device identity in the request, preserving compatibility with base HELD behavior where authentication is not mandated.
All HELD requests that contain Device identity MUST be authenticated by the LIS. For such requests, the requestor MUST support HTTP Digest Authentication (RFC 2617). Unauthenticated requests may be challenged with HTTP 401 or rejected with HTTP 403.
Any identifier used in a HELD location request MUST only be used when it uniquely identifies a single Device at the time location is determined. The LIS is responsible for ensuring that identifiers are not transient or ambiguous.
For third-party requests, the requestor MUST be authenticated by the LIS and the request MUST be explicitly authorized by a policy established by a Rule Maker. There is no implicit authorization for third parties; the default policy is deny-all until an explicit authorization is in place.
In the WiMAX NAI verification procedure, the AAA server MUST be authenticated as a trusted entity for linking NAI to IP address, and the AAA protocol (Diameter or RADIUS) MUST provide protection against modification and replay attacks so that attacker-altered responses cannot authorize a request.
Requests containing Device identity MUST NOT be authorized under the LCP policy (i.e., policy that permits Devices to acquire their own location) unless specific measures are taken to prevent spoofing of the provided Device identity. The LIS MUST treat requests containing identifiers other than a verified NAI as third-party requests.
The identifiers defined in this document MUST only be used where that identifier is the basis for location determination; a LIS MUST NOT allow alternative identifiers merely for convenience if doing so could cause the identifier to refer to a different Device.
The LIS MUST NOT use Device identity information provided in a request for any purpose other than serving that specific request; the Device provides this data solely in expectation of receiving its own location.
When a LIS permits third-party requests, it becomes a Location Server and MUST explicitly authorize each request per policies provided by Rule Makers. The default authorization policy MUST be 'deny all'; no third-party request may be served until an explicit authorization policy has been established by the relevant Rule Maker.
When a Target uses HELD identity extensions to obtain its own location, HELD can no longer be classified as an LCP and return routability is insufficient as the sole anti-spoofing mechanism. Specific anti-spoofing measures MUST be defined for each alternative identifier; this document defines such a measure only for NAI in WiMAX networks.
Port number elements ('udpport', 'tcpport', 'sctpport', 'dccpport') allow a Device to be identified by a flow when NAT prevents unique identification by IP address alone. A port number must be combined with an IP address and is only useful when the LIS has knowledge of the NAT mappings in use.
The 'badIdentifier' HELD error code is returned when a Device identifier in the request is not supported by the LIS, is badly formatted, or is not one for which the requestor is authorized. An optional 'requiredIdentifiers' child element can list the XML qualified names of identifiers the LIS needs to fulfill the request.
The 'device' XML element (namespace urn:ietf:params:xml:ns:geopriv:held:id) is the container for Device identity information in a HELD locationRequest. A LIS that supports this extension echoes the 'device' element in a successful response to indicate which identifiers were used for location determination; absence of the echo means the source IP address was used.
This document registers the 'badIdentifier' error code in the IANA 'HELD Error Codes' sub-registry of the 'Geopriv HTTP Enabled Location Delivery (HELD) Parameters' registry. The code indicates the identifier was unsupported, badly formatted, or not authorized for use by the requestor.
This document registers the XML namespace 'urn:ietf:params:xml:ns:geopriv:held:id' and the XML schema 'urn:ietf:params:xml:schema:geopriv:held:id' in the IANA XML registry per RFC 3688.
TLS (RFC 5246) MUST be used for all HELD requests, including those using identity extensions, to provide server authentication, confidentiality, and integrity protection. This applies equally to Target self-location requests and third-party requests.
Transient identifiers enable a time-of-check/time-of-use attack: an attacker can force re-allocation of an identifier between when authorization is granted and when location is returned, causing the LIS to provide location for the wrong Device or to be coerced into lying. Ambiguous identifiers compound this by allowing authorized access to one Device to implicitly expose location of others sharing the same identifier.
Cellular telephony identifiers are expressed as decimal digit strings: 'msisdn' and 'imsi' and 'mdn' use the E.164 type (6–15 digits); 'imei' allows up to 15 digits; 'min' is exactly 10 digits. The 'duid' element encodes a DHCP Unique Identifier as an xs:hexBinary value per RFC 3315 Section 9.
The 'ip' element encodes an IP address identifier: a required 'v' attribute carries a single hexadecimal digit indicating IP version (4 or 6), and the text content uses the textual format from RFC 3986 (IPv4address or IPv6address). IPv6 addresses SHOULD follow RFC 5952 formatting conventions.
The 'mac' element encodes a MAC address (MAC-48, EUI-48, or EUI-64) in the IEEE 802 hyphen-separated hexadecimal representation (e.g., 'A0-12-34-56-78-90'). Locally assigned MAC addresses are valid only within the administrative domain where they are assigned.
The 'nai' element carries a Network Access Identifier per RFC 4282. Because NAI grammar permits non-UTF-8 octet sequences that are not valid in XML, non-UTF-8 octets MUST be escaped as a backslash ('\') followed by two case-insensitive hexadecimal digits; the resulting canonical octet sequence must still conform to RFC 4282 constraints.