draft-ietf-geopriv-held-identity-extensions-00.txt   draft-ietf-geopriv-held-identity-extensions-01.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: March 10, 2010 H. Tschofenig Expires: April 21, 2010 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
R. Barnes R. Barnes
BBN Technologies BBN Technologies
September 6, 2009 October 18, 2009
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-00 draft-ietf-geopriv-held-identity-extensions-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 10, 2010. This Internet-Draft will expire on April 21, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 13 skipping to change at page 3, line 13
identifiers are permitted. identifiers are permitted.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7 3. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7 3.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7
3.1.1. Subjective Network Views . . . . . . . . . . . . . . . 7 3.1.1. Subjective Network Views . . . . . . . . . . . . . . . 7
3.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 8 3.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9
3.2. Identifier Format and Protocol Details . . . . . . . . . . 9 3.2. Identifier Format and Protocol Details . . . . . . . . . . 9
3.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . 10 3.3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . 10
3.3.3. TCP or UDP Port Number . . . . . . . . . . . . . . . . 11 3.3.3. TCP or UDP Port Number . . . . . . . . . . . . . . . . 11
3.3.4. Network Access Identifier . . . . . . . . . . . . . . 11 3.3.4. Network Access Identifier . . . . . . . . . . . . . . 11
3.3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.6. Hostname . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.6. Hostname . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.7. Directory Number . . . . . . . . . . . . . . . . . . . 12 3.3.7. Directory Number . . . . . . . . . . . . . . . . . . . 12
3.3.8. Cellular Telephony Identifiers . . . . . . . . . . . . 12 3.3.8. Cellular Telephony Identifiers . . . . . . . . . . . . 12
3.3.9. DHCP Unique Identifier . . . . . . . . . . . . . . . . 13 3.3.9. DHCP Unique Identifier . . . . . . . . . . . . . . . . 13
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 17 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 17
5.1. Targets Requesting Their Own Location . . . . . . . . . . 17
5.2. Third-Party Requests . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 19 6.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 19
6.2. Location Configuration Protocol Requests . . . . . . . . . 19 6.2. Targets Requesting Their Own Location . . . . . . . . . . 19
6.3. Third Party Requests . . . . . . . . . . . . . . . . . . . 20 6.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. URN Sub-Namespace Registration for 7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 21 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 21
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 21 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 21
7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 22 7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative references . . . . . . . . . . . . . . . . . . . 24 9.1. Normative references . . . . . . . . . . . . . . . . . . . 24
9.2. Informative references . . . . . . . . . . . . . . . . . . 24 9.2. Informative references . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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 simpler for LCPs, since IP problem of identifying the Device simple for LCPs, since IP datagrams
datagrams that carry the request already carry an identifier for the that carry the request already carry an identifier for the Device,
Device, namely the source IP address of an incoming request. namely the source IP address of an incoming request. Existing LCPs,
Existing LCPs, such as HELD [I-D.ietf-geopriv-http-location-delivery] such as HELD [I-D.ietf-geopriv-http-location-delivery] and DHCP
and DHCP ([RFC3825], [RFC4776]) rely on the source IP address or ([RFC3825], [RFC4776]) rely on the source IP address or other
other information present in protocol datagrams to identify a Device. information present in protocol datagrams to identify a Device.
Aside from the datagrams that form a request, a location information Aside from the datagrams that form a request, a location information
server (LIS) does not necessarily have access to information that server (LIS) does not necessarily have access to information that
could further identify the Device. In some circumstances, as shown could further identify the Device. In some circumstances, as shown
in [I-D.ietf-geopriv-l7-lcp-ps], additional identification in [I-D.ietf-geopriv-l7-lcp-ps], additional identification
information can be included in a request to identify a Device. information can be included 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 to the HELD protocol is An important characteristic of this addition is that the HELD
that it also expands the potential scope of HELD beyond that of an protocol with identity extensions implemented is not considered an
LCP. The scope of an LCP is limited to the interaction between a LCP. The scope of an LCP is limited to the interaction between a
Device and a LIS. That is, an LCP is limited to the Device Device and a LIS, and LCPs can guarantee the identity of Devices
retrieving information about their own location. With this addition, without additional authorization checks. Neither of these is true
authorized third party location recipients (LRs) are able to make for HELD with identity extensions. Furthermore, identity extensions
allow authorized third-party location recipients (LRs) to make
requests that include identifiers to retrieve location information requests that include identifiers to retrieve location information
about a particular Device. about a particular Device.
The usage of HELD for purposes beyond the Device-LIS interaction The usage of identifiers in HELD obviously introduces a new set of
obviously introduces a new set of privacy concerns. In an LCP, the privacy concerns. In an LCP, the requester can be implicitly
requester is implicitly authorized to access the requested location authorized to access the requested location information, because it
information, because it is their own location. In contrast, a third is their own location. In contrast, a third-party LR must be
party LR must be explicitly authorized when requesting the location explicitly authorized when requesting the location of a Device.
of a Device. Establishing appropriate authorization and other Establishing appropriate authorization and other related privacy
related privacy concerns are discussed in Section 5. concerns are discussed in Section 5.
1.1. Applications 1.1. Applications
The use of additional identifiers in HELD falls into two categories. The use of additional identifiers in HELD falls into two categories:
A Device can use these parameters to provide additional
identification information to a LIS. Identification information,
such as the MAC address of the interface card of a Target, can be
used to reduce the time required to determine the location by a LIS.
In other cases, a LIS might require Device identification before any 1. A Device can use these parameters to provide additional
location information can be generated. identification information about itself to a LIS. Identification
information, such as the MAC address of the interface card of a
Target, can be used to reduce the time required to determine the
location by a LIS. In other cases, a LIS might require Device
identification before any location information can be generated.
A third party LR can be granted authorization to make requests for a 2. A third-party LR can be granted authorization to make requests
given Device. In particular, network services can be permitted to for a given Device. In particular, network services can be
retrieve location for a Device that is unable to acquire location permitted to retrieve location for a Device that is unable to
information for itself (see Section 6.3 of acquire location information for itself (see Section 6.3 of
[I-D.ietf-ecrit-phonebcp]). This allows use of location-dependent [I-D.ietf-ecrit-phonebcp]). This allows use of location-
applications - particularly essential services like emergency calling dependent applications - particularly essential services like
- where Devices do not support a location configuration protocol emergency calling - where Devices do not support a location
(LCP) or they are unable to successfully retrieve location configuration protocol (LCP) or they are unable to successfully
information. retrieve location information.
2. Terminology 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 location configuration protocol (LCP) as described in
[I-D.ietf-geopriv-l7-lcp-ps]. [I-D.ietf-geopriv-l7-lcp-ps].
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
skipping to change at page 7, line 29 skipping to change at page 7, line 29
identifiers are either temporary or could potentially identify identifiers are either temporary or could potentially identify
multiple devices. Identifiers that are transient or ambiguous could multiple devices. Identifiers that are transient or ambiguous could
be exploited by an attacker to either gain information about another be exploited by an attacker to either gain information about another
device or to coerce the LIS into producing misleading information. device or to coerce the LIS into producing misleading information.
The identifiers described in this section MUST only be used where The identifiers described in this section 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 requesting its own location are discussed in Section 5 of
[I-D.ietf-geopriv-l7-lcp-ps]; this section discusses use of [I-D.ietf-geopriv-l7-lcp-ps]; this section discusses use of
identifiers for authorized third party requests. identifiers for authorized third-party 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. identifiers for convenience or some other perceived benefit.
However, care needs to be taken to ensure that the binding between However, care needs to be taken to ensure that the binding between
the indicated identifier and the identifier that is used for the indicated identifier and the identifier that is used for
location determination is unique and not subject to attacks. location determination is unique and not subject to attacks.
Identifiers can have a different meaning to different entities on a Identifiers can have a different meaning to different entities on a
network. An identifier in one network context might have a network. An identifier in one network context might have a
completely different meaning in a different context. Errors in completely different meaning in a different context. Errors in
perspective arise in both topology (all network entities have a perspective arise in both topology (all network entities have a
subjective view of the network) and time (the network changes over subjective view of the network) and time (the network changes over
time). time).
3.1.1. Subjective Network Views 3.1.1. Subjective Network Views
Subjective views of the network mean that the identifier a requests Subjective views of the network mean that the identifier a requests
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.
In this case, the third party receives information that is correct Where subjective views differ, the third-party receives information
only within the network context of the LIS. The location information that is correct only within the network context of the LIS. The
provided by the LIS is probably misleading: the requester believes location information provided by the LIS is probably misleading: the
that the information relates to a different entity than it was requester believes that the information relates to a different entity
generated for. than it was generated for.
Authorization policy can be affected by a subjective network view if
it is applied based on an identifier, or it's application depends on
identifiers. The subjective view presented to the LIS and Rule Maker
need to agree for the two entities to understand policy on the same
terms. For instance, it is possible that the authorization policy
applied by the LIS is entirely incorrect if authorization policy is
selected using a subjective identifier. Alternatively, policy might
be incorrectly applied if identifiers differ.
In IP networks, network address translation (NAT) and other forms In IP networks, network address translation (NAT) and other forms
of address modification create network contexts. Entities on of address modification create network contexts. Entities on
either side of the point where modification occurs have a either side of the point where modification occurs have a
different view of the network. Private use addresses [RFC1918] different view of the network. Private use addresses [RFC1918]
are the most easily recognizable identifiers that have limited are the most easily recognizable identifiers that have limited
scope. scope.
A LIS can be configured to recognize scenarios where the subjective A LIS can be configured to recognize scenarios where the subjective
view of a requester might not coincide with the view of the LIS. The view of a requester or Rule Maker might not coincide with the view of
LIS can either provide location information that takes the view of the LIS. The LIS can either provide location information that takes
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.
The residential gateway scenario in Section 3.1 of The residential gateway scenario in Section 3.1 of
[I-D.ietf-geopriv-l7-lcp-ps] is a particular example of where a [I-D.ietf-geopriv-l7-lcp-ps] is a particular example of where a
subjective view is permitted. The LIS knowingly provides Devices on subjective view is permitted. The LIS knowingly provides Devices on
the remote side of the residential gateway with location information, the remote side of the residential gateway with location information.
in spite of the ambiguity. The LIS provides location information The LIS provides location information with appropriate uncertainty to
with appropriate uncertainty to allow for the fact that the allow for the fact that the residential gateway serves a small
residential gateway serves a small geographical area. geographical area.
3.1.2. Transient Identifiers 3.1.2. Transient Identifiers
Some identifiers are temporary and can, over the course of time, be Some identifiers are temporary and can, over the course of time, be
assigned to different physical entities. An identifier that is assigned to different physical entities. An identifier that is
reassigned between the time that a request is formulated by a reassigned between the time that a request is formulated by a
requester and when the request is received by the LIS causes the LIS requester and when the request is received by the LIS causes the LIS
to locate a different entity than the requester intended. The to locate a different entity than the requester intended. The
response from the LIS might be accurate, but the request incorrectly response from the LIS might be accurate, but the request incorrectly
associates this information with the wrong subject. associates this information with the wrong subject.
skipping to change at page 10, line 37 skipping to change at page 10, line 45
The "ip" element can express a Device identity as an IP address. An The "ip" element can express a Device identity as an IP address. An
optional "v" attribute identifies the IP version. The element uses optional "v" attribute identifies the IP version. The element uses
the textual format specific to the indicated IP version. the textual format specific to the indicated IP version.
<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.3.2. MAC Address 3.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.
skipping to change at page 17, line 7 skipping to change at page 17, line 7
<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>
5. Privacy Considerations 5. Privacy Considerations
The authorization model for a location configuration protocol assumes Location configuration protocols can make use of an authorization
that the LR is also the Target, and that providing that LR with model known as "LCP policy", which permits only Targets to be the
information about its own location is allowed. We call this property recipients of their own locations. In effect, an LCP server (that
"LCP policy". In effect, an LCP server (that is, the LIS) follows a is, the LIS) follows a single rule policy that states that the Target
single rule policy that states that the Target is the only authorized is the only authorized Location Recipient.
Location Recipient.
Note: HELD explicitly takes the position that the Target is a Device The security and privacy considerations of the base HELD protocol
and not a person. When discussing privacy, Targets other than a [I-D.ietf-geopriv-http-location-delivery] are applicable, except as
Device have a stake in protecting privacy. Therefore, the more they relate to return routability.
general term of Target - any potential subject of location
information - is used in place of Device.
When Device identity is used, the "LCP policy" is only applicable if 5.1. Targets Requesting Their Own Location
the LR and Target are the same entity. If they are the same, the
security and privacy considerations of the base HELD protocol
[I-D.ietf-geopriv-http-location-delivery] MAY be applied by a LIS.
The usage of the additional identifiers defined in this document by
the LR MAY cause the LIS to perform additional security verifications
to take place.
LR and Target MUST be verified by the LIS to be the same identity, When a Target uses identity extensions to obtain its own location,
assuming that related identities are the same is not sufficient. HELD can no longer be considered an LCP. The authorization policy
that the LIS uses to respond to these requests must be provisioned by
one or more Rule Makers.
For example, it is not appropriate to apply LCP policy where a In the case that the LIS exclusively provides Targets with their own
requester is authenticated by NAI and the supplied Device identity locations, the LIS can still be said to be following the "LCP
is a MAC address, even if that MAC address is currently registered policy". In all cases, the Geopriv security and privacy
with the network under the given NAI. In this case, the requester considerations [I-D.ietf-geopriv-arch] are applicable.
might be requesting from a different MAC address registered under
the same NAI. The correct way of gaining authorization is to The spoofing protections provided when using HELD with identity
establish a policy that permits this particular request as a third extensions to provide Targets with their own locations differ from
party request. the protections inherent in an LCP. For an LCP, return routability
is considered sufficient protection against spoofing. A similar
degree of assurance is required if a similar policy is to be used.
A Rule Maker might require additional verification that the
identifier is owned by the requester. Verification that depends on
return routability can only provide weaker assurances than those
provided by return routability; therefore, policy might require the
use of additional, independent methods of verification.
Care is required where a direct one-to-one relationship between
requester and Device identity does not exist. If identifiers are not
identical, the use of HELD identity extensions to provide Targets
with their own locations could be exploited by an attacker.
For example, it is not appropriate to provide Targets with their
own locations under these terms where a requester is authenticated
by NAI and the supplied Device identity is a MAC address, even if
that MAC address is currently registered with the network under
the given NAI. In this case, the requester might be requesting
from a different MAC address registered under the same NAI. The
correct way of gaining authorization is to establish a policy that
permits this particular request as a third party request.
5.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. This that are provided by Rule Makers, including the Target. This
includes authentication of requesters where required by the includes authentication of requesters where required by the
authorization policies. authorization policies.
An organization that provides a LIS that allows third party requests An organization that provides a LIS that allows third party requests
skipping to change at page 19, line 10 skipping to change at page 19, line 10
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.
6. Security Considerations 6. Security Considerations
The security considerations in The security considerations in
[I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for [I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for
server authentication, confidentiality and protection from server authentication, confidentiality and protection from
modification. These protections apply to both LCP requests and the modification. These protections apply to both Target requests for
requests made by third parties. their own locations and requests 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. The base HELD protocol uses return desired is a matter for policy.
reachability of an IP address implied by the requester being able to
successfully complete a TCP handshake. It is RECOMMENDED that any The base HELD protocol uses return reachability of an IP address
means of authentication provide at least this degree of assurance. implied by the requester being able to successfully complete a TCP
For requests that include Device identity, the LIS MUST support handshake. It is RECOMMENDED that any means of authentication
authentication of TLS clients. provide at least this degree of assurance. For requests that include
Device identity, the LIS MUST support authentication of TLS clients.
6.1. Identifier Suitability 6.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 3.1 provides further discussion on this subject. Section 3.1 provides further discussion on this subject.
Identifier transience of can lead to incorrect location information Identifier transience of 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 46 skipping to change at page 19, line 47
allocation occurs between the time where authorization is granted and allocation occurs between the time where authorization is granted and
location information is granted. location information is granted.
Ambiguous identifiers present a similar problem. An attacker could Ambiguous identifiers present a similar problem. An attacker could
legitimately gain authorization to use a particular identifier. legitimately gain authorization to use a particular identifier.
Since an ambiguous identifier potentially refers to multiple Devices, Since an ambiguous identifier potentially refers to multiple Devices,
if authorization is granted for one of those Devices, an attacker if authorization is granted for one of those Devices, an attacker
potentially gains access to location information for all of those potentially gains access to location information for all of those
Devices. Devices.
6.2. Location Configuration Protocol Requests 6.2. Targets Requesting Their Own Location
Requests made by a Device in the context of a location configuration Requests made by a Device for its own location are covered by the
protocol are covered by the same set of protections offered by HELD. same set of protections offered by HELD. These requests might be
LCP requests are authorized under an "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.
6.3. Third Party Requests 6.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
LCP requests. However, because the third party needs to be Target requests for their own locations. However, because the third-
authorized, the requester MUST be authenticated by the LIS. In party needs to be authorized, the requester MUST be authenticated by
addition, third party requests MUST be explicitly authorized by a the LIS. In addition, third-party requests MUST be explicitly
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 5. covered in Section 5.
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]. It also creates a new
registry for device identity types, and stipulates how new types are registry for device identity types, and stipulates how new types are
to be added. to be added.
7.1. URN Sub-Namespace Registration for 7.1. URN Sub-Namespace Registration for
skipping to change at page 23, line 15 skipping to change at page 23, line 15
8. Acknowledgements 8. Acknowledgements
The authors wish to thank the NENA VoIP location working group for The authors wish to thank the NENA VoIP location working group for
their assistance in the definition of the schema used in this their assistance in the definition of the schema used in this
document. Special thanks go to Barbara Stark, Guy Caron, Nadine document. Special thanks go to Barbara Stark, Guy Caron, Nadine
Abbott, Jerome Grenier and Martin Dawson. Bob Sherry provided input Abbott, Jerome Grenier and Martin Dawson. Bob Sherry provided input
on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for
providing further corrections. Bernard Aboba provided extensive providing further corrections. Bernard Aboba provided extensive
feedback on use cases and the security model; Bernard, along with feedback on use cases and the security model; Bernard, along with
Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis
provided motivation for the protocol port parameters. provided motivation for the protocol port parameters. Marc Linsner
and Alissa Cooper provided guidance and text (respectively) that
greatly clarified the discussion on LCPs.
9. References 9. References
9.1. Normative references 9.1. Normative references
[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.
[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
skipping to change at page 24, line 39 skipping to change at page 24, line 39
draft-ietf-geopriv-http-location-delivery-16 (work in draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009. progress), August 2009.
[I-D.ietf-geopriv-l7-lcp-ps] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in
progress), July 2009. progress), July 2009.
[W3C.REC-xml-names11-20060816] [W3C.REC-xml-names11-20060816]
Tobin, R., Hollander, D., Bray, T., and A. Layman, 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>.
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 25, line 24 skipping to change at page 25, line 24
Format for Expressing Privacy Preferences", RFC 4745, Format for Expressing Privacy Preferences", RFC 4745,
February 2007. February 2007.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-00 (work in progress), July 2009.
[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-13 (work in progress), draft-ietf-ecrit-phonebcp-13 (work in progress),
July 2009. July 2009.
[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-04 Protocols", draft-thomson-geopriv-held-measurements-04
 End of changes. 36 change blocks. 
105 lines changed or deleted 143 lines changed or added

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