idnits 2.17.1 draft-ietf-geopriv-held-identity-extensions-04.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 (June 21, 2010) is 5056 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 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) -- Possible downref: Non-RFC (?) normative reference: ref. 'WiMAX-T33-110-R015v01-B' -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-03) exists of draft-ietf-geopriv-arch-02 == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-14 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geopriv J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: Standards Track Andrew Corporation 5 Expires: December 23, 2010 H. Tschofenig 6 Nokia Siemens Networks 7 R. Barnes 8 BBN Technologies 9 June 21, 2010 11 Use of Device Identity in HTTP-Enabled Location Delivery (HELD) 12 draft-ietf-geopriv-held-identity-extensions-04 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 December 23, 2010. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 71 2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7 73 2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 8 74 2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9 75 2.2. Identifier Format and Protocol Details . . . . . . . . . . 9 76 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 11 79 3.3. TCP or UDP Port Number . . . . . . . . . . . . . . . . . . 11 80 3.4. Network Access Identifier . . . . . . . . . . . . . . . . 12 81 3.4.1. Using NAI for Location Configuration . . . . . . . . . 12 82 3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 3.6. Fully Qualified Domain Name . . . . . . . . . . . . . . . 14 84 3.7. Cellular Telephony Identifiers . . . . . . . . . . . . . . 14 85 3.8. DHCP Unique Identifier . . . . . . . . . . . . . . . . . . 14 86 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16 87 4.1. Targets Requesting Their Own Location . . . . . . . . . . 16 88 4.2. Third-Party Requests . . . . . . . . . . . . . . . . . . . 17 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 5.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 18 91 5.2. Targets Requesting Their Own Location . . . . . . . . . . 19 92 5.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 19 93 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 95 7.1. URN Sub-Namespace Registration for 96 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 23 97 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 23 98 7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 24 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 101 9.1. Normative references . . . . . . . . . . . . . . . . . . . 26 102 9.2. Informative references . . . . . . . . . . . . . . . . . . 27 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 105 1. Introduction 107 Protocols for requesting and providing location information require a 108 way for the requestor to specify the location that should be 109 returned. In a location configuration protocol (LCP), the location 110 being requested is the requestor's location. This fact can make the 111 problem of identifying the Device simple, since IP datagrams that 112 carry the request already carry an identifier for the Device, namely 113 the source IP address of an incoming request. Existing LCPs, such as 114 HTTP-Enabled Location Delivery (HELD) 115 [I-D.ietf-geopriv-http-location-delivery] and DHCP ([RFC3825], 116 [RFC4776]) rely on the source IP address or other information present 117 in protocol datagrams to identify a Device. 119 Aside from the datagrams that form a request, a location information 120 server (LIS) does not necessarily have access to information that 121 could further identify the Device. In some circumstances, as shown 122 in [RFC5687], additional identification information can be included 123 in a request to identify a Device. 125 This document extends the HELD protocol to support the inclusion of 126 additional identifiers for the Device in HELD location requests. An 127 XML schema is defined that provides a structure for including these 128 identifiers in HELD requests. 130 An important characteristic of this addition is that the HELD 131 protocol with identity extensions implemented is not considered an 132 LCP. The scope of an LCP is limited to the interaction between a 133 Device and a LIS, and LCPs can guarantee the identity of Devices 134 without additional authorization checks. A LIS identifies the Device 135 making the LCP request using the source addressing on the request 136 packets, using return routability to ensure that these identifiers 137 are not spoofed. 139 HELD with identity extensions allows a requester to explicitly 140 provide identification details in the body of a location request. 141 This means that location requests can be made in cases where 142 additional Device identity checks are necessary, and in cases where 143 the requester is not the Device itself. Third-party location 144 recipients (LRs) are able to make requests that include identifiers 145 to retrieve location information about a particular Device. 147 The usage of identifiers in HELD obviously introduces a new set of 148 privacy concerns. In an LCP, the requester can be implicitly 149 authorized to access the requested location information, because it 150 is their own location. In contrast, a third-party LR must be 151 explicitly authorized when requesting the location of a Device. 152 Establishing appropriate authorization and other related privacy 153 concerns are discussed in Section 4. 155 1.1. Applications 157 This document defines a means to explicitly include Device identity 158 information in the body of a HELD location request. This identity 159 information is used to identify the Device that is the subject (or 160 Target) of the location request. If device identity is present, the 161 identity of the requester is not used to identify the subject of the 162 request. 164 Device identifiers in HELD can be used for two purposes: 166 Location configuration: A Device can use these parameters to 167 identify itself to a LIS. Identification information other than 168 an IP address might be needed to determine the location of a 169 Device. 171 A LIS can authorize location configuration requests using a policy 172 that allows Devices to acquire their own location (see 173 Section 4.1). If an unauthorized third-party falsifies addressing 174 on request packets to match the provided Device identity, the 175 request might be erroneously authorized under this policy. 176 Requests containing Device identity must not be authorized using 177 this policy unless specific measures are taken to prevent this 178 type of attack. 180 This document describes a mechanism that provides assurances that 181 the requester and included Device identity are the same for the 182 network access identifier (NAI) in a WiMAX network. The LIS MUST 183 treat requests containing other identifiers as third-party 184 requests, unless it is able to ensure that the provided Device 185 identity is uniquely attributable to the requester. 187 Third-party requests: A third-party location recipient can be 188 granted authorization to make requests for a given Device. In 189 particular, network services can be permitted to retrieve location 190 for a Device that is unable to acquire location information for 191 itself (see Section 6.3 of [I-D.ietf-ecrit-phonebcp]). This 192 allows use of location-dependent applications - particularly 193 essential services like emergency calling - where Devices do not 194 support a location configuration protocol or they are unable to 195 successfully retrieve location information. 197 This document does not describe how a third party acquires an 198 identifier for a Device, nor how that third-party is authorized by 199 a LIS. It is critical that these issues are resolved before 200 permitting a third-party request. A pre-arranged contract between 201 the third-party, a Rule Maker and the LIS operator is necessary to 202 use Device identifiers in this fashion. This contract must 203 include how the request is authenticated and the set of 204 identifiers (and types of identifiers) that the third-party is 205 authorized to use in requests. 207 Automated mechanisms to ensure privacy constraints are respected 208 are possible. 210 1.2. Terminology 212 This document uses the term Location Information Server (LIS) and 213 location configuration protocol (LCP) as described in [RFC5687] and 214 [I-D.ietf-geopriv-arch]. 216 The term Device is used specifically as the subject of an LCP, 217 consistent with [I-D.ietf-geopriv-http-location-delivery]. This 218 document also uses the term Target to refer to any entity that might 219 be a subject of the same location information. Target is used in a 220 more general sense, including the Device, but also any nearby entity, 221 such as the user of a Device. A Target has a stake in setting 222 authorization policy on the use of location information. Both Device 223 and Target are defined in [I-D.ietf-geopriv-arch]. 225 The term "requester" is used in this document to refer to the entity 226 making a HELD request. 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in [RFC2119]. 232 2. Device Identity 234 Identifiers are used as the starting point in location determination. 235 They should not be confused with measurement information 236 ([I-D.thomson-geopriv-held-measurements]). Measurement information 237 is information about a Device and the time varying details of its 238 network attachment. Identifiers might be associated with a different 239 Device over time, but their purpose is to identify the Device, not to 240 describe its environment or network attachment. 242 2.1. Identifier Suitability 244 Use of any identifier MUST only be allowed if it identifies a single 245 Device at the time that location is determined. The LIS is 246 responsible for ensuring that location information is correct for the 247 Device, which includes ensuring that the identifier is uniquely 248 attributable to the Device. 250 Some identifiers can be either temporary or could potentially 251 identify multiple Devices. Identifiers that are transient or 252 ambiguous could be exploited by an attacker to either gain 253 information about another Device or to coerce the LIS into producing 254 misleading information. 256 The identifiers described in this document MUST only be used where 257 that identifier is used as the basis for location determination. 258 Considerations relating to the use of identifiers for a Device 259 requesting its own location are discussed in Section 5 of [RFC5687]; 260 this section discusses use of identifiers for authorized third-party 261 requests. 263 It is tempting for a LIS implementation to allow alternative 264 identifiers for convenience or some other perceived benefit. The 265 LIS is responsible for ensuring that the identifier used in the 266 request does not refer to a Device other than the one for which it 267 determines location. 269 Some identifiers are always uniquely attributable to a single Device. 270 However, other identifiers can have a different meaning to different 271 entities on a network. This is especially true for IP addresses 272 [RFC2101], but this can be true for other identifiers to varying 273 degrees. Non-uniqueness arises from both topology (all network 274 entities have a subjective view of the network) and time (the network 275 changes over time). 277 2.1.1. Subjective Network Views 279 Subjective views of the network mean that the identifier a requester 280 uses to refer to one physical entity could actually apply to a 281 different physical entity when used in a different network context. 282 Unless an authorized third-party requester and LIS operate in the 283 same network context, each could have a different subjective view of 284 the meaning of the identifier. 286 Where subjective views differ, the third-party receives information 287 that is correct only within the network context of the LIS. The 288 location information provided by the LIS is probably misleading: the 289 requester believes that the information relates to a different entity 290 than it was generated for. 292 Authorization policy can be affected by a subjective network view if 293 it is applied based on an identifier, or its application depends on 294 identifiers. The subjective view presented to the LIS and Rule Maker 295 need to agree for the two entities to understand policy on the same 296 terms. For instance, it is possible that the LIS could apply the 297 incorrect authorization policy if it selects the policy using a 298 subjective identifier. Alternatively, it may use the correct policy 299 but apply it incorrectly if subjective identifiers are used. 301 In IP networks, network address translation (NAT) and other forms 302 of address modification create network contexts. Entities on 303 either side of the point where modification occurs have a 304 different view of the network. Private use addresses [RFC1918] 305 are the most easily recognizable identifiers that have limited 306 scope. 308 A LIS can be configured to recognize scenarios where the subjective 309 view of a requester or Rule Maker might not coincide with the view of 310 the LIS. The LIS can either provide location information that takes 311 the view of the requester into account, or it can reject the request. 313 For instance, a LIS might operate within a network that uses a 314 private address space, with NAT between that network and other 315 networks. A third-party request that originates in an external 316 network with an IP address from the private address space might 317 not be valid - it could be identifying an entity within another 318 address space. The LIS can be configured to reject such requests, 319 unless it knows by other means that the request is valid. 321 In the same example, the requester might include an address from 322 the external space in an attempt to identify a host within the 323 network. The LIS could use knowledge about how the external 324 address is mapped to a private address, if that mapping is fixed, 325 to determine an appropriate response. 327 The residential gateway scenario in Section 3.1 of [RFC5687] is a 328 particular example of where a subjective view is permitted. The LIS 329 knowingly provides Devices on the remote side of the residential 330 gateway with location information. The LIS provides location 331 information with appropriate uncertainty to allow for the fact that 332 the residential gateway serves a small geographical area. 334 2.1.2. Transient Identifiers 336 Some identifiers are temporary and can, over the course of time, be 337 assigned to different physical entities. An identifier that is 338 reassigned between the time that a request is formulated by a 339 requester and when the request is received by the LIS causes the LIS 340 to locate a different entity than the requester intended. The 341 response from the LIS might be accurate, but the request incorrectly 342 associates this information with the wrong subject. 344 A LIS should be configured with information about any potentially 345 temporary identifiers. It can use this information to identify when 346 changes have occurred. A LIS must not provide location information 347 if the identifier it uses might refer to a different Device. If an 348 identifier might have been reassigned recently, or it is likely to be 349 reassigned, it is not suitable as an identifier. 351 It's possible that some degree of uncertainty could persist where 352 identifiers are reassigned frequently; the extent to which errors 353 arising from using transient identifiers are tolerated is a matter 354 for local policy. 356 2.2. Identifier Format and Protocol Details 358 XML elements are used to express the Device identity. The "device" 359 element is used as a general container for identity information. 360 This document defines a basic set of identifiers. An example HELD 361 request, shown in Figure 1, includes an IP version 4 address. 363 365 geodetic 366 367 192.0.2.5 368 369 371 Figure 1 373 A LIS that supports this specification echoes the "device" element in 374 a successful HELD response, including the identifiers that were used 375 as the basis for location determination. Absence of this indication 376 means that the location information was generated using the source IP 377 address in the request. 379 A "badIdentifier" HELD error code indicates that the requester is not 380 authorized to use that identifier or that the request contains an 381 identifier that is badly formatted or not supported by the LIS. This 382 code is registered in Section 7.3. 384 If the LIS requires an identifier that is not provided in the 385 request, the desired identifiers MAY be identified in the HELD error 386 response, using the "requiredIdentifiers" element. This element 387 contains a list of XML qualified names [W3C.REC-xml-names11-20060816] 388 that identify the identifier elements required by the LIS. Namespace 389 prefix bindings for the qualified names are taken from document 390 context. Figure 2 shows an example error indicating that the 391 requester needs to include a MAC address (Section 3.2) if the request 392 is to succeed. 394 396 MAC address required 397 399 mac 400 401 403 Figure 2 405 3. Identifiers 407 A limited selection of identifiers are included in this document. 408 The basic Device identity schema allows for the inclusion of elements 409 from any namespace, therefore additional elements can be defined 410 using different XML namespaces. 412 3.1. IP Address 414 The "ip" element can express a Device identity as an IP address. The 415 "v" attribute identifies the IP version with a single hexadecimal 416 digit. The element uses the textual format specific to the indicated 417 IP version. 419 420 2001:DB8::1:ea7:fee1:d1e 421 423 In situations where location configuration does not require 424 additional identifiers, using IP address as an identifier enables 425 authorized third-party requests. 427 3.2. MAC Address 429 The media access control (MAC) address used by the IEEE 802 family of 430 access technologies is an identifier that is assigned to a particular 431 network Device. A MAC address is a unique sequence that is either 432 assigned at the time of manufacture of a Device, or assigned by a 433 local administrator. A MAC address rarely changes; therefore, a MAC 434 address is an appropriate identifier for a Device. 436 437 A0-12-34-56-78-90 438 440 3.3. TCP or UDP Port Number 442 On its own, a TCP or UDP port number is insufficient to uniquely 443 identify a single host, but in combination with an IP address, it can 444 be used in some environments to uniquely identify a Device. 446 Use of a particular port number can be transient; often significantly 447 more than use of any given IP address. However, widespread use of 448 network address translation (NAT) means that some Devices cannot be 449 uniquely identified by IP address alone. An individual Device might 450 be identified by a flow of packets that it generates. Providing that 451 a LIS has sufficient knowledge of the mappings used by the NAT, an 452 individual target on the remote side of the NAT might be able to be 453 identified uniquely. 455 456 192.0.2.75 457 51393 458 460 Use of port numbers is especially reliant on the value remaining 461 consistent over time. 463 3.4. Network Access Identifier 465 A Network Access Identifier (NAI) [RFC4282] is an identifier used in 466 network authentication in a range of networks. The identifier 467 establishes a user identity within a particular domain. Often, 468 network services use an NAI in relation to location records, tying 469 network access to user authentication and authorization. 471 472 user@example.net 473 475 The formal grammar for NAI [RFC4282] permits invalid Unicode, which 476 cannot be expressed using XML. Therefore, this expression of NAI 477 permits escaping. Non-unicode characters (and any other character) 478 are expressed using a backslash ('\') followed by two hexadecimal 479 digits representing the value of a single octet. 481 The canonical representation of an NAI is the sequence of octets that 482 is produced from the concatenation of UTF-8 encoded sequences of 483 unescaped characters and octets derived from escaped components. 484 This sequence MUST conform to the constraints in [RFC4282]. 486 3.4.1. Using NAI for Location Configuration 488 An NAI in WiMAX is uniquely attributable to a single Device at any 489 one time. An NAI either identifies a Device or a service 490 subscription, neither of which can have multiple active sessions. 492 In a WiMAX network, an IP address is not sufficient information for a 493 LIS to locate a Device. The following procedure, described in more 494 detail in [WiMAX-T33-110-R015v01-B], relies on an NAI to identify the 495 Device. 497 Location requests in a WiMAX network always require the inclusion of 498 an NAI. However, if a LIS receives a request that does not come from 499 an authenticated and authorized third-party requester, it can treat 500 this request as a location configuration request. 502 After receiving a location request that includes an NAI, the LIS 503 sends a "Location-Requestor-Authentication-Protocol" access request 504 message to the Authentication, Authorization and Accounting (AAA) 505 server. This request includes an "MS-Identity-Assertion" parameter 506 containing the NAI. 508 The AAA server consults network policy and if the request is 509 permitted, the response includes the IP address that is currently 510 assigned to the Device. If this IP address matches the source IP 511 address of the HELD location request, the location request can be 512 authorized under the LCP policy (see Section 4.1). Otherwise, the 513 request must be treated as a third-party request. 515 This relies on the same IP address spoofing protections that are 516 required by [I-D.ietf-geopriv-http-location-delivery]. In addition, 517 the request made of the AAA uses either Diameter [RFC3588] or RADIUS 518 [RFC2865], and therefore relies on the protections provided by those 519 protocols. In order to rely on the access request, the AAA server 520 MUST be authenticated to be a trusted entity for the purpose of 521 providing a link between the NAI and IP address. The AAA protocol 522 MUST also provide protection from modification and replay attacks to 523 ensure that data cannot be altered by an attacker. 525 3.5. URI 527 A Device can be identified by a URI. Any URI can be used providing 528 that the requester and LIS have a common understanding of the 529 semantics implied by use of the URI. 531 532 sip:user@example.net;gr=kjh29x97us97d 533 535 Particular care needs to be taken in ensuring that a particular URI 536 only refers to a single Device. In many cases, a URI can resolve to 537 multiple destinations. For example, a SIP address of record URI can 538 correspond to a service subscription rather than a single Device. 540 A "tel:" URI [RFC3966] can be used identify a Device by telephone 541 number: 543 544 tel:800-555-1111;extension=1234;phone-context=+1 545 547 3.6. Fully Qualified Domain Name 549 A fully-qualified domain name can be used as the basis for 550 identification using the "fqdn" element. 552 553 host.example.net 554 556 This IDN-aware domain name slot [I-D.ietf-idnabis-defs] is formed 557 from any sequence of valid U-labels or NR-LDH-labels. 559 A domain name does not always correspond to a single IP address or 560 host. If this is the case, a domain name is not a suitable 561 identifier. 563 3.7. Cellular Telephony Identifiers 565 A range of different forms of mobile station identifiers are used for 566 different cellular telephony systems. Elements are defined for these 567 identifiers. The following identifiers are defined: 569 msisdn: The Mobile Station International Subscriber Dial Number 570 (MSISDN) is an E.164 number between 6 and 15 digits long. 572 imsi: The International Mobile Subscriber Identity (IMSI) an 573 identifier associated with all GSM and UMTS mobile subscribers. 575 imei: The International Mobile Equipment Identifier (IMEI) is a 576 unique device serial number up to 15 digits long. 578 min: The Mobile Identification Number (MIN) is a unique number 579 assigned to CDMA handsets. 581 mdn: The Mobile Directory Number (MDN) is an E.164 number, with 582 usage similar to MSISDN. 584 585 11235550123 586 588 3.8. DHCP Unique Identifier 590 The Dynamic Host Configuration Protocol (DHCP) uses a binary 591 identifier for its clients. The DHCP Unique Identifier (DUID) is 592 expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of 593 DHCPv6 and follows the format defined in Section 9 of [RFC3315]. The 594 "duid" element includes the binary value of the DUID expressed in 595 hexadecimal. 597 598 1234567890AaBbCcDdEeFf 599 601 4. Privacy Considerations 603 Location configuration protocols can make use of an authorization 604 model known as "LCP policy", which permits only Targets to be the 605 recipients of their own locations. In effect, an LCP server (that 606 is, the LIS) follows a single rule policy that states that the Target 607 is the only authorized Location Recipient. 609 The security and privacy considerations of the base HELD protocol 610 [I-D.ietf-geopriv-http-location-delivery] are applicable. However, 611 the considerations relating to return routability do not apply to 612 third-party requests. Return routability may also not apply to 613 requests from Targets for their own location depending on the anti- 614 spoofing mechanisms employed for the identifier. 616 4.1. Targets Requesting Their Own Location 618 When a Target uses identity extensions to obtain its own location, 619 HELD can no longer be considered an LCP. The authorization policy 620 that the LIS uses to respond to these requests must be provisioned by 621 one or more Rule Makers. 623 In the case that the LIS exclusively provides Targets with their own 624 locations, the LIS can still be said to be following the "LCP 625 policy". In all cases, the Geopriv security and privacy 626 considerations [I-D.ietf-geopriv-arch] are applicable. 628 The spoofing protections provided when using HELD with identity 629 extensions to provide Targets with their own locations differ from 630 the protections inherent in an LCP. For an LCP, return routability 631 is considered sufficient protection against spoofing. For a similar 632 policy to be used, specific measures MUST be defined to protect 633 against spoofing of the alternative identifier. This document 634 defines this for an NAI when used in WiMAX networks (see 635 Section 3.4.1), but for no other identifier. 637 A Rule Maker might require an assurance that the identifier is owned 638 by the requester. Any multi-stage verification process that includes 639 a return routability test cannot provide any stronger assurance than 640 return routability alone; therefore, policy might require the use of 641 additional, independent methods of verification. 643 Care is required where a direct one-to-one relationship between 644 requester and Device identity does not exist. If identifiers are not 645 uniquely attributable to a single Device, the use of HELD identity 646 extensions to provide Targets with their own locations could be 647 exploited by an attacker. 649 It might be possible in some networks to establish multiple 650 concurrent sessions using the same credentials. For instance, 651 Devices with different MAC addresses might be granted concurrent 652 access to a network using the same NAI. It is not appropriate to 653 provide Targets with their own locations based on NAI in this 654 case. Neither is it appropriate to authenticate a Device using 655 NAI and allow that Device to provide an unauthenticated MAC 656 address as a Device identifier, even if the MAC address is 657 registered to the NAI. The MAC address potentially identifies a 658 different Device to the one that is making the request. The 659 correct way of gaining authorization is to establish a policy that 660 permits this particular request as a third-party request. 662 Section 3.4.1 discusses the implications of using an NAI as an 663 identifier for location requests made of a LIS serving a WiMAX 664 network. Additional security considerations are discussed in 665 [WiMAX-T33-110-R015v01-B]. 667 4.2. Third-Party Requests 669 The LCP policy does not allow requests made by third parties. If a 670 LIS permits requests from third parties using Device identity, it 671 assumes the rule of a Location Server (LS). As a Location Server, 672 the LIS MUST explicitly authorize requests according to the policies 673 that are provided by Rule Makers, including the Target. The LIS MUST 674 also authenticate requesters according to any agreed-upon 675 authorization policy. 677 An organization that provides a LIS that allows third party requests 678 must provide a means for a Rule Maker to specify authorization 679 policies as part of the LIS implementation (e.g, in the form of 680 access control lists). Authorization must be established before 681 allowing third party requests for the location of any Target. Until 682 an authorization policy is established, the LIS MUST reject requests 683 by third parties (that is, the default policy is "deny all"). 685 When the LIS is operated by an access network, the relationship 686 between the Target and the LIS can be transient. As the Target is a 687 potential Rule Maker, this presents a problem. However, the process 688 of establishing network access usually results in a form of agreement 689 between the Target and the network provider. This process offers a 690 natural vehicle for establishing location privacy policies. 691 Establishing authorization policy might be a manual process, an 692 explicit part of the terms of service for the network, or an 693 automated system that accepts formal authorization policies (see 694 [RFC4745], [RFC4825]). This document does not mandate any particular 695 mechanism for establishing an authorization policy. 697 5. Security Considerations 699 The security considerations in 700 [I-D.ietf-geopriv-http-location-delivery] describe the use of 701 Transport Layer Security (TLS) [RFC5246] for server authentication, 702 confidentiality and protection from modification. These protections 703 apply to both Target requests for their own locations and requests 704 made by third parties. 706 All HELD requests containing identity MUST be authenticated by the 707 LIS. How authentication is accomplished and what assurances are 708 desired is a matter for policy. 710 The base HELD protocol uses return reachability of an IP address 711 implied by the requester being able to successfully complete a TCP 712 handshake. It is RECOMMENDED that any means of authentication 713 provide at least this degree of assurance. For requests that include 714 Device identity, the LIS MUST support HTTP digest authentication. 715 Unauthenticated location requests containing Device identity can be 716 challenged with an HTTP 401 (Unauthorized) response or rejected with 717 an HTTP 403 (Forbidden) response. 719 5.1. Identifier Suitability 721 Transient and ambiguous identifiers can be exploited by malicious 722 requests and are not suitable as a basis for identifying a Device. 723 Section 2.1 provides further discussion on this subject. 725 Identifier transience can lead to incorrect location information 726 being provided. An attacker could exploit the use of transient 727 identifiers. In this attack, the attacker either knows of a re- 728 allocation of that identifier or is able to force the identifier to 729 be re-allocated during the processing of the request. 731 An attacker could use this to acquire location information for 732 another Device or to coerce the LIS to lie on its behalf if this re- 733 allocation occurs between the time where authorization is granted and 734 location information is granted. 736 Ambiguous identifiers present a similar problem. An attacker could 737 legitimately gain authorization to use a particular identifier. 738 Since an ambiguous identifier potentially refers to multiple Devices, 739 if authorization is granted for one of those Devices, an attacker 740 potentially gains access to location information for all of those 741 Devices. 743 5.2. Targets Requesting Their Own Location 745 Requests made by a Device for its own location are covered by the 746 same set of protections offered by HELD. These requests might be 747 authorized under a policy similar to the "LCP policy" that permits a 748 Target access to location information about itself. 750 Identity information provided by the Device is private data that 751 might be sensitive. The Device provides this information in the 752 expectation that it assists the LIS in providing the Device a 753 service. The LIS MUST NOT use identity information for any other 754 purpose other than serving the request that includes that 755 information. 757 5.3. Third-Party Requests 759 Requests from third parties have the same requirements for server 760 authentication, confidentiality and protection from modification as 761 Target requests for their own locations. However, because the third- 762 party needs to be authorized, the requester MUST be authenticated by 763 the LIS. In addition, third-party requests MUST be explicitly 764 authorized by a policy that is established by a Rule Maker. 766 More detail on the privacy implications of third-party requests are 767 covered in Section 4. 769 6. XML Schema 771 777 778 780 HELD Device Identity 781 782 783 785 This document defines Device identity elements for HELD. 786 787 789 790 791 792 794 795 797 798 799 800 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 821 822 824 825 826 827 828 829 830 832 833 834 835 839 840 842 843 845 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 868 870 7. IANA Considerations 872 This document registers an XML namespace and schema with IANA in 873 accordance with guidelines in [RFC3688]. It also creates a new 874 registry for Device identity types, and stipulates how new types are 875 to be added. 877 7.1. URN Sub-Namespace Registration for 878 urn:ietf:params:xml:ns:geopriv:held:id 880 This section registers a new XML namespace, 881 "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in 882 [RFC3688]. 884 URI: urn:ietf:params:xml:ns:geopriv:held:id 886 Registrant Contact: IETF, GEOPRIV working group 887 (geopriv@ietf.org), James Winterbottom 888 (james.winterbottom@andrew.com). 890 XML: 892 BEGIN 893 894 896 897 898 HELD Device Identity Parameters 899 900 901

Namespace for HELD Device Identity Parameters

902

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

903 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 904 with the RFC number for this specification.]] 905

See RFCXXXX.

906 907 908 END 910 7.2. XML Schema Registration 912 This section registers an XML schema as per the guidelines in 913 [RFC3688]. 915 URI: urn:ietf:params:xml:schema:geopriv:held:id 917 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 918 James Winterbottom (james.winterbottom@andrew.com). 920 Schema: The XML for this schema can be found as the entirety of 921 Section 6 of this document. [IANA Note: The pattern attribute for 922 naiType does not contain whitespace.] 924 7.3. Registration of HELD 'badIdentifier' Error Code 926 This section registers the "badIdentifier" error code in the "Geopriv 927 HELD Registries, Error codes for HELD" IANA registry. 929 badIdentifier This error code indicates that a Device identifier 930 used in the HELD request was either: not supported by the LIS, 931 badly formatted, or not one for which the requester was authorized 932 to make a request. 934 8. Acknowledgements 936 The the NENA VoIP location working group provided assistance in the 937 definition of the schema used in this document. Special thanks go to 938 Barbara Stark, Guy Caron, Nadine Abbott, Jerome Grenier and Martin 939 Dawson. Bob Sherry provided input on use of URIs. Thanks to Adam 940 Muhlbauer and Eddy Corbett for providing further corrections. 941 Bernard Aboba provided excellent feedback on use cases and the 942 security model; Bernard, along with Alan DeKok, also helped resolve 943 an issue with NAIs. Ray Bellis provided motivation for the protocol 944 port parameters. Marc Linsner and Alissa Cooper provided guidance 945 and text (respectively) that greatly clarified the discussion 946 relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for 947 forcing this to be practical. 949 9. References 951 9.1. Normative references 953 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 954 Requirement Levels", BCP 14, RFC 2119, March 1997. 956 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 957 "Remote Authentication Dial In User Service (RADIUS)", 958 RFC 2865, June 2000. 960 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 961 and M. Carney, "Dynamic Host Configuration Protocol for 962 IPv6 (DHCPv6)", RFC 3315, July 2003. 964 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 965 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 967 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 968 January 2004. 970 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 971 Network Access Identifier", RFC 4282, December 2005. 973 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 974 Identifiers for Dynamic Host Configuration Protocol 975 Version Four (DHCPv4)", RFC 4361, February 2006. 977 [I-D.ietf-idnabis-defs] 978 Klensin, J., "Internationalized Domain Names for 979 Applications (IDNA): Definitions and Document Framework", 980 draft-ietf-idnabis-defs-13 (work in progress), 981 January 2010. 983 [I-D.ietf-geopriv-http-location-delivery] 984 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 985 "HTTP Enabled Location Delivery (HELD)", 986 draft-ietf-geopriv-http-location-delivery-16 (work in 987 progress), August 2009. 989 [W3C.REC-xml-names11-20060816] 990 Tobin, R., Hollander, D., Bray, T., and A. Layman, 991 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 992 Consortium Recommendation REC-xml-names11-20060816, 993 August 2006, 994 . 996 [WiMAX-T33-110-R015v01-B] 997 WiMAX Forum, "Protocols and Procedures for Location Based 998 Services", WiMAX Forum Network Architecture T33-110- 999 R015v01-B, May 2009. 1001 9.2. Informative references 1003 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1004 E. Lear, "Address Allocation for Private Internets", 1005 BCP 5, RFC 1918, February 1996. 1007 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 1008 Address Behaviour Today", RFC 2101, February 1997. 1010 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1011 Configuration Protocol Option for Coordinate-based 1012 Location Configuration Information", RFC 3825, July 2004. 1014 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1015 RFC 3966, December 2004. 1017 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 1018 Polk, J., and J. Rosenberg, "Common Policy: A Document 1019 Format for Expressing Privacy Preferences", RFC 4745, 1020 February 2007. 1022 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1023 (DHCPv4 and DHCPv6) Option for Civic Addresses 1024 Configuration Information", RFC 4776, November 2006. 1026 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1027 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1029 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1030 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1032 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 1033 Location Configuration Protocol: Problem Statement and 1034 Requirements", RFC 5687, March 2010. 1036 [I-D.ietf-geopriv-arch] 1037 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 1038 Tschofenig, H., and H. Schulzrinne, "An Architecture for 1039 Location and Location Privacy in Internet Applications", 1040 draft-ietf-geopriv-arch-02 (work in progress), May 2010. 1042 [I-D.ietf-ecrit-phonebcp] 1043 Rosen, B. and J. Polk, "Best Current Practice for 1044 Communications Services in support of Emergency Calling", 1045 draft-ietf-ecrit-phonebcp-14 (work in progress), 1046 January 2010. 1048 [I-D.thomson-geopriv-held-measurements] 1049 Thomson, M. and J. Winterbottom, "Using Device-provided 1050 Location-Related Measurements in Location Configuration 1051 Protocols", draft-thomson-geopriv-held-measurements-06 1052 (work in progress), May 2010. 1054 [TS.3GPP.23.271] 1055 3GPP, "Functional stage 2 description of Location Services 1056 (LCS)", 3GPP TS 23.271 8.0.0, December 2008. 1058 Authors' Addresses 1060 James Winterbottom 1061 Andrew Corporation 1062 Andrew Building (39) 1063 Wollongong University Campus 1064 Northfields Avenue 1065 Wollongong, NSW 2522 1066 AU 1068 Phone: +61 2 4221 2938 1069 Email: james.winterbottom@andrew.com 1071 Martin Thomson 1072 Andrew Corporation 1073 Andrew Building (39) 1074 Wollongong University Campus 1075 Northfields Avenue 1076 Wollongong, NSW 2522 1077 AU 1079 Phone: +61 2 4221 2915 1080 Email: martin.thomson@andrew.com 1082 Hannes Tschofenig 1083 Nokia Siemens Networks 1084 Linnoitustie 6 1085 Espoo 02600 1086 Finland 1088 Phone: +358 (50) 4871445 1089 Email: Hannes.Tschofenig@gmx.net 1090 URI: http://www.tschofenig.priv.at 1092 Richard Barnes 1093 BBN Technologies 1094 9861 Broken Land Pkwy, Suite 400 1095 Columbia, MD 21046 1096 USA 1098 Phone: +1 410 290 6169 1099 Email: rbarnes@bbn.com