RFC 6155
Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
RFC 6155: Use of Device Identity in HTTP-Enabled Location Delivery (HELD) 💖
okay bestie, here's the title block tea ☕ This is an IETF document, and it's RFC 6155 🎀
- Series: Internet Engineering Task Force (IETF) 🌸
- Authors: J. Winterbottom and M. Thomson (both from Andrew Corporation), H. Tschofenig (from Nokia Siemens Networks), and R. Barnes (from BBN Technologies) ✨
- Category: Standards Track 🦋
- ISSN: 2070-1721
- Date: March 2011 📅
- Obsoletes and updates: the title block doesn't say it obsoletes or updates anything 🙈
Abstract
So when a Location Information Server gets a request for location info (the locationRequest message from the base HTTP-Enabled Location Delivery (HELD) spec 📬), it uses the source IP address of the incoming message as a pointer to the location determination process. That totally works in environments where a Device's location can be figured out from its IP address 💅
But there are two extra use cases this doc covers 👀 In the first, location configuration needs extra or different identifiers besides the source IP address in the request. In the second, someone who isn't the Device asks for the Device's location 🫶
This document extends HELD so the location request message can carry Device identifiers ✨ The privacy and security considerations spell out when requests containing identifiers are allowed 🔐
Status of This Memo
This is an Internet Standards Track document 🌈
It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community 💜 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, see Section 2 of RFC 5741 📚
Want the current status, any errata, or a way to send feedback? Check http://www.rfc-editor.org/info/rfc6155 🧚
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, ngl, because they explain your rights and restrictions for this document 🙈 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 💖
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7
2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 7
2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9
2.1.3. Network Interfaces and Devices . . . . . . . . . . . . 9
2.2. Identifier Format and Protocol Details . . . . . . . . . . 9
3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Network Access Identifier . . . . . . . . . . . . . . . . 12
3.4.1. Using NAI for Location Configuration . . . . . . . . . 13
3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6. Fully Qualified Domain Name . . . . . . . . . . . . . . . 14
3.7. Cellular Telephony Identifiers . . . . . . . . . . . . . . 14
3.8. DHCP Unique Identifier . . . . . . . . . . . . . . . . . . 15
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15
4.1. Targets Requesting Their Own Location . . . . . . . . . . 16
4.2. Third-Party Requests . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 18
5.2. Targets Requesting Their Own Location . . . . . . . . . . 18
5.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 19
6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 21
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 22
7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 251. Introduction ✨
Okay so protocols that ask for or deliver location info need a way for the requestor to say which location they want back 🗺️ In a Location Configuration Protocol (LCP), the location being asked for is the requestor's own location, which honestly makes identifying the Device feel easy 😌 The IP datagrams carrying the request already include an identifier for the Device, namely the source IP address of the incoming request 💅 Existing LCPs like HTTP-Enabled Location Delivery (HELD) [RFC5985] and DHCP ([RFC3825], [RFC4776]) rely on the source IP address or other info in the protocol datagrams to figure out which Device is asking 🦋
Here's the catch 🙈 Apart from the datagrams that make up a request, a Location Information Server (LIS) doesn't necessarily have access to anything else that could further identify the Device. In some situations, [RFC5687] shows that extra identification info can be included in a request to identify a Device 🔍
This document extends HELD to support adding extra identifiers for the Device in HELD location requests 💖 It defines an XML schema that gives those identifiers a structure inside HELD requests 🧩
Here's the big thing about this addition 🔥 A HELD protocol with identity extensions implemented is not considered an LCP 😤 The scope of an LCP is limited to the interaction between a Device and a LIS, and LCPs can guarantee Device identity without any extra authorization checks. A LIS identifies the Device making the LCP request using the source addressing on the request packets, and it uses return routability to make sure those identifiers aren't spoofed 🛡️
With HELD identity extensions, a requestor can explicitly provide identification details in the body of a location request ✨ So location requests can happen in cases where extra Device identity checks are needed, and in cases where the requestor isn't the Device itself 👑 Third-party Location Recipients (LRs) can make requests that include identifiers to get location info about a particular Device 🧚
Adding identifiers to HELD brings a whole new set of privacy concerns 😭 In an LCP, the requestor can be implicitly authorized to access the requested location info, because it's their own location 💜 A third-party LR, on the other hand, must be explicitly authorized before requesting a Device's location. Setting up appropriate authorization and dealing with the other related privacy concerns is covered in Section 4 🎀
1.1. Applications
This document defines a way to explicitly include Device identity info in the body of a HELD location request 📦 That identity info is used to identify the Device that's the subject (or Target) of the location request. If Device identity is present, the requestor's identity (in the form of the source IP address) is not used to identify the subject of the request 🙅♀️
Device identifiers in HELD can be used for two purposes:
Location configuration: A Device can use these parameters to identify itself to a LIS. Identification info other than an IP address might be needed to figure out where a Device is 🗺️
A LIS can authorize location configuration requests using a policy that lets Devices acquire their own location (see Section 4.1). But here's the risk 😬 If an unauthorized third party fakes the addressing on request packets to match the provided Device identity, the request might get wrongly authorized under this policy. Requests containing Device identity MUST NOT be authorized using this policy unless specific measures are taken to prevent this type of attack 🚫
This document describes a mechanism that gives assurance that the requestor and the included Device identity are the same, for the Network Access Identifier (NAI) in a WiMAX network 🦋 The LIS MUST treat requests containing other identifiers as third-party requests, unless it can make sure the provided Device identity is uniquely attributable to the requestor 🔐
Third-party requests: A third-party Location Recipient can be granted authorization to make requests for a given Device 🧚 In particular, network services can be permitted to retrieve location for a Device that can't acquire location info for itself (see Section 6.3 of [EMERGENCY-CALLING]). This allows location-dependent applications to work, especially essential services like emergency calling, where Devices don't support a location configuration protocol or can't successfully retrieve location info 🚨
This document does not describe how a third party acquires an identifier for a Device, nor how that third party is authorized by a LIS. It is critical that these issues are resolved before permitting a third-party request 💀 A pre-arranged contract between the third party, a Rule Maker, and the LIS operator is necessary to use Device identifiers in this fashion. The contract must include how the request is authenticated and the set of identifiers (and types of identifiers) that the third party is authorized to use in requests 📝
Automated mechanisms to make sure privacy constraints are respected are possible 🤖 For instance, a policy rules document could be used to express the agreed policy. Formal policy documents, such as the common policy [RFC4745], can be applied in an automated fashion by a LIS 🌸
1.2. Terminology 💅
okay so this doc leans on two big terms, Location Information Server (LIS) and Location Configuration Protocol (LCP), which are described in [RFC5687] and [GEOPRIV-ARCH] 🧚
The Device is the word used specifically for the subject of an LCP, which matches [RFC5985] 🎀. This doc also uses Target for any entity that might be the subject of the same location info. Target is the more general one! It includes the Device, but it also covers nearby stuff like the user of a Device 🦋
A Target has a stake in setting authorization policy on how location info gets used 💜. The Rule Maker is the role that makes those policy calls: it decides who's allowed to receive location and how that info gets provided 👑
Device, Target, and Rule Maker are all defined in [GEOPRIV-ARCH] ✨
The term "requestor" is used in this doc to mean the entity making a HELD request 🫶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🌸
2. Device Identity 🎀
Identifiers are the starting point for location determination 🔥 They might end up linked to a different Device over time, but their whole purpose is to identify the Device. They are not there to describe its environment or its network attachment 💖
2.1. Identifier Suitability 💅
Use of any identifier MUST only be allowed if it identifies a single Device at the time that location is determined. The LIS is responsible for making sure location info is correct for the Device, and that includes making sure the identifier is uniquely attributable to the Device 😭
Some identifiers are either temporary or could potentially identify multiple Devices 💀 Identifiers that are transient or ambiguous could be exploited by an attacker to either snoop on info about another Device or to coerce the LIS into producing misleading info. Not cute, so be careful!! 🙈
The identifiers described in this document MUST only be used where that identifier is used as the basis for location determination. Considerations for a Device requesting its own location are discussed in Section 5 of [RFC5687]. This section is about identifiers for authorized third-party requests 🦋
It is tempting for a LIS implementation to allow alternative identifiers for convenience or some other perceived benefit. The LIS is responsible for ensuring that the identifier used in the request does not refer to a Device other than the one for which it determines location. 🚫
Some identifiers are always uniquely attributable to a single Device. Other identifiers, though, can mean different things to different entities on a network. This is especially true for IP addresses [RFC2101], but it can be true for other identifiers too, just to different degrees 🌈 Non-uniqueness comes from both topology (every network entity has a subjective view of the network) and time (the network changes over time) ⏳
2.1.1. Subjective Network Views 🌸
Subjective views of the network mean the identifier a requestor uses for one physical entity could actually point at a different physical entity when it's used in a different network context. Unless an authorized third-party requestor and LIS operate in the same network context, each one could have a different subjective view of what the identifier means 👀
When the subjective views differ, the third party gets info that's only correct within the LIS's network context. The location info from the LIS is probably misleading, because the requestor thinks the info is about a different entity than the one it was generated for 😭
Authorization policy can be affected by a subjective network view if it's applied based on an identifier, or if its application depends on identifiers. The subjective view presented to the LIS and the Rule Maker need to agree so the two entities understand policy on the same terms. For example, the LIS could apply the wrong authorization policy if it picks the policy using a subjective identifier. Or it might use the correct policy but apply it incorrectly if subjective identifiers are used 🫠
In IP networks, network address translation (NAT) and other forms of address modification create network contexts. Entities on either side of the point where modification happens have a different view of the network. Private use addresses [RFC1918] are the most easily recognizable identifiers with limited scope 🧱
A LIS can be configured to recognize situations where the subjective view of a requestor or Rule Maker might not line up with the view of the LIS. The LIS can either provide location info that takes the requestor's view into account, or it can reject the request 💅
For instance, a LIS might operate within a network that uses a private address space, with NAT between that network and other networks. A third-party request that comes from an external network with an IP address from that private address space might not be valid. It could be identifying an entity inside another address space. The LIS can be configured to reject such requests, unless it knows by other means that the request is valid 🙅♀️ In that same example, the requestor might include an address from the external space in an attempt to identify a host within the network. The LIS could use knowledge about how the external address maps to a private address, if that mapping is fixed, to figure out an appropriate response 🧠
The residential gateway scenario in Section 3.1 of [RFC5687] is a particular example of where a subjective view is permitted. The LIS knowingly provides Devices on the remote side of the residential gateway with location info. It gives that info with appropriate uncertainty, since the residential gateway serves a small geographical area 🏡✨
2.1.2. Transient Identifiers 🦋
Some identifiers are temporary, and over time they can be assigned to different physical entities. If an identifier gets reassigned between the moment a requestor formulates a request and the moment the LIS receives it, the LIS ends up locating a different entity than the one the requestor meant 😵 The response from the LIS might be accurate, but the request links that info to the wrong subject 💔
A LIS should be configured with info about any potentially temporary identifiers. It can use that info to spot when changes have happened. A LIS must not provide location information if the identifier it uses might refer to a different Device. If an identifier might have been reassigned recently, or it's likely to get reassigned, it isn't suitable to use as an identifier 🚫
It's possible some uncertainty could stick around where identifiers get reassigned a lot. How much error from transient identifiers gets tolerated is up to local policy 🎀
2.1.3. Network Interfaces and Devices 🔌
Several of the identifiers in this document are used to identify a network interface. A Device can have multiple network interfaces 📱 Uniquely identifying any network interface is assumed to be enough to identify the Device. When a network interface is identified, the goal is to identify the Device that's directly attached to that interface 🎯
Most network interfaces stay physically attached to one particular Device, though a network interface might be physically separable from the Device. So by identifying a network interface, the Device that's meant to be identified could change 🥹
2.2. Identifier Format and Protocol Details 💖
XML elements are used to express the Device identity. The "device" element works as a general container for identity info. This document defines a basic set of identifiers. The example HELD request in Figure 1 includes an IP version 4 address ✨
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8">
<locationType exact="true">geodetic</locationType>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="4">192.0.2.5</ip>
</device>
</locationRequest>Figure 1: HELD Request with Device Identity
A LIS that supports this specification echoes the "device" element in a successful HELD response, including the identifiers that were used as the basis for location determination. If that indication is absent, it means the location info was generated using the source IP address in the request 📍
A "badIdentifier" HELD error code means one of two things: the requestor isn't authorized to use that identifier, or the request has an identifier that's badly formatted or not supported by the LIS. This code is registered in Section 7.3 🙃
If the LIS needs an identifier that the request didn't include, the desired identifiers MAY be listed in the HELD error response, using the "requiredIdentifiers" element. That element holds a list of XML qualified names [W3C.REC-xml-names11-20060816] that name the identifier elements the LIS needs. Namespace prefix bindings for those qualified names come from document context. Figure 2 shows an error saying the requestor has to include a media access control (MAC) address (Section 3.2) and an IP address (Section 3.1) for the request to succeed 🛠️
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="badIdentifier">
<message xml:lang="en">MAC address required</message>
<requiredIdentifiers
xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
mac ip
</requiredIdentifiers>
</error>Figure 2: HELD Error Requesting Device Identifiers
3. Identifiers 🦋
A limited selection of identifiers is included in this document. The basic Device identity schema lets you include elements from any namespace, so additional elements can be defined using different XML namespaces 🌈
3.1. IP Address 🌐
The "ip" element can express a Device identity as an IP address ([RFC0791], [RFC4291]). The "v" attribute identifies the IP version with a single hexadecimal digit. The element uses the textual format specific to the indicated IP version. The textual format for IP version 4 and version 6 addresses MUST conform to the grammar defined in [RFC3986] ("IPv4address" and "IPv6address", respectively). IP version 6 addresses SHOULD conform to the formatting conventions in [RFC5952] 💜
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="6">2001:db8::1:ea7:fee1:d1e</ip>
</device>In situations where location configuration doesn't need additional identifiers, using an IP address as the identifier is what enables authorized third-party requests 🫶
3.2. MAC Address 💖
okay so a MAC address is the ID that a network interface uses when it's plugged into an IEEE LAN [IEEE802]. It's a unique sequence that either gets set at the factory or gets handed out by a local administrator 🍓. It's a solid identifier for a Device that uses the interface, as long as the two stay together (see Section 2.1.3) 🎀.
A MAC address can be written as a MAC-48, EUI-48, or EUI-64 address ([IEEE802], or an extended unique identifier [EUI64]), using the hexadecimal format defined in [IEEE802] ✨.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<mac>A0-12-34-56-78-90</mac>
</device>⚠️ A locally assigned MAC address is not guaranteed to be unique outside the administrative domain where it's assigned. It can only be used inside that domain, so don't go treating it like a global ID 🙈.
3.3. Port Numbers 🦋
a host might only be known by the flow of packets it's sending or receiving 🌊. On its own, a port number isn't enough to uniquely identify one host. But paired with an IP address, it can uniquely identify a Device in some situations 💅.
Port numbers can be super transient. They usually change way more often than an IP address does 🌸. That said, NAT is everywhere now, so some Devices can't be pinned down by IP address alone. A Device might still be identified by the flow of packets it generates. If a LIS knows the NAT mappings, then a target on the far side of the NAT might be uniquely identifiable too 🧚.
Port numbers are defined for UDP [RFC0768], TCP [RFC0793], SCTP [RFC4960], and DCCP [RFC4340] 🌈.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="4">192.0.2.75</ip>
<udpport>51393</udpport>
</device>Port numbers really depend on staying the same over time, so if that value shifts, the whole identification shifts with it 😭.
3.4. Network Access Identifier 🧚
a Network Access Identifier (NAI) [RFC4282] is an identifier used for network authentication across a bunch of different networks. It establishes a user identity inside a particular domain. Network services often use an NAI alongside location records, which ties network access to user authentication and authorization 🔐.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<nai>user@example.net</nai>
</device>ok this part is a little picky 🤓. The formal NAI grammar [RFC4282] allows octet sequences that aren't valid UTF-8 [RFC3629] sequences. Those can't be expressed in XML, so this NAI expression lets you escape them. Any octets that don't form a valid UTF-8 encoding can be written as a backslash (\) followed by two hexadecimal digits (case-insensitive) that represent the value of one octet 💜.
The canonical form of an NAI is the octet sequence you get by concatenating the UTF-8 encoded unescaped characters with the octets from the escaped parts. That resulting octet sequence MUST conform to the constraints in [RFC4282] 💖.
For example, the NAI f<U+FC>\<0xFF>@bar.com, which has the UTF-8 encoded u-umlaut character (U+FC) and an invalid UTF-8 octet (0xFF), might be written as f\c3\bc\5c\90@bar.com. The u-umlaut can also be included directly 🦋.
3.4.1. Using NAI for Location Configuration 💜
an NAI in WiMAX is uniquely attributable to a single Device at any one time. An NAI identifies either a Device or a service subscription, and neither of those can have multiple active sessions 🌟.
In a WiMAX network, an IP address isn't enough for a LIS to locate a Device. So the following procedure uses an NAI to identify the Device. The procedure, plus the messages and parameters it relies on, are defined in [WiMAX-T33-110-R015v01-B] 🛰️.
Location requests in a WiMAX network always need an NAI included. However, if a LIS gets a request that doesn't come from an authenticated and authorized third-party requestor, it can treat that request as a location configuration request ✨.
After getting a location request that includes an NAI, the LIS sends a "Location-Requestor-Authentication-Protocol" access request message to the Authentication, Authorization, and Accounting (AAA) server. That request includes an "MS-Identity-Assertion" parameter containing the NAI 🎀.
The AAA server checks network policy. If the request is permitted, the response includes the IP address currently assigned to the Device. If that IP address matches the source IP address of the HELD location request, then the location request can be authorized under the LCP policy (see Section 4.1). Otherwise, the request must be treated as a third-party request 👀.
This relies on the same protections against IP address spoofing that are required by [RFC5985]. On top of that, the request to the AAA server uses either Diameter [RFC3588] or RADIUS [RFC2865], so it also leans on whatever protections those protocols provide 🛡️. For the access request to count, the AAA server MUST be authenticated as a trusted entity for the purpose of linking the NAI and IP address. The AAA protocol MUST also protect against modification and replay attacks, so nobody can alter the data 🔥.
3.5. URI 👑
a Device can be identified by a URI [RFC3986]. Any URI works, as long as the requestor and LIS share the same understanding of what the URI means 🌸.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>sip:user@example.net;gr=kjh29x97us97d</uri>
</device>You really have to be careful that a given URI only points to one Device 🙈. A URI can often resolve to multiple destinations. For example, a SIP address of record URI might correspond to a service subscription instead of a single Device 💀.
A "tel:" URI [RFC3966] can identify a Device by telephone number 📞:
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>tel:800-555-1111;extension=1234;phone-context=+1</uri>
</device>3.6. Fully Qualified Domain Name 💅
a fully qualified domain name can be the basis for identification using the "fqdn" element 🌐.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<fqdn>host.example.net</fqdn>
</device>This domain name slot is IDNA-aware [RFC5890], and it's built from any sequence of valid U-labels or NR-LDH-labels 🌍.
A domain name doesn't always map to a single IP address or host. When that's the case, a domain name isn't a suitable identifier 🙅♀️.
3.7. Cellular Telephony Identifiers 🌈
different cellular telephony systems use lots of different mobile station identifiers, and elements are defined for them. These are the identifiers defined:
msisdn: The Mobile Station International Subscriber Dial Number (MSISDN) [E.213] is an E.164 number [E.164] between 6 and 15 digits long 📱.imsi: The International Mobile Subscriber Identity (IMSI) [TS.3GPP.23.003] is an identifier tied to all GSM (Global System for Mobile Communications) and UMTS (Universal Mobile Telecommunications System) mobile subscribers, and it's between 6 and 15 digits in length 🛜.imei: The International Mobile Equipment Identifier (IMEI) [TS.3GPP.23.003] is a unique device serial number up to 15 digits long 🔢.min: The Mobile Identification Number (MIN) [TIA.EIA.IS-2000-6] is a 10-digit unique number assigned to CDMA handsets 📲.mdn: The Mobile Directory Number (MDN) is an E.164 number [E.164], and it's used similarly to MSISDN 🧾.
Each identifier is a string of decimal digits with a length as specified 🔟.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<msisdn>11235550123</msisdn>
</device>3.8. DHCP Unique Identifier 🫶
the Dynamic Host Configuration Protocol (DHCP) uses a binary identifier for its clients. The DHCP Unique Identifier (DUID) is carried in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of DHCPv6, and it follows the format defined in Section 9 of [RFC3315]. The "duid" element holds the binary value of the DUID written in hexadecimal 🧡.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<duid>1234567890AaBbCcDdEeFf</duid>
</device>4. Privacy Considerations 🙈
location configuration protocols can use an authorization model called "LCP policy", which only lets Targets receive their own locations 🔒. Basically, the LCP server (that's the LIS) runs a single-rule policy: the Target is the only authorized Location Recipient 👑.
The security and privacy considerations of the base HELD protocol [RFC5985] apply here too. The return routability considerations, though, don't apply to third-party requests. Return routability might also not apply to requests from Targets asking for their own location, depending on which anti-spoofing mechanisms are used for the identifier 🦋.
4.1. Targets Requesting Their Own Location 🦋
okay so when a Target uses identity extensions to grab its own location, HELD can no longer be called an LCP 💅. The authorization policy the LIS uses for these requests has to be set up by one or more Rule Makers.
If the LIS only hands Targets their own locations, it can still be said to be following the "LCP policy" 🎀. You can find the "LCP policy" concept, plus more security and privacy stuff, in [GEOPRIV-ARCH].
The spoofing protections for HELD with identity extensions (giving Targets their own locations) are different from what you get with an LCP 👀. With an LCP, return routability is treated as enough protection against spoofing. If you want a similar policy here, you MUST define specific measures to protect against spoofing of the alternative identifier. This document only does that for an NAI used in WiMAX networks (see Section 3.4.1), and for no other identifier 🌸.
A Rule Maker might want assurance that the identifier is owned by the requestor 🔐. Any multi-stage verification that includes a return routability test can't give you any stronger assurance than return routability alone. So policy might need extra, independent verification methods 🧚.
Careful, bestie: you need to be careful when there isn't a direct one-to-one relationship between the requestor and the Device identity 🙈. If identifiers can't be uniquely tied to one Device, an attacker could exploit the use of HELD identity extensions to get Targets their own locations 💀.
It might be possible in some networks to set up multiple concurrent sessions using the same credentials. For example, Devices with different MAC addresses might get concurrent access to a network using the same NAI. In that case it is not appropriate to give Targets their own locations based on the NAI. It's also not appropriate to authenticate a Device using the NAI and then let that Device supply an unauthenticated MAC address as a Device identifier, even if that MAC address is registered to the NAI 😭. The MAC address could identify a different Device from the one making the request. The correct way to get authorization is to set up a policy that permits this particular request as a third-party request ✨.
Section 3.4.1 talks about what happens when you use an NAI as an identifier for location requests made to a LIS serving a WiMAX network 📡. More security considerations are in [WiMAX-T33-110-R015v01-B] 🫶.
4.2. Third-Party Requests 💌
The "LCP policy" does not allow requests made by third parties 🙅♀️. If a LIS allows third-party requests using Device identity, it takes on the role of a Location Server (LS) 👑. As a Location Server, the LIS MUST explicitly authorize requests according to the policies provided by Rule Makers, including the Target. The LIS MUST also authenticate requestors according to any agreed-upon authorization policy 🔒.
An organization that runs a LIS allowing third-party requests must provide a way for a Rule Maker to specify authorization policies as part of the LIS implementation (e.g, in the form of access control lists) 🗂️. Authorization must be established before third-party requests for the location of any Target are allowed. Until an authorization policy is established, the LIS MUST reject requests from third parties (that is, the default policy is "deny all") 🚫.
When the LIS is run by an access network, the relationship between the Target and the LIS can be transient 🌬️. The Target is a potential Rule Maker, so this is kind of a problem 😅. BUT, the process of setting up network access usually results in some sort of agreement between the Target and the network provider 🤝. That process is a natural vehicle for setting up location privacy policies ✨. Establishing an authorization policy might be a manual process, an explicit part of the network's terms of service, or an automated system that accepts formal authorization policies (see [RFC4745] and [RFC4825]) 🤖. This document does not mandate any particular mechanism for establishing an authorization policy 🎀.
5. Security Considerations 🛡️
Okay, this section is serious, so buckle up 😤. The security considerations in [RFC5985] describe the use of Transport Layer Security (TLS) [RFC5246] for server authentication, confidentiality, and protection from modification 🔐. These protections apply to both Target requests for their own locations and requests made by third parties 💖.
All HELD requests containing identity MUST be authenticated by the LIS 🚨. How authentication is done and what assurances are wanted is a matter for policy 📋.
The base HELD protocol uses return reachability of an IP address, implied by the requestor being able to successfully complete a TCP handshake 🤝. It is RECOMMENDED that any means of authentication provide at least this degree of assurance. For requests that include Device identity, the requestor MUST support HTTP digest authentication [RFC2617] 💅. Unauthenticated location requests containing Device identity can be challenged with an HTTP 401 (Unauthorized) response, or rejected with an HTTP 403 (Forbidden) response 🙅♀️.
HELD [RFC5985] does not mandate that Devices implement authentication 🙈. A LIS SHOULD NOT send an HTTP 401 response if the Device does not include Device identity 🫠.
Note that this document's text says "a HTTP 401", so I'll keep the original wording in spirit: a LIS SHOULD NOT send a HTTP 401 response if the Device doesn't include Device identity. That's the vibe ✨.
5.1. Identifier Suitability 🔍
Transient and ambiguous identifiers can be exploited by malicious requests, and they are not suitable as a basis for identifying a Device 😬. Section 2.1 gives more discussion on this subject 📚.
Identifier transience can lead to incorrect location information being provided 🌀. An attacker could exploit the use of transient identifiers. In this attack, the attacker either knows about a re-allocation of that identifier, or can force the identifier to be re-allocated while the request is being processed 😱.
An attacker could use this to get location information for another Device, or to make the LIS lie on its behalf, if this re-allocation happens between the time authorization is granted and the time location information is granted 🥺.
Ambiguous identifiers are a similar problem 🌫️. An attacker could legitimately gain authorization to use a particular identifier. Since an ambiguous identifier might refer to multiple Devices, if authorization is granted for one of those Devices, the attacker might gain access to location information for all of them 😭.
5.2. Targets Requesting Their Own Location 💜
Requests made by a Device for its own location are covered by the same set of protections HELD offers 🦋. These requests might be authorized under a policy similar to the "LCP policy" that lets a Target access location information about itself 🎀.
Identity information provided by the Device is private data that might be sensitive 🙈. The Device gives this information in the expectation that it helps the LIS provide the Device with a service. The LIS MUST NOT use identity information for any purpose other than serving the request that includes that information 🫶.
5.3. Third-Party Requests 👀
Requests from third parties have the same requirements for server authentication, confidentiality, and protection from modification as Target requests for their own locations 🌈. However, because the third party needs to be authorized, the requestor MUST be authenticated by the LIS 🔑. On top of that, third-party requests MUST be explicitly authorized by a policy established by a Rule Maker 👑.
More detail on the privacy implications of third-party requests is covered in Section 4 🌸.
6. XML Schema 🧩
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:id="urn:ietf:params:xml:ns:geopriv:held:id"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:id">
HELD Device Identity
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc6155.txt">
This document defines Device identity elements for HELD.
</xs:documentation>
</xs:annotation>
<xs:element name="device" type="id:deviceIdentity"/>
<xs:complexType name="deviceIdentity">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="requiredIdentifiers" type="id:qnameList"/>
<xs:simpleType name="qnameList">
<xs:list itemType="xs:QName"/>
</xs:simpleType>
<xs:element name="ip" type="id:ipAddress"/>
<xs:complexType name="ipAddress">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute name="v" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="[\da-fA-F]"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="mac" type="id:macAddress"/>
<xs:simpleType name="macAddress">
<xs:restriction base="xs:token">
<xs:pattern
value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="udpport" type="id:portNumber"/>
<xs:element name="tcpport" type="id:portNumber"/>
<xs:element name="sctpport" type="id:portNumber"/>
<xs:element name="dccpport" type="id:portNumber"/>
<xs:simpleType name="portNumber">
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="65535"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="nai" type="id:naiType"/>
<xs:simpleType name="naiType">
<xs:restriction base="xs:token">
<xs:pattern
value="([^\\]|\\[\dA-Fa-f]{2})*
(@([A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*\.)+
[A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*)?"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="fqdn" type="xs:token"/>
<xs:element name="duid" type="xs:hexBinary"/>
<xs:element name="msisdn" type="id:e164"/>
<xs:element name="imsi" type="id:e164"/>
<xs:element name="imei" type="id:digit15"/>
<xs:element name="min" type="id:digit10"/>
<xs:element name="mdn" type="id:e164"/>
<xs:simpleType name="digits">
<xs:restriction base="xs:token">
<xs:pattern value="[\d]+"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="e164">
<xs:restriction base="id:digit15">
<xs:minLength value="6"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="digit15">
<xs:restriction base="id:digits">
<xs:maxLength value="15"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="digit10">
<xs:restriction base="id:digits">
<xs:length value="10"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>7. IANA Considerations 📝
This document registers an XML namespace and schema with IANA, in accordance with the guidelines in [RFC3688] 🎀✨
7.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:id
okay so this section registers a brand new XML namespace, urn:ietf:params:xml:ns:geopriv:held:id 🎀, and it does it following the rules in [RFC3688]. bestie this is so official and I'm here for it 💅
URI: urn:ietf:params:xml:ns:geopriv:held:id
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com) 🦋
Here's the XML for it, copied exactly. It's a tiny XHTML page that just says what the namespace is and points back to RFC 6155 ✨
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Device Identity Parameters</title>
</head>
<body>
<h1>Namespace for HELD Device Identity Parameters</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:id</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6155.txt">
RFC 6155</a>.</p>
</body>
</html>7.2. XML Schema Registration
this part registers an XML schema, again following the guidelines in [RFC3688]. so cute, two registrations in a row 🌸
URI: urn:ietf:params:xml:schema:geopriv:held:id
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com) 💜
Schema: the XML for this schema is the entirety of Section 6 of this document, so go check that out if you want the actual schema, bestie 🧚
7.3. Registration of HELD 'badIdentifier' Error Code
this section registers the badIdentifier error code in the IANA maintained "HELD Error Codes" sub-registry, which lives inside the "Geopriv HTTP Enabled Location Delivery (HELD) Parameters" registry 🍓
Now the vibe check on the error itself. badIdentifier shows up when a Device identifier in a HELD request is any of these three things, and no, not a fourth one:
- not supported by the LIS
- badly formatted
- not one the requestor was authorized to make a request for
bestie, that last one is the sneaky one. The identifier can look perfectly fine and still get bounced if the requestor doesn't have permission for it 🙈
8. Acknowledgements
the National Emergency Number Association (NENA) VoIP location working group helped shape the schema in this document, and they deserve all the flowers 💐 Special thanks go to Barbara Stark, Guy Caron, Nadine Abbott, Jerome Grenier, and Martin Dawson 🫶 Bob Sherry gave input on how URIs get used, and Adam Muhlbauer and Eddy Corbett sent in more corrections, which is so iconic of them 👑
Bernard Aboba gave excellent feedback on the use cases and the security model 🔥 Bernard, together with Alan DeKok, also helped sort out an issue with NAIs. Ray Bellis is the reason the protocol port parameters exist, since he's the one who motivated them 🦋 Marc Linsner and Alissa Cooper gave guidance and text (respectively) that made the LCP discussion way clearer 🌈 And last but definitely not least, Jon Peterson and Cullen Jennings are the ones who forced this to be practical 💖 we love a practical queen ✨
9. References
9.1. Normative References
Here are the normative references, copied exactly so you can find every single one 📚
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010.
[W3C.REC-xml-names11-20060816]
Hollander, D., Tobin, R., Layman, A., and T. Bray,
"Namespaces in XML 1.1 (Second Edition)", World Wide Web
Consortium Recommendation REC-xml-names11-20060816,
August 2006,
<http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE 802,
February 2002.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority", March 1997,
<http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html>.
[E.164] ITU-T, "E.164 : The international public telecommunication
numbering plan", ITU-T Recommendation E.164,
February 2005,
<http://www.itu.int/rec/T-REC-E.164-200502-I/en>.
[E.213] ITU-T, "E.213 : Telephone and ISDN numbering plan for land
mobile stations in public land mobile networks (PLMN)",
ITU-T Recommendation E.213, November 1988,
<http://www.itu.int/rec/T-REC-E.213-198811-I/en>.
[TS.3GPP.23.003]
3GPP, "Numbering, addressing and identification", 3GPP
TS 23.003 9.4.0, September 2010,
<http://www.3gpp.org/ftp/Specs/html-info/23003.htm>.
[TIA.EIA.IS-2000-6]
TIA/EIA, "Analog Signaling Standard for CDMA 2000 Spread
Spectrum Systems", TIA/EIA/IS-2000-6-C, May 2002.
[WiMAX-T33-110-R015v01-B]
WiMAX Forum, "Protocols and Procedures for Location Based
Services", WiMAX Forum Network Architecture T33-110-
R015v01-B, May 2009.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.9.2. Informative References
and these are the informative ones, the "good to know" reading list 🌷
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, February 1997.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745,
February 2007.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010.
[GEOPRIV-ARCH]
Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
Work in Progress, October 2010.
[EMERGENCY-CALLING]
Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
Work in Progress, October 2010.Authors' Addresses
and last but not least, the people who wrote this thing, with all their contact details 💌
James Winterbottom
Andrew Corporation
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com
Martin Thomson
Andrew Corporation
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Richard Barnes
BBN Technologies
9861 Broken Land Pkwy, Suite 400
Columbia, MD 21046
USA
Phone: +1 410 290 6169
EMail: rbarnes@bbn.comthat's the whole thing, bestie 🌈✨ you made it through all of RFC 6155 💖
📦 where this page comes from
- ietf: rfc6155 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms