idnits 2.17.1
draft-ietf-geopriv-held-identity-extensions-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 18, 2009) is 5303 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'RFC4388' is defined on line 887, but no explicit
reference was found in the text
== Unused Reference: 'LLDP' is defined on line 920, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415)
** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542)
** Downref: Normative reference to an Informational draft:
draft-ietf-geopriv-l7-lcp-ps (ref. 'I-D.ietf-geopriv-l7-lcp-ps')
-- Obsolete informational reference (is this intentional?): RFC 3825
(Obsoleted by RFC 6225)
== Outdated reference: A later version (-03) exists of
draft-ietf-geopriv-arch-00
== Outdated reference: A later version (-20) exists of
draft-ietf-ecrit-phonebcp-13
== Outdated reference: A later version (-06) exists of
draft-thomson-geopriv-held-measurements-04
Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Geopriv J. Winterbottom
3 Internet-Draft M. Thomson
4 Intended status: Standards Track Andrew Corporation
5 Expires: April 21, 2010 H. Tschofenig
6 Nokia Siemens Networks
7 R. Barnes
8 BBN Technologies
9 October 18, 2009
11 Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
12 draft-ietf-geopriv-held-identity-extensions-01
14 Status of this Memo
16 This Internet-Draft is submitted to IETF in full conformance with the
17 provisions of BCP 78 and BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
22 Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on April 21, 2010.
37 Copyright Notice
39 Copyright (c) 2009 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents in effect on the date of
44 publication of this document (http://trustee.ietf.org/license-info).
45 Please review these documents carefully, as they describe your rights
46 and restrictions with respect to this document.
48 Abstract
50 When a Location Information Server receives a request for location
51 information (using the locationRequest message), described in the
52 base HTTP Enabled Location Delivery (HELD) specification, it uses the
53 source IP address of arriving message as a pointer to the location
54 determination process. This is sufficient in environments where the
55 location of a Device can be determined based on its IP address.
57 Two additional use cases are addresses by this document. In the
58 first, location configuration requires additional or alternative
59 identifiers from the source IP address provided in the request. In
60 the second, an entity other than the Device requests the location of
61 the Device.
63 This document extends the HELD protocol to allow the location request
64 message to carry Device identifiers. Privacy and security
65 considerations describe the conditions where requests containing
66 identifiers are permitted.
68 Table of Contents
70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
71 1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 4
72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
73 3. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7
74 3.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7
75 3.1.1. Subjective Network Views . . . . . . . . . . . . . . . 7
76 3.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9
77 3.2. Identifier Format and Protocol Details . . . . . . . . . . 9
78 3.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 10
79 3.3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . 10
80 3.3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . 10
81 3.3.3. TCP or UDP Port Number . . . . . . . . . . . . . . . . 11
82 3.3.4. Network Access Identifier . . . . . . . . . . . . . . 11
83 3.3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . 12
84 3.3.6. Hostname . . . . . . . . . . . . . . . . . . . . . . . 12
85 3.3.7. Directory Number . . . . . . . . . . . . . . . . . . . 12
86 3.3.8. Cellular Telephony Identifiers . . . . . . . . . . . . 12
87 3.3.9. DHCP Unique Identifier . . . . . . . . . . . . . . . . 13
88 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
89 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 17
90 5.1. Targets Requesting Their Own Location . . . . . . . . . . 17
91 5.2. Third-Party Requests . . . . . . . . . . . . . . . . . . . 18
92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
93 6.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 19
94 6.2. Targets Requesting Their Own Location . . . . . . . . . . 19
95 6.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 20
96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
97 7.1. URN Sub-Namespace Registration for
98 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 21
99 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 21
100 7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 22
101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
103 9.1. Normative references . . . . . . . . . . . . . . . . . . . 24
104 9.2. Informative references . . . . . . . . . . . . . . . . . . 24
105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
107 1. Introduction
109 Protocols for requesting and providing location information require a
110 way for the requestor to specify the location that should be
111 returned. In a location configuration protocol (LCP), the location
112 being requested is the requestor's location. This fact can make the
113 problem of identifying the Device simple for LCPs, since IP datagrams
114 that carry the request already carry an identifier for the Device,
115 namely the source IP address of an incoming request. Existing LCPs,
116 such as HELD [I-D.ietf-geopriv-http-location-delivery] and DHCP
117 ([RFC3825], [RFC4776]) rely on the source IP address or other
118 information present in protocol datagrams to identify a Device.
120 Aside from the datagrams that form a request, a location information
121 server (LIS) does not necessarily have access to information that
122 could further identify the Device. In some circumstances, as shown
123 in [I-D.ietf-geopriv-l7-lcp-ps], additional identification
124 information can be included in a request to identify a Device.
126 This document extends the HELD protocol to support the inclusion of
127 additional identifiers for the Device in HELD location requests. An
128 XML schema is defined that provides a structure for including these
129 identifiers in HELD requests.
131 An important characteristic of this addition is that the HELD
132 protocol with identity extensions implemented is not considered an
133 LCP. The scope of an LCP is limited to the interaction between a
134 Device and a LIS, and LCPs can guarantee the identity of Devices
135 without additional authorization checks. Neither of these is true
136 for HELD with identity extensions. Furthermore, identity extensions
137 allow authorized third-party location recipients (LRs) to make
138 requests that include identifiers to retrieve location information
139 about a particular Device.
141 The usage of identifiers in HELD obviously introduces a new set of
142 privacy concerns. In an LCP, the requester can be implicitly
143 authorized to access the requested location information, because it
144 is their own location. In contrast, a third-party LR must be
145 explicitly authorized when requesting the location of a Device.
146 Establishing appropriate authorization and other related privacy
147 concerns are discussed in Section 5.
149 1.1. Applications
151 The use of additional identifiers in HELD falls into two categories:
153 1. A Device can use these parameters to provide additional
154 identification information about itself to a LIS. Identification
155 information, such as the MAC address of the interface card of a
156 Target, can be used to reduce the time required to determine the
157 location by a LIS. In other cases, a LIS might require Device
158 identification before any location information can be generated.
160 2. A third-party LR can be granted authorization to make requests
161 for a given Device. In particular, network services can be
162 permitted to retrieve location for a Device that is unable to
163 acquire location information for itself (see Section 6.3 of
164 [I-D.ietf-ecrit-phonebcp]). This allows use of location-
165 dependent applications - particularly essential services like
166 emergency calling - where Devices do not support a location
167 configuration protocol (LCP) or they are unable to successfully
168 retrieve location information.
170 2. Terminology
172 This document uses the term Location Information Server (LIS) and
173 location configuration protocol (LCP) as described in
174 [I-D.ietf-geopriv-l7-lcp-ps].
176 The term Device is used specifically as the subject of an LCP,
177 consistent with [I-D.ietf-geopriv-http-location-delivery]. This
178 document also uses the term Target to refer to any entity that might
179 be a subject of the same location information. Target is used in a
180 more general sense, including the Device, but also any nearby entity,
181 such as the user of a Device. A Target has a stake in setting
182 authorization policy on the use of location information. Both Device
183 and Target are defined in [RFC3693].
185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
187 document are to be interpreted as described in [RFC2119].
189 3. Device Identity
191 Identifiers are used as the starting point in location determination.
192 They should not be confused with measurement information
193 ([I-D.thomson-geopriv-held-measurements]). Measurement information
194 is information about a Device and the time varying details of its
195 network attachment. Identifiers might be associated with a different
196 Device over time, but the their purpose is to identify the Device,
197 not to describe its environment or network attachment.
199 3.1. Identifier Suitability
201 Use of any identifier MUST only be allowed if it identifies a single
202 Device at a particular time. In some circumstances, certain of these
203 identifiers are either temporary or could potentially identify
204 multiple devices. Identifiers that are transient or ambiguous could
205 be exploited by an attacker to either gain information about another
206 device or to coerce the LIS into producing misleading information.
208 The identifiers described in this section MUST only be used where
209 that identifier is used as the basis for location determination.
210 Considerations relating to the use of identifiers for a Device
211 requesting its own location are discussed in Section 5 of
212 [I-D.ietf-geopriv-l7-lcp-ps]; this section discusses use of
213 identifiers for authorized third-party requests.
215 It is tempting for a LIS implementation to allow alternative
216 identifiers for convenience or some other perceived benefit.
217 However, care needs to be taken to ensure that the binding between
218 the indicated identifier and the identifier that is used for
219 location determination is unique and not subject to attacks.
221 Identifiers can have a different meaning to different entities on a
222 network. An identifier in one network context might have a
223 completely different meaning in a different context. Errors in
224 perspective arise in both topology (all network entities have a
225 subjective view of the network) and time (the network changes over
226 time).
228 3.1.1. Subjective Network Views
230 Subjective views of the network mean that the identifier a requests
231 uses to refer to one physical entity could actually apply to a
232 different physical entity when used in a different network context.
233 Unless an authorized third-party requester and LIS operate in the
234 same network context, each could have a different subjective view of
235 the meaning of the identifier.
237 Where subjective views differ, the third-party receives information
238 that is correct only within the network context of the LIS. The
239 location information provided by the LIS is probably misleading: the
240 requester believes that the information relates to a different entity
241 than it was generated for.
243 Authorization policy can be affected by a subjective network view if
244 it is applied based on an identifier, or it's application depends on
245 identifiers. The subjective view presented to the LIS and Rule Maker
246 need to agree for the two entities to understand policy on the same
247 terms. For instance, it is possible that the authorization policy
248 applied by the LIS is entirely incorrect if authorization policy is
249 selected using a subjective identifier. Alternatively, policy might
250 be incorrectly applied if identifiers differ.
252 In IP networks, network address translation (NAT) and other forms
253 of address modification create network contexts. Entities on
254 either side of the point where modification occurs have a
255 different view of the network. Private use addresses [RFC1918]
256 are the most easily recognizable identifiers that have limited
257 scope.
259 A LIS can be configured to recognize scenarios where the subjective
260 view of a requester or Rule Maker might not coincide with the view of
261 the LIS. The LIS can either provide location information that takes
262 the view of the requester into account, or it can reject the request.
264 For instance, a LIS might operate within a network that uses a
265 private address space, with NAT between that network and other
266 networks. A third-party request that originates in an external
267 network with an IP address from the private address space might
268 not be valid - it could be identifying an entity within another
269 address space. The LIS can be configured to reject such requests,
270 unless it knows by other means that the request is valid.
272 In the same example, the requester might include an address from
273 the external space in an attempt to identify a host within the
274 network. The LIS could use knowledge about how the external
275 address is mapped to a private address, if that mapping is fixed,
276 to determine an appropriate response.
278 The residential gateway scenario in Section 3.1 of
279 [I-D.ietf-geopriv-l7-lcp-ps] is a particular example of where a
280 subjective view is permitted. The LIS knowingly provides Devices on
281 the remote side of the residential gateway with location information.
282 The LIS provides location information with appropriate uncertainty to
283 allow for the fact that the residential gateway serves a small
284 geographical area.
286 3.1.2. Transient Identifiers
288 Some identifiers are temporary and can, over the course of time, be
289 assigned to different physical entities. An identifier that is
290 reassigned between the time that a request is formulated by a
291 requester and when the request is received by the LIS causes the LIS
292 to locate a different entity than the requester intended. The
293 response from the LIS might be accurate, but the request incorrectly
294 associates this information with the wrong subject.
296 A LIS should be configured with information about any potentially
297 temporary identifiers. It can use this information to identify when
298 changes have occurred. A LIS must not provide location information
299 if the identifier it uses might refer to a different Device. If an
300 identifier might have been reassigned recently, or it is likely to be
301 reassigned, it is not suitable as an identifier.
303 It's possible that some degree of uncertainty could persist where
304 identifiers are reassigned frequently; the extent to which errors
305 arising from using transient identifiers are tolerated is a matter
306 for local policy.
308 3.2. Identifier Format and Protocol Details
310 XML elements are used to express the Device identity. The "target"
311 element is used as a general container for identity information.
312 This document defines a basic set of identifiers. An example HELD
313 request, shown in Figure 1, includes an IP version 4 address.
315
See RFCXXXX.
793 794 795 END 797 7.2. XML Schema Registration 799 This section registers an XML schema as per the guidelines in 800 [RFC3688]. 802 URI: urn:ietf:params:xml:schema:geopriv:held:id 804 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 805 James Winterbottom (james.winterbottom@andrew.com). 807 Schema: The XML for this schema can be found as the entirety of 808 Section 4 of this document. 810 7.3. Registration of HELD 'badIdentifier' Error Code 812 This section registers the "badIdentifier" error code in the "Geopriv 813 HELD Registries, Error codes for HELD" IANA registry. 815 badIdentifier This error code indicates that the Device identifiers 816 used in the HELD request were either: not supported by the LIS, 817 badly formatted, or that the requester was not authorized to make 818 a erquest for that identifier. 820 8. Acknowledgements 822 The authors wish to thank the NENA VoIP location working group for 823 their assistance in the definition of the schema used in this 824 document. Special thanks go to Barbara Stark, Guy Caron, Nadine 825 Abbott, Jerome Grenier and Martin Dawson. Bob Sherry provided input 826 on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for 827 providing further corrections. Bernard Aboba provided extensive 828 feedback on use cases and the security model; Bernard, along with 829 Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis 830 provided motivation for the protocol port parameters. Marc Linsner 831 and Alissa Cooper provided guidance and text (respectively) that 832 greatly clarified the discussion on LCPs. 834 9. References 836 9.1. Normative references 838 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 839 Requirement Levels", BCP 14, RFC 2119, March 1997. 841 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 842 and M. Carney, "Dynamic Host Configuration Protocol for 843 IPv6 (DHCPv6)", RFC 3315, July 2003. 845 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 846 January 2004. 848 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 849 Network Access Identifier", RFC 4282, December 2005. 851 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 852 Identifiers for Dynamic Host Configuration Protocol 853 Version Four (DHCPv4)", RFC 4361, February 2006. 855 [I-D.ietf-geopriv-http-location-delivery] 856 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 857 "HTTP Enabled Location Delivery (HELD)", 858 draft-ietf-geopriv-http-location-delivery-16 (work in 859 progress), August 2009. 861 [I-D.ietf-geopriv-l7-lcp-ps] 862 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 863 Location Configuration Protocol; Problem Statement and 864 Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in 865 progress), July 2009. 867 [W3C.REC-xml-names11-20060816] 868 Hollander, D., Bray, T., Layman, A., and R. Tobin, 869 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 870 Consortium Recommendation REC-xml-names11-20060816, 871 August 2006, 872