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

Namespace for HELD Device Identity Parameters

929

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

930 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 931 with the RFC number for this specification.]] 932

See RFCXXXX.

933 934 935 END 937 7.2. XML Schema Registration 939 This section registers an XML schema as per the guidelines in 940 [RFC3688]. 942 URI: urn:ietf:params:xml:schema:geopriv:held:id 943 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 944 James Winterbottom (james.winterbottom@andrew.com). 946 Schema: The XML for this schema can be found as the entirety of 947 Section 6 of this document. [IANA Note: The pattern attribute for 948 naiType does not contain whitespace.] 950 7.3. Registration of HELD 'badIdentifier' Error Code 952 This section registers the "badIdentifier" error code in the "Geopriv 953 HELD Registries, Error codes for HELD" IANA registry. 955 badIdentifier This error code indicates that a Device identifier 956 used in the HELD request was either: not supported by the LIS, 957 badly formatted, or not one for which the requester was authorized 958 to make a request. 960 8. Acknowledgements 962 The the NENA VoIP location working group provided assistance in the 963 definition of the schema used in this document. Special thanks go to 964 Barbara Stark, Guy Caron, Nadine Abbott, Jerome Grenier and Martin 965 Dawson. Bob Sherry provided input on use of URIs. Thanks to Adam 966 Muhlbauer and Eddy Corbett for providing further corrections. 967 Bernard Aboba provided excellent feedback on use cases and the 968 security model; Bernard, along with Alan DeKok, also helped resolve 969 an issue with NAIs. Ray Bellis provided motivation for the protocol 970 port parameters. Marc Linsner and Alissa Cooper provided guidance 971 and text (respectively) that greatly clarified the discussion 972 relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for 973 forcing this to be practical. 975 9. References 977 9.1. Normative references 979 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 980 September 1981. 982 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 983 Requirement Levels", BCP 14, RFC 2119, March 1997. 985 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 986 Leach, P., Luotonen, A., and L. Stewart, "HTTP 987 Authentication: Basic and Digest Access Authentication", 988 RFC 2617, June 1999. 990 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 991 "Remote Authentication Dial In User Service (RADIUS)", 992 RFC 2865, June 2000. 994 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 995 and M. Carney, "Dynamic Host Configuration Protocol for 996 IPv6 (DHCPv6)", RFC 3315, July 2003. 998 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 999 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1001 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1002 10646", STD 63, RFC 3629, November 2003. 1004 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1005 January 2004. 1007 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1008 Resource Identifier (URI): Generic Syntax", STD 66, 1009 RFC 3986, January 2005. 1011 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1012 Network Access Identifier", RFC 4282, December 2005. 1014 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1015 Architecture", RFC 4291, February 2006. 1017 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 1018 Identifiers for Dynamic Host Configuration Protocol 1019 Version Four (DHCPv4)", RFC 4361, February 2006. 1021 [I-D.ietf-idnabis-defs] 1022 Klensin, J., "Internationalized Domain Names for 1023 Applications (IDNA): Definitions and Document Framework", 1024 draft-ietf-idnabis-defs-13 (work in progress), 1025 January 2010. 1027 [I-D.ietf-geopriv-http-location-delivery] 1028 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 1029 "HTTP Enabled Location Delivery (HELD)", 1030 draft-ietf-geopriv-http-location-delivery-16 (work in 1031 progress), August 2009. 1033 [W3C.REC-xml-names11-20060816] 1034 Hollander, D., Layman, A., Tobin, R., and T. Bray, 1035 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 1036 Consortium Recommendation REC-xml-names11-20060816, 1037 August 2006, 1038 . 1040 [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area 1041 Networks: Overview and Architecture", 802, February 2002. 1043 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 1044 Registration Authority", March 1997, . 1047 [WiMAX-T33-110-R015v01-B] 1048 WiMAX Forum, "Protocols and Procedures for Location Based 1049 Services", WiMAX Forum Network Architecture T33-110- 1050 R015v01-B, May 2009. 1052 9.2. Informative references 1054 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1055 E. Lear, "Address Allocation for Private Internets", 1056 BCP 5, RFC 1918, February 1996. 1058 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 1059 Address Behaviour Today", RFC 2101, February 1997. 1061 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1062 Configuration Protocol Option for Coordinate-based 1063 Location Configuration Information", RFC 3825, July 2004. 1065 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1066 RFC 3966, December 2004. 1068 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 1069 Polk, J., and J. Rosenberg, "Common Policy: A Document 1070 Format for Expressing Privacy Preferences", RFC 4745, 1071 February 2007. 1073 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1074 (DHCPv4 and DHCPv6) Option for Civic Addresses 1075 Configuration Information", RFC 4776, November 2006. 1077 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1078 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1080 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1081 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1083 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 1084 Location Configuration Protocol: Problem Statement and 1085 Requirements", RFC 5687, March 2010. 1087 [I-D.ietf-geopriv-arch] 1088 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 1089 Tschofenig, H., and H. Schulzrinne, "An Architecture for 1090 Location and Location Privacy in Internet Applications", 1091 draft-ietf-geopriv-arch-03 (work in progress), 1092 October 2010. 1094 [I-D.ietf-ecrit-phonebcp] 1095 Rosen, B. and J. Polk, "Best Current Practice for 1096 Communications Services in support of Emergency Calling", 1097 draft-ietf-ecrit-phonebcp-15 (work in progress), 1098 July 2010. 1100 [I-D.thomson-geopriv-held-measurements] 1101 Thomson, M. and J. Winterbottom, "Using Device-provided 1102 Location-Related Measurements in Location Configuration 1103 Protocols", draft-thomson-geopriv-held-measurements-06 1104 (work in progress), May 2010. 1106 [TS.3GPP.23.271] 1107 3GPP, "Functional stage 2 description of Location Services 1108 (LCS)", 3GPP TS 23.271 8.0.0, December 2008. 1110 Authors' Addresses 1112 James Winterbottom 1113 Andrew Corporation 1114 Andrew Building (39) 1115 Wollongong University Campus 1116 Northfields Avenue 1117 Wollongong, NSW 2522 1118 AU 1120 Phone: +61 2 4221 2938 1121 Email: james.winterbottom@andrew.com 1123 Martin Thomson 1124 Andrew Corporation 1125 Andrew Building (39) 1126 Wollongong University Campus 1127 Northfields Avenue 1128 Wollongong, NSW 2522 1129 AU 1131 Phone: +61 2 4221 2915 1132 Email: martin.thomson@andrew.com 1134 Hannes Tschofenig 1135 Nokia Siemens Networks 1136 Linnoitustie 6 1137 Espoo 02600 1138 Finland 1140 Phone: +358 (50) 4871445 1141 Email: Hannes.Tschofenig@gmx.net 1142 URI: http://www.tschofenig.priv.at 1144 Richard Barnes 1145 BBN Technologies 1146 9861 Broken Land Pkwy, Suite 400 1147 Columbia, MD 21046 1148 USA 1150 Phone: +1 410 290 6169 1151 Email: rbarnes@bbn.com