idnits 2.17.1
draft-ietf-geopriv-held-identity-extensions-06.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 (November 15, 2010) is 4909 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 793 (Obsoleted by RFC 9293)
** 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)
** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260)
-- 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-16
Summary: 6 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: May 19, 2011 H. Tschofenig
6 Nokia Siemens Networks
7 R. Barnes
8 BBN Technologies
9 November 15, 2010
11 Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
12 draft-ietf-geopriv-held-identity-extensions-06
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 May 19, 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 . . . . . . . . . . . . . . . 7
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. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 12
80 3.4. Network Access Identifier . . . . . . . . . . . . . . . . 12
81 3.4.1. Using NAI for Location Configuration . . . . . . . . . 13
82 3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . 28
103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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) [RFC5985] and DHCP ([RFC3825],
115 [RFC4776]) rely on the source IP address or other information present
116 in protocol datagrams to identify a Device.
118 Aside from the datagrams that form a request, a Location Information
119 Server (LIS) does not necessarily have access to information that
120 could further identify the Device. In some circumstances, as shown
121 in [RFC5687], additional identification information can be included
122 in a request to identify a Device.
124 This document extends the HELD protocol to support the inclusion of
125 additional identifiers for the Device in HELD location requests. An
126 XML schema is defined that provides a structure for including these
127 identifiers in HELD requests.
129 An important characteristic of this addition is that the HELD
130 protocol with identity extensions implemented is not considered an
131 LCP. The scope of an LCP is limited to the interaction between a
132 Device and a LIS, and LCPs can guarantee the identity of Devices
133 without additional authorization checks. A LIS identifies the Device
134 making the LCP request using the source addressing on the request
135 packets, using return routability to ensure that these identifiers
136 are not spoofed.
138 HELD with identity extensions allows a requester to explicitly
139 provide identification details in the body of a location request.
140 This means that location requests can be made in cases where
141 additional Device identity checks are necessary, and in cases where
142 the requester is not the Device itself. Third party Location
143 Recipients (LRs) are able to make requests that include identifiers
144 to retrieve location information about a particular Device.
146 The usage of identifiers in HELD introduces a new set of privacy
147 concerns. In an LCP, the requester can be implicitly authorized to
148 access the requested location information, because it is their own
149 location. In contrast, a third party LR must be explicitly
150 authorized when requesting the location of a Device. Establishing
151 appropriate authorization and other related privacy concerns are
152 discussed in Section 4.
154 1.1. Applications
156 This document defines a means to explicitly include Device identity
157 information in the body of a HELD location request. This identity
158 information is used to identify the Device that is the subject (or
159 Target) of the location request. If device identity is present, the
160 identity of the requester in the form of the source IP address is not
161 used to identify the subject of the request.
163 Device identifiers in HELD can be used for two purposes:
165 Location configuration: A Device can use these parameters to
166 identify itself to a LIS. Identification information other than
167 an IP address might be needed to determine the location of a
168 Device.
170 A LIS can authorize location configuration requests using a policy
171 that allows Devices to acquire their own location (see
172 Section 4.1). If an unauthorized third party falsifies addressing
173 on request packets to match the provided Device identity, the
174 request might be erroneously authorized under this policy.
175 Requests containing Device identity MUST NOT be authorized using
176 this policy unless specific measures are taken to prevent this
177 type of attack.
179 This document describes a mechanism that provides assurances that
180 the requester and included Device identity are the same for the
181 Network Access Identifier (NAI) in a WiMAX network. The LIS MUST
182 treat requests containing other identifiers as third party
183 requests, unless it is able to ensure that the provided Device
184 identity is uniquely attributable to the requester.
186 Third party requests: A third party location recipient can be
187 granted authorization to make requests for a given Device. In
188 particular, network services can be permitted to retrieve location
189 for a Device that is unable to acquire location information for
190 itself (see Section 6.3 of [I-D.ietf-ecrit-phonebcp]). This
191 allows use of location-dependent applications - particularly
192 essential services like emergency calling - where Devices do not
193 support a location configuration protocol or they are unable to
194 successfully retrieve location information.
196 This document does not describe how a third party acquires an
197 identifier for a Device, nor how that third party is authorized by
198 a LIS. It is critical that these issues are resolved before
199 permitting a third party request. A pre-arranged contract between
200 the third party, a Rule Maker and the LIS operator is necessary to
201 use Device identifiers in this fashion. This contract must
202 include how the request is authenticated and the set of
203 identifiers (and types of identifiers) that the third party is
204 authorized to use in requests.
206 Automated mechanisms to ensure privacy constraints are respected
207 are possible. For instance, a policy rules document could be used
208 to express the agreed policy. Formal policy documents, such as
209 the common policy [RFC4745], can be applied in an automated
210 fashion by a LIS.
212 1.2. Terminology
214 This document uses the term Location Information Server (LIS) and
215 Location Configuration Protocol (LCP) as described in [RFC5687] and
216 [I-D.ietf-geopriv-arch].
218 The term Device is used specifically as the subject of an LCP,
219 consistent with [RFC5985]. This document also uses the term Target
220 to refer to any entity that might be a subject of the same location
221 information. Target is used in a more general sense, including the
222 Device, but also any nearby entity, such as the user of a Device.
224 A Target has a stake in setting authorization policy on the use of
225 location information. A Rule Maker is the term used for the role
226 that makes policy decisions about authorization, determining what
227 entities are permitted to receive location and how that information
228 is provided.
230 Device, Target and Rule Maker are defined in [I-D.ietf-geopriv-arch].
232 The term "requester" is used in this document to refer to the entity
233 making a HELD request.
235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
237 document are to be interpreted as described in [RFC2119].
239 2. Device Identity
241 Identifiers are used as the starting point in location determination.
242 Identifiers might be associated with a different Device over time,
243 but their purpose is to identify the Device, not to describe its
244 environment or network attachment.
246 2.1. Identifier Suitability
248 Use of any identifier MUST only be allowed if it identifies a single
249 Device at the time that location is determined. The LIS is
250 responsible for ensuring that location information is correct for the
251 Device, which includes ensuring that the identifier is uniquely
252 attributable to the Device.
254 Some identifiers can be either temporary or could potentially
255 identify multiple Devices. Identifiers that are transient or
256 ambiguous could be exploited by an attacker to either gain
257 information about another Device or to coerce the LIS into producing
258 misleading information.
260 The identifiers described in this document MUST only be used where
261 that identifier is used as the basis for location determination.
262 Considerations relating to the use of identifiers for a Device
263 requesting its own location are discussed in Section 5 of [RFC5687];
264 this section discusses use of identifiers for authorized third party
265 requests.
267 It is tempting for a LIS implementation to allow alternative
268 identifiers for convenience or some other perceived benefit. The
269 LIS is responsible for ensuring that the identifier used in the
270 request does not refer to a Device other than the one for which it
271 determines location.
273 Some identifiers are always uniquely attributable to a single Device.
274 However, other identifiers can have a different meaning to different
275 entities on a network. This is especially true for IP addresses
276 [RFC2101], but this can be true for other identifiers to varying
277 degrees. Non-uniqueness arises from both topology (all network
278 entities have a subjective view of the network) and time (the network
279 changes over time).
281 2.1.1. Subjective Network Views
283 Subjective views of the network mean that the identifier a requester
284 uses to refer to one physical entity could actually apply to a
285 different physical entity when used in a different network context.
286 Unless an authorized third party requester and LIS operate in the
287 same network context, each could have a different subjective view of
288 the meaning of the identifier.
290 Where subjective views differ, the third party receives information
291 that is correct only within the network context of the LIS. The
292 location information provided by the LIS is probably misleading: the
293 requester believes that the information relates to a different entity
294 than it was generated for.
296 Authorization policy can be affected by a subjective network view if
297 it is applied based on an identifier, or its application depends on
298 identifiers. The subjective view presented to the LIS and Rule Maker
299 need to agree for the two entities to understand policy on the same
300 terms. For instance, it is possible that the LIS could apply the
301 incorrect authorization policy if it selects the policy using a
302 subjective identifier. Alternatively, it may use the correct policy
303 but apply it incorrectly if subjective identifiers are used.
305 In IP networks, network address translation (NAT) and other forms
306 of address modification create network contexts. Entities on
307 either side of the point where modification occurs have a
308 different view of the network. Private use addresses [RFC1918]
309 are the most easily recognizable identifiers that have limited
310 scope.
312 A LIS can be configured to recognize scenarios where the subjective
313 view of a requester or Rule Maker might not coincide with the view of
314 the LIS. The LIS can either provide location information that takes
315 the view of the requester into account, or it can reject the request.
317 For instance, a LIS might operate within a network that uses a
318 private address space, with NAT between that network and other
319 networks. A third party request that originates in an external
320 network with an IP address from the private address space might
321 not be valid - it could be identifying an entity within another
322 address space. The LIS can be configured to reject such requests,
323 unless it knows by other means that the request is valid.
325 In the same example, the requester might include an address from
326 the external space in an attempt to identify a host within the
327 network. The LIS could use knowledge about how the external
328 address is mapped to a private address, if that mapping is fixed,
329 to determine an appropriate response.
331 The residential gateway scenario in Section 3.1 of [RFC5687] is a
332 particular example of where a subjective view is permitted. The LIS
333 knowingly provides Devices on the remote side of the residential
334 gateway with location information. The LIS provides location
335 information with appropriate uncertainty to allow for the fact that
336 the residential gateway serves a small geographical area.
338 2.1.2. Transient Identifiers
340 Some identifiers are temporary and can, over the course of time, be
341 assigned to different physical entities. An identifier that is
342 reassigned between the time that a request is formulated by a
343 requester and when the request is received by the LIS causes the LIS
344 to locate a different entity than the requester intended. The
345 response from the LIS might be accurate, but the request incorrectly
346 associates this information with the wrong subject.
348 A LIS should be configured with information about any potentially
349 temporary identifiers. It can use this information to identify when
350 changes have occurred. A LIS must not provide location information
351 if the identifier it uses might refer to a different Device. If an
352 identifier might have been reassigned recently, or it is likely to be
353 reassigned, it is not suitable as an identifier.
355 It's possible that some degree of uncertainty could persist where
356 identifiers are reassigned frequently; the extent to which errors
357 arising from using transient identifiers are tolerated is a matter
358 for local policy.
360 2.2. Identifier Format and Protocol Details
362 XML elements are used to express the Device identity. The "device"
363 element is used as a general container for identity information.
364 This document defines a basic set of identifiers. An example HELD
365 request, shown in Figure 1, includes an IP version 4 address.
367 Namespace for HELD Device Identity Parameters
944 urn:ietf:params:xml:ns:geopriv:held:id
945 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
946 with the RFC number for this specification.]]
947
See RFCXXXX.
948 949 950 END 952 7.2. XML Schema Registration 954 This section registers an XML schema as per the guidelines in 955 [RFC3688]. 957 URI: urn:ietf:params:xml:schema:geopriv:held:id 958 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 959 James Winterbottom (james.winterbottom@andrew.com). 961 Schema: The XML for this schema can be found as the entirety of 962 Section 6 of this document. [IANA Note: The pattern attribute for 963 naiType does not contain whitespace.] 965 7.3. Registration of HELD 'badIdentifier' Error Code 967 This section registers the "badIdentifier" error code in the "Geopriv 968 HELD Registries, Error codes for HELD" IANA registry. 970 badIdentifier This error code indicates that a Device identifier 971 used in the HELD request was either: not supported by the LIS, 972 badly formatted, or not one for which the requester was authorized 973 to make a request. 975 8. Acknowledgements 977 The the NENA VoIP location working group provided assistance in the 978 definition of the schema used in this document. Special thanks go to 979 Barbara Stark, Guy Caron, Nadine Abbott, Jerome Grenier and Martin 980 Dawson. Bob Sherry provided input on use of URIs. Thanks to Adam 981 Muhlbauer and Eddy Corbett for providing further corrections. 982 Bernard Aboba provided excellent feedback on use cases and the 983 security model; Bernard, along with Alan DeKok, also helped resolve 984 an issue with NAIs. Ray Bellis provided motivation for the protocol 985 port parameters. Marc Linsner and Alissa Cooper provided guidance 986 and text (respectively) that greatly clarified the discussion 987 relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for 988 forcing this to be practical. 990 9. References 992 9.1. Normative references 994 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 995 August 1980. 997 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 998 September 1981. 1000 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1001 RFC 793, September 1981. 1003 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1004 Requirement Levels", BCP 14, RFC 2119, March 1997. 1006 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1007 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1008 Authentication: Basic and Digest Access Authentication", 1009 RFC 2617, June 1999. 1011 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1012 "Remote Authentication Dial In User Service (RADIUS)", 1013 RFC 2865, June 2000. 1015 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1016 and M. Carney, "Dynamic Host Configuration Protocol for 1017 IPv6 (DHCPv6)", RFC 3315, July 2003. 1019 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1020 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1022 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1023 10646", STD 63, RFC 3629, November 2003. 1025 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1026 January 2004. 1028 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1029 Resource Identifier (URI): Generic Syntax", STD 66, 1030 RFC 3986, January 2005. 1032 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1033 Network Access Identifier", RFC 4282, December 2005. 1035 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1036 Architecture", RFC 4291, February 2006. 1038 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1039 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1041 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 1042 Identifiers for Dynamic Host Configuration Protocol 1043 Version Four (DHCPv4)", RFC 4361, February 2006. 1045 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1046 RFC 4960, September 2007. 1048 [RFC5890] Klensin, J., "Internationalized Domain Names for 1049 Applications (IDNA): Definitions and Document Framework", 1050 RFC 5890, August 2010. 1052 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 1053 RFC 5985, September 2010. 1055 [W3C.REC-xml-names11-20060816] 1056 Hollander, D., Bray, T., Layman, A., and R. Tobin, 1057 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 1058 Consortium Recommendation REC-xml-names11-20060816, 1059 August 2006, 1060