idnits 2.17.1 draft-ietf-geopriv-held-identity-extensions-00.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 (September 6, 2009) is 5336 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 855, but no explicit reference was found in the text == Unused Reference: 'LLDP' is defined on line 882, 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 (-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 (~~), 5 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: March 10, 2010 H. Tschofenig 6 Nokia Siemens Networks 7 R. Barnes 8 BBN Technologies 9 September 6, 2009 11 Use of Device Identity in HTTP-Enabled Location Delivery (HELD) 12 draft-ietf-geopriv-held-identity-extensions-00 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 March 10, 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 . . . . . . . . . . . . . . . . 8 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 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 6.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 19 92 6.2. Location Configuration Protocol Requests . . . . . . . . . 19 93 6.3. Third Party Requests . . . . . . . . . . . . . . . . . . . 20 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 95 7.1. URN Sub-Namespace Registration for 96 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 21 97 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 21 98 7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 22 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 9.1. Normative references . . . . . . . . . . . . . . . . . . . 24 102 9.2. Informative references . . . . . . . . . . . . . . . . . . 24 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 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 simpler for LCPs, since IP 112 datagrams that carry the request already carry an identifier for the 113 Device, namely the source IP address of an incoming request. 114 Existing LCPs, such as HELD [I-D.ietf-geopriv-http-location-delivery] 115 and DHCP ([RFC3825], [RFC4776]) rely on the source IP address or 116 other information present 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 [I-D.ietf-geopriv-l7-lcp-ps], additional identification 122 information can be included 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 to the HELD protocol is 130 that it also expands the potential scope of HELD beyond that of an 131 LCP. The scope of an LCP is limited to the interaction between a 132 Device and a LIS. That is, an LCP is limited to the Device 133 retrieving information about their own location. With this addition, 134 authorized third party location recipients (LRs) are able to make 135 requests that include identifiers to retrieve location information 136 about a particular Device. 138 The usage of HELD for purposes beyond the Device-LIS interaction 139 obviously introduces a new set of privacy concerns. In an LCP, the 140 requester is implicitly authorized to access the requested location 141 information, because it is their own location. In contrast, a third 142 party LR must be explicitly authorized when requesting the location 143 of a Device. Establishing appropriate authorization and other 144 related privacy concerns are discussed in Section 5. 146 1.1. Applications 148 The use of additional identifiers in HELD falls into two categories. 149 A Device can use these parameters to provide additional 150 identification information to a LIS. Identification information, 151 such as the MAC address of the interface card of a Target, can be 152 used to reduce the time required to determine the location by a LIS. 154 In other cases, a LIS might require Device identification before any 155 location information can be generated. 157 A third party LR can be granted authorization to make requests for a 158 given Device. In particular, network services can be permitted to 159 retrieve location for a Device that is unable to acquire location 160 information for itself (see Section 6.3 of 161 [I-D.ietf-ecrit-phonebcp]). This allows use of location-dependent 162 applications - particularly essential services like emergency calling 163 - where Devices do not support a location configuration protocol 164 (LCP) or they are unable to successfully retrieve location 165 information. 167 2. Terminology 169 This document uses the term Location Information Server (LIS) and 170 location configuration protocol (LCP) as described in 171 [I-D.ietf-geopriv-l7-lcp-ps]. 173 The term Device is used specifically as the subject of an LCP, 174 consistent with [I-D.ietf-geopriv-http-location-delivery]. This 175 document also uses the term Target to refer to any entity that might 176 be a subject of the same location information. Target is used in a 177 more general sense, including the Device, but also any nearby entity, 178 such as the user of a Device. A Target has a stake in setting 179 authorization policy on the use of location information. Both Device 180 and Target are defined in [RFC3693]. 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 3. Device Identity 188 Identifiers are used as the starting point in location determination. 189 They should not be confused with measurement information 190 ([I-D.thomson-geopriv-held-measurements]). Measurement information 191 is information about a Device and the time varying details of its 192 network attachment. Identifiers might be associated with a different 193 Device over time, but the their purpose is to identify the Device, 194 not to describe its environment or network attachment. 196 3.1. Identifier Suitability 198 Use of any identifier MUST only be allowed if it identifies a single 199 Device at a particular time. In some circumstances, certain of these 200 identifiers are either temporary or could potentially identify 201 multiple devices. Identifiers that are transient or ambiguous could 202 be exploited by an attacker to either gain information about another 203 device or to coerce the LIS into producing misleading information. 205 The identifiers described in this section MUST only be used where 206 that identifier is used as the basis for location determination. 207 Considerations relating to the use of identifiers for a Device 208 requesting its own location are discussed in Section 5 of 209 [I-D.ietf-geopriv-l7-lcp-ps]; this section discusses use of 210 identifiers for authorized third party requests. 212 It is tempting for a LIS implementation to allow alternative 213 identifiers for convenience or some other perceived benefit. 214 However, care needs to be taken to ensure that the binding between 215 the indicated identifier and the identifier that is used for 216 location determination is unique and not subject to attacks. 218 Identifiers can have a different meaning to different entities on a 219 network. An identifier in one network context might have a 220 completely different meaning in a different context. Errors in 221 perspective arise in both topology (all network entities have a 222 subjective view of the network) and time (the network changes over 223 time). 225 3.1.1. Subjective Network Views 227 Subjective views of the network mean that the identifier a requests 228 uses to refer to one physical entity could actually apply to a 229 different physical entity when used in a different network context. 230 Unless an authorized third party requester and LIS operate in the 231 same network context, each could have a different subjective view of 232 the meaning of the identifier. 234 In this case, the third party receives information that is correct 235 only within the network context of the LIS. The location information 236 provided by the LIS is probably misleading: the requester believes 237 that the information relates to a different entity than it was 238 generated for. 240 In IP networks, network address translation (NAT) and other forms 241 of address modification create network contexts. Entities on 242 either side of the point where modification occurs have a 243 different view of the network. Private use addresses [RFC1918] 244 are the most easily recognizable identifiers that have limited 245 scope. 247 A LIS can be configured to recognize scenarios where the subjective 248 view of a requester might not coincide with the view of the LIS. The 249 LIS can either provide location information that takes the view of 250 the requester into account, or it can reject the request. 252 For instance, a LIS might operate within a network that uses a 253 private address space, with NAT between that network and other 254 networks. A third party request that originates in an external 255 network with an IP address from the private address space might 256 not be valid - it could be identifying an entity within another 257 address space. The LIS can be configured to reject such requests, 258 unless it knows by other means that the request is valid. 260 In the same example, the requester might include an address from 261 the external space in an attempt to identify a host within the 262 network. The LIS could use knowledge about how the external 263 address is mapped to a private address, if that mapping is fixed, 264 to determine an appropriate response. 266 The residential gateway scenario in Section 3.1 of 267 [I-D.ietf-geopriv-l7-lcp-ps] is a particular example of where a 268 subjective view is permitted. The LIS knowingly provides Devices on 269 the remote side of the residential gateway with location information, 270 in spite of the ambiguity. The LIS provides location information 271 with appropriate uncertainty to allow for the fact that the 272 residential gateway serves a small geographical area. 274 3.1.2. Transient Identifiers 276 Some identifiers are temporary and can, over the course of time, be 277 assigned to different physical entities. An identifier that is 278 reassigned between the time that a request is formulated by a 279 requester and when the request is received by the LIS causes the LIS 280 to locate a different entity than the requester intended. The 281 response from the LIS might be accurate, but the request incorrectly 282 associates this information with the wrong subject. 284 A LIS should be configured with information about any potentially 285 temporary identifiers. It can use this information to identify when 286 changes have occurred. A LIS must not provide location information 287 if the identifier it uses might refer to a different Device. If an 288 identifier might have been reassigned recently, or it is likely to be 289 reassigned, it is not suitable as an identifier. 291 It's possible that some degree of uncertainty could persist where 292 identifiers are reassigned frequently; the extent to which errors 293 arising from using transient identifiers are tolerated is a matter 294 for local policy. 296 3.2. Identifier Format and Protocol Details 298 XML elements are used to express the Device identity. The "target" 299 element is used as a general container for identity information. 300 This document defines a basic set of identifiers. An example HELD 301 request, shown in Figure 1, includes an IP version 4 address. 303 305 geodetic 306 307 192.0.2.5 308 309 311 Figure 1 313 A LIS that supports this specification echoes the "target" element in 314 a successful HELD response, including the identifiers that were used 315 as the basis for location determination. Absence of this indication 316 means that the location information was generated using the source IP 317 address in the request. 319 If an identifier is invalid, not supported by the LIS, or the 320 requester is not authorized to use that identifier, a HELD error 321 response of "badIdentifier". This code is registered in Section 7.3. 323 If the LIS requires an identifier that is not provided in the 324 request, the desired identifiers MAY be identified in the HELD error 325 response, using the "requiredIdentifiers" element. This element 326 contains a list of XML qualified names [W3C.REC-xml-names11-20060816] 327 that identify the identifier elements required by the LIS. Namespace 328 prefix bindings for the qualified names are taken from document 329 context. Figure 2 shows an example error indicating that the 330 requester needs to include a MAC address (Section 3.3.2) if the 331 request is to succeed. 333 335 MAC address required 336 338 mac 339 340 342 Figure 2 344 3.3. Identifiers 346 A limited selection of identifiers are included in this document. 347 The basic Device identity schema allows for the inclusion of elements 348 from any namespace, therefore additional elements can be defined 349 using different XML namespaces. 351 3.3.1. IP Address 353 The "ip" element can express a Device identity as an IP address. An 354 optional "v" attribute identifies the IP version. The element uses 355 the textual format specific to the indicated IP version. 357 358 2001:DB8::1:ea7:fee1:d1e 359 361 In situations where location configuration does not require 362 additional identifiers, using IP address as an identifier enables 363 authorized third party requests. 365 3.3.2. MAC Address 367 The media access control (MAC) address used by the IEEE 802 family of 368 access technologies is an identifier that is assigned to a particular 369 network device. A MAC address is a unique sequence that is either 370 assigned at the time of manufacture of a device, or assigned by a 371 local administrator. A MAC address rarely changes; therefore, a MAC 372 address is an appropriate identifier for a Device. 374 375 A0-12-34-56-78-90 376 378 A LIS that operates on the same layer 2 segment as a Device sees the 379 MAC address of the Device and can authenticate the device in that 380 fashion. If a router is interposed between LIS and Device, other 381 means of authentication are required. 383 3.3.3. TCP or UDP Port Number 385 On its own, a TCP or UDP port number is insufficient to uniquely 386 identify a single host, but in combination with an IP address, it can 387 be used in some environments to uniquely identify a Device. 389 Use of a particular port number can be transient; often significantly 390 more than use of any given IP address. However, widespread use of 391 network address translation (NAT) means that some Devices cannot be 392 uniquely identified by IP address alone. An individual Device might 393 be identified by a flow of packets that it generates. Providing that 394 a LIS has sufficient knowledge of the mappings used by the NAT, an 395 individual target on the remote side of the NAT might be able to be 396 identified uniquely. 398 399 2001:DB8::1:ea7:fee1:d1e 400 51393 401 403 Use of port numbers is especially reliant on the value remaining 404 consistent over time. 406 3.3.4. Network Access Identifier 408 A Network Access Identifier (NAI) [RFC4282] is an identifier used in 409 network authentication in a range of networks. The identifier 410 establishes a user identity within a particular domain. Often, 411 network services use an NAI in relation to location records, tying 412 network access to user authentication and authorization. 414 415 user@example.net 416 418 The formal grammar for NAI [RFC4282] permits invalid Unicode, which 419 cannot be expressed using XML. Therefore, this expression of NAI 420 permits escaping. Non-unicode characters (and any other character) 421 are expressed using a backslash ('\') followed by two hexadecimal 422 digits representing the value of a single octet. 424 The canonical representation of an NAI is the sequence of octets that 425 is produced from the concatenation of UTF-8 encoded sequences of 426 unescaped characters and octets derived from escaped components. 427 This sequence MUST conform to the constraints in [RFC4282]. 429 3.3.5. URI 431 A Device can be identified by a URI. Any URI can be used providing 432 that the requester and LIS have a common understanding of the 433 semantics implied by use of the URI. 435 436 sip:user@example.net;gr=kjh29x97us97d 437 439 3.3.6. Hostname 441 A domain name can be used as the basis for identification using the 442 "hostname" element. 444 445 host.example.net 446 448 3.3.7. Directory Number 450 Telephony devices are typically identified by the number that is used 451 to reach them. Within enterprises, where globally accessible 452 telephone numbers might not be used, a directory number is the usual 453 form of identification. 455 456 7515 457 459 3.3.8. Cellular Telephony Identifiers 461 A range of different forms of mobile station identifiers are used for 462 different cellular telephony systems. Elements are defined for these 463 identifiers. The following identifiers are defined: 465 msisdn: The Mobile Subscriber Integrated Services Digital Network 466 Number (MSISDN) is an E.164 number between 6 and 15 digits long. 468 imsi: The International Mobile Subscriber Identity (IMSI) an 469 identifier associated with all GSM and UMTS mobile subscribers. 471 imei: The International Mobile Equipment Identifier (IMEI) is a 472 unique device serial number up to 15 digits long. 474 min: The Mobile Identification Number (MIN) is a unique number 475 assigned to CDMA handsets. 477 mdn: The Mobile Directory Number (MDN) is an E.164 number, with 478 usage similar to MSISDN. 480 481 11235550123 482 484 3.3.9. DHCP Unique Identifier 486 The Dynamic Host Configuration Protocol (DHCP) uses a binary 487 identifier for its clients. The DHCP Unique Identifier (DUID) is 488 expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of 489 DHCPv6 and follows the format defined in Section 9 of [RFC3315]. The 490 "duid" element includes the binary value of the DUID expressed in 491 hexadecimal. 493 494 1234567890AaBbCcDdEeFf 495 497 4. XML Schema 499 500 506 507 508 509 510 512 513 515 516 517 518 520 521 522 523 524 525 526 527 528 529 530 531 532 533 535 536 537 538 539 540 542 543 544 545 546 547 548 550 552 554 555 556 557 558 559 561 562 563 564 567 569 570 572 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 594 596 598 5. Privacy Considerations 600 The authorization model for a location configuration protocol assumes 601 that the LR is also the Target, and that providing that LR with 602 information about its own location is allowed. We call this property 603 "LCP policy". In effect, an LCP server (that is, the LIS) follows a 604 single rule policy that states that the Target is the only authorized 605 Location Recipient. 607 Note: HELD explicitly takes the position that the Target is a Device 608 and not a person. When discussing privacy, Targets other than a 609 Device have a stake in protecting privacy. Therefore, the more 610 general term of Target - any potential subject of location 611 information - is used in place of Device. 613 When Device identity is used, the "LCP policy" is only applicable if 614 the LR and Target are the same entity. If they are the same, the 615 security and privacy considerations of the base HELD protocol 616 [I-D.ietf-geopriv-http-location-delivery] MAY be applied by a LIS. 617 The usage of the additional identifiers defined in this document by 618 the LR MAY cause the LIS to perform additional security verifications 619 to take place. 621 LR and Target MUST be verified by the LIS to be the same identity, 622 assuming that related identities are the same is not sufficient. 624 For example, it is not appropriate to apply LCP policy where a 625 requester is authenticated by NAI and the supplied Device identity 626 is a MAC address, even if that MAC address is currently registered 627 with the network under the given NAI. In this case, the requester 628 might be requesting from a different MAC address registered under 629 the same NAI. The correct way of gaining authorization is to 630 establish a policy that permits this particular request as a third 631 party request. 633 The LCP policy does not allow requests made by third parties. If a 634 LIS permits requests from third parties using Device identity, it 635 assumes the rule of a Location Server (LS). As a Location Server, 636 the LIS MUST explicitly authorize requests according to the policies 637 that are provided by Rule Makers, including the Target. This 638 includes authentication of requesters where required by the 639 authorization policies. 641 An organization that provides a LIS that allows third party requests 642 must provide a means for a Rule Maker to specify authorization 643 policies as part of the LIS implementation (e.g, in the form of 644 access control lists). Authorization must be established before 645 allowing third party requests for the location of any Target. Until 646 an authorization policy is established, the LIS MUST reject requests 647 by third parties (that is, the default policy is "deny all"). 649 When the LIS is operated by an access network, the relationship 650 between the Target and the LIS can be transient. However, the 651 process of establishing network access usually results in a form of 652 agreement between the Target and the network provider. This process 653 offers a natural vehicle for establishing location privacy policies. 654 Establishing authorization policy might be a manual process, an 655 explicit part of the terms of service for the network, or an 656 automated system that accepts formal authorization policies (see 657 [RFC4745], [RFC4825]). This document does not mandate any particular 658 mechanism for establishing an authorization policy. 660 6. Security Considerations 662 The security considerations in 663 [I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for 664 server authentication, confidentiality and protection from 665 modification. These protections apply to both LCP requests and the 666 requests made by third parties. 668 All HELD requests containing identity MUST be authenticated by the 669 LIS. How authentication is accomplished and what assurances are 670 desired is a matter for policy. The base HELD protocol uses return 671 reachability of an IP address implied by the requester being able to 672 successfully complete a TCP handshake. It is RECOMMENDED that any 673 means of authentication provide at least this degree of assurance. 674 For requests that include Device identity, the LIS MUST support 675 authentication of TLS clients. 677 6.1. Identifier Suitability 679 Transient and ambiguous identifiers can be exploited by malicious 680 requests and are not suitable as a basis for identifying a Device. 681 Section 3.1 provides further discussion on this subject. 683 Identifier transience of can lead to incorrect location information 684 being provided. An attacker could exploit the use of transient 685 identifiers. In this attack, the attacker either knows of a re- 686 allocation of that identifier or is able to force the identifier to 687 be re-allocated during the processing of the request. 689 An attacker could use this to acquire location information for 690 another Device or to coerce the LIS to lie on its behalf if this re- 691 allocation occurs between the time where authorization is granted and 692 location information is granted. 694 Ambiguous identifiers present a similar problem. An attacker could 695 legitimately gain authorization to use a particular identifier. 696 Since an ambiguous identifier potentially refers to multiple Devices, 697 if authorization is granted for one of those Devices, an attacker 698 potentially gains access to location information for all of those 699 Devices. 701 6.2. Location Configuration Protocol Requests 703 Requests made by a Device in the context of a location configuration 704 protocol are covered by the same set of protections offered by HELD. 705 LCP requests are authorized under an "LCP policy" that permits a 706 Target access to location information about itself. 708 Identity information provided by the Device is private data that 709 might be sensitive. The Device provides this information in the 710 expectation that it assists the LIS in providing the Device a 711 service. The LIS MUST NOT use identity information for any other 712 purpose other than serving the request that includes that 713 information. 715 6.3. Third Party Requests 717 Requests from third parties have the same requirements for server 718 authentication, confidentiality and protection from modification as 719 LCP requests. However, because the third party needs to be 720 authorized, the requester MUST be authenticated by the LIS. In 721 addition, third party requests MUST be explicitly authorized by a 722 policy that is established by a Rule Maker. 724 More detail on the privacy implications of third party requests are 725 covered in Section 5. 727 7. IANA Considerations 729 This document registers an XML namespace and schema with IANA in 730 accordance with guidelines in [RFC3688]. It also creates a new 731 registry for device identity types, and stipulates how new types are 732 to be added. 734 7.1. URN Sub-Namespace Registration for 735 urn:ietf:params:xml:ns:geopriv:held:id 737 This section registers a new XML namespace, 738 "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in 739 [RFC3688]. 741 URI: urn:ietf:params:xml:ns:geopriv:held:id 743 Registrant Contact: IETF, GEOPRIV working group, 744 (geopriv@ietf.org), James Winterbottom 745 (james.winterbottom@andrew.com). 747 XML: 749 BEGIN 750 751 753 754 755 HELD Device Identity Parameters 756 757 758

Namespace for HELD Device Identity Parameters

759

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

760 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 761 with the RFC number for this specification.]] 762

See RFCXXXX.

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