idnits 2.17.1 draft-ietf-geopriv-held-identity-extensions-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2009) is 5303 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4388' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'LLDP' is defined on line 920, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-l7-lcp-ps (ref. 'I-D.ietf-geopriv-l7-lcp-ps') -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) == Outdated reference: A later version (-03) exists of draft-ietf-geopriv-arch-00 == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-13 == Outdated reference: A later version (-06) exists of draft-thomson-geopriv-held-measurements-04 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geopriv J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: Standards Track Andrew Corporation 5 Expires: April 21, 2010 H. Tschofenig 6 Nokia Siemens Networks 7 R. Barnes 8 BBN Technologies 9 October 18, 2009 11 Use of Device Identity in HTTP-Enabled Location Delivery (HELD) 12 draft-ietf-geopriv-held-identity-extensions-01 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 21, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 When a Location Information Server receives a request for location 51 information (using the locationRequest message), described in the 52 base HTTP Enabled Location Delivery (HELD) specification, it uses the 53 source IP address of arriving message as a pointer to the location 54 determination process. This is sufficient in environments where the 55 location of a Device can be determined based on its IP address. 57 Two additional use cases are addresses by this document. In the 58 first, location configuration requires additional or alternative 59 identifiers from the source IP address provided in the request. In 60 the second, an entity other than the Device requests the location of 61 the Device. 63 This document extends the HELD protocol to allow the location request 64 message to carry Device identifiers. Privacy and security 65 considerations describe the conditions where requests containing 66 identifiers are permitted. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7 75 3.1.1. Subjective Network Views . . . . . . . . . . . . . . . 7 76 3.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9 77 3.2. Identifier Format and Protocol Details . . . . . . . . . . 9 78 3.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . 10 80 3.3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . 10 81 3.3.3. TCP or UDP Port Number . . . . . . . . . . . . . . . . 11 82 3.3.4. Network Access Identifier . . . . . . . . . . . . . . 11 83 3.3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 3.3.6. Hostname . . . . . . . . . . . . . . . . . . . . . . . 12 85 3.3.7. Directory Number . . . . . . . . . . . . . . . . . . . 12 86 3.3.8. Cellular Telephony Identifiers . . . . . . . . . . . . 12 87 3.3.9. DHCP Unique Identifier . . . . . . . . . . . . . . . . 13 88 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 17 90 5.1. Targets Requesting Their Own Location . . . . . . . . . . 17 91 5.2. Third-Party Requests . . . . . . . . . . . . . . . . . . . 18 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 6.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 19 94 6.2. Targets Requesting Their Own Location . . . . . . . . . . 19 95 6.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 20 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 97 7.1. URN Sub-Namespace Registration for 98 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 21 99 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 21 100 7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 22 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 9.1. Normative references . . . . . . . . . . . . . . . . . . . 24 104 9.2. Informative references . . . . . . . . . . . . . . . . . . 24 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 107 1. Introduction 109 Protocols for requesting and providing location information require a 110 way for the requestor to specify the location that should be 111 returned. In a location configuration protocol (LCP), the location 112 being requested is the requestor's location. This fact can make the 113 problem of identifying the Device simple for LCPs, since IP datagrams 114 that carry the request already carry an identifier for the Device, 115 namely the source IP address of an incoming request. Existing LCPs, 116 such as HELD [I-D.ietf-geopriv-http-location-delivery] and DHCP 117 ([RFC3825], [RFC4776]) rely on the source IP address or other 118 information present in protocol datagrams to identify a Device. 120 Aside from the datagrams that form a request, a location information 121 server (LIS) does not necessarily have access to information that 122 could further identify the Device. In some circumstances, as shown 123 in [I-D.ietf-geopriv-l7-lcp-ps], additional identification 124 information can be included in a request to identify a Device. 126 This document extends the HELD protocol to support the inclusion of 127 additional identifiers for the Device in HELD location requests. An 128 XML schema is defined that provides a structure for including these 129 identifiers in HELD requests. 131 An important characteristic of this addition is that the HELD 132 protocol with identity extensions implemented is not considered an 133 LCP. The scope of an LCP is limited to the interaction between a 134 Device and a LIS, and LCPs can guarantee the identity of Devices 135 without additional authorization checks. Neither of these is true 136 for HELD with identity extensions. Furthermore, identity extensions 137 allow authorized third-party location recipients (LRs) to make 138 requests that include identifiers to retrieve location information 139 about a particular Device. 141 The usage of identifiers in HELD obviously introduces a new set of 142 privacy concerns. In an LCP, the requester can be implicitly 143 authorized to access the requested location information, because it 144 is their own location. In contrast, a third-party LR must be 145 explicitly authorized when requesting the location of a Device. 146 Establishing appropriate authorization and other related privacy 147 concerns are discussed in Section 5. 149 1.1. Applications 151 The use of additional identifiers in HELD falls into two categories: 153 1. A Device can use these parameters to provide additional 154 identification information about itself to a LIS. Identification 155 information, such as the MAC address of the interface card of a 156 Target, can be used to reduce the time required to determine the 157 location by a LIS. In other cases, a LIS might require Device 158 identification before any location information can be generated. 160 2. A third-party LR can be granted authorization to make requests 161 for a given Device. In particular, network services can be 162 permitted to retrieve location for a Device that is unable to 163 acquire location information for itself (see Section 6.3 of 164 [I-D.ietf-ecrit-phonebcp]). This allows use of location- 165 dependent applications - particularly essential services like 166 emergency calling - where Devices do not support a location 167 configuration protocol (LCP) or they are unable to successfully 168 retrieve location information. 170 2. Terminology 172 This document uses the term Location Information Server (LIS) and 173 location configuration protocol (LCP) as described in 174 [I-D.ietf-geopriv-l7-lcp-ps]. 176 The term Device is used specifically as the subject of an LCP, 177 consistent with [I-D.ietf-geopriv-http-location-delivery]. This 178 document also uses the term Target to refer to any entity that might 179 be a subject of the same location information. Target is used in a 180 more general sense, including the Device, but also any nearby entity, 181 such as the user of a Device. A Target has a stake in setting 182 authorization policy on the use of location information. Both Device 183 and Target are defined in [RFC3693]. 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 3. Device Identity 191 Identifiers are used as the starting point in location determination. 192 They should not be confused with measurement information 193 ([I-D.thomson-geopriv-held-measurements]). Measurement information 194 is information about a Device and the time varying details of its 195 network attachment. Identifiers might be associated with a different 196 Device over time, but the their purpose is to identify the Device, 197 not to describe its environment or network attachment. 199 3.1. Identifier Suitability 201 Use of any identifier MUST only be allowed if it identifies a single 202 Device at a particular time. In some circumstances, certain of these 203 identifiers are either temporary or could potentially identify 204 multiple devices. Identifiers that are transient or ambiguous could 205 be exploited by an attacker to either gain information about another 206 device or to coerce the LIS into producing misleading information. 208 The identifiers described in this section MUST only be used where 209 that identifier is used as the basis for location determination. 210 Considerations relating to the use of identifiers for a Device 211 requesting its own location are discussed in Section 5 of 212 [I-D.ietf-geopriv-l7-lcp-ps]; this section discusses use of 213 identifiers for authorized third-party requests. 215 It is tempting for a LIS implementation to allow alternative 216 identifiers for convenience or some other perceived benefit. 217 However, care needs to be taken to ensure that the binding between 218 the indicated identifier and the identifier that is used for 219 location determination is unique and not subject to attacks. 221 Identifiers can have a different meaning to different entities on a 222 network. An identifier in one network context might have a 223 completely different meaning in a different context. Errors in 224 perspective arise in both topology (all network entities have a 225 subjective view of the network) and time (the network changes over 226 time). 228 3.1.1. Subjective Network Views 230 Subjective views of the network mean that the identifier a requests 231 uses to refer to one physical entity could actually apply to a 232 different physical entity when used in a different network context. 233 Unless an authorized third-party requester and LIS operate in the 234 same network context, each could have a different subjective view of 235 the meaning of the identifier. 237 Where subjective views differ, the third-party receives information 238 that is correct only within the network context of the LIS. The 239 location information provided by the LIS is probably misleading: the 240 requester believes that the information relates to a different entity 241 than it was generated for. 243 Authorization policy can be affected by a subjective network view if 244 it is applied based on an identifier, or it's application depends on 245 identifiers. The subjective view presented to the LIS and Rule Maker 246 need to agree for the two entities to understand policy on the same 247 terms. For instance, it is possible that the authorization policy 248 applied by the LIS is entirely incorrect if authorization policy is 249 selected using a subjective identifier. Alternatively, policy might 250 be incorrectly applied if identifiers differ. 252 In IP networks, network address translation (NAT) and other forms 253 of address modification create network contexts. Entities on 254 either side of the point where modification occurs have a 255 different view of the network. Private use addresses [RFC1918] 256 are the most easily recognizable identifiers that have limited 257 scope. 259 A LIS can be configured to recognize scenarios where the subjective 260 view of a requester or Rule Maker might not coincide with the view of 261 the LIS. The LIS can either provide location information that takes 262 the view of the requester into account, or it can reject the request. 264 For instance, a LIS might operate within a network that uses a 265 private address space, with NAT between that network and other 266 networks. A third-party request that originates in an external 267 network with an IP address from the private address space might 268 not be valid - it could be identifying an entity within another 269 address space. The LIS can be configured to reject such requests, 270 unless it knows by other means that the request is valid. 272 In the same example, the requester might include an address from 273 the external space in an attempt to identify a host within the 274 network. The LIS could use knowledge about how the external 275 address is mapped to a private address, if that mapping is fixed, 276 to determine an appropriate response. 278 The residential gateway scenario in Section 3.1 of 279 [I-D.ietf-geopriv-l7-lcp-ps] is a particular example of where a 280 subjective view is permitted. The LIS knowingly provides Devices on 281 the remote side of the residential gateway with location information. 282 The LIS provides location information with appropriate uncertainty to 283 allow for the fact that the residential gateway serves a small 284 geographical area. 286 3.1.2. Transient Identifiers 288 Some identifiers are temporary and can, over the course of time, be 289 assigned to different physical entities. An identifier that is 290 reassigned between the time that a request is formulated by a 291 requester and when the request is received by the LIS causes the LIS 292 to locate a different entity than the requester intended. The 293 response from the LIS might be accurate, but the request incorrectly 294 associates this information with the wrong subject. 296 A LIS should be configured with information about any potentially 297 temporary identifiers. It can use this information to identify when 298 changes have occurred. A LIS must not provide location information 299 if the identifier it uses might refer to a different Device. If an 300 identifier might have been reassigned recently, or it is likely to be 301 reassigned, it is not suitable as an identifier. 303 It's possible that some degree of uncertainty could persist where 304 identifiers are reassigned frequently; the extent to which errors 305 arising from using transient identifiers are tolerated is a matter 306 for local policy. 308 3.2. Identifier Format and Protocol Details 310 XML elements are used to express the Device identity. The "target" 311 element is used as a general container for identity information. 312 This document defines a basic set of identifiers. An example HELD 313 request, shown in Figure 1, includes an IP version 4 address. 315 317 geodetic 318 319 192.0.2.5 320 321 323 Figure 1 325 A LIS that supports this specification echoes the "target" element in 326 a successful HELD response, including the identifiers that were used 327 as the basis for location determination. Absence of this indication 328 means that the location information was generated using the source IP 329 address in the request. 331 If an identifier is invalid, not supported by the LIS, or the 332 requester is not authorized to use that identifier, a HELD error 333 response of "badIdentifier". This code is registered in Section 7.3. 335 If the LIS requires an identifier that is not provided in the 336 request, the desired identifiers MAY be identified in the HELD error 337 response, using the "requiredIdentifiers" element. This element 338 contains a list of XML qualified names [W3C.REC-xml-names11-20060816] 339 that identify the identifier elements required by the LIS. Namespace 340 prefix bindings for the qualified names are taken from document 341 context. Figure 2 shows an example error indicating that the 342 requester needs to include a MAC address (Section 3.3.2) if the 343 request is to succeed. 345 347 MAC address required 348 350 mac 351 352 354 Figure 2 356 3.3. Identifiers 358 A limited selection of identifiers are included in this document. 359 The basic Device identity schema allows for the inclusion of elements 360 from any namespace, therefore additional elements can be defined 361 using different XML namespaces. 363 3.3.1. IP Address 365 The "ip" element can express a Device identity as an IP address. An 366 optional "v" attribute identifies the IP version. The element uses 367 the textual format specific to the indicated IP version. 369 370 2001:DB8::1:ea7:fee1:d1e 371 373 In situations where location configuration does not require 374 additional identifiers, using IP address as an identifier enables 375 authorized third-party requests. 377 3.3.2. MAC Address 379 The media access control (MAC) address used by the IEEE 802 family of 380 access technologies is an identifier that is assigned to a particular 381 network device. A MAC address is a unique sequence that is either 382 assigned at the time of manufacture of a device, or assigned by a 383 local administrator. A MAC address rarely changes; therefore, a MAC 384 address is an appropriate identifier for a Device. 386 387 A0-12-34-56-78-90 388 390 A LIS that operates on the same layer 2 segment as a Device sees the 391 MAC address of the Device and can authenticate the device in that 392 fashion. If a router is interposed between LIS and Device, other 393 means of authentication are required. 395 3.3.3. TCP or UDP Port Number 397 On its own, a TCP or UDP port number is insufficient to uniquely 398 identify a single host, but in combination with an IP address, it can 399 be used in some environments to uniquely identify a Device. 401 Use of a particular port number can be transient; often significantly 402 more than use of any given IP address. However, widespread use of 403 network address translation (NAT) means that some Devices cannot be 404 uniquely identified by IP address alone. An individual Device might 405 be identified by a flow of packets that it generates. Providing that 406 a LIS has sufficient knowledge of the mappings used by the NAT, an 407 individual target on the remote side of the NAT might be able to be 408 identified uniquely. 410 411 2001:DB8::1:ea7:fee1:d1e 412 51393 413 415 Use of port numbers is especially reliant on the value remaining 416 consistent over time. 418 3.3.4. Network Access Identifier 420 A Network Access Identifier (NAI) [RFC4282] is an identifier used in 421 network authentication in a range of networks. The identifier 422 establishes a user identity within a particular domain. Often, 423 network services use an NAI in relation to location records, tying 424 network access to user authentication and authorization. 426 427 user@example.net 428 430 The formal grammar for NAI [RFC4282] permits invalid Unicode, which 431 cannot be expressed using XML. Therefore, this expression of NAI 432 permits escaping. Non-unicode characters (and any other character) 433 are expressed using a backslash ('\') followed by two hexadecimal 434 digits representing the value of a single octet. 436 The canonical representation of an NAI is the sequence of octets that 437 is produced from the concatenation of UTF-8 encoded sequences of 438 unescaped characters and octets derived from escaped components. 439 This sequence MUST conform to the constraints in [RFC4282]. 441 3.3.5. URI 443 A Device can be identified by a URI. Any URI can be used providing 444 that the requester and LIS have a common understanding of the 445 semantics implied by use of the URI. 447 448 sip:user@example.net;gr=kjh29x97us97d 449 451 3.3.6. Hostname 453 A domain name can be used as the basis for identification using the 454 "hostname" element. 456 457 host.example.net 458 460 3.3.7. Directory Number 462 Telephony devices are typically identified by the number that is used 463 to reach them. Within enterprises, where globally accessible 464 telephone numbers might not be used, a directory number is the usual 465 form of identification. 467 468 7515 469 471 3.3.8. Cellular Telephony Identifiers 473 A range of different forms of mobile station identifiers are used for 474 different cellular telephony systems. Elements are defined for these 475 identifiers. The following identifiers are defined: 477 msisdn: The Mobile Subscriber Integrated Services Digital Network 478 Number (MSISDN) is an E.164 number between 6 and 15 digits long. 480 imsi: The International Mobile Subscriber Identity (IMSI) an 481 identifier associated with all GSM and UMTS mobile subscribers. 483 imei: The International Mobile Equipment Identifier (IMEI) is a 484 unique device serial number up to 15 digits long. 486 min: The Mobile Identification Number (MIN) is a unique number 487 assigned to CDMA handsets. 489 mdn: The Mobile Directory Number (MDN) is an E.164 number, with 490 usage similar to MSISDN. 492 493 11235550123 494 496 3.3.9. DHCP Unique Identifier 498 The Dynamic Host Configuration Protocol (DHCP) uses a binary 499 identifier for its clients. The DHCP Unique Identifier (DUID) is 500 expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of 501 DHCPv6 and follows the format defined in Section 9 of [RFC3315]. The 502 "duid" element includes the binary value of the DUID expressed in 503 hexadecimal. 505 506 1234567890AaBbCcDdEeFf 507 509 4. XML Schema 511 512 518 519 520 521 522 524 525 527 528 529 530 532 533 534 535 536 537 538 539 540 541 542 543 544 545 547 548 549 550 551 552 554 555 556 557 558 559 560 562 564 566 567 568 569 570 571 573 574 575 576 579 581 582 584 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 606 608 610 5. Privacy Considerations 612 Location configuration protocols can make use of an authorization 613 model known as "LCP policy", which permits only Targets to be the 614 recipients of their own locations. In effect, an LCP server (that 615 is, the LIS) follows a single rule policy that states that the Target 616 is the only authorized Location Recipient. 618 The security and privacy considerations of the base HELD protocol 619 [I-D.ietf-geopriv-http-location-delivery] are applicable, except as 620 they relate to return routability. 622 5.1. Targets Requesting Their Own Location 624 When a Target uses identity extensions to obtain its own location, 625 HELD can no longer be considered an LCP. The authorization policy 626 that the LIS uses to respond to these requests must be provisioned by 627 one or more Rule Makers. 629 In the case that the LIS exclusively provides Targets with their own 630 locations, the LIS can still be said to be following the "LCP 631 policy". In all cases, the Geopriv security and privacy 632 considerations [I-D.ietf-geopriv-arch] are applicable. 634 The spoofing protections provided when using HELD with identity 635 extensions to provide Targets with their own locations differ from 636 the protections inherent in an LCP. For an LCP, return routability 637 is considered sufficient protection against spoofing. A similar 638 degree of assurance is required if a similar policy is to be used. 640 A Rule Maker might require additional verification that the 641 identifier is owned by the requester. Verification that depends on 642 return routability can only provide weaker assurances than those 643 provided by return routability; therefore, policy might require the 644 use of additional, independent methods of verification. 646 Care is required where a direct one-to-one relationship between 647 requester and Device identity does not exist. If identifiers are not 648 identical, the use of HELD identity extensions to provide Targets 649 with their own locations could be exploited by an attacker. 651 For example, it is not appropriate to provide Targets with their 652 own locations under these terms where a requester is authenticated 653 by NAI and the supplied Device identity is a MAC address, even if 654 that MAC address is currently registered with the network under 655 the given NAI. In this case, the requester might be requesting 656 from a different MAC address registered under the same NAI. The 657 correct way of gaining authorization is to establish a policy that 658 permits this particular request as a third party request. 660 5.2. Third-Party Requests 662 The LCP policy does not allow requests made by third parties. If a 663 LIS permits requests from third parties using Device identity, it 664 assumes the rule of a Location Server (LS). As a Location Server, 665 the LIS MUST explicitly authorize requests according to the policies 666 that are provided by Rule Makers, including the Target. This 667 includes authentication of requesters where required by the 668 authorization policies. 670 An organization that provides a LIS that allows third party requests 671 must provide a means for a Rule Maker to specify authorization 672 policies as part of the LIS implementation (e.g, in the form of 673 access control lists). Authorization must be established before 674 allowing third party requests for the location of any Target. Until 675 an authorization policy is established, the LIS MUST reject requests 676 by third parties (that is, the default policy is "deny all"). 678 When the LIS is operated by an access network, the relationship 679 between the Target and the LIS can be transient. However, the 680 process of establishing network access usually results in a form of 681 agreement between the Target and the network provider. This process 682 offers a natural vehicle for establishing location privacy policies. 683 Establishing authorization policy might be a manual process, an 684 explicit part of the terms of service for the network, or an 685 automated system that accepts formal authorization policies (see 686 [RFC4745], [RFC4825]). This document does not mandate any particular 687 mechanism for establishing an authorization policy. 689 6. Security Considerations 691 The security considerations in 692 [I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for 693 server authentication, confidentiality and protection from 694 modification. These protections apply to both Target requests for 695 their own locations and requests made by third parties. 697 All HELD requests containing identity MUST be authenticated by the 698 LIS. How authentication is accomplished and what assurances are 699 desired is a matter for policy. 701 The base HELD protocol uses return reachability of an IP address 702 implied by the requester being able to successfully complete a TCP 703 handshake. It is RECOMMENDED that any means of authentication 704 provide at least this degree of assurance. For requests that include 705 Device identity, the LIS MUST support authentication of TLS clients. 707 6.1. Identifier Suitability 709 Transient and ambiguous identifiers can be exploited by malicious 710 requests and are not suitable as a basis for identifying a Device. 711 Section 3.1 provides further discussion on this subject. 713 Identifier transience of can lead to incorrect location information 714 being provided. An attacker could exploit the use of transient 715 identifiers. In this attack, the attacker either knows of a re- 716 allocation of that identifier or is able to force the identifier to 717 be re-allocated during the processing of the request. 719 An attacker could use this to acquire location information for 720 another Device or to coerce the LIS to lie on its behalf if this re- 721 allocation occurs between the time where authorization is granted and 722 location information is granted. 724 Ambiguous identifiers present a similar problem. An attacker could 725 legitimately gain authorization to use a particular identifier. 726 Since an ambiguous identifier potentially refers to multiple Devices, 727 if authorization is granted for one of those Devices, an attacker 728 potentially gains access to location information for all of those 729 Devices. 731 6.2. Targets Requesting Their Own Location 733 Requests made by a Device for its own location are covered by the 734 same set of protections offered by HELD. These requests might be 735 authorized under a policy similar to the "LCP policy" that permits a 736 Target access to location information about itself. 738 Identity information provided by the Device is private data that 739 might be sensitive. The Device provides this information in the 740 expectation that it assists the LIS in providing the Device a 741 service. The LIS MUST NOT use identity information for any other 742 purpose other than serving the request that includes that 743 information. 745 6.3. Third-Party Requests 747 Requests from third parties have the same requirements for server 748 authentication, confidentiality and protection from modification as 749 Target requests for their own locations. However, because the third- 750 party needs to be authorized, the requester MUST be authenticated by 751 the LIS. In addition, third-party requests MUST be explicitly 752 authorized by a policy that is established by a Rule Maker. 754 More detail on the privacy implications of third-party requests are 755 covered in Section 5. 757 7. IANA Considerations 759 This document registers an XML namespace and schema with IANA in 760 accordance with guidelines in [RFC3688]. It also creates a new 761 registry for device identity types, and stipulates how new types are 762 to be added. 764 7.1. URN Sub-Namespace Registration for 765 urn:ietf:params:xml:ns:geopriv:held:id 767 This section registers a new XML namespace, 768 "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in 769 [RFC3688]. 771 URI: urn:ietf:params:xml:ns:geopriv:held:id 773 Registrant Contact: IETF, GEOPRIV working group, 774 (geopriv@ietf.org), James Winterbottom 775 (james.winterbottom@andrew.com). 777 XML: 779 BEGIN 780 781 783 784 785 HELD Device Identity Parameters 786 787 788

Namespace for HELD Device Identity Parameters

789

urn:ietf:params:xml:ns:geopriv:held:id

790 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 791 with the RFC number for this specification.]] 792

See RFCXXXX.

793 794 795 END 797 7.2. XML Schema Registration 799 This section registers an XML schema as per the guidelines in 800 [RFC3688]. 802 URI: urn:ietf:params:xml:schema:geopriv:held:id 804 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 805 James Winterbottom (james.winterbottom@andrew.com). 807 Schema: The XML for this schema can be found as the entirety of 808 Section 4 of this document. 810 7.3. Registration of HELD 'badIdentifier' Error Code 812 This section registers the "badIdentifier" error code in the "Geopriv 813 HELD Registries, Error codes for HELD" IANA registry. 815 badIdentifier This error code indicates that the Device identifiers 816 used in the HELD request were either: not supported by the LIS, 817 badly formatted, or that the requester was not authorized to make 818 a erquest for that identifier. 820 8. Acknowledgements 822 The authors wish to thank the NENA VoIP location working group for 823 their assistance in the definition of the schema used in this 824 document. Special thanks go to Barbara Stark, Guy Caron, Nadine 825 Abbott, Jerome Grenier and Martin Dawson. Bob Sherry provided input 826 on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for 827 providing further corrections. Bernard Aboba provided extensive 828 feedback on use cases and the security model; Bernard, along with 829 Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis 830 provided motivation for the protocol port parameters. Marc Linsner 831 and Alissa Cooper provided guidance and text (respectively) that 832 greatly clarified the discussion on LCPs. 834 9. References 836 9.1. Normative references 838 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 839 Requirement Levels", BCP 14, RFC 2119, March 1997. 841 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 842 and M. Carney, "Dynamic Host Configuration Protocol for 843 IPv6 (DHCPv6)", RFC 3315, July 2003. 845 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 846 January 2004. 848 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 849 Network Access Identifier", RFC 4282, December 2005. 851 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 852 Identifiers for Dynamic Host Configuration Protocol 853 Version Four (DHCPv4)", RFC 4361, February 2006. 855 [I-D.ietf-geopriv-http-location-delivery] 856 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 857 "HTTP Enabled Location Delivery (HELD)", 858 draft-ietf-geopriv-http-location-delivery-16 (work in 859 progress), August 2009. 861 [I-D.ietf-geopriv-l7-lcp-ps] 862 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 863 Location Configuration Protocol; Problem Statement and 864 Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in 865 progress), July 2009. 867 [W3C.REC-xml-names11-20060816] 868 Hollander, D., Bray, T., Layman, A., and R. Tobin, 869 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 870 Consortium Recommendation REC-xml-names11-20060816, 871 August 2006, 872 . 874 9.2. Informative references 876 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 877 E. Lear, "Address Allocation for Private Internets", 878 BCP 5, RFC 1918, February 1996. 880 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 881 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 883 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 884 Configuration Protocol Option for Coordinate-based 885 Location Configuration Information", RFC 3825, July 2004. 887 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 888 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 890 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 891 Polk, J., and J. Rosenberg, "Common Policy: A Document 892 Format for Expressing Privacy Preferences", RFC 4745, 893 February 2007. 895 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 896 (DHCPv4 and DHCPv6) Option for Civic Addresses 897 Configuration Information", RFC 4776, November 2006. 899 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 900 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 902 [I-D.ietf-geopriv-arch] 903 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 904 Tschofenig, H., and H. Schulzrinne, "An Architecture for 905 Location and Location Privacy in Internet Applications", 906 draft-ietf-geopriv-arch-00 (work in progress), July 2009. 908 [I-D.ietf-ecrit-phonebcp] 909 Rosen, B. and J. Polk, "Best Current Practice for 910 Communications Services in support of Emergency Calling", 911 draft-ietf-ecrit-phonebcp-13 (work in progress), 912 July 2009. 914 [I-D.thomson-geopriv-held-measurements] 915 Thomson, M. and J. Winterbottom, "Using Device-provided 916 Location-Related Measurements in Location Configuration 917 Protocols", draft-thomson-geopriv-held-measurements-04 918 (work in progress), May 2009. 920 [LLDP] IEEE, "802.1AB, IEEE Standard for Local and Metropolitan 921 area networks, Station and Media Access Control 922 Connectivity Discovery", June 2005. 924 Authors' Addresses 926 James Winterbottom 927 Andrew Corporation 928 Andrew Building (39) 929 Wollongong University Campus 930 Northfields Avenue 931 Wollongong, NSW 2522 932 AU 934 Email: james.winterbottom@andrew.com 936 Martin Thomson 937 Andrew Corporation 938 Andrew Building (39) 939 Wollongong University Campus 940 Northfields Avenue 941 Wollongong, NSW 2522 942 AU 944 Email: martin.thomson@andrew.com 946 Hannes Tschofenig 947 Nokia Siemens Networks 948 Linnoitustie 6 949 Espoo 02600 950 Finland 952 Phone: +358 (50) 4871445 953 Email: Hannes.Tschofenig@gmx.net 954 URI: http://www.tschofenig.priv.at 956 Richard Barnes 957 BBN Technologies 958 9861 Broken Land Pkwy, Suite 400 959 Columbia, MD 21046 960 USA 962 Phone: +1 410 290 6169 963 Email: rbarnes@bbn.com