Skip to main content

Use of Device Identity in HTTP-Enabled Location Delivery (HELD)

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6155.
Authors Martin Thomson , Richard Barnes , James Winterbottom , Hannes Tschofenig
Last updated 2018-12-20 (Latest revision 2010-11-14)
Replaces draft-winterbottom-geopriv-held-identity-extensions
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 6155 (Proposed Standard)
Action Holders
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Robert Sparks
Send notices to (None)
Geopriv                                                  J. Winterbottom
Internet-Draft                                                M. Thomson
Intended status: Standards Track                      Andrew Corporation
Expires: May 19, 2011                                      H. Tschofenig
                                                  Nokia Siemens Networks
                                                               R. Barnes
                                                        BBN Technologies
                                                       November 15, 2010

    Use of Device Identity in HTTP-Enabled Location Delivery (HELD)


   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

   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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Winterbottom, et al.      Expires May 19, 2011                  [Page 1]
Internet-Draft                HELD Identity                November 2010

   This Internet-Draft will expire on May 19, 2011.

Copyright Notice

   Copyright (c) 2010 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
   ( 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.      Expires May 19, 2011                  [Page 2]
Internet-Draft                HELD Identity                November 2010

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Applications . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Device Identity  . . . . . . . . . . . . . . . . . . . . . . .  7
     2.1.  Identifier Suitability . . . . . . . . . . . . . . . . . .  7
       2.1.1.  Subjective Network Views . . . . . . . . . . . . . . .  7
       2.1.2.  Transient Identifiers  . . . . . . . . . . . . . . . .  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 . . . . . . . . . . . . . . . . . . . . 16
     4.1.  Targets Requesting Their Own Location  . . . . . . . . . . 16
     4.2.  Third Party Requests . . . . . . . . . . . . . . . . . . . 17
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
     5.1.  Identifier Suitability . . . . . . . . . . . . . . . . . . 18
     5.2.  Targets Requesting Their Own Location  . . . . . . . . . . 19
     5.3.  Third Party Requests . . . . . . . . . . . . . . . . . . . 19
   6.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
     7.1.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 23
     7.2.  XML Schema Registration  . . . . . . . . . . . . . . . . . 23
     7.3.  Registration of HELD 'badIdentifier' Error Code  . . . . . 24
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  Normative references . . . . . . . . . . . . . . . . . . . 26
     9.2.  Informative references . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30

Winterbottom, et al.      Expires May 19, 2011                  [Page 3]
Internet-Draft                HELD Identity                November 2010

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 requester 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 requester 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 requester 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.      Expires May 19, 2011                  [Page 4]
Internet-Draft                HELD Identity                November 2010

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 requester 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

      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 requester 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 requester.

   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 [I-D.ietf-ecrit-phonebcp]).  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.      Expires May 19, 2011                  [Page 5]
Internet-Draft                HELD Identity                November 2010

      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 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

   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 [I-D.ietf-geopriv-arch].

   The term "requester" is used in this document to refer to the entity
   making a HELD request.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Winterbottom, et al.      Expires May 19, 2011                  [Page 6]
Internet-Draft                HELD Identity                November 2010

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.

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

      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 requester
   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 requester and LIS operate in the

Winterbottom, et al.      Expires May 19, 2011                  [Page 7]
Internet-Draft                HELD Identity                November 2010

   same network context, each could have a different subjective view of
   the meaning of the identifier.

   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
   requester 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 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

   A LIS can be configured to recognize scenarios where the subjective
   view of a requester 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 requester 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 requester 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

Winterbottom, et al.      Expires May 19, 2011                  [Page 8]
Internet-Draft                HELD Identity                November 2010

   information with appropriate uncertainty to allow for the fact that
   the residential gateway serves a small geographical area.

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
   requester and when the request is received by the LIS causes the LIS
   to locate a different entity than the requester 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.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.

     <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
       <locationType exact="true">geodetic</locationType>
       <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
         <ip v="4"></ip>

                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.  Absence of this indication
   means that the location information was generated using the source IP
   address in the request.

Winterbottom, et al.      Expires May 19, 2011                  [Page 9]
Internet-Draft                HELD Identity                November 2010

   A "badIdentifier" HELD error code indicates that the requester is not
   authorized to use that identifier or that the request contains an
   identifier that is badly formatted or not supported by the LIS.  This
   code is registered in Section 7.3.

   If the LIS requires an identifier that is not provided in the
   request, the desired identifiers MAY be identified in the HELD error
   response, using the "requiredIdentifiers" element.  This element
   contains a list of XML qualified names [W3C.REC-xml-names11-20060816]
   that identify the identifier elements required by the LIS.  Namespace
   prefix bindings for the qualified names are taken from document
   context.  Figure 2 shows an example error indicating that the
   requester needs to include a MAC address (Section 3.2) and IP address
   (Section 3.1) if the request is to succeed.

     <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
       <message xml:lang="en">MAC address required</message>
         mac ip

            Figure 2: HELD Error Requesting Device Identifiers

Winterbottom, et al.      Expires May 19, 2011                 [Page 10]
Internet-Draft                HELD Identity                November 2010

3.  Identifiers

   A limited selection of identifiers are included in this document.
   The basic Device identity schema allows for the inclusion of elements
   from any namespace, therefore 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).

     <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <ip v="6">2001:db8::1:ea7:fee1:d1e</ip>

   In situations where location configuration does not require
   additional identifiers, using IP address as an identifier enables
   authorized third party requests.

3.2.  MAC Address

   The media access control (MAC) address used by the IEEE 802 family of
   access technologies is an identifier that is assigned to a particular
   network Device.  A MAC address is a unique sequence that is either
   assigned at the time of manufacture of a Device, or assigned by a
   local administrator.  A MAC address rarely changes; therefore, a MAC
   address is an appropriate identifier for a Device.

   A MAC address can be represented as MAC-48, EUI-48 or EUI-64 address
   ([IEEE802], or extended unique identifier [EUI64]) using the
   hexadecimal representation defined in [IEEE802].

     <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

   A locally-assigned MAC address is not guaranteed to be unique outside
   the administrative domain where it is assigned.  Locally-assigned MAC
   addresses can only be used within this domain.

Winterbottom, et al.      Expires May 19, 2011                 [Page 11]
Internet-Draft                HELD Identity                November 2010

3.3.  Port Numbers

   A host might only be known by a flow of packets that it is sending or
   receiving.  On its own, a port number is insufficient to uniquely
   identify a single host.  In combination with an IP address, a port
   number can be used to uniquely identify a Device in some

   Use of a particular port number can be transient; often significantly
   more than use of any given IP address.  However, widespread use of
   network address translation (NAT) means that some Devices cannot be
   uniquely identified by IP address alone.  An individual Device might
   be identified by a flow of packets that it generates.  Providing that
   a LIS has sufficient knowledge of the mappings used by the NAT, an
   individual target on the remote side of the NAT might be able to be
   identified uniquely.

   Port numbers are defined for UCP [RFC0768], TCP [RFC0793], SCTP
   [RFC4960] and DCCP [RFC4340].

     <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <ip v="4"></ip>

   Use of port numbers is especially reliant on the value remaining
   consistent over time.

3.4.  Network Access Identifier

   A Network Access Identifier (NAI) [RFC4282] is an identifier used in
   network authentication in a range of networks.  The identifier
   establishes a user identity within a particular domain.  Often,
   network services use an NAI in relation to location records, tying
   network access to user authentication and authorization.

     <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

   The formal grammar for NAI [RFC4282] permits sequences of octets that
   are not valid UTF-8 [RFC3629] sequences.  These sequences cannot be
   expressed using XML.  Therefore, this expression of NAI permits
   escaping.  Sequences of octets that do not represent a valid UTF-8
   encoding can be expressed using a backslash ('\') followed by two
   case-insensitive hexadecimal digits representing the value of a
   single octet.

Winterbottom, et al.      Expires May 19, 2011                 [Page 12]
Internet-Draft                HELD Identity                November 2010

   The canonical representation of an NAI is the sequence of octets that
   is produced from the concatenation of UTF-8 encoded sequences of
   unescaped characters and octets derived from escaped components.  The
   resulting sequence of octets MUST conform to the constraints in

   For example, the NAI "f<U+FC>\<0xFF>" that includes the UTF-8
   encoded u-umlaut character (U+FC) and an invalid UTF-8 octet (0xFF)
   might be represented as "f\c3\bc\5c\", though the u-umlaut
   character might 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 either identifies a Device or a service
   subscription, neither of which can have multiple active sessions.

   In a WiMAX network, an IP address is not sufficient information for a
   LIS to locate a Device.  The following procedure relies on an NAI to
   identify the Device.  This procedure and the messages and parameters
   is relies upon are defined in [WiMAX-T33-110-R015v01-B].

   Location requests in a WiMAX network always require the inclusion of
   an NAI.  However, if a LIS receives a request that does not come from
   an authenticated and authorized third party requester, it can treat
   this request as a location configuration request.

   After receiving 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.  This request includes an "MS-Identity-Assertion" parameter
   containing the NAI.

   The AAA server consults network policy and if the request is
   permitted, the response includes the IP address that is currently
   assigned to the Device.  If this IP address matches the source IP
   address of the HELD location request, 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 IP address spoofing protections that are
   required by [RFC5985].  In addition, the request made of the AAA uses
   either Diameter [RFC3588] or RADIUS [RFC2865], and therefore relies
   on the protections provided by those protocols.  In order to rely on
   the access request, the AAA server MUST be authenticated to be a
   trusted entity for the purpose of providing a link between the NAI
   and IP address.  The AAA protocol MUST also provide protection from
   modification and replay attacks to ensure that data cannot be altered

Winterbottom, et al.      Expires May 19, 2011                 [Page 13]
Internet-Draft                HELD Identity                November 2010

   by an attacker.

3.5.  URI

   A Device can be identified by a URI [RFC3986].  Any URI can be used
   providing that the requester and LIS have a common understanding of
   the semantics implied by use of the URI.

     <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

   Particular care needs to be taken in ensuring that a particular URI
   only refers to a single Device.  In many cases, a URI can resolve to
   multiple destinations.  For example, a SIP address of record URI can
   correspond to a service subscription rather than a single Device.

   A "tel:" URI [RFC3966] can be used identify a Device by telephone

     <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

3.6.  Fully Qualified Domain Name

   A fully-qualified domain name can be used as the basis for
   identification using the "fqdn" element.

     <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

   This IDN-aware domain name slot [RFC5890] is formed from any sequence
   of valid U-labels or NR-LDH-labels.

   A domain name does not always correspond to a single IP address or
   host.  If this is the case, a domain name is not a suitable

3.7.  Cellular Telephony Identifiers

   A range of different forms of mobile station identifiers are used for
   different cellular telephony systems.  Elements are defined for these
   identifiers.  The following identifiers are defined:

Winterbottom, et al.      Expires May 19, 2011                 [Page 14]
Internet-Draft                HELD Identity                November 2010

   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] an identifier associated with all GSM and UMTS
      mobile subscribers.

   imei:  The International Mobile Equipment Identifier (IMEI)
      [TS.3GPP.23.003] is a unique device serial number up to 15 digits

   min:  The Mobile Identification Number (MIN) [TIA.EIA.IS-2000-6] is a
      unique number assigned to CDMA handsets.

   mdn:  The Mobile Directory Number (MDN) is an E.164 number [E.164],
      with usage similar to MSISDN.

   Each identifier contains a string of decimal digits with a length as

     <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

3.8.  DHCP Unique Identifier

   The Dynamic Host Configuration Protocol (DHCP) uses a binary
   identifier for its clients.  The DHCP Unique Identifier (DUID) is
   expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of
   DHCPv6 and follows the format defined in Section 9 of [RFC3315].  The
   "duid" element includes the binary value of the DUID expressed in

     <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

Winterbottom, et al.      Expires May 19, 2011                 [Page 15]
Internet-Draft                HELD Identity                November 2010

4.  Privacy Considerations

   Location configuration protocols can make use of an authorization
   model known as "LCP policy", which permits only Targets to be the
   recipients of their own locations.  In effect, an LCP server (that
   is, the LIS) follows a single rule policy that states that the Target
   is the only authorized Location Recipient.

   The security and privacy considerations of the base HELD protocol
   [RFC5985] are applicable.  However, the considerations relating to
   return routability do not apply to third party requests.  Return
   routability may also not apply to requests from Targets for their own
   location depending on the anti-spoofing mechanisms employed for the

4.1.  Targets Requesting Their Own Location

   When a Target uses identity extensions to obtain its own location,
   HELD can no longer be considered an LCP.  The authorization policy
   that the LIS uses to respond to these requests must be provisioned by
   one or more Rule Makers.

   In the case that the LIS exclusively provides Targets with their own
   locations, the LIS can still be said to be following the "LCP
   policy".  The "LCP policy" concept and further security and privacy
   considerations can be found in [I-D.ietf-geopriv-arch].

   The spoofing protections provided when using HELD with identity
   extensions to provide Targets with their own locations differ from
   the protections inherent in an LCP.  For an LCP, return routability
   is considered sufficient protection against spoofing.  For a similar
   policy to be used, specific measures MUST be defined to protect
   against spoofing of the alternative identifier.  This document
   defines this for an NAI when used in WiMAX networks (see
   Section 3.4.1), but for no other identifier.

   A Rule Maker might require an assurance that the identifier is owned
   by the requester.  Any multi-stage verification process that includes
   a return routability test cannot provide any stronger assurance than
   return routability alone; therefore, policy might require the use of
   additional, independent methods of verification.

   Care is required where a direct one-to-one relationship between
   requester and Device identity does not exist.  If identifiers are not
   uniquely attributable to a single Device, the use of HELD identity
   extensions to provide Targets with their own locations could be
   exploited by an attacker.

Winterbottom, et al.      Expires May 19, 2011                 [Page 16]
Internet-Draft                HELD Identity                November 2010

      It might be possible in some networks to establish multiple
      concurrent sessions using the same credentials.  For instance,
      Devices with different MAC addresses might be granted concurrent
      access to a network using the same NAI.  It is not appropriate to
      provide Targets with their own locations based on NAI in this
      case.  Neither is it appropriate to authenticate a Device using
      NAI and allow that Device to provide an unauthenticated MAC
      address as a Device identifier, even if the MAC address is
      registered to the NAI.  The MAC address potentially identifies a
      different Device to the one that is making the request.  The
      correct way of gaining authorization is to establish a policy that
      permits this particular request as a third party request.

   Section 3.4.1 discusses the implications of using an NAI as an
   identifier for location requests made of a LIS serving a WiMAX
   network.  Additional security considerations are discussed in

4.2.  Third Party Requests

   The "LCP policy" does not allow requests made by third parties.  If a
   LIS permits requests from third parties using Device identity, it
   assumes the rule of a Location Server (LS).  As a Location Server,
   the LIS MUST explicitly authorize requests according to the policies
   that are provided by Rule Makers, including the Target.  The LIS MUST
   also authenticate requesters according to any agreed-upon
   authorization policy.

   An organization that provides a LIS that allows third party requests
   must provide a means 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
   allowing third party requests for the location of any Target.  Until
   an authorization policy is established, the LIS MUST reject requests
   by third parties (that is, the default policy is "deny all").

   When the LIS is operated by an access network, the relationship
   between the Target and the LIS can be transient.  As the Target is a
   potential Rule Maker, this presents a problem.  However, the process
   of establishing network access usually results in a form of agreement
   between the Target and the network provider.  This process offers a
   natural vehicle for establishing location privacy policies.
   Establishing authorization policy might be a manual process, an
   explicit part of the terms of service for the network, or an
   automated system that accepts formal authorization policies (see
   [RFC4745], [RFC4825]).  This document does not mandate any particular
   mechanism for establishing an authorization policy.

Winterbottom, et al.      Expires May 19, 2011                 [Page 17]
Internet-Draft                HELD Identity                November 2010

5.  Security Considerations

   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 accomplished and what assurances are
   desired is a matter for policy.

   The base HELD protocol uses return reachability of an IP address
   implied by the requester 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 requester 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)

      Note that HELD [RFC5985] does not mandate that Devices implement
      authentication.  A LIS SHOULD NOT send a HTTP 401 response if the
      Device does not include Device identity.

5.1.  Identifier Suitability

   Transient and ambiguous identifiers can be exploited by malicious
   requests and are not suitable as a basis for identifying a Device.
   Section 2.1 provides further 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 of a re-
   allocation of that identifier or is able to force the identifier to
   be re-allocated during the processing of the request.

   An attacker could use this to acquire location information for
   another Device or to coerce the LIS to lie on its behalf if this re-
   allocation occurs between the time where authorization is granted and
   location information is granted.

   Ambiguous identifiers present a similar problem.  An attacker could
   legitimately gain authorization to use a particular identifier.
   Since an ambiguous identifier potentially refers to multiple Devices,
   if authorization is granted for one of those Devices, an attacker
   potentially gains access to location information for all of those

Winterbottom, et al.      Expires May 19, 2011                 [Page 18]
Internet-Draft                HELD Identity                November 2010


5.2.  Targets Requesting Their Own Location

   Requests made by a Device for its own location are covered by the
   same set of protections offered by HELD.  These requests might be
   authorized under a policy similar to the "LCP policy" that permits a
   Target access to location information about itself.

   Identity information provided by the Device is private data that
   might be sensitive.  The Device provides this information in the
   expectation that it assists the LIS in providing the Device a
   service.  The LIS MUST NOT use identity information for any other
   purpose other than serving the request that includes that

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 requester MUST be authenticated by
   the LIS.  In addition, third party requests MUST be explicitly
   authorized by a policy that is established by a Rule Maker.

   More detail on the privacy implications of third party requests are
   covered in Section 4.

Winterbottom, et al.      Expires May 19, 2011                 [Page 19]
Internet-Draft                HELD Identity                November 2010

6.  XML Schema

      elementFormDefault="qualified" attributeFormDefault="unqualified">

        HELD Device Identity
      <xs:documentation source="">
  <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
                         published RFC and remove this note.]] -->
        This document defines Device identity elements for HELD.

    <xs:element name="device" type="id:deviceIdentity"/>
    <xs:complexType name="deviceIdentity">
        <xs:any namespace="##any" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>

    <xs:element name="requiredIdentifiers" type="id:qnameList"/>
    <xs:simpleType name="qnameList">
      <xs:list itemType="xs:QName"/>

    <xs:element name="ip" type="id:ipAddress"/>
    <xs:complexType name="ipAddress">
        <xs:extension base="xs:token">
          <xs:attribute name="v" use="required">
              <xs:restriction base="xs:token">
                <xs:pattern value="[\da-fA-F]"/>

Winterbottom, et al.      Expires May 19, 2011                 [Page 20]
Internet-Draft                HELD Identity                November 2010

    <xs:element name="mac" type="id:macAddress"/>
    <xs:simpleType name="macAddress">
      <xs:restriction base="xs:token">

    <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:element name="nai" type="id:naiType"/>
    <xs:simpleType name="naiType">
      <xs:restriction base="xs:token">

    <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:simpleType name="e164">
      <xs:restriction base="id:digit15">
        <xs:minLength value="6"/>

Winterbottom, et al.      Expires May 19, 2011                 [Page 21]
Internet-Draft                HELD Identity                November 2010

    <xs:simpleType name="digit15">
      <xs:restriction base="id:digits">
        <xs:maxLength value="15"/>
    <xs:simpleType name="digit10">
      <xs:restriction base="id:digits">
        <xs:length value="10"/>


Winterbottom, et al.      Expires May 19, 2011                 [Page 22]
Internet-Draft                HELD Identity                November 2010

7.  IANA Considerations

   This document registers an XML namespace and schema with IANA in
   accordance with guidelines in [RFC3688].

7.1.  URN Sub-Namespace Registration for

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in

      URI: urn:ietf:params:xml:ns:geopriv:held:id

      Registrant Contact: IETF, GEOPRIV working group
      (, James Winterbottom


         <?xml version="1.0"?>
         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
         <html xmlns="" xml:lang="en">
             <title>HELD Device Identity Parameters</title>
             <h1>Namespace for HELD Device Identity Parameters</h1>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
             <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>

7.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines in

   URI:  urn:ietf:params:xml:schema:geopriv:held:id

Winterbottom, et al.      Expires May 19, 2011                 [Page 23]
Internet-Draft                HELD Identity                November 2010

   Registrant Contact:  IETF, GEOPRIV working group (,
      James Winterbottom (

   Schema:  The XML for this schema can be found as the entirety of
      Section 6 of this document.  [IANA Note: The pattern attribute for
      naiType does not contain whitespace.]

7.3.  Registration of HELD 'badIdentifier' Error Code

   This section registers the "badIdentifier" error code in the "Geopriv
   HELD Registries, Error codes for HELD" IANA 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 requester was authorized
      to make a request.

Winterbottom, et al.      Expires May 19, 2011                 [Page 24]
Internet-Draft                HELD Identity                November 2010

8.  Acknowledgements

   The the NENA VoIP location working group provided assistance in the
   definition of the schema used in this document.  Special thanks go to
   Barbara Stark, Guy 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.

Winterbottom, et al.      Expires May 19, 2011                 [Page 25]
Internet-Draft                HELD Identity                November 2010

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.

   [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.

Winterbottom, et al.      Expires May 19, 2011                 [Page 26]
Internet-Draft                HELD Identity                November 2010

   [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.

              Hollander, D., Bray, T., Layman, A., and R. Tobin,
              "Namespaces in XML 1.1 (Second Edition)", World Wide Web
              Consortium Recommendation REC-xml-names11-20060816,
              August 2006,

   [IEEE802]  IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks: Overview and Architecture",  802, February 2002.

   [EUI64]    IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
              Registration Authority", March 1997, <http://

   [E.164]    ITU-T, "E.164 : The international public telecommunication
              numbering plan", ITU-T Recommendation E.164,
              February 2005.

   [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.

              3GPP, "Numbering, addressing and identification", 3GPP
              TS 23.003 9.4.0, September 2010.

              TIA/EIA, "Analog Signaling Standard for CDMA 2000 Spread
              Spectrum Systems",  TIA/EIA/IS-2000-6-C, May 2002.


Winterbottom, et al.      Expires May 19, 2011                 [Page 27]
Internet-Draft                HELD Identity                November 2010

              WiMAX Forum, "Protocols and Procedures for Location Based
              Services", WiMAX Forum Network Architecture T33-110-
              R015v01-B, May 2009.

9.2.  Informative references

   [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.

              Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
              Tschofenig, H., and H. Schulzrinne, "An Architecture for
              Location and Location Privacy in Internet Applications",
              draft-ietf-geopriv-arch-03 (work in progress),
              October 2010.

              Rosen, B. and J. Polk, "Best Current Practice for

Winterbottom, et al.      Expires May 19, 2011                 [Page 28]
Internet-Draft                HELD Identity                November 2010

              Communications Services in support of Emergency Calling",
              draft-ietf-ecrit-phonebcp-16 (work in progress),
              October 2010.

Winterbottom, et al.      Expires May 19, 2011                 [Page 29]
Internet-Draft                HELD Identity                November 2010

Authors' Addresses

   James Winterbottom
   Andrew Corporation
   Andrew Building (39)
   Wollongong University Campus
   Northfields Avenue
   Wollongong, NSW  2522

   Phone: +61 2 4221 2938

   Martin Thomson
   Andrew Corporation
   Andrew Building (39)
   Wollongong University Campus
   Northfields Avenue
   Wollongong, NSW  2522

   Phone: +61 2 4221 2915

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600

   Phone: +358 (50) 4871445

   Richard Barnes
   BBN Technologies
   9861 Broken Land Pkwy, Suite 400
   Columbia, MD  21046

   Phone: +1 410 290 6169

Winterbottom, et al.      Expires May 19, 2011                 [Page 30]