Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 6155 M. Thomson
Category: Standards Track Andrew Corporation
ISSN: 2070-1721 H. Tschofenig
Nokia Siemens Networks
R. Barnes
BBN Technologies
March 2011
Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
Abstract
When a Location Information Server receives a request for location
information (using the locationRequest message), described in the
base HTTP-Enabled Location Delivery (HELD) specification, it uses the
source IP address of the arriving message as a pointer to the
location determination process. This is sufficient in environments
where the location of a Device can be determined based on its IP
address.
Two additional use cases are addressed by this document. In the
first, location configuration requires additional or alternative
identifiers from the source IP address provided in the request. In
the second, an entity other than the Device requests the location of
the Device.
This document extends the HELD protocol to allow the location request
message to carry Device identifiers. Privacy and security
considerations describe the conditions where requests containing
identifiers are permitted.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6155.
Winterbottom, et al. Standards Track [Page 1]
RFC 6155 HELD Identity March 2011
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) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Winterbottom, et al. Standards Track [Page 2]
RFC 6155 HELD Identity March 2011
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 . . . . . . . . . . . . . . . . . . 25
Winterbottom, et al. Standards Track [Page 3]
RFC 6155 HELD Identity March 2011
1. Introduction
Protocols for requesting and providing location information require a
way for the requestor to specify the location that should be
returned. In a Location Configuration Protocol (LCP), the location
being requested is the requestor's location. This fact can make the
problem of identifying the Device simple, since IP datagrams that
carry the request already carry an identifier for the Device --
namely, the source IP address of an incoming request. Existing LCPs,
such as HTTP-Enabled Location Delivery (HELD) [RFC5985] and DHCP
([RFC3825], [RFC4776]) rely on the source IP address or other
information present in protocol datagrams to identify a Device.
Aside from the datagrams that form a request, a Location Information
Server (LIS) does not necessarily have access to information that
could further identify the Device. In some circumstances, as shown
in [RFC5687], additional identification information can be included
in a request to identify a Device.
This document extends the HELD protocol to support the inclusion of
additional identifiers for the Device in HELD location requests. An
XML schema is defined that provides a structure for including these
identifiers in HELD requests.
An important characteristic of this addition is that the 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 the identity of Devices
without additional authorization checks. A LIS identifies the Device
making the LCP request using the source addressing on the request
packets, using return routability to ensure that these identifiers
are not spoofed.
HELD with identity extensions allows a requestor to explicitly
provide identification details in the body of a location request.
This means that location requests can be made in cases where
additional Device identity checks are necessary, and in cases where
the requestor is not the Device itself. Third-party Location
Recipients (LRs) are able to make requests that include identifiers
to retrieve location information about a particular Device.
The usage of identifiers in HELD introduces a new set of privacy
concerns. In an LCP, the requestor can be implicitly authorized to
access the requested location information, because it is their own
location. In contrast, a third-party LR must be explicitly
authorized when requesting the location of a Device. Establishing
appropriate authorization and other related privacy concerns are
discussed in Section 4.
Winterbottom, et al. Standards Track [Page 4]
RFC 6155 HELD Identity March 2011
1.1. Applications
This document defines a means to explicitly include Device identity
information in the body of a HELD location request. This identity
information is used to identify the Device that is the subject (or
Target) of the location request. If Device identity is present, the
identity of the requestor 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 information other than
an IP address might be needed to determine the location of a
Device.
A LIS can authorize location configuration requests using a policy
that allows Devices to acquire their own location (see
Section 4.1). If an unauthorized third party falsifies addressing
on request packets to match the provided Device identity, the
request might be erroneously 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 provides assurances that
the requestor and 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 is able to ensure that 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 is unable to acquire location information for
itself (see Section 6.3 of [EMERGENCY-CALLING]). This allows use
of location-dependent applications -- particularly essential
services like emergency calling -- where Devices do not support a
location configuration protocol or they are unable to successfully
retrieve location information.
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. This contract must
Winterbottom, et al. Standards Track [Page 5]
RFC 6155 HELD Identity March 2011
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 ensure that 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
This document uses the term Location Information Server (LIS) and
Location Configuration Protocol (LCP) as described in [RFC5687] and
[GEOPRIV-ARCH].
The term Device is used specifically as the subject of an LCP,
consistent with [RFC5985]. This document also uses the term Target
to refer to any entity that might be a subject of the same location
information. Target is used in a more general sense, including the
Device, but also any nearby entity, such as the user of a Device.
A Target has a stake in setting authorization policy on the use of
location information. A Rule Maker is the term used for the role
that makes policy decisions about authorization, determining what
entities are permitted to receive location and how that information
is provided.
Device, Target, and Rule Maker are defined in [GEOPRIV-ARCH].
The term "requestor" is used in this document to refer to 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 used as the starting point in location determination.
Identifiers might be associated with a different Device over time,
but their purpose is to identify the Device, not to describe its
environment or network attachment.
Winterbottom, et al. Standards Track [Page 6]
RFC 6155 HELD Identity March 2011
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 ensuring that location information is correct for the
Device, which includes ensuring that the identifier is uniquely
attributable to the Device.
Some identifiers can be either temporary or could potentially
identify multiple Devices. Identifiers that are transient or
ambiguous could be exploited by an attacker to either gain
information about another Device or to coerce the LIS into producing
misleading information.
The identifiers described in this document MUST only be used where
that identifier is used as the basis for location determination.
Considerations relating to the use of identifiers for a Device
requesting its own location are discussed in Section 5 of [RFC5687];
this section discusses use of 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.
However, other identifiers can have a different meaning to different
entities on a network. This is especially true for IP addresses
[RFC2101], but this can be true for other identifiers to varying
degrees. Non-uniqueness arises from both topology (all network
entities have 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 that the identifier a requestor
uses to refer to one physical entity could actually apply to a
different physical entity when used in a different network context.
Unless an authorized third-party requestor and LIS operate in the
same network context, each could have a different subjective view of
the meaning of the identifier.
Winterbottom, et al. Standards Track [Page 7]
RFC 6155 HELD Identity March 2011
Where subjective views differ, the third party receives information
that is correct only within the network context of the LIS. The
location information provided by the LIS is probably misleading: the
requestor believes that the information relates to a different entity
than it was generated for.
Authorization policy can be affected by a subjective network view if
it is applied based on an identifier or if its application depends on
identifiers. The subjective view presented to the LIS and Rule Maker
need to agree for the two entities to understand policy on the same
terms. For instance, it is possible that the LIS could apply the
incorrect authorization policy if it selects the policy using a
subjective identifier. Alternatively, it may 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 occurs have a
different view of the network. Private use addresses [RFC1918]
are the most easily recognizable identifiers that have limited
scope.
A LIS can be configured to recognize scenarios where the subjective
view of a requestor or Rule Maker might not coincide with the view of
the LIS. The LIS can either provide location information that takes
the view of the requestor 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 originates in an external
network with an IP address from the private address space might
not be valid -- it could be identifying an entity within another
address space. The LIS can be configured to reject such requests,
unless it knows by other means that the request is valid.
In the 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 is mapped to a private address, if that mapping is fixed,
to determine 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 information. The LIS provides location
information with appropriate uncertainty to allow for the fact that
the residential gateway serves a small geographical area.
Winterbottom, et al. Standards Track [Page 8]
RFC 6155 HELD Identity March 2011
2.1.2. Transient Identifiers
Some identifiers are temporary and can, over the course of time, be
assigned to different physical entities. An identifier that is
reassigned between the time that a request is formulated by a
requestor and when the request is received by the LIS causes the LIS
to locate a different entity than the requestor intended. The
response from the LIS might be accurate, but the request incorrectly
associates this information with the wrong subject.
A LIS should be configured with information about any potentially
temporary identifiers. It can use this information to identify when
changes have occurred. 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 is likely to be
reassigned, it is not suitable as an identifier.
It's possible that some degree of uncertainty could persist where
identifiers are reassigned frequently; the extent to which errors
arising from using transient identifiers are tolerated is a matter
for 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
sufficient to identify the Device. When a network interface is
identified, the goal is to identify the Device that is immediately
attached to the network interface.
Most network interfaces remain physically attached to a particular
Device, though a network interface might be physically separable from
the Device. By identifying a network interface, any Device that is
intended to be identified could change.
2.2. Identifier Format and Protocol Details
XML elements are used to express the Device identity. The "device"
element is used as a general container for identity information.
This document defines a basic set of identifiers. An example HELD
request, shown in Figure 1, includes an IP version 4 address.
Winterbottom, et al. Standards Track [Page 9]
RFC 6155 HELD Identity March 2011
Namespace for HELD Device Identity Parameters
urn:ietf:params:xml:ns:geopriv:held:id
See RFC 6155.
END 7.2. XML Schema Registration This section registers an XML schema as per the guidelines in [RFC3688]. 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 can be found as the entirety of Section 6 of this document. 7.3. Registration of HELD 'badIdentifier' Error Code This section registers the "badIdentifier" error code in the IANA maintained "HELD Error Codes" sub-registry of the "Geopriv HTTP Enabled Location Delivery (HELD) Parameters" registry. badIdentifier This error code indicates that a Device identifier used in the HELD request was either: not supported by the LIS, badly formatted, or not one for which the requestor was authorized to make a request. 8. Acknowledgements The National Emergency Number Association (NENA) VoIP location working group provided assistance in the definition of the schema used in this document. Special thanks go to Barbara Stark, Guy Winterbottom, et al. Standards Track [Page 22] RFC 6155 HELD Identity March 2011 Caron, Nadine Abbott, Jerome Grenier, and Martin Dawson. Bob Sherry provided input on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for providing further corrections. Bernard Aboba provided excellent feedback on use cases and the security model; Bernard, along with Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis provided motivation for the protocol port parameters. Marc Linsner and Alissa Cooper provided guidance and text (respectively) that greatly clarified the discussion relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for forcing this to be practical. 9. References 9.1. Normative References [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. Winterbottom, et al. Standards Track [Page 23] RFC 6155 HELD Identity March 2011 [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,