draft-ietf-geopriv-held-identity-extensions-05.txt   draft-ietf-geopriv-held-identity-extensions-06.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: April 23, 2011 H. Tschofenig Expires: May 19, 2011 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
R. Barnes R. Barnes
BBN Technologies BBN Technologies
October 20, 2010 November 15, 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-05 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.
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 April 23, 2011. 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) 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 12 skipping to change at page 3, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7 2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7
2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 8 2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 7
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. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 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, 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) [RFC5985] 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
skipping to change at page 5, line 12 skipping to change at page 5, line 11
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 is not used to identify the subject of the identity of the requester in the form of the source IP address is not
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
skipping to change at page 6, line 23 skipping to change at page 6, line 21
the common policy [RFC4745], can be applied in an automated the common policy [RFC4745], can be applied in an automated
fashion by a LIS. 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 [RFC5985]. This document also uses the term Target
document also uses the term Target to refer to any entity that might to refer to any entity that might be a subject of the same location
be a subject of the same location information. Target is used in a information. Target is used in a more general sense, including the
more general sense, including the Device, but also any nearby entity, Device, but also any nearby entity, such as the user of a Device.
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 [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
Identifiers are used as the starting point in location determination. Identifiers are used as the starting point in location determination.
They should not be confused with measurement information Identifiers might be associated with a different Device over time,
([I-D.thomson-geopriv-held-measurements]). Measurement information but their purpose is to identify the Device, not to describe its
is information about a Device and the time varying details of its environment or network attachment.
network attachment. Identifiers might be associated with a different
Device over time, but their purpose is to identify the Device, not to
describe its environment or network attachment.
2.1. Identifier Suitability 2.1. Identifier Suitability
Use of any identifier MUST only be allowed if it identifies a single Use of any identifier MUST only be allowed if it identifies a single
Device at the time that location is determined. The LIS is Device at the time that location is determined. The LIS is
responsible for ensuring that location information is correct for the responsible for ensuring that location information is correct for the
Device, which includes ensuring that the identifier is uniquely Device, which includes ensuring that the identifier is uniquely
attributable to the Device. attributable to the Device.
Some identifiers can be either temporary or could potentially Some identifiers can be either temporary or could potentially
skipping to change at page 9, line 50 skipping to change at page 9, line 44
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>
<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.5</ip> <ip v="4">192.0.2.5</ip>
</device> </device>
</locationRequest> </locationRequest>
Figure 1 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 requester 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
skipping to change at page 10, line 35 skipping to change at page 10, line 29
<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 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 The "ip" element can express a Device identity as an IP address
"v" attribute identifies the IP version with a single hexadecimal ([RFC0791], [RFC4291]). The "v" attribute identifies the IP version
digit. The element uses the textual format specific to the indicated with a single hexadecimal digit. The element uses the textual format
IP version ([RFC0791] for IPv6, [RFC4291] for IPv6). specific to the indicated IP version. The textual format for IP
version 4 and version 6 addresses MUST conform to the grammar defined
in [RFC3986] ("IPv4address" and "IPv6address" respectively).
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <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
skipping to change at page 11, line 44 skipping to change at page 11, line 46
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 A MAC address can be represented as MAC-48, EUI-48 or EUI-64 address
([IEEE802], or extended unique identifier [EUI64]) using the ([IEEE802], or extended unique identifier [EUI64]) using the
hexadecimal representation defined in [IEEE802]. 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 A locally-assigned MAC address is not guaranteed to be unique outside
the administrative domain where it is assigned. Locally-assigned MAC
addresses can only be used within this domain.
On its own, a TCP or UDP port number is insufficient to uniquely 3.3. Port Numbers
identify a single host, but in combination with an IP address, it can
be used in some environments to uniquely identify a Device. A host might only be known by a flow of packets that it is sending or
receiving. On its own, a port number is insufficient to uniquely
identify a single host. In combination with an IP address, a port
number can be used to uniquely identify a Device in some
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
[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 35 skipping to change at page 13, line 46
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 [RFC5985]. In addition, the request made of the AAA uses
the request made of the AAA uses either Diameter [RFC3588] or RADIUS either Diameter [RFC3588] or RADIUS [RFC2865], and therefore relies
[RFC2865], and therefore relies on the protections provided by those on the protections provided by those protocols. In order to rely on
protocols. In order to rely on the access request, the AAA server the access request, the AAA server MUST be authenticated to be a
MUST be authenticated to be a trusted entity for the purpose of trusted entity for the purpose of providing a link between the NAI
providing a link between the NAI and IP address. The AAA protocol and IP address. The AAA protocol MUST also provide protection from
MUST also provide protection from modification and replay attacks to modification and replay attacks to ensure that data cannot be altered
ensure that data cannot be altered by an attacker. 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 requester 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>
skipping to change at page 14, line 26 skipping to change at page 14, line 37
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 [I-D.ietf-idnabis-defs] is formed This IDN-aware domain name slot [RFC5890] is formed from any sequence
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) is an E.164 number between 6 and 15 digits long. (MSISDN) [E.213] is an E.164 number [E.164] between 6 and 15
digits long.
imsi: The International Mobile Subscriber Identity (IMSI) an imsi: The International Mobile Subscriber Identity (IMSI)
identifier associated with all GSM and UMTS mobile subscribers. [TS.3GPP.23.003] an identifier associated with all GSM and UMTS
mobile subscribers.
imei: The International Mobile Equipment Identifier (IMEI) is a imei: The International Mobile Equipment Identifier (IMEI)
unique device serial number up to 15 digits long. [TS.3GPP.23.003] is a 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) [TIA.EIA.IS-2000-6] is a
assigned to CDMA handsets. unique number 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 [E.164],
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>
3.8. DHCP Unique Identifier 3.8. DHCP Unique Identifier
skipping to change at page 16, line 14 skipping to change at page 16, line 14
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
[I-D.ietf-geopriv-http-location-delivery] are applicable. However, [RFC5985] are applicable. However, the considerations relating to
the considerations relating to return routability do not apply to return routability do not apply to third party requests. Return
third party requests. Return routability may also not apply to routability may also not apply to requests from Targets for their own
requests from Targets for their own location depending on the anti- location depending on the anti-spoofing mechanisms employed for the
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
skipping to change at page 18, line 7 skipping to change at page 18, line 7
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], [RFC4825]). This document does not mandate any particular
mechanism for establishing an authorization policy. mechanism for establishing an authorization policy.
5. Security Considerations 5. Security Considerations
The security considerations in The security considerations in [RFC5985] describe the use of
[I-D.ietf-geopriv-http-location-delivery] 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 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 requester MUST support HTTP digest
[RFC2617]. Unauthenticated location requests containing Device authentication [RFC2617]. Unauthenticated location requests
identity can be challenged with an HTTP 401 (Unauthorized) response containing Device identity can be challenged with an HTTP 401
or rejected with an HTTP 403 (Forbidden) response. (Unauthorized) response or rejected with an HTTP 403 (Forbidden)
response.
Note that HELD [RFC5985] does not mandate that Devices implement
authentication. A LIS SHOULD NOT send a HTTP 401 response if the
Device does not include Device identity.
5.1. Identifier Suitability 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 21, line 14 skipping to change at page 21, line 14
<xs:element name="mac" type="id:macAddress"/> <xs:element name="mac" type="id:macAddress"/>
<xs:simpleType name="macAddress"> <xs:simpleType name="macAddress">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern <xs:pattern
value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/> value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:element name="udpport" type="id:portNumber"/> <xs:element name="udpport" type="id:portNumber"/>
<xs:element name="tcpport" type="id:portNumber"/> <xs:element name="tcpport" type="id:portNumber"/>
<xs:element name="sctpport" type="id:portNumber"/>
<xs:element name="dccpport" type="id:portNumber"/>
<xs:simpleType name="portNumber"> <xs:simpleType name="portNumber">
<xs:restriction base="xs:nonNegativeInteger"> <xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="65535"/> <xs:maxInclusive value="65535"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:element name="nai" type="id:naiType"/> <xs:element name="nai" type="id:naiType"/>
<xs:simpleType name="naiType"> <xs:simpleType name="naiType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern <xs:pattern
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
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
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,
RFC 793, 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., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. 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)",
skipping to change at page 26, line 47 skipping to change at page 27, line 5
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. 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 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client [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] [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
Klensin, J., "Internationalized Domain Names for RFC 4960, September 2007.
[RFC5890] 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), RFC 5890, August 2010.
January 2010.
[I-D.ietf-geopriv-http-location-delivery] [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, RFC 5985, September 2010.
"HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009.
[W3C.REC-xml-names11-20060816] [W3C.REC-xml-names11-20060816]
Hollander, D., Layman, A., Tobin, R., and T. Bray, Hollander, D., Bray, T., Layman, A., and R. Tobin,
"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", 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, <http://
standards.ieee.org/regauth/oui/tutorials/EUI64.html>. standards.ieee.org/regauth/oui/tutorials/EUI64.html>.
[E.164] ITU-T, "E.164 : The international public telecommunication
numbering plan", ITU-T Recommendation E.164,
February 2005.
[E.213] ITU-T, "E.213 : Telephone and ISDN numbering plan for land
mobile stations in public land mobile networks (PLMN)",
ITU-T Recommendation E.213, November 1988.
[TS.3GPP.23.003]
3GPP, "Numbering, addressing and identification", 3GPP
TS 23.003 9.4.0, September 2010.
[TIA.EIA.IS-2000-6]
TIA/EIA, "Analog Signaling Standard for CDMA 2000 Spread
Spectrum Systems", TIA/EIA/IS-2000-6-C, May 2002.
[WiMAX-T33-110-R015v01-B] [WiMAX-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 28, line 30 skipping to change at page 29, line 5
[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-03 (work in progress), draft-ietf-geopriv-arch-03 (work in progress),
October 2010. 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-15 (work in progress), draft-ietf-ecrit-phonebcp-16 (work in progress),
July 2010. October 2010.
[I-D.thomson-geopriv-held-measurements]
Thomson, M. and J. Winterbottom, "Using Device-provided
Location-Related Measurements in Location Configuration
Protocols", draft-thomson-geopriv-held-measurements-06
(work in progress), May 2010.
[TS.3GPP.23.271]
3GPP, "Functional stage 2 description of Location Services
(LCS)", 3GPP TS 23.271 8.0.0, December 2008.
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
 End of changes. 38 change blocks. 
86 lines changed or deleted 114 lines changed or added

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