idnits 2.17.1
draft-ietf-geopriv-held-identity-extensions-05.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 (October 20, 2010) is 4937 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 2617 (Obsoleted by RFC 7235, RFC 7615,
RFC 7616, RFC 7617)
** 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. 'IEEE802'
-- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64'
-- 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 (-20) exists of
draft-ietf-ecrit-phonebcp-15
Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 6 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 23, 2011 H. Tschofenig
6 Nokia Siemens Networks
7 R. Barnes
8 BBN Technologies
9 October 20, 2010
11 Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
12 draft-ietf-geopriv-held-identity-extensions-05
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 April 23, 2011.
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 . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . 15
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 introduces a new set of privacy
148 concerns. In an LCP, the requester can be implicitly authorized to
149 access the requested location information, because it is their own
150 location. In contrast, a third party LR must be explicitly
151 authorized when requesting the location of a Device. Establishing
152 appropriate authorization and other related privacy concerns are
153 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. For instance, a policy rules document could be used
209 to express the agreed policy. Formal policy documents, such as
210 the common policy [RFC4745], can be applied in an automated
211 fashion by a LIS.
213 1.2. Terminology
215 This document uses the term Location Information Server (LIS) and
216 Location Configuration Protocol (LCP) as described in [RFC5687] and
217 [I-D.ietf-geopriv-arch].
219 The term Device is used specifically as the subject of an LCP,
220 consistent with [I-D.ietf-geopriv-http-location-delivery]. This
221 document also uses the term Target to refer to any entity that might
222 be a subject of the same location information. Target is used in a
223 more general sense, including the Device, but also any nearby entity,
224 such as the user of a Device.
226 A Target has a stake in setting authorization policy on the use of
227 location information. A Rule Maker is the term used for the role
228 that makes policy decisions about authorization, determining what
229 entities are permitted to receive location and how that information
230 is provided.
232 Device, Target and Rule Maker are defined in [I-D.ietf-geopriv-arch].
234 The term "requester" is used in this document to refer to the entity
235 making a HELD request.
237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
239 document are to be interpreted as described in [RFC2119].
241 2. Device Identity
243 Identifiers are used as the starting point in location determination.
244 They should not be confused with measurement information
245 ([I-D.thomson-geopriv-held-measurements]). Measurement information
246 is information about a Device and the time varying details of its
247 network attachment. Identifiers might be associated with a different
248 Device over time, but their purpose is to identify the Device, not to
249 describe its environment or network attachment.
251 2.1. Identifier Suitability
253 Use of any identifier MUST only be allowed if it identifies a single
254 Device at the time that location is determined. The LIS is
255 responsible for ensuring that location information is correct for the
256 Device, which includes ensuring that the identifier is uniquely
257 attributable to the Device.
259 Some identifiers can be either temporary or could potentially
260 identify multiple Devices. Identifiers that are transient or
261 ambiguous could be exploited by an attacker to either gain
262 information about another Device or to coerce the LIS into producing
263 misleading information.
265 The identifiers described in this document MUST only be used where
266 that identifier is used as the basis for location determination.
267 Considerations relating to the use of identifiers for a Device
268 requesting its own location are discussed in Section 5 of [RFC5687];
269 this section discusses use of identifiers for authorized third party
270 requests.
272 It is tempting for a LIS implementation to allow alternative
273 identifiers for convenience or some other perceived benefit. The
274 LIS is responsible for ensuring that the identifier used in the
275 request does not refer to a Device other than the one for which it
276 determines location.
278 Some identifiers are always uniquely attributable to a single Device.
279 However, other identifiers can have a different meaning to different
280 entities on a network. This is especially true for IP addresses
281 [RFC2101], but this can be true for other identifiers to varying
282 degrees. Non-uniqueness arises from both topology (all network
283 entities have a subjective view of the network) and time (the network
284 changes over time).
286 2.1.1. Subjective Network Views
288 Subjective views of the network mean that the identifier a requester
289 uses to refer to one physical entity could actually apply to a
290 different physical entity when used in a different network context.
291 Unless an authorized third party requester and LIS operate in the
292 same network context, each could have a different subjective view of
293 the meaning of the identifier.
295 Where subjective views differ, the third party receives information
296 that is correct only within the network context of the LIS. The
297 location information provided by the LIS is probably misleading: the
298 requester believes that the information relates to a different entity
299 than it was generated for.
301 Authorization policy can be affected by a subjective network view if
302 it is applied based on an identifier, or its application depends on
303 identifiers. The subjective view presented to the LIS and Rule Maker
304 need to agree for the two entities to understand policy on the same
305 terms. For instance, it is possible that the LIS could apply the
306 incorrect authorization policy if it selects the policy using a
307 subjective identifier. Alternatively, it may use the correct policy
308 but apply it incorrectly if subjective identifiers are used.
310 In IP networks, network address translation (NAT) and other forms
311 of address modification create network contexts. Entities on
312 either side of the point where modification occurs have a
313 different view of the network. Private use addresses [RFC1918]
314 are the most easily recognizable identifiers that have limited
315 scope.
317 A LIS can be configured to recognize scenarios where the subjective
318 view of a requester or Rule Maker might not coincide with the view of
319 the LIS. The LIS can either provide location information that takes
320 the view of the requester into account, or it can reject the request.
322 For instance, a LIS might operate within a network that uses a
323 private address space, with NAT between that network and other
324 networks. A third party request that originates in an external
325 network with an IP address from the private address space might
326 not be valid - it could be identifying an entity within another
327 address space. The LIS can be configured to reject such requests,
328 unless it knows by other means that the request is valid.
330 In the same example, the requester might include an address from
331 the external space in an attempt to identify a host within the
332 network. The LIS could use knowledge about how the external
333 address is mapped to a private address, if that mapping is fixed,
334 to determine an appropriate response.
336 The residential gateway scenario in Section 3.1 of [RFC5687] is a
337 particular example of where a subjective view is permitted. The LIS
338 knowingly provides Devices on the remote side of the residential
339 gateway with location information. The LIS provides location
340 information with appropriate uncertainty to allow for the fact that
341 the residential gateway serves a small geographical area.
343 2.1.2. Transient Identifiers
345 Some identifiers are temporary and can, over the course of time, be
346 assigned to different physical entities. An identifier that is
347 reassigned between the time that a request is formulated by a
348 requester and when the request is received by the LIS causes the LIS
349 to locate a different entity than the requester intended. The
350 response from the LIS might be accurate, but the request incorrectly
351 associates this information with the wrong subject.
353 A LIS should be configured with information about any potentially
354 temporary identifiers. It can use this information to identify when
355 changes have occurred. A LIS must not provide location information
356 if the identifier it uses might refer to a different Device. If an
357 identifier might have been reassigned recently, or it is likely to be
358 reassigned, it is not suitable as an identifier.
360 It's possible that some degree of uncertainty could persist where
361 identifiers are reassigned frequently; the extent to which errors
362 arising from using transient identifiers are tolerated is a matter
363 for local policy.
365 2.2. Identifier Format and Protocol Details
367 XML elements are used to express the Device identity. The "device"
368 element is used as a general container for identity information.
369 This document defines a basic set of identifiers. An example HELD
370 request, shown in Figure 1, includes an IP version 4 address.
372 Namespace for HELD Device Identity Parameters
929 urn:ietf:params:xml:ns:geopriv:held:id
930 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
931 with the RFC number for this specification.]]
932
See RFCXXXX.
933 934 935 END 937 7.2. XML Schema Registration 939 This section registers an XML schema as per the guidelines in 940 [RFC3688]. 942 URI: urn:ietf:params:xml:schema:geopriv:held:id 943 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 944 James Winterbottom (james.winterbottom@andrew.com). 946 Schema: The XML for this schema can be found as the entirety of 947 Section 6 of this document. [IANA Note: The pattern attribute for 948 naiType does not contain whitespace.] 950 7.3. Registration of HELD 'badIdentifier' Error Code 952 This section registers the "badIdentifier" error code in the "Geopriv 953 HELD Registries, Error codes for HELD" IANA registry. 955 badIdentifier This error code indicates that a Device identifier 956 used in the HELD request was either: not supported by the LIS, 957 badly formatted, or not one for which the requester was authorized 958 to make a request. 960 8. Acknowledgements 962 The the NENA VoIP location working group provided assistance in the 963 definition of the schema used in this document. Special thanks go to 964 Barbara Stark, Guy Caron, Nadine Abbott, Jerome Grenier and Martin 965 Dawson. Bob Sherry provided input on use of URIs. Thanks to Adam 966 Muhlbauer and Eddy Corbett for providing further corrections. 967 Bernard Aboba provided excellent feedback on use cases and the 968 security model; Bernard, along with Alan DeKok, also helped resolve 969 an issue with NAIs. Ray Bellis provided motivation for the protocol 970 port parameters. Marc Linsner and Alissa Cooper provided guidance 971 and text (respectively) that greatly clarified the discussion 972 relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for 973 forcing this to be practical. 975 9. References 977 9.1. Normative references 979 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 980 September 1981. 982 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 983 Requirement Levels", BCP 14, RFC 2119, March 1997. 985 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 986 Leach, P., Luotonen, A., and L. Stewart, "HTTP 987 Authentication: Basic and Digest Access Authentication", 988 RFC 2617, June 1999. 990 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 991 "Remote Authentication Dial In User Service (RADIUS)", 992 RFC 2865, June 2000. 994 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 995 and M. Carney, "Dynamic Host Configuration Protocol for 996 IPv6 (DHCPv6)", RFC 3315, July 2003. 998 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 999 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1001 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1002 10646", STD 63, RFC 3629, November 2003. 1004 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1005 January 2004. 1007 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1008 Resource Identifier (URI): Generic Syntax", STD 66, 1009 RFC 3986, January 2005. 1011 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1012 Network Access Identifier", RFC 4282, December 2005. 1014 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1015 Architecture", RFC 4291, February 2006. 1017 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 1018 Identifiers for Dynamic Host Configuration Protocol 1019 Version Four (DHCPv4)", RFC 4361, February 2006. 1021 [I-D.ietf-idnabis-defs] 1022 Klensin, J., "Internationalized Domain Names for 1023 Applications (IDNA): Definitions and Document Framework", 1024 draft-ietf-idnabis-defs-13 (work in progress), 1025 January 2010. 1027 [I-D.ietf-geopriv-http-location-delivery] 1028 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 1029 "HTTP Enabled Location Delivery (HELD)", 1030 draft-ietf-geopriv-http-location-delivery-16 (work in 1031 progress), August 2009. 1033 [W3C.REC-xml-names11-20060816] 1034 Hollander, D., Layman, A., Tobin, R., and T. Bray, 1035 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 1036 Consortium Recommendation REC-xml-names11-20060816, 1037 August 2006, 1038