draft-ietf-geopriv-held-identity-extensions-06.txt   rfc6155.txt 
Geopriv J. Winterbottom Internet Engineering Task Force (IETF) J. Winterbottom
Internet-Draft M. Thomson Request for Comments: 6155 M. Thomson
Intended status: Standards Track Andrew Corporation Category: Standards Track Andrew Corporation
Expires: May 19, 2011 H. Tschofenig ISSN: 2070-1721 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
R. Barnes R. Barnes
BBN Technologies BBN Technologies
November 15, 2010 March 2011
Use of Device Identity in HTTP-Enabled Location Delivery (HELD) Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
draft-ietf-geopriv-held-identity-extensions-06
Abstract Abstract
When a Location Information Server receives a request for location When a Location Information Server receives a request for location
information (using the locationRequest message), described in the information (using the locationRequest message), described in the
base HTTP Enabled Location Delivery (HELD) specification, it uses the base HTTP-Enabled Location Delivery (HELD) specification, it uses the
source IP address of the arriving message as a pointer to the source IP address of the arriving message as a pointer to the
location determination process. This is sufficient in environments location determination process. This is sufficient in environments
where the location of a Device can be determined based on its IP where the location of a Device can be determined based on its IP
address. address.
Two additional use cases are addressed by this document. In the Two additional use cases are addressed by this document. In the
first, location configuration requires additional or alternative first, location configuration requires additional or alternative
identifiers from the source IP address provided in the request. In identifiers from the source IP address provided in the request. In
the second, an entity other than the Device requests the location of the second, an entity other than the Device requests the location of
the Device. the Device.
This document extends the HELD protocol to allow the location request This document extends the HELD protocol to allow the location request
message to carry Device identifiers. Privacy and security message to carry Device identifiers. Privacy and security
considerations describe the conditions where requests containing considerations describe the conditions where requests containing
identifiers are permitted. identifiers are permitted.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc6155.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7 2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7 2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7
2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 7 2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 7
2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9 2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9
2.1.3. Network Interfaces and Devices . . . . . . . . . . . . 9
2.2. Identifier Format and Protocol Details . . . . . . . . . . 9 2.2. Identifier Format and Protocol Details . . . . . . . . . . 9
3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Network Access Identifier . . . . . . . . . . . . . . . . 12 3.4. Network Access Identifier . . . . . . . . . . . . . . . . 12
3.4.1. Using NAI for Location Configuration . . . . . . . . . 13 3.4.1. Using NAI for Location Configuration . . . . . . . . . 13
3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6. Fully Qualified Domain Name . . . . . . . . . . . . . . . 14 3.6. Fully Qualified Domain Name . . . . . . . . . . . . . . . 14
3.7. Cellular Telephony Identifiers . . . . . . . . . . . . . . 14 3.7. Cellular Telephony Identifiers . . . . . . . . . . . . . . 14
3.8. DHCP Unique Identifier . . . . . . . . . . . . . . . . . . 15 3.8. DHCP Unique Identifier . . . . . . . . . . . . . . . . . . 15
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15
4.1. Targets Requesting Their Own Location . . . . . . . . . . 16 4.1. Targets Requesting Their Own Location . . . . . . . . . . 16
4.2. Third Party Requests . . . . . . . . . . . . . . . . . . . 17 4.2. Third-Party Requests . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 18 5.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 18
5.2. Targets Requesting Their Own Location . . . . . . . . . . 19 5.2. Targets Requesting Their Own Location . . . . . . . . . . 18
5.3. Third Party Requests . . . . . . . . . . . . . . . . . . . 19 5.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 19
6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. URN Sub-Namespace Registration for 7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 23 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 21
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 23 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 22
7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 24 7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative references . . . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative references . . . . . . . . . . . . . . . . . . 28 9.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Protocols for requesting and providing location information require a Protocols for requesting and providing location information require a
way for the requestor to specify the location that should be way for the requestor to specify the location that should be
returned. In a Location Configuration Protocol (LCP), the location returned. In a Location Configuration Protocol (LCP), the location
being requested is the requestor's location. This fact can make the being requested is the requestor's location. This fact can make the
problem of identifying the Device simple, since IP datagrams that problem of identifying the Device simple, since IP datagrams that
carry the request already carry an identifier for the Device, namely carry the request already carry an identifier for the Device --
the source IP address of an incoming request. Existing LCPs, such as namely, the source IP address of an incoming request. Existing LCPs,
HTTP-Enabled Location Delivery (HELD) [RFC5985] and DHCP ([RFC3825], such as HTTP-Enabled Location Delivery (HELD) [RFC5985] and DHCP
[RFC4776]) rely on the source IP address or other information present ([RFC3825], [RFC4776]) rely on the source IP address or other
in protocol datagrams to identify a Device. information present in protocol datagrams to identify a Device.
Aside from the datagrams that form a request, a Location Information Aside from the datagrams that form a request, a Location Information
Server (LIS) does not necessarily have access to information that Server (LIS) does not necessarily have access to information that
could further identify the Device. In some circumstances, as shown could further identify the Device. In some circumstances, as shown
in [RFC5687], additional identification information can be included in [RFC5687], additional identification information can be included
in a request to identify a Device. in a request to identify a Device.
This document extends the HELD protocol to support the inclusion of This document extends the HELD protocol to support the inclusion of
additional identifiers for the Device in HELD location requests. An additional identifiers for the Device in HELD location requests. An
XML schema is defined that provides a structure for including these XML schema is defined that provides a structure for including these
skipping to change at page 4, line 38 skipping to change at page 4, line 38
An important characteristic of this addition is that the HELD An important characteristic of this addition is that the HELD
protocol with identity extensions implemented is not considered an protocol with identity extensions implemented is not considered an
LCP. The scope of an LCP is limited to the interaction between a 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 Device and a LIS, and LCPs can guarantee the identity of Devices
without additional authorization checks. A LIS identifies the Device without additional authorization checks. A LIS identifies the Device
making the LCP request using the source addressing on the request making the LCP request using the source addressing on the request
packets, using return routability to ensure that these identifiers packets, using return routability to ensure that these identifiers
are not spoofed. are not spoofed.
HELD with identity extensions allows a requester to explicitly HELD with identity extensions allows a requestor to explicitly
provide identification details in the body of a location request. provide identification details in the body of a location request.
This means that location requests can be made in cases where This means that location requests can be made in cases where
additional Device identity checks are necessary, and in cases where additional Device identity checks are necessary, and in cases where
the requester is not the Device itself. Third party Location the requestor is not the Device itself. Third-party Location
Recipients (LRs) are able to make requests that include identifiers Recipients (LRs) are able to make requests that include identifiers
to retrieve location information about a particular Device. to retrieve location information about a particular Device.
The usage of identifiers in HELD introduces a new set of privacy The usage of identifiers in HELD introduces a new set of privacy
concerns. In an LCP, the requester can be implicitly authorized to concerns. In an LCP, the requestor can be implicitly authorized to
access the requested location information, because it is their own access the requested location information, because it is their own
location. In contrast, a third party LR must be explicitly location. In contrast, a third-party LR must be explicitly
authorized when requesting the location of a Device. Establishing authorized when requesting the location of a Device. Establishing
appropriate authorization and other related privacy concerns are appropriate authorization and other related privacy concerns are
discussed in Section 4. discussed in Section 4.
1.1. Applications 1.1. Applications
This document defines a means to explicitly include Device identity This document defines a means to explicitly include Device identity
information in the body of a HELD location request. This identity information in the body of a HELD location request. This identity
information is used to identify the Device that is the subject (or information is used to identify the Device that is the subject (or
Target) of the location request. If device identity is present, the 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 identity of the requestor in the form of the source IP address is not
used to identify the subject of the request. used to identify the subject of the request.
Device identifiers in HELD can be used for two purposes: Device identifiers in HELD can be used for two purposes:
Location configuration: A Device can use these parameters to Location configuration: A Device can use these parameters to
identify itself to a LIS. Identification information other than identify itself to a LIS. Identification information other than
an IP address might be needed to determine the location of a an IP address might be needed to determine the location of a
Device. Device.
A LIS can authorize location configuration requests using a policy A LIS can authorize location configuration requests using a policy
that allows Devices to acquire their own location (see that allows Devices to acquire their own location (see
Section 4.1). If an unauthorized third party falsifies addressing Section 4.1). If an unauthorized third party falsifies addressing
on request packets to match the provided Device identity, the on request packets to match the provided Device identity, the
request might be erroneously authorized under this policy. request might be erroneously authorized under this policy.
Requests containing Device identity MUST NOT be authorized using Requests containing Device identity MUST NOT be authorized using
this policy unless specific measures are taken to prevent this this policy unless specific measures are taken to prevent this
type of attack. type of attack.
This document describes a mechanism that provides assurances that This document describes a mechanism that provides assurances that
the requester and included Device identity are the same for the the requestor and included Device identity are the same for the
Network Access Identifier (NAI) in a WiMAX network. The LIS MUST Network Access Identifier (NAI) in a WiMAX network. The LIS MUST
treat requests containing other identifiers as third party treat requests containing other identifiers as third-party
requests, unless it is able to ensure that the provided Device requests, unless it is able to ensure that the provided Device
identity is uniquely attributable to the requester. identity is uniquely attributable to the requestor.
Third party requests: A third party location recipient can be Third-party requests: A third-party Location Recipient can be
granted authorization to make requests for a given Device. In granted authorization to make requests for a given Device. In
particular, network services can be permitted to retrieve location particular, network services can be permitted to retrieve location
for a Device that is unable to acquire location information for for a Device that is unable to acquire location information for
itself (see Section 6.3 of [I-D.ietf-ecrit-phonebcp]). This itself (see Section 6.3 of [EMERGENCY-CALLING]). This allows use
allows use of location-dependent applications - particularly of location-dependent applications -- particularly essential
essential services like emergency calling - where Devices do not services like emergency calling -- where Devices do not support a
support a location configuration protocol or they are unable to location configuration protocol or they are unable to successfully
successfully retrieve location information. retrieve location information.
This document does not describe how a third party acquires an This document does not describe how a third party acquires an
identifier for a Device, nor how that third party is authorized by identifier for a Device, nor how that third party is authorized by
a LIS. It is critical that these issues are resolved before a LIS. It is critical that these issues are resolved before
permitting a third party request. A pre-arranged contract between permitting a third-party request. A pre-arranged contract between
the third party, a Rule Maker and the LIS operator is necessary to the third party, a Rule Maker, and the LIS operator is necessary
use Device identifiers in this fashion. This contract must to use Device identifiers in this fashion. This contract must
include how the request is authenticated and the set of include how the request is authenticated and the set of
identifiers (and types of identifiers) that the third party is identifiers (and types of identifiers) that the third party is
authorized to use in requests. authorized to use in requests.
Automated mechanisms to ensure privacy constraints are respected Automated mechanisms to ensure that privacy constraints are
are possible. For instance, a policy rules document could be used respected are possible. For instance, a policy rules document
to express the agreed policy. Formal policy documents, such as could be used to express the agreed policy. Formal policy
the common policy [RFC4745], can be applied in an automated documents, such as the common policy [RFC4745], can be applied in
fashion by a LIS. an automated fashion by a LIS.
1.2. Terminology 1.2. Terminology
This document uses the term Location Information Server (LIS) and This document uses the term Location Information Server (LIS) and
Location Configuration Protocol (LCP) as described in [RFC5687] and Location Configuration Protocol (LCP) as described in [RFC5687] and
[I-D.ietf-geopriv-arch]. [GEOPRIV-ARCH].
The term Device is used specifically as the subject of an LCP, The term Device is used specifically as the subject of an LCP,
consistent with [RFC5985]. This document also uses the term Target consistent with [RFC5985]. This document also uses the term Target
to refer to any entity that might be a subject of the same location 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 information. Target is used in a more general sense, including the
Device, but also any nearby entity, such as the user of a Device. 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 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 location information. A Rule Maker is the term used for the role
that makes policy decisions about authorization, determining what that makes policy decisions about authorization, determining what
entities are permitted to receive location and how that information entities are permitted to receive location and how that information
is provided. is provided.
Device, Target and Rule Maker are defined in [I-D.ietf-geopriv-arch]. Device, Target, and Rule Maker are defined in [GEOPRIV-ARCH].
The term "requester" is used in this document to refer to the entity The term "requestor" is used in this document to refer to the entity
making a HELD request. making a HELD request.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Device Identity 2. Device Identity
Identifiers are used as the starting point in location determination. Identifiers are used as the starting point in location determination.
Identifiers might be associated with a different Device over time, Identifiers might be associated with a different Device over time,
skipping to change at page 7, line 30 skipping to change at page 7, line 23
Some identifiers can be either temporary or could potentially Some identifiers can be either temporary or could potentially
identify multiple Devices. Identifiers that are transient or identify multiple Devices. Identifiers that are transient or
ambiguous could be exploited by an attacker to either gain ambiguous could be exploited by an attacker to either gain
information about another Device or to coerce the LIS into producing information about another Device or to coerce the LIS into producing
misleading information. misleading information.
The identifiers described in this document MUST only be used where The identifiers described in this document MUST only be used where
that identifier is used as the basis for location determination. that identifier is used as the basis for location determination.
Considerations relating to the use of identifiers for a Device Considerations relating to the use of identifiers for a Device
requesting its own location are discussed in Section 5 of [RFC5687]; requesting its own location are discussed in Section 5 of [RFC5687];
this section discusses use of identifiers for authorized third party this section discusses use of identifiers for authorized third-party
requests. requests.
It is tempting for a LIS implementation to allow alternative It is tempting for a LIS implementation to allow alternative
identifiers for convenience or some other perceived benefit. The identifiers for convenience or some other perceived benefit. The
LIS is responsible for ensuring that the identifier used in 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 request does not refer to a Device other than the one for which it
determines location. determines location.
Some identifiers are always uniquely attributable to a single Device. Some identifiers are always uniquely attributable to a single Device.
However, other identifiers can have a different meaning to different However, other identifiers can have a different meaning to different
entities on a network. This is especially true for IP addresses entities on a network. This is especially true for IP addresses
[RFC2101], but this can be true for other identifiers to varying [RFC2101], but this can be true for other identifiers to varying
degrees. Non-uniqueness arises from both topology (all network degrees. Non-uniqueness arises from both topology (all network
entities have a subjective view of the network) and time (the network entities have a subjective view of the network) and time (the network
changes over time). changes over time).
2.1.1. Subjective Network Views 2.1.1. Subjective Network Views
Subjective views of the network mean that the identifier a requester Subjective views of the network mean that the identifier a requestor
uses to refer to one physical entity could actually apply to a uses to refer to one physical entity could actually apply to a
different physical entity when used in a different network context. different physical entity when used in a different network context.
Unless an authorized third party requester and LIS operate in the Unless an authorized third-party requestor and LIS operate in the
same network context, each could have a different subjective view of same network context, each could have a different subjective view of
the meaning of the identifier. the meaning of the identifier.
Where subjective views differ, the third party receives information Where subjective views differ, the third party receives information
that is correct only within the network context of the LIS. The that is correct only within the network context of the LIS. The
location information provided by the LIS is probably misleading: the location information provided by the LIS is probably misleading: the
requester believes that the information relates to a different entity requestor believes that the information relates to a different entity
than it was generated for. than it was generated for.
Authorization policy can be affected by a subjective network view if Authorization policy can be affected by a subjective network view if
it is applied based on an identifier, or its application depends on it is applied based on an identifier or if its application depends on
identifiers. The subjective view presented to the LIS and Rule Maker identifiers. The subjective view presented to the LIS and Rule Maker
need to agree for the two entities to understand policy on the same 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 terms. For instance, it is possible that the LIS could apply the
incorrect authorization policy if it selects the policy using a incorrect authorization policy if it selects the policy using a
subjective identifier. Alternatively, it may use the correct policy subjective identifier. Alternatively, it may use the correct policy
but apply it incorrectly if subjective identifiers are used. but apply it incorrectly if subjective identifiers are used.
In IP networks, network address translation (NAT) and other forms In IP networks, network address translation (NAT) and other forms
of address modification create network contexts. Entities on of address modification create network contexts. Entities on
either side of the point where modification occurs have a either side of the point where modification occurs have a
different view of the network. Private use addresses [RFC1918] different view of the network. Private use addresses [RFC1918]
are the most easily recognizable identifiers that have limited are the most easily recognizable identifiers that have limited
scope. scope.
A LIS can be configured to recognize scenarios where the subjective 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 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 LIS. The LIS can either provide location information that takes
the view of the requester into account, or it can reject the request. 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 For instance, a LIS might operate within a network that uses a
private address space, with NAT between that network and other private address space, with NAT between that network and other
networks. A third party request that originates in an external networks. A third-party request that originates in an external
network with an IP address from the private address space might network with an IP address from the private address space might
not be valid - it could be identifying an entity within another not be valid -- it could be identifying an entity within another
address space. The LIS can be configured to reject such requests, address space. The LIS can be configured to reject such requests,
unless it knows by other means that the request is valid. unless it knows by other means that the request is valid.
In the same example, the requester might include an address from In the same example, the requestor might include an address from
the external space in an attempt to identify a host within the the external space in an attempt to identify a host within the
network. The LIS could use knowledge about how the external network. The LIS could use knowledge about how the external
address is mapped to a private address, if that mapping is fixed, address is mapped to a private address, if that mapping is fixed,
to determine an appropriate response. to determine an appropriate response.
The residential gateway scenario in Section 3.1 of [RFC5687] is a The residential gateway scenario in Section 3.1 of [RFC5687] is a
particular example of where a subjective view is permitted. The LIS particular example of where a subjective view is permitted. The LIS
knowingly provides Devices on the remote side of the residential knowingly provides Devices on the remote side of the residential
gateway with location information. The LIS provides location gateway with location information. The LIS provides location
information with appropriate uncertainty to allow for the fact that information with appropriate uncertainty to allow for the fact that
the residential gateway serves a small geographical area. the residential gateway serves a small geographical area.
2.1.2. Transient Identifiers 2.1.2. Transient Identifiers
Some identifiers are temporary and can, over the course of time, be Some identifiers are temporary and can, over the course of time, be
assigned to different physical entities. An identifier that is assigned to different physical entities. An identifier that is
reassigned between the time that a request is formulated by a reassigned between the time that a request is formulated by a
requester and when the request is received by the LIS causes the LIS requestor and when the request is received by the LIS causes the LIS
to locate a different entity than the requester intended. The to locate a different entity than the requestor intended. The
response from the LIS might be accurate, but the request incorrectly response from the LIS might be accurate, but the request incorrectly
associates this information with the wrong subject. associates this information with the wrong subject.
A LIS should be configured with information about any potentially A LIS should be configured with information about any potentially
temporary identifiers. It can use this information to identify when temporary identifiers. It can use this information to identify when
changes have occurred. A LIS must not provide location information changes have occurred. A LIS must not provide location information
if the identifier it uses might refer to a different Device. If an 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 identifier might have been reassigned recently, or it is likely to be
reassigned, it is not suitable as an identifier. reassigned, it is not suitable as an identifier.
It's possible that some degree of uncertainty could persist where It's possible that some degree of uncertainty could persist where
identifiers are reassigned frequently; the extent to which errors identifiers are reassigned frequently; the extent to which errors
arising from using transient identifiers are tolerated is a matter arising from using transient identifiers are tolerated is a matter
for local policy. 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 2.2. Identifier Format and Protocol Details
XML elements are used to express the Device identity. The "device" XML elements are used to express the Device identity. The "device"
element is used as a general container for identity information. element is used as a general container for identity information.
This document defines a basic set of identifiers. An example HELD This document defines a basic set of identifiers. An example HELD
request, shown in Figure 1, includes an IP version 4 address. request, shown in Figure 1, includes an IP version 4 address.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8"> responseTime="8">
<locationType exact="true">geodetic</locationType> <locationType exact="true">geodetic</locationType>
skipping to change at page 10, line 5 skipping to change at page 10, line 21
</locationRequest> </locationRequest>
Figure 1: HELD Request with Device Identity Figure 1: HELD Request with Device Identity
A LIS that supports this specification echoes the "device" element in A LIS that supports this specification echoes the "device" element in
a successful HELD response, including the identifiers that were used a successful HELD response, including the identifiers that were used
as the basis for location determination. Absence of this indication as the basis for location determination. Absence of this indication
means that the location information was generated using the source IP means that the location information was generated using the source IP
address in the request. address in the request.
A "badIdentifier" HELD error code indicates that the requester is not A "badIdentifier" HELD error code indicates that the requestor is not
authorized to use that identifier or that the request contains an authorized to use that identifier or that the request contains an
identifier that is badly formatted or not supported by the LIS. This identifier that is badly formatted or not supported by the LIS. This
code is registered in Section 7.3. code is registered in Section 7.3.
If the LIS requires an identifier that is not provided in the If the LIS requires an identifier that is not provided in the
request, the desired identifiers MAY be identified in the HELD error request, the desired identifiers MAY be identified in the HELD error
response, using the "requiredIdentifiers" element. This element response, using the "requiredIdentifiers" element. This element
contains a list of XML qualified names [W3C.REC-xml-names11-20060816] contains a list of XML qualified names [W3C.REC-xml-names11-20060816]
that identify the identifier elements required by the LIS. Namespace that identify the identifier elements required by the LIS. Namespace
prefix bindings for the qualified names are taken from document prefix bindings for the qualified names are taken from document
context. Figure 2 shows an example error indicating that the context. Figure 2 shows an example error indicating that the
requester needs to include a MAC address (Section 3.2) and IP address requestor needs to include a media access control (MAC) address
(Section 3.1) if the request is to succeed. (Section 3.2) and IP address (Section 3.1) if the request is to
succeed.
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="badIdentifier"> code="badIdentifier">
<message xml:lang="en">MAC address required</message> <message xml:lang="en">MAC address required</message>
<requiredIdentifiers <requiredIdentifiers
xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
mac ip mac ip
</requiredIdentifiers> </requiredIdentifiers>
</error> </error>
Figure 2: HELD Error Requesting Device Identifiers Figure 2: HELD Error Requesting Device Identifiers
3. Identifiers 3. Identifiers
A limited selection of identifiers are included in this document. A limited selection of identifiers are included in this document.
The basic Device identity schema allows for the inclusion of elements The basic Device identity schema allows for the inclusion of elements
from any namespace, therefore additional elements can be defined from any namespace; therefore, additional elements can be defined
using different XML namespaces. using different XML namespaces.
3.1. IP Address 3.1. IP Address
The "ip" element can express a Device identity as an IP address The "ip" element can express a Device identity as an IP address
([RFC0791], [RFC4291]). The "v" attribute identifies the IP version ([RFC0791], [RFC4291]). The "v" attribute identifies the IP version
with a single hexadecimal digit. The element uses the textual format with a single hexadecimal digit. The element uses the textual format
specific to the indicated IP version. The textual format for IP specific to the indicated IP version. The textual format for IP
version 4 and version 6 addresses MUST conform to the grammar defined version 4 and version 6 addresses MUST conform to the grammar defined
in [RFC3986] ("IPv4address" and "IPv6address" respectively). 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"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="6">2001:db8::1:ea7:fee1:d1e</ip> <ip v="6">2001:db8::1:ea7:fee1:d1e</ip>
</device> </device>
In situations where location configuration does not require In situations where location configuration does not require
additional identifiers, using IP address as an identifier enables additional identifiers, using an IP address as an identifier enables
authorized third party requests. authorized third-party requests.
3.2. MAC Address 3.2. MAC Address
The media access control (MAC) address used by the IEEE 802 family of The MAC address used by network interfaces attached to the IEEE LAN
access technologies is an identifier that is assigned to a particular [IEEE802]. A MAC address is a unique sequence that is either
network Device. A MAC address is a unique sequence that is either assigned at the time of manufacture of the interface, or assigned by
assigned at the time of manufacture of a Device, or assigned by a a local administrator. A MAC address is an appropriate identifier
local administrator. A MAC address rarely changes; therefore, a MAC for the Device that uses the network interface as long as the two
address is an appropriate identifier for a Device. remain together (see Section 2.1.3).
A MAC address can be represented as MAC-48, EUI-48 or EUI-64 address A MAC address can be represented as a MAC-48, EUI-48, or EUI-64
([IEEE802], or extended unique identifier [EUI64]) using the address ([IEEE802], or an extended unique identifier [EUI64]) using
hexadecimal representation defined in [IEEE802]. the hexadecimal representation defined in [IEEE802].
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<mac>A0-12-34-56-78-90</mac> <mac>A0-12-34-56-78-90</mac>
</device> </device>
A locally-assigned MAC address is not guaranteed to be unique outside A locally assigned MAC address is not guaranteed to be unique outside
the administrative domain where it is assigned. Locally-assigned MAC the administrative domain where it is assigned. Locally assigned MAC
addresses can only be used within this domain. addresses can only be used within this domain.
3.3. Port Numbers 3.3. Port Numbers
A host might only be known by a flow of packets that it is sending or 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 receiving. On its own, a port number is insufficient to uniquely
identify a single host. In combination with an IP address, a port identify a single host. In combination with an IP address, a port
number can be used to uniquely identify a Device in some number can be used to uniquely identify a Device in some
circumstances. circumstances.
Use of a particular port number can be transient; often significantly Use of a particular port number can be transient; often significantly
more than use of any given IP address. However, widespread use of more than use of any given IP address. However, widespread use of
network address translation (NAT) means that some Devices cannot be network address translation (NAT) means that some Devices cannot be
uniquely identified by IP address alone. An individual Device might uniquely identified by IP address alone. An individual Device might
be identified by a flow of packets that it generates. Providing that 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 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 individual target on the remote side of the NAT might be able to be
identified uniquely. identified uniquely.
Port numbers are defined for UCP [RFC0768], TCP [RFC0793], SCTP Port numbers are defined for UDP [RFC0768], TCP [RFC0793], SCTP
[RFC4960] and DCCP [RFC4340]. [RFC4960], and DCCP [RFC4340].
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="4">192.0.2.75</ip> <ip v="4">192.0.2.75</ip>
<udpport>51393</udpport> <udpport>51393</udpport>
</device> </device>
Use of port numbers is especially reliant on the value remaining Use of port numbers is especially reliant on the value remaining
consistent over time. consistent over time.
3.4. Network Access Identifier 3.4. Network Access Identifier
skipping to change at page 13, line 29 skipping to change at page 13, line 29
one time. An NAI either identifies a Device or a service one time. An NAI either identifies a Device or a service
subscription, neither of which can have multiple active sessions. subscription, neither of which can have multiple active sessions.
In a WiMAX network, an IP address is not sufficient information for a 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 LIS to locate a Device. The following procedure relies on an NAI to
identify the Device. This procedure and the messages and parameters identify the Device. This procedure and the messages and parameters
is relies upon are defined in [WiMAX-T33-110-R015v01-B]. is relies upon are defined in [WiMAX-T33-110-R015v01-B].
Location requests in a WiMAX network always require the inclusion of 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 NAI. However, if a LIS receives a request that does not come from
an authenticated and authorized third party requester, it can treat an authenticated and authorized third-party requestor, it can treat
this request as a location configuration request. this request as a location configuration request.
After receiving a location request that includes an NAI, the LIS After receiving a location request that includes an NAI, the LIS
sends a "Location-Requestor-Authentication-Protocol" access request sends a "Location-Requestor-Authentication-Protocol" access request
message to the Authentication, Authorization and Accounting (AAA) message to the Authentication, Authorization, and Accounting (AAA)
server. This request includes an "MS-Identity-Assertion" parameter server. This request includes an "MS-Identity-Assertion" parameter
containing the NAI. containing the NAI.
The AAA server consults network policy and if the request is The AAA server consults network policy, and if the request is
permitted, the response includes the IP address that is currently permitted, the response includes the IP address that is currently
assigned to the Device. If this IP address matches the source IP assigned to the Device. If this IP address matches the source IP
address of the HELD location request, the location request can be address of the HELD location request, the location request can be
authorized under the LCP policy (see Section 4.1). Otherwise, the authorized under the LCP policy (see Section 4.1). Otherwise, the
request must be treated as a third party request. request must be treated as a third-party request.
This relies on the same IP address spoofing protections that are This relies on the same protections against IP address spoofing that
required by [RFC5985]. In addition, the request made of the AAA uses are required by [RFC5985]. In addition, the request made of the AAA
either Diameter [RFC3588] or RADIUS [RFC2865], and therefore relies uses either Diameter [RFC3588] or RADIUS [RFC2865], and therefore
on the protections provided by those protocols. In order to rely on relies on the protections provided by those protocols. In order to
the access request, the AAA server MUST be authenticated to be a rely on the access request, the AAA server MUST be authenticated to
trusted entity for the purpose of providing a link between the NAI be a trusted entity for the purpose of providing a link between the
and IP address. The AAA protocol MUST also provide protection from NAI and IP address. The AAA protocol MUST also provide protection
modification and replay attacks to ensure that data cannot be altered from modification and replay attacks to ensure that data cannot be
by an attacker. altered by an attacker.
3.5. URI 3.5. URI
A Device can be identified by a URI [RFC3986]. Any URI can be used 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 providing that the requestor and LIS have a common understanding of
the semantics implied by use of the URI. the semantics implied by use of the URI.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>sip:user@example.net;gr=kjh29x97us97d</uri> <uri>sip:user@example.net;gr=kjh29x97us97d</uri>
</device> </device>
Particular care needs to be taken in ensuring that a particular URI 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 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 multiple destinations. For example, a SIP address of record URI can
correspond to a service subscription rather than a single Device. correspond to a service subscription rather than a single Device.
A "tel:" URI [RFC3966] can be used identify a Device by telephone A "tel:" URI [RFC3966] can be used to identify a Device by telephone
number: number:
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>tel:800-555-1111;extension=1234;phone-context=+1</uri> <uri>tel:800-555-1111;extension=1234;phone-context=+1</uri>
</device> </device>
3.6. Fully Qualified Domain Name 3.6. Fully Qualified Domain Name
A fully-qualified domain name can be used as the basis for A fully qualified domain name can be used as the basis for
identification using the "fqdn" element. identification using the "fqdn" element.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<fqdn>host.example.net</fqdn> <fqdn>host.example.net</fqdn>
</device> </device>
This IDN-aware domain name slot [RFC5890] is formed from any sequence This domain name slot, which is aware of Internationalized Domain
Names for Applications (IDNA) [RFC5890], is formed from any sequence
of valid U-labels or NR-LDH-labels. of valid U-labels or NR-LDH-labels.
A domain name does not always correspond to a single IP address or 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 host. If this is the case, a domain name is not a suitable
identifier. identifier.
3.7. Cellular Telephony Identifiers 3.7. Cellular Telephony Identifiers
A range of different forms of mobile station identifiers are used for A range of different forms of mobile station identifiers are used for
different cellular telephony systems. Elements are defined for these different cellular telephony systems. Elements are defined for these
identifiers. The following identifiers are defined: identifiers. The following identifiers are defined:
msisdn: The Mobile Station International Subscriber Dial Number msisdn: The Mobile Station International Subscriber Dial Number
(MSISDN) [E.213] is an E.164 number [E.164] between 6 and 15 (MSISDN) [E.213] is an E.164 number [E.164] between 6 and 15
digits long. digits long.
imsi: The International Mobile Subscriber Identity (IMSI) imsi: The International Mobile Subscriber Identity (IMSI)
[TS.3GPP.23.003] an identifier associated with all GSM and UMTS [TS.3GPP.23.003] is an identifier associated with all GSM (Global
mobile subscribers. System for Mobile Communications) and UMTS (Universal Mobile
Telecommunications System) mobile subscribers between 6 and 15
digits in length.
imei: The International Mobile Equipment Identifier (IMEI) imei: The International Mobile Equipment Identifier (IMEI)
[TS.3GPP.23.003] is a unique device serial number up to 15 digits [TS.3GPP.23.003] is a unique device serial number up to 15 digits
long. long.
min: The Mobile Identification Number (MIN) [TIA.EIA.IS-2000-6] is a min: The Mobile Identification Number (MIN) [TIA.EIA.IS-2000-6] is a
unique number assigned to CDMA handsets. 10-digit unique number assigned to CDMA handsets.
mdn: The Mobile Directory Number (MDN) is an E.164 number [E.164], mdn: The Mobile Directory Number (MDN) is an E.164 number [E.164],
with usage similar to MSISDN. with usage similar to MSISDN.
Each identifier contains a string of decimal digits with a length as Each identifier contains a string of decimal digits with a length as
specified. specified.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<msisdn>11235550123</msisdn> <msisdn>11235550123</msisdn>
</device> </device>
skipping to change at page 16, line 10 skipping to change at page 15, line 50
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<duid>1234567890AaBbCcDdEeFf</duid> <duid>1234567890AaBbCcDdEeFf</duid>
</device> </device>
4. Privacy Considerations 4. Privacy Considerations
Location configuration protocols can make use of an authorization Location configuration protocols can make use of an authorization
model known as "LCP policy", which permits only Targets to be the model known as "LCP policy", which permits only Targets to be the
recipients of their own locations. In effect, an LCP server (that 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 LIS) follows a single-rule policy that states that the Target
is the only authorized Location Recipient. is the only authorized Location Recipient.
The security and privacy considerations of the base HELD protocol The security and privacy considerations of the base HELD protocol
[RFC5985] are applicable. However, the considerations relating to [RFC5985] are applicable. However, the considerations relating to
return routability do not apply to third party requests. Return return routability do not apply to third-party requests. Return
routability may also not apply to requests from Targets for their own routability may also not apply to requests from Targets for their own
location depending on the anti-spoofing mechanisms employed for the location, depending on the anti-spoofing mechanisms employed for the
identifier. identifier.
4.1. Targets Requesting Their Own Location 4.1. Targets Requesting Their Own Location
When a Target uses identity extensions to obtain its own location, When a Target uses identity extensions to obtain its own location,
HELD can no longer be considered an LCP. The authorization policy HELD can no longer be considered an LCP. The authorization policy
that the LIS uses to respond to these requests must be provisioned by that the LIS uses to respond to these requests must be provisioned by
one or more Rule Makers. one or more Rule Makers.
In the case that the LIS exclusively provides Targets with their own In the case that the LIS exclusively provides Targets with their own
locations, the LIS can still be said to be following the "LCP locations, the LIS can still be said to be following the "LCP
policy". The "LCP policy" concept and further security and privacy policy". The "LCP policy" concept and further security and privacy
considerations can be found in [I-D.ietf-geopriv-arch]. considerations can be found in [GEOPRIV-ARCH].
The spoofing protections provided when using HELD with identity The spoofing protections provided when using HELD with identity
extensions to provide Targets with their own locations differ from extensions to provide Targets with their own locations differ from
the protections inherent in an LCP. For an LCP, return routability the protections inherent in an LCP. For an LCP, return routability
is considered sufficient protection against spoofing. For a similar is considered sufficient protection against spoofing. For a similar
policy to be used, specific measures MUST be defined to protect policy to be used, specific measures MUST be defined to protect
against spoofing of the alternative identifier. This document against spoofing of the alternative identifier. This document
defines this for an NAI when used in WiMAX networks (see defines this for an NAI when used in WiMAX networks (see
Section 3.4.1), but for no other identifier. Section 3.4.1), but for no other identifier.
A Rule Maker might require an assurance that the identifier is owned A Rule Maker might require an assurance that the identifier is owned
by the requester. Any multi-stage verification process that includes by the requestor. Any multi-stage verification process that includes
a return routability test cannot provide any stronger assurance than a return routability test cannot provide any stronger assurance than
return routability alone; therefore, policy might require the use of return routability alone; therefore, policy might require the use of
additional, independent methods of verification. additional, independent methods of verification.
Care is required where a direct one-to-one relationship between Care is required where a direct one-to-one relationship between
requester and Device identity does not exist. If identifiers are not requestor and Device identity does not exist. If identifiers are not
uniquely attributable to a single Device, the use of HELD identity uniquely attributable to a single Device, the use of HELD identity
extensions to provide Targets with their own locations could be extensions to provide Targets with their own locations could be
exploited by an attacker. exploited by an attacker.
It might be possible in some networks to establish multiple It might be possible in some networks to establish multiple
concurrent sessions using the same credentials. For instance, concurrent sessions using the same credentials. For instance,
Devices with different MAC addresses might be granted concurrent Devices with different MAC addresses might be granted concurrent
access to a network using the same NAI. It is not appropriate to access to a network using the same NAI. It is not appropriate to
provide Targets with their own locations based on NAI in this provide Targets with their own locations based on the NAI in this
case. Neither is it appropriate to authenticate a Device using case. Neither is it appropriate to authenticate a Device using
NAI and allow that Device to provide an unauthenticated MAC NAI and allow that Device to provide an unauthenticated MAC
address as a Device identifier, even if the MAC address is address as a Device identifier, even if the MAC address is
registered to the NAI. The MAC address potentially identifies a registered to the NAI. The MAC address potentially identifies a
different Device to the one that is making the request. The different Device than the one that is making the request. The
correct way of gaining authorization is to establish a policy that correct way of gaining authorization is to establish a policy that
permits this particular request as a third party request. permits this particular request as a third-party request.
Section 3.4.1 discusses the implications of using an NAI as an Section 3.4.1 discusses the implications of using an NAI as an
identifier for location requests made of a LIS serving a WiMAX identifier for location requests made of a LIS serving a WiMAX
network. Additional security considerations are discussed in network. Additional security considerations are discussed in
[WiMAX-T33-110-R015v01-B]. [WiMAX-T33-110-R015v01-B].
4.2. Third Party Requests 4.2. Third-Party Requests
The "LCP policy" does not allow requests made by third parties. If a The "LCP policy" does not allow requests made by third parties. If a
LIS permits requests from third parties using Device identity, it LIS permits requests from third parties using Device identity, it
assumes the rule of a Location Server (LS). As a Location Server, assumes the rule of a Location Server (LS). As a Location Server,
the LIS MUST explicitly authorize requests according to the policies the LIS MUST explicitly authorize requests according to the policies
that are provided by Rule Makers, including the Target. The LIS MUST that are provided by Rule Makers, including the Target. The LIS MUST
also authenticate requesters according to any agreed-upon also authenticate requestors according to any agreed-upon
authorization policy. authorization policy.
An organization that provides a LIS that allows third party requests An organization that provides a LIS that allows third-party requests
must provide a means for a Rule Maker to specify authorization must provide a means for a Rule Maker to specify authorization
policies as part of the LIS implementation (e.g, in the form of policies as part of the LIS implementation (e.g, in the form of
access control lists). Authorization must be established before access control lists). Authorization must be established before
allowing third party requests for the location of any Target. Until allowing third-party requests for the location of any Target. Until
an authorization policy is established, the LIS MUST reject requests an authorization policy is established, the LIS MUST reject requests
by third parties (that is, the default policy is "deny all"). by third parties (that is, the default policy is "deny all").
When the LIS is operated by an access network, the relationship 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 between the Target and the LIS can be transient. As the Target is a
potential Rule Maker, this presents a problem. However, the process potential Rule Maker, this presents a problem. However, the process
of establishing network access usually results in a form of agreement of establishing network access usually results in a form of agreement
between the Target and the network provider. This process offers a between the Target and the network provider. This process offers a
natural vehicle for establishing location privacy policies. natural vehicle for establishing location privacy policies.
Establishing authorization policy might be a manual process, an Establishing authorization policy might be a manual process, an
explicit part of the terms of service for the network, or an explicit part of the terms of service for the network, or an
automated system that accepts formal authorization policies (see automated system that accepts formal authorization policies (see
[RFC4745], [RFC4825]). This document does not mandate any particular [RFC4745] and [RFC4825]). This document does not mandate any
mechanism for establishing an authorization policy. particular mechanism for establishing an authorization policy.
5. Security Considerations 5. Security Considerations
The security considerations in [RFC5985] describe the use of The security considerations in [RFC5985] describe the use of
Transport Layer Security (TLS) [RFC5246] for server authentication, Transport Layer Security (TLS) [RFC5246] for server authentication,
confidentiality and protection from modification. These protections confidentiality, and protection from modification. These protections
apply to both Target requests for their own locations and requests apply to both Target requests for their own locations and requests
made by third parties. made by third parties.
All HELD requests containing identity MUST be authenticated by the All HELD requests containing identity MUST be authenticated by the
LIS. How authentication is accomplished and what assurances are LIS. How authentication is accomplished and what assurances are
desired is a matter for policy. desired is a matter for policy.
The base HELD protocol uses return reachability of an IP address The base HELD protocol uses return reachability of an IP address
implied by the requester being able to successfully complete a TCP implied by the requestor being able to successfully complete a TCP
handshake. It is RECOMMENDED that any means of authentication handshake. It is RECOMMENDED that any means of authentication
provide at least this degree of assurance. For requests that include provide at least this degree of assurance. For requests that include
Device identity, the requester MUST support HTTP digest Device identity, the requestor MUST support HTTP digest
authentication [RFC2617]. Unauthenticated location requests authentication [RFC2617]. Unauthenticated location requests
containing Device identity can be challenged with an HTTP 401 containing Device identity can be challenged with an HTTP 401
(Unauthorized) response or rejected with an HTTP 403 (Forbidden) (Unauthorized) response or rejected with an HTTP 403 (Forbidden)
response. response.
Note that HELD [RFC5985] does not mandate that Devices implement HELD [RFC5985] does not mandate that Devices implement
authentication. A LIS SHOULD NOT send a HTTP 401 response if the authentication. A LIS SHOULD NOT send a HTTP 401 response if the
Device does not include Device identity. Device does not include Device identity.
5.1. Identifier Suitability 5.1. Identifier Suitability
Transient and ambiguous identifiers can be exploited by malicious Transient and ambiguous identifiers can be exploited by malicious
requests and are not suitable as a basis for identifying a Device. requests and are not suitable as a basis for identifying a Device.
Section 2.1 provides further discussion on this subject. Section 2.1 provides further discussion on this subject.
Identifier transience can lead to incorrect location information Identifier transience can lead to incorrect location information
being provided. An attacker could exploit the use of transient being provided. An attacker could exploit the use of transient
identifiers. In this attack, the attacker either knows of a re- identifiers. In this attack, the attacker either knows of a
allocation of that identifier or is able to force the identifier to re-allocation of that identifier or is able to force the identifier
be re-allocated during the processing of the request. to be re-allocated during the processing of the request.
An attacker could use this to acquire location information for 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- another Device or to coerce the LIS to lie on its behalf if this
allocation occurs between the time where authorization is granted and re-allocation occurs between the time where authorization is granted
location information is granted. and location information is granted.
Ambiguous identifiers present a similar problem. An attacker could Ambiguous identifiers present a similar problem. An attacker could
legitimately gain authorization to use a particular identifier. legitimately gain authorization to use a particular identifier.
Since an ambiguous identifier potentially refers to multiple Devices, Since an ambiguous identifier potentially refers to multiple Devices,
if authorization is granted for one of those Devices, an attacker if authorization is granted for one of those Devices, an attacker
potentially gains access to location information for all of those potentially gains access to location information for all of those
Devices. Devices.
5.2. Targets Requesting Their Own Location 5.2. Targets Requesting Their Own Location
skipping to change at page 19, line 20 skipping to change at page 19, line 12
authorized under a policy similar to the "LCP policy" that permits a authorized under a policy similar to the "LCP policy" that permits a
Target access to location information about itself. Target access to location information about itself.
Identity information provided by the Device is private data that Identity information provided by the Device is private data that
might be sensitive. The Device provides this information in the might be sensitive. The Device provides this information in the
expectation that it assists the LIS in providing the Device a expectation that it assists the LIS in providing the Device a
service. The LIS MUST NOT use identity information for any other service. The LIS MUST NOT use identity information for any other
purpose other than serving the request that includes that purpose other than serving the request that includes that
information. information.
5.3. Third Party Requests 5.3. Third-Party Requests
Requests from third parties have the same requirements for server Requests from third parties have the same requirements for server
authentication, confidentiality and protection from modification as authentication, confidentiality, and protection from modification as
Target requests for their own locations. However, because the third Target requests for their own locations. However, because the third
party needs to be authorized, the requester MUST be authenticated by party needs to be authorized, the requestor MUST be authenticated by
the LIS. In addition, third party requests MUST be explicitly the LIS. In addition, third-party requests MUST be explicitly
authorized by a policy that is established by a Rule Maker. authorized by a policy that is established by a Rule Maker.
More detail on the privacy implications of third party requests are More detail on the privacy implications of third-party requests are
covered in Section 4. covered in Section 4.
6. XML Schema 6. XML Schema
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id" targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:id="urn:ietf:params:xml:ns:geopriv:held:id" xmlns:id="urn:ietf:params:xml:ns:geopriv:held:id"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:appinfo <xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:id"> source="urn:ietf:params:xml:schema:geopriv:held:id">
HELD Device Identity HELD Device Identity
</xs:appinfo> </xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of source="http://www.rfc-editor.org/rfc/rfc6155.txt">
published RFC and remove this note.]] --> This document defines Device identity elements for HELD.
This document defines Device identity elements for HELD. </xs:documentation>
</xs:documentation> </xs:annotation>
</xs:annotation>
<xs:element name="device" type="id:deviceIdentity"/> <xs:element name="device" type="id:deviceIdentity"/>
<xs:complexType name="deviceIdentity"> <xs:complexType name="deviceIdentity">
<xs:sequence> <xs:sequence>
<xs:any namespace="##any" processContents="lax" <xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:element name="requiredIdentifiers" type="id:qnameList"/> <xs:element name="requiredIdentifiers" type="id:qnameList"/>
<xs:simpleType name="qnameList"> <xs:simpleType name="qnameList">
<xs:list itemType="xs:QName"/> <xs:list itemType="xs:QName"/>
</xs:simpleType> </xs:simpleType>
<xs:element name="ip" type="id:ipAddress"/> <xs:element name="ip" type="id:ipAddress"/>
<xs:complexType name="ipAddress"> <xs:complexType name="ipAddress">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:token"> <xs:extension base="xs:token">
<xs:attribute name="v" use="required"> <xs:attribute name="v" use="required">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="[\da-fA-F]"/> <xs:pattern value="[\da-fA-F]"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </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="mac" type="id:macAddress"/>
<xs:element name="tcpport" type="id:portNumber"/> <xs:simpleType name="macAddress">
<xs:element name="sctpport" type="id:portNumber"/> <xs:restriction base="xs:token">
<xs:element name="dccpport" type="id:portNumber"/> <xs:pattern
<xs:simpleType name="portNumber"> value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
<xs:restriction base="xs:nonNegativeInteger"> </xs:restriction>
<xs:maxInclusive value="65535"/> </xs:simpleType>
</xs:restriction>
</xs:simpleType>
<xs:element name="nai" type="id:naiType"/> <xs:element name="udpport" type="id:portNumber"/>
<xs:simpleType name="naiType"> <xs:element name="tcpport" type="id:portNumber"/>
<xs:restriction base="xs:token"> <xs:element name="sctpport" type="id:portNumber"/>
<xs:pattern <xs:element name="dccpport" type="id:portNumber"/>
value="([^\\]|\\[\dA-Fa-f]{2})* <xs:simpleType name="portNumber">
(@([A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*\.)+ <xs:restriction base="xs:nonNegativeInteger">
[A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*)?"/> <xs:maxInclusive value="65535"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:element name="uri" type="xs:anyURI"/> <xs:element name="nai" type="id:naiType"/>
<xs:element name="fqdn" type="xs:token"/> <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="duid" type="xs:hexBinary"/> <xs:element name="uri" type="xs:anyURI"/>
<xs:element name="fqdn" type="xs:token"/>
<xs:element name="msisdn" type="id:e164"/> <xs:element name="duid" type="xs:hexBinary"/>
<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> <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 7. IANA Considerations
This document registers an XML namespace and schema with IANA in This document registers an XML namespace and schema with IANA in
accordance with guidelines in [RFC3688]. accordance with guidelines in [RFC3688].
7.1. URN Sub-Namespace Registration for 7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id urn:ietf:params:xml:ns:geopriv:held:id
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held:id URI: urn:ietf:params:xml:ns:geopriv:held:id
Registrant Contact: IETF, GEOPRIV working group Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
(geopriv@ietf.org), James Winterbottom James Winterbottom (james.winterbottom@andrew.com).
(james.winterbottom@andrew.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>HELD Device Identity Parameters</title> <title>HELD Device Identity Parameters</title>
</head> </head>
<body> <body>
<h1>Namespace for HELD Device Identity Parameters</h1> <h1>Namespace for HELD Device Identity Parameters</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:id</h2> <h2>urn:ietf:params:xml:ns:geopriv:held:id</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc6155.txt">
with the RFC number for this specification.]] RFC 6155</a>.</p>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p> </body>
</body> </html>
</html> END
END
7.2. XML Schema Registration 7.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held:id URI: urn:ietf:params:xml:schema:geopriv:held:id
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
James Winterbottom (james.winterbottom@andrew.com). James Winterbottom (james.winterbottom@andrew.com).
Schema: The XML for this schema can be found as the entirety of Schema: The XML for this schema can be found as the entirety of
Section 6 of this document. [IANA Note: The pattern attribute for Section 6 of this document.
naiType does not contain whitespace.]
7.3. Registration of HELD 'badIdentifier' Error Code 7.3. Registration of HELD 'badIdentifier' Error Code
This section registers the "badIdentifier" error code in the "Geopriv This section registers the "badIdentifier" error code in the IANA
HELD Registries, Error codes for HELD" IANA registry. 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 badIdentifier This error code indicates that a Device identifier
used in the HELD request was either: not supported by the LIS, used in the HELD request was either: not supported by the LIS,
badly formatted, or not one for which the requester was authorized badly formatted, or not one for which the requestor was authorized
to make a request. to make a request.
8. Acknowledgements 8. Acknowledgements
The the NENA VoIP location working group provided assistance in the The National Emergency Number Association (NENA) VoIP location
definition of the schema used in this document. Special thanks go to working group provided assistance in the definition of the schema
Barbara Stark, Guy Caron, Nadine Abbott, Jerome Grenier and Martin used in this document. Special thanks go to Barbara Stark, Guy
Dawson. Bob Sherry provided input on use of URIs. Thanks to Adam Caron, Nadine Abbott, Jerome Grenier, and Martin Dawson. Bob Sherry
Muhlbauer and Eddy Corbett for providing further corrections. provided input on use of URIs. Thanks to Adam Muhlbauer and Eddy
Bernard Aboba provided excellent feedback on use cases and the Corbett for providing further corrections. Bernard Aboba provided
security model; Bernard, along with Alan DeKok, also helped resolve excellent feedback on use cases and the security model; Bernard,
an issue with NAIs. Ray Bellis provided motivation for the protocol along with Alan DeKok, also helped resolve an issue with NAIs. Ray
port parameters. Marc Linsner and Alissa Cooper provided guidance Bellis provided motivation for the protocol port parameters. Marc
and text (respectively) that greatly clarified the discussion Linsner and Alissa Cooper provided guidance and text (respectively)
relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for that greatly clarified the discussion relating to LCPs. Thanks to
forcing this to be practical. Jon Peterson and Cullen Jennings for forcing this to be practical.
9. References 9. References
9.1. Normative references 9.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
skipping to change at page 27, line 23 skipping to change at page 24, line 33
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010. RFC 5985, September 2010.
[W3C.REC-xml-names11-20060816] [W3C.REC-xml-names11-20060816]
Hollander, D., Bray, T., Layman, A., and R. Tobin, Hollander, D., Tobin, R., Layman, A., and T. Bray,
"Namespaces in XML 1.1 (Second Edition)", World Wide Web "Namespaces in XML 1.1 (Second Edition)", World Wide Web
Consortium Recommendation REC-xml-names11-20060816, Consortium Recommendation REC-xml-names11-20060816,
August 2006, August 2006,
<http://www.w3.org/TR/2006/REC-xml-names11-20060816>. <http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", 802, February 2002. Networks: Overview and Architecture", IEEE 802,
February 2002.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority", March 1997, <http:// Registration Authority", March 1997,
standards.ieee.org/regauth/oui/tutorials/EUI64.html>. <http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html>.
[E.164] ITU-T, "E.164 : The international public telecommunication [E.164] ITU-T, "E.164 : The international public telecommunication
numbering plan", ITU-T Recommendation E.164, numbering plan", ITU-T Recommendation E.164,
February 2005. 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 [E.213] ITU-T, "E.213 : Telephone and ISDN numbering plan for land
mobile stations in public land mobile networks (PLMN)", mobile stations in public land mobile networks (PLMN)",
ITU-T Recommendation E.213, November 1988. ITU-T Recommendation E.213, November 1988,
<http://www.itu.int/rec/T-REC-E.213-198811-I/en>.
[TS.3GPP.23.003] [TS.3GPP.23.003]
3GPP, "Numbering, addressing and identification", 3GPP 3GPP, "Numbering, addressing and identification", 3GPP
TS 23.003 9.4.0, September 2010. 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.IS-2000-6]
TIA/EIA, "Analog Signaling Standard for CDMA 2000 Spread TIA/EIA, "Analog Signaling Standard for CDMA 2000 Spread
Spectrum Systems", TIA/EIA/IS-2000-6-C, May 2002. Spectrum Systems", TIA/EIA/IS-2000-6-C, May 2002.
[WiMAX-T33-110-R015v01-B] [WiMAX-T33-110-R015v01-B]
WiMAX Forum, "Protocols and Procedures for Location Based WiMAX Forum, "Protocols and Procedures for Location Based
Services", WiMAX Forum Network Architecture T33-110- Services", WiMAX Forum Network Architecture T33-110-
R015v01-B, May 2009. R015v01-B, May 2009.
9.2. Informative references [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.
9.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, February 1997. Address Behaviour Today", RFC 2101, February 1997.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Configuration Protocol Option for Coordinate-based
skipping to change at page 28, line 43 skipping to change at page 26, line 15
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol: Problem Statement and Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010. Requirements", RFC 5687, March 2010.
[I-D.ietf-geopriv-arch] [GEOPRIV-ARCH]
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-03 (work in progress), Work in Progress, October 2010.
October 2010.
[I-D.ietf-ecrit-phonebcp] [EMERGENCY-CALLING]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-16 (work in progress), Work in Progress, October 2010.
October 2010.
Authors' Addresses Authors' Addresses
James Winterbottom James Winterbottom
Andrew Corporation Andrew Corporation
Andrew Building (39) Andrew Building (39)
Wollongong University Campus Wollongong University Campus
Northfields Avenue Northfields Avenue
Wollongong, NSW 2522 Wollongong, NSW 2522
AU AU
Phone: +61 2 4221 2938 Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com EMail: james.winterbottom@andrew.com
Martin Thomson Martin Thomson
Andrew Corporation Andrew Corporation
Andrew Building (39) Andrew Building (39)
Wollongong University Campus Wollongong University Campus
Northfields Avenue Northfields Avenue
Wollongong, NSW 2522 Wollongong, NSW 2522
AU AU
Phone: +61 2 4221 2915 Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com EMail: martin.thomson@andrew.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Richard Barnes Richard Barnes
BBN Technologies BBN Technologies
9861 Broken Land Pkwy, Suite 400 9861 Broken Land Pkwy, Suite 400
Columbia, MD 21046 Columbia, MD 21046
USA USA
Phone: +1 410 290 6169 Phone: +1 410 290 6169
Email: rbarnes@bbn.com EMail: rbarnes@bbn.com
 End of changes. 123 change blocks. 
303 lines changed or deleted 326 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/