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