idnits 2.17.1
draft-ietf-geopriv-held-identity-extensions-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
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 (June 21, 2010) is 5056 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)
** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415)
** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733)
** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542)
-- Possible downref: Non-RFC (?) normative reference: ref.
'WiMAX-T33-110-R015v01-B'
-- Obsolete informational reference (is this intentional?): RFC 3825
(Obsoleted by RFC 6225)
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
== Outdated reference: A later version (-03) exists of
draft-ietf-geopriv-arch-02
== Outdated reference: A later version (-20) exists of
draft-ietf-ecrit-phonebcp-14
Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: December 23, 2010 H. Tschofenig
6 Nokia Siemens Networks
7 R. Barnes
8 BBN Technologies
9 June 21, 2010
11 Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
12 draft-ietf-geopriv-held-identity-extensions-04
14 Abstract
16 When a Location Information Server receives a request for location
17 information (using the locationRequest message), described in the
18 base HTTP Enabled Location Delivery (HELD) specification, it uses the
19 source IP address of the arriving message as a pointer to the
20 location determination process. This is sufficient in environments
21 where the location of a Device can be determined based on its IP
22 address.
24 Two additional use cases are addressed by this document. In the
25 first, location configuration requires additional or alternative
26 identifiers from the source IP address provided in the request. In
27 the second, an entity other than the Device requests the location of
28 the Device.
30 This document extends the HELD protocol to allow the location request
31 message to carry Device identifiers. Privacy and security
32 considerations describe the conditions where requests containing
33 identifiers are permitted.
35 Status of this Memo
37 This Internet-Draft is submitted in full conformance with the
38 provisions of BCP 78 and BCP 79.
40 Internet-Drafts are working documents of the Internet Engineering
41 Task Force (IETF). Note that other groups may also distribute
42 working documents as Internet-Drafts. The list of current Internet-
43 Drafts is at http://datatracker.ietf.org/drafts/current/.
45 Internet-Drafts are draft documents valid for a maximum of six months
46 and may be updated, replaced, or obsoleted by other documents at any
47 time. It is inappropriate to use Internet-Drafts as reference
48 material or to cite them other than as "work in progress."
49 This Internet-Draft will expire on December 23, 2010.
51 Copyright Notice
53 Copyright (c) 2010 IETF Trust and the persons identified as the
54 document authors. All rights reserved.
56 This document is subject to BCP 78 and the IETF Trust's Legal
57 Provisions Relating to IETF Documents
58 (http://trustee.ietf.org/license-info) in effect on the date of
59 publication of this document. Please review these documents
60 carefully, as they describe your rights and restrictions with respect
61 to this document. Code Components extracted from this document must
62 include Simplified BSD License text as described in Section 4.e of
63 the Trust Legal Provisions and are provided without warranty as
64 described in the Simplified BSD License.
66 Table of Contents
68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
69 1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 5
70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
71 2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7
72 2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7
73 2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 8
74 2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9
75 2.2. Identifier Format and Protocol Details . . . . . . . . . . 9
76 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 11
77 3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . . . 11
78 3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 11
79 3.3. TCP or UDP Port Number . . . . . . . . . . . . . . . . . . 11
80 3.4. Network Access Identifier . . . . . . . . . . . . . . . . 12
81 3.4.1. Using NAI for Location Configuration . . . . . . . . . 12
82 3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
83 3.6. Fully Qualified Domain Name . . . . . . . . . . . . . . . 14
84 3.7. Cellular Telephony Identifiers . . . . . . . . . . . . . . 14
85 3.8. DHCP Unique Identifier . . . . . . . . . . . . . . . . . . 14
86 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16
87 4.1. Targets Requesting Their Own Location . . . . . . . . . . 16
88 4.2. Third-Party Requests . . . . . . . . . . . . . . . . . . . 17
89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
90 5.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 18
91 5.2. Targets Requesting Their Own Location . . . . . . . . . . 19
92 5.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 19
93 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20
94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
95 7.1. URN Sub-Namespace Registration for
96 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 23
97 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 23
98 7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 24
99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
101 9.1. Normative references . . . . . . . . . . . . . . . . . . . 26
102 9.2. Informative references . . . . . . . . . . . . . . . . . . 27
103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
105 1. Introduction
107 Protocols for requesting and providing location information require a
108 way for the requestor to specify the location that should be
109 returned. In a location configuration protocol (LCP), the location
110 being requested is the requestor's location. This fact can make the
111 problem of identifying the Device simple, since IP datagrams that
112 carry the request already carry an identifier for the Device, namely
113 the source IP address of an incoming request. Existing LCPs, such as
114 HTTP-Enabled Location Delivery (HELD)
115 [I-D.ietf-geopriv-http-location-delivery] and DHCP ([RFC3825],
116 [RFC4776]) rely on the source IP address or other information present
117 in protocol datagrams to identify a Device.
119 Aside from the datagrams that form a request, a location information
120 server (LIS) does not necessarily have access to information that
121 could further identify the Device. In some circumstances, as shown
122 in [RFC5687], additional identification information can be included
123 in a request to identify a Device.
125 This document extends the HELD protocol to support the inclusion of
126 additional identifiers for the Device in HELD location requests. An
127 XML schema is defined that provides a structure for including these
128 identifiers in HELD requests.
130 An important characteristic of this addition is that the HELD
131 protocol with identity extensions implemented is not considered an
132 LCP. The scope of an LCP is limited to the interaction between a
133 Device and a LIS, and LCPs can guarantee the identity of Devices
134 without additional authorization checks. A LIS identifies the Device
135 making the LCP request using the source addressing on the request
136 packets, using return routability to ensure that these identifiers
137 are not spoofed.
139 HELD with identity extensions allows a requester to explicitly
140 provide identification details in the body of a location request.
141 This means that location requests can be made in cases where
142 additional Device identity checks are necessary, and in cases where
143 the requester is not the Device itself. Third-party location
144 recipients (LRs) are able to make requests that include identifiers
145 to retrieve location information about a particular Device.
147 The usage of identifiers in HELD obviously introduces a new set of
148 privacy concerns. In an LCP, the requester can be implicitly
149 authorized to access the requested location information, because it
150 is their own location. In contrast, a third-party LR must be
151 explicitly authorized when requesting the location of a Device.
152 Establishing appropriate authorization and other related privacy
153 concerns are discussed in Section 4.
155 1.1. Applications
157 This document defines a means to explicitly include Device identity
158 information in the body of a HELD location request. This identity
159 information is used to identify the Device that is the subject (or
160 Target) of the location request. If device identity is present, the
161 identity of the requester is not used to identify the subject of the
162 request.
164 Device identifiers in HELD can be used for two purposes:
166 Location configuration: A Device can use these parameters to
167 identify itself to a LIS. Identification information other than
168 an IP address might be needed to determine the location of a
169 Device.
171 A LIS can authorize location configuration requests using a policy
172 that allows Devices to acquire their own location (see
173 Section 4.1). If an unauthorized third-party falsifies addressing
174 on request packets to match the provided Device identity, the
175 request might be erroneously authorized under this policy.
176 Requests containing Device identity must not be authorized using
177 this policy unless specific measures are taken to prevent this
178 type of attack.
180 This document describes a mechanism that provides assurances that
181 the requester and included Device identity are the same for the
182 network access identifier (NAI) in a WiMAX network. The LIS MUST
183 treat requests containing other identifiers as third-party
184 requests, unless it is able to ensure that the provided Device
185 identity is uniquely attributable to the requester.
187 Third-party requests: A third-party location recipient can be
188 granted authorization to make requests for a given Device. In
189 particular, network services can be permitted to retrieve location
190 for a Device that is unable to acquire location information for
191 itself (see Section 6.3 of [I-D.ietf-ecrit-phonebcp]). This
192 allows use of location-dependent applications - particularly
193 essential services like emergency calling - where Devices do not
194 support a location configuration protocol or they are unable to
195 successfully retrieve location information.
197 This document does not describe how a third party acquires an
198 identifier for a Device, nor how that third-party is authorized by
199 a LIS. It is critical that these issues are resolved before
200 permitting a third-party request. A pre-arranged contract between
201 the third-party, a Rule Maker and the LIS operator is necessary to
202 use Device identifiers in this fashion. This contract must
203 include how the request is authenticated and the set of
204 identifiers (and types of identifiers) that the third-party is
205 authorized to use in requests.
207 Automated mechanisms to ensure privacy constraints are respected
208 are possible.
210 1.2. Terminology
212 This document uses the term Location Information Server (LIS) and
213 location configuration protocol (LCP) as described in [RFC5687] and
214 [I-D.ietf-geopriv-arch].
216 The term Device is used specifically as the subject of an LCP,
217 consistent with [I-D.ietf-geopriv-http-location-delivery]. This
218 document also uses the term Target to refer to any entity that might
219 be a subject of the same location information. Target is used in a
220 more general sense, including the Device, but also any nearby entity,
221 such as the user of a Device. A Target has a stake in setting
222 authorization policy on the use of location information. Both Device
223 and Target are defined in [I-D.ietf-geopriv-arch].
225 The term "requester" is used in this document to refer to the entity
226 making a HELD request.
228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
230 document are to be interpreted as described in [RFC2119].
232 2. Device Identity
234 Identifiers are used as the starting point in location determination.
235 They should not be confused with measurement information
236 ([I-D.thomson-geopriv-held-measurements]). Measurement information
237 is information about a Device and the time varying details of its
238 network attachment. Identifiers might be associated with a different
239 Device over time, but their purpose is to identify the Device, not to
240 describe its environment or network attachment.
242 2.1. Identifier Suitability
244 Use of any identifier MUST only be allowed if it identifies a single
245 Device at the time that location is determined. The LIS is
246 responsible for ensuring that location information is correct for the
247 Device, which includes ensuring that the identifier is uniquely
248 attributable to the Device.
250 Some identifiers can be either temporary or could potentially
251 identify multiple Devices. Identifiers that are transient or
252 ambiguous could be exploited by an attacker to either gain
253 information about another Device or to coerce the LIS into producing
254 misleading information.
256 The identifiers described in this document MUST only be used where
257 that identifier is used as the basis for location determination.
258 Considerations relating to the use of identifiers for a Device
259 requesting its own location are discussed in Section 5 of [RFC5687];
260 this section discusses use of identifiers for authorized third-party
261 requests.
263 It is tempting for a LIS implementation to allow alternative
264 identifiers for convenience or some other perceived benefit. The
265 LIS is responsible for ensuring that the identifier used in the
266 request does not refer to a Device other than the one for which it
267 determines location.
269 Some identifiers are always uniquely attributable to a single Device.
270 However, other identifiers can have a different meaning to different
271 entities on a network. This is especially true for IP addresses
272 [RFC2101], but this can be true for other identifiers to varying
273 degrees. Non-uniqueness arises from both topology (all network
274 entities have a subjective view of the network) and time (the network
275 changes over time).
277 2.1.1. Subjective Network Views
279 Subjective views of the network mean that the identifier a requester
280 uses to refer to one physical entity could actually apply to a
281 different physical entity when used in a different network context.
282 Unless an authorized third-party requester and LIS operate in the
283 same network context, each could have a different subjective view of
284 the meaning of the identifier.
286 Where subjective views differ, the third-party receives information
287 that is correct only within the network context of the LIS. The
288 location information provided by the LIS is probably misleading: the
289 requester believes that the information relates to a different entity
290 than it was generated for.
292 Authorization policy can be affected by a subjective network view if
293 it is applied based on an identifier, or its application depends on
294 identifiers. The subjective view presented to the LIS and Rule Maker
295 need to agree for the two entities to understand policy on the same
296 terms. For instance, it is possible that the LIS could apply the
297 incorrect authorization policy if it selects the policy using a
298 subjective identifier. Alternatively, it may use the correct policy
299 but apply it incorrectly if subjective identifiers are used.
301 In IP networks, network address translation (NAT) and other forms
302 of address modification create network contexts. Entities on
303 either side of the point where modification occurs have a
304 different view of the network. Private use addresses [RFC1918]
305 are the most easily recognizable identifiers that have limited
306 scope.
308 A LIS can be configured to recognize scenarios where the subjective
309 view of a requester or Rule Maker might not coincide with the view of
310 the LIS. The LIS can either provide location information that takes
311 the view of the requester into account, or it can reject the request.
313 For instance, a LIS might operate within a network that uses a
314 private address space, with NAT between that network and other
315 networks. A third-party request that originates in an external
316 network with an IP address from the private address space might
317 not be valid - it could be identifying an entity within another
318 address space. The LIS can be configured to reject such requests,
319 unless it knows by other means that the request is valid.
321 In the same example, the requester might include an address from
322 the external space in an attempt to identify a host within the
323 network. The LIS could use knowledge about how the external
324 address is mapped to a private address, if that mapping is fixed,
325 to determine an appropriate response.
327 The residential gateway scenario in Section 3.1 of [RFC5687] is a
328 particular example of where a subjective view is permitted. The LIS
329 knowingly provides Devices on the remote side of the residential
330 gateway with location information. The LIS provides location
331 information with appropriate uncertainty to allow for the fact that
332 the residential gateway serves a small geographical area.
334 2.1.2. Transient Identifiers
336 Some identifiers are temporary and can, over the course of time, be
337 assigned to different physical entities. An identifier that is
338 reassigned between the time that a request is formulated by a
339 requester and when the request is received by the LIS causes the LIS
340 to locate a different entity than the requester intended. The
341 response from the LIS might be accurate, but the request incorrectly
342 associates this information with the wrong subject.
344 A LIS should be configured with information about any potentially
345 temporary identifiers. It can use this information to identify when
346 changes have occurred. A LIS must not provide location information
347 if the identifier it uses might refer to a different Device. If an
348 identifier might have been reassigned recently, or it is likely to be
349 reassigned, it is not suitable as an identifier.
351 It's possible that some degree of uncertainty could persist where
352 identifiers are reassigned frequently; the extent to which errors
353 arising from using transient identifiers are tolerated is a matter
354 for local policy.
356 2.2. Identifier Format and Protocol Details
358 XML elements are used to express the Device identity. The "device"
359 element is used as a general container for identity information.
360 This document defines a basic set of identifiers. An example HELD
361 request, shown in Figure 1, includes an IP version 4 address.
363
See RFCXXXX.
906 907 908 END 910 7.2. XML Schema Registration 912 This section registers an XML schema as per the guidelines in 913 [RFC3688]. 915 URI: urn:ietf:params:xml:schema:geopriv:held:id 917 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 918 James Winterbottom (james.winterbottom@andrew.com). 920 Schema: The XML for this schema can be found as the entirety of 921 Section 6 of this document. [IANA Note: The pattern attribute for 922 naiType does not contain whitespace.] 924 7.3. Registration of HELD 'badIdentifier' Error Code 926 This section registers the "badIdentifier" error code in the "Geopriv 927 HELD Registries, Error codes for HELD" IANA registry. 929 badIdentifier This error code indicates that a Device identifier 930 used in the HELD request was either: not supported by the LIS, 931 badly formatted, or not one for which the requester was authorized 932 to make a request. 934 8. Acknowledgements 936 The the NENA VoIP location working group provided assistance in the 937 definition of the schema used in this document. Special thanks go to 938 Barbara Stark, Guy Caron, Nadine Abbott, Jerome Grenier and Martin 939 Dawson. Bob Sherry provided input on use of URIs. Thanks to Adam 940 Muhlbauer and Eddy Corbett for providing further corrections. 941 Bernard Aboba provided excellent feedback on use cases and the 942 security model; Bernard, along with Alan DeKok, also helped resolve 943 an issue with NAIs. Ray Bellis provided motivation for the protocol 944 port parameters. Marc Linsner and Alissa Cooper provided guidance 945 and text (respectively) that greatly clarified the discussion 946 relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for 947 forcing this to be practical. 949 9. References 951 9.1. Normative references 953 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 954 Requirement Levels", BCP 14, RFC 2119, March 1997. 956 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 957 "Remote Authentication Dial In User Service (RADIUS)", 958 RFC 2865, June 2000. 960 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 961 and M. Carney, "Dynamic Host Configuration Protocol for 962 IPv6 (DHCPv6)", RFC 3315, July 2003. 964 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 965 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 967 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 968 January 2004. 970 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 971 Network Access Identifier", RFC 4282, December 2005. 973 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 974 Identifiers for Dynamic Host Configuration Protocol 975 Version Four (DHCPv4)", RFC 4361, February 2006. 977 [I-D.ietf-idnabis-defs] 978 Klensin, J., "Internationalized Domain Names for 979 Applications (IDNA): Definitions and Document Framework", 980 draft-ietf-idnabis-defs-13 (work in progress), 981 January 2010. 983 [I-D.ietf-geopriv-http-location-delivery] 984 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 985 "HTTP Enabled Location Delivery (HELD)", 986 draft-ietf-geopriv-http-location-delivery-16 (work in 987 progress), August 2009. 989 [W3C.REC-xml-names11-20060816] 990 Tobin, R., Hollander, D., Bray, T., and A. Layman, 991 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 992 Consortium Recommendation REC-xml-names11-20060816, 993 August 2006, 994