< draft-ietf-geopriv-held-identity-extensions-04.txt   draft-ietf-geopriv-held-identity-extensions-05.txt >
Geopriv J. Winterbottom Geopriv J. Winterbottom
Internet-Draft M. Thomson Internet-Draft M. Thomson
Intended status: Standards Track Andrew Corporation Intended status: Standards Track Andrew Corporation
Expires: December 23, 2010 H. Tschofenig Expires: April 23, 2011 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
R. Barnes R. Barnes
BBN Technologies BBN Technologies
June 21, 2010 October 20, 2010
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-04 draft-ietf-geopriv-held-identity-extensions-05
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.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 23, 2010. This Internet-Draft will expire on April 23, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 3, line 20 skipping to change at page 3, line 20
2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7 2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7 2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7
2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 8 2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 8
2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9 2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 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. TCP or UDP Port Number . . . . . . . . . . . . . . . . . . 11 3.3. TCP or UDP Port Number . . . . . . . . . . . . . . . . . . 11
3.4. Network Access Identifier . . . . . . . . . . . . . . . . 12 3.4. Network Access Identifier . . . . . . . . . . . . . . . . 12
3.4.1. Using NAI for Location Configuration . . . . . . . . . 12 3.4.1. Using NAI for Location Configuration . . . . . . . . . 13
3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . 14 3.8. DHCP Unique Identifier . . . . . . . . . . . . . . . . . . 15
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . 19
5.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 19 5.3. Third Party Requests . . . . . . . . . . . . . . . . . . . 19
6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . 23
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 23 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 23
7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 24 7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative references . . . . . . . . . . . . . . . . . . . 26 9.1. Normative references . . . . . . . . . . . . . . . . . . . 26
9.2. Informative references . . . . . . . . . . . . . . . . . . 27 9.2. Informative references . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
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, namely
the source IP address of an incoming request. Existing LCPs, such as the source IP address of an incoming request. Existing LCPs, such as
HTTP-Enabled Location Delivery (HELD) HTTP-Enabled Location Delivery (HELD)
[I-D.ietf-geopriv-http-location-delivery] and DHCP ([RFC3825], [I-D.ietf-geopriv-http-location-delivery] and DHCP ([RFC3825],
[RFC4776]) rely on the source IP address or other information present [RFC4776]) rely on the source IP address or other information present
in protocol datagrams to identify a Device. 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
identifiers in HELD requests. identifiers in HELD requests.
An important characteristic of this addition is that the HELD An important characteristic of this addition is that the HELD
skipping to change at page 4, line 43 skipping to change at page 4, line 43
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 requester 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 requester 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 obviously introduces a new set of The usage of identifiers in HELD introduces a new set of privacy
privacy concerns. In an LCP, the requester can be implicitly concerns. In an LCP, the requester can be implicitly authorized to
authorized to access the requested location information, because it access the requested location information, because it is their own
is their own location. In contrast, a third-party LR must be location. In contrast, a third party LR must be explicitly
explicitly authorized when requesting the location of a Device. authorized when requesting the location of a Device. Establishing
Establishing appropriate authorization and other related privacy appropriate authorization and other related privacy concerns are
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 is not used to identify the subject of the identity of the requester is not used to identify the subject of the
request. 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 requester 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 requester.
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 [I-D.ietf-ecrit-phonebcp]). This
allows use of location-dependent applications - particularly allows use of location-dependent applications - particularly
essential services like emergency calling - where Devices do not essential services like emergency calling - where Devices do not
support a location configuration protocol or they are unable to support a location configuration protocol or they are unable to
successfully retrieve location information. successfully 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 to
use Device identifiers in this fashion. This contract must 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 privacy constraints are respected
are possible. 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 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]. [I-D.ietf-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 [I-D.ietf-geopriv-http-location-delivery]. This consistent with [I-D.ietf-geopriv-http-location-delivery]. This
document also uses the term Target to refer to any entity that might 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 be a subject of the same location information. Target is used in a
more general sense, including the Device, but also any nearby entity, 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 such as the user of a Device.
authorization policy on the use of location information. Both Device
and Target are defined in [I-D.ietf-geopriv-arch]. 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 The term "requester" 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
skipping to change at page 7, line 33 skipping to change at page 7, line 33
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
skipping to change at page 8, line 10 skipping to change at page 8, line 10
[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 requester
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 requester 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 requester 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 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
skipping to change at page 8, line 43 skipping to change at page 8, line 43
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 requester 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 requester 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 requester 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.
skipping to change at page 10, line 23 skipping to change at page 10, line 23
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) if the request requester needs to include a MAC address (Section 3.2) and IP address
is to succeed. (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 mac ip
</requiredIdentifiers> </requiredIdentifiers>
</error> </error>
Figure 2 Figure 2
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 The "ip" element can express a Device identity as an IP address. The
"v" attribute identifies the IP version with a single hexadecimal "v" attribute identifies the IP version with a single hexadecimal
digit. The element uses the textual format specific to the indicated digit. The element uses the textual format specific to the indicated
IP version. IP version ([RFC0791] for IPv6, [RFC4291] for IPv6).
<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 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 media access control (MAC) address used by the IEEE 802 family of
access technologies is an identifier that is assigned to a particular access technologies is an identifier that is assigned to a particular
network Device. 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 a Device, or assigned by a assigned at the time of manufacture of a Device, or assigned by a
local administrator. A MAC address rarely changes; therefore, a MAC local administrator. A MAC address rarely changes; therefore, a MAC
address is an appropriate identifier for a Device. 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"> <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>
3.3. TCP or UDP Port Number 3.3. TCP or UDP Port Number
On its own, a TCP or UDP port number is insufficient to uniquely On its own, a TCP or UDP port number is insufficient to uniquely
identify a single host, but in combination with an IP address, it can identify a single host, but in combination with an IP address, it can
be used in some environments to uniquely identify a Device. be used in some environments to uniquely identify a Device.
skipping to change at page 12, line 26 skipping to change at page 12, line 30
A Network Access Identifier (NAI) [RFC4282] is an identifier used in A Network Access Identifier (NAI) [RFC4282] is an identifier used in
network authentication in a range of networks. The identifier network authentication in a range of networks. The identifier
establishes a user identity within a particular domain. Often, establishes a user identity within a particular domain. Often,
network services use an NAI in relation to location records, tying network services use an NAI in relation to location records, tying
network access to user authentication and authorization. network access to user authentication and authorization.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<nai>user@example.net</nai> <nai>user@example.net</nai>
</device> </device>
The formal grammar for NAI [RFC4282] permits invalid Unicode, which The formal grammar for NAI [RFC4282] permits sequences of octets that
cannot be expressed using XML. Therefore, this expression of NAI are not valid UTF-8 [RFC3629] sequences. These sequences cannot be
permits escaping. Non-unicode characters (and any other character) expressed using XML. Therefore, this expression of NAI permits
are expressed using a backslash ('\') followed by two hexadecimal escaping. Sequences of octets that do not represent a valid UTF-8
digits representing the value of a single octet. encoding can be expressed using a backslash ('\') followed by two
case-insensitive hexadecimal digits representing the value of a
single octet.
The canonical representation of an NAI is the sequence of octets that The canonical representation of an NAI is the sequence of octets that
is produced from the concatenation of UTF-8 encoded sequences of is produced from the concatenation of UTF-8 encoded sequences of
unescaped characters and octets derived from escaped components. unescaped characters and octets derived from escaped components. The
This sequence MUST conform to the constraints in [RFC4282]. resulting sequence of octets MUST conform to the constraints in
[RFC4282].
For example, the NAI "f<U+FC>\<0xFF>@bar.com" 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\90@bar.com", though the u-umlaut
character might be included directly.
3.4.1. Using NAI for Location Configuration 3.4.1. Using NAI for Location Configuration
An NAI in WiMAX is uniquely attributable to a single Device at any An NAI in WiMAX is uniquely attributable to a single Device at any
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, described in more LIS to locate a Device. The following procedure relies on an NAI to
detail in [WiMAX-T33-110-R015v01-B], relies on an NAI to identify the identify the Device. This procedure and the messages and parameters
Device. 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 requester, 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 IP address spoofing protections that are
required by [I-D.ietf-geopriv-http-location-delivery]. In addition, required by [I-D.ietf-geopriv-http-location-delivery]. In addition,
the request made of the AAA uses either Diameter [RFC3588] or RADIUS the request made of the AAA uses either Diameter [RFC3588] or RADIUS
[RFC2865], and therefore relies on the protections provided by those [RFC2865], and therefore relies on the protections provided by those
protocols. In order to rely on the access request, the AAA server protocols. In order to rely on the access request, the AAA server
MUST be authenticated to be a trusted entity for the purpose of MUST be authenticated to be a trusted entity for the purpose of
providing a link between the NAI and IP address. The AAA protocol providing a link between the NAI and IP address. The AAA protocol
MUST also provide protection from modification and replay attacks to MUST also provide protection from modification and replay attacks to
ensure that data cannot be altered by an attacker. ensure that data cannot be altered by an attacker.
3.5. URI 3.5. URI
A Device can be identified by a URI. Any URI can be used providing A Device can be identified by a URI [RFC3986]. Any URI can be used
that the requester and LIS have a common understanding of the providing that the requester and LIS have a common understanding of
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.
skipping to change at page 14, line 42 skipping to change at page 15, line 8
imei: The International Mobile Equipment Identifier (IMEI) is a imei: The International Mobile Equipment Identifier (IMEI) is a
unique device serial number up to 15 digits long. unique device serial number up to 15 digits long.
min: The Mobile Identification Number (MIN) is a unique number min: The Mobile Identification Number (MIN) is a unique number
assigned to CDMA handsets. assigned to CDMA handsets.
mdn: The Mobile Directory Number (MDN) is an E.164 number, with mdn: The Mobile Directory Number (MDN) is an E.164 number, with
usage similar to MSISDN. usage similar to MSISDN.
Each identifier contains a string of decimal digits with a length as
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>
3.8. DHCP Unique Identifier 3.8. DHCP Unique Identifier
The Dynamic Host Configuration Protocol (DHCP) uses a binary The Dynamic Host Configuration Protocol (DHCP) uses a binary
identifier for its clients. The DHCP Unique Identifier (DUID) is identifier for its clients. The DHCP Unique Identifier (DUID) is
expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of
DHCPv6 and follows the format defined in Section 9 of [RFC3315]. The DHCPv6 and follows the format defined in Section 9 of [RFC3315]. The
skipping to change at page 16, line 16 skipping to change at page 16, line 16
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
[I-D.ietf-geopriv-http-location-delivery] are applicable. However, [I-D.ietf-geopriv-http-location-delivery] are applicable. However,
the considerations relating to return routability do not apply to the considerations relating to return routability do not apply to
third-party requests. Return routability may also not apply to third party requests. Return routability may also not apply to
requests from Targets for their own location depending on the anti- requests from Targets for their own location depending on the anti-
spoofing mechanisms employed for the identifier. spoofing mechanisms employed for the 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". In all cases, the Geopriv security and privacy policy". The "LCP policy" concept and further security and privacy
considerations [I-D.ietf-geopriv-arch] are applicable. considerations can be found in [I-D.ietf-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.
skipping to change at page 17, line 16 skipping to change at page 17, line 16
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 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 to 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 requesters 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
skipping to change at page 18, line 22 skipping to change at page 18, line 22
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 requester 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 LIS MUST support HTTP digest authentication. Device identity, the LIS MUST support HTTP digest authentication
Unauthenticated location requests containing Device identity can be [RFC2617]. Unauthenticated location requests containing Device
challenged with an HTTP 401 (Unauthorized) response or rejected with identity can be challenged with an HTTP 401 (Unauthorized) response
an HTTP 403 (Forbidden) response. or rejected with an HTTP 403 (Forbidden) response.
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 re-
skipping to change at page 19, line 19 skipping to change at page 19, line 19
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 requester 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">
skipping to change at page 21, line 40 skipping to change at page 21, line 40
<xs:element name="uri" type="xs:anyURI"/> <xs:element name="uri" type="xs:anyURI"/>
<xs:element name="fqdn" type="xs:token"/> <xs:element name="fqdn" type="xs:token"/>
<xs:element name="duid" type="xs:hexBinary"/> <xs:element name="duid" type="xs:hexBinary"/>
<xs:element name="msisdn" type="id:e164"/> <xs:element name="msisdn" type="id:e164"/>
<xs:element name="imsi" type="id:e164"/> <xs:element name="imsi" type="id:e164"/>
<xs:element name="imei" type="id:digit15"/> <xs:element name="imei" type="id:digit15"/>
<xs:element name="min" type="id:digit10"/> <xs:element name="min" type="id:digit10"/>
<xs:element name="mdn" type="id:e164"/> <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:simpleType name="e164">
<xs:restriction base="id:digit15"> <xs:restriction base="id:digit15">
<xs:minLength value="6"/> <xs:minLength value="6"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="digit15"> <xs:simpleType name="digit15">
<xs:restriction base="id:digits"> <xs:restriction base="id:digits">
<xs:maxLength value="15"/> <xs:maxLength value="15"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
skipping to change at page 23, line 8 skipping to change at page 23, line 8
<xs:restriction base="id:digits"> <xs:restriction base="id:digits">
<xs:length value="10"/> <xs:length value="10"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </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]. It also creates a new accordance with guidelines in [RFC3688].
registry for Device identity types, and stipulates how new types are
to be added.
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
skipping to change at page 26, line 9 skipping to change at page 26, line 9
an issue with NAIs. Ray Bellis provided motivation for the protocol an issue with NAIs. Ray Bellis provided motivation for the protocol
port parameters. Marc Linsner and Alissa Cooper provided guidance port parameters. Marc Linsner and Alissa Cooper provided guidance
and text (respectively) that greatly clarified the discussion and text (respectively) that greatly clarified the discussion
relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for
forcing this to be practical. forcing this to be practical.
9. References 9. References
9.1. Normative references 9.1. Normative references
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 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, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. 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 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, February 2006. Version Four (DHCPv4)", RFC 4361, February 2006.
[I-D.ietf-idnabis-defs] [I-D.ietf-idnabis-defs]
Klensin, J., "Internationalized Domain Names for Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
draft-ietf-idnabis-defs-13 (work in progress), draft-ietf-idnabis-defs-13 (work in progress),
January 2010. January 2010.
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-16 (work in draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009. progress), August 2009.
[W3C.REC-xml-names11-20060816] [W3C.REC-xml-names11-20060816]
Tobin, R., Hollander, D., Bray, T., and A. Layman, Hollander, D., Layman, A., Tobin, R., 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
Networks: Overview and Architecture", 802, February 2002.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority", March 1997, <http://
standards.ieee.org/regauth/oui/tutorials/EUI64.html>.
[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 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.
skipping to change at page 27, line 47 skipping to change at page 28, line 24
(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] [I-D.ietf-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-02 (work in progress), May 2010. draft-ietf-geopriv-arch-03 (work in progress),
October 2010.
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
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-14 (work in progress), draft-ietf-ecrit-phonebcp-15 (work in progress),
January 2010. July 2010.
[I-D.thomson-geopriv-held-measurements] [I-D.thomson-geopriv-held-measurements]
Thomson, M. and J. Winterbottom, "Using Device-provided Thomson, M. and J. Winterbottom, "Using Device-provided
Location-Related Measurements in Location Configuration Location-Related Measurements in Location Configuration
Protocols", draft-thomson-geopriv-held-measurements-06 Protocols", draft-thomson-geopriv-held-measurements-06
(work in progress), May 2010. (work in progress), May 2010.
[TS.3GPP.23.271] [TS.3GPP.23.271]
3GPP, "Functional stage 2 description of Location Services 3GPP, "Functional stage 2 description of Location Services
(LCS)", 3GPP TS 23.271 8.0.0, December 2008. (LCS)", 3GPP TS 23.271 8.0.0, December 2008.
 End of changes. 60 change blocks. 
80 lines changed or deleted 133 lines changed or added

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