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

Namespace for HELD Device Identity Parameters

944

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

945 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 946 with the RFC number for this specification.]] 947

See RFCXXXX.

948 949 950 END 952 7.2. XML Schema Registration 954 This section registers an XML schema as per the guidelines in 955 [RFC3688]. 957 URI: urn:ietf:params:xml:schema:geopriv:held:id 958 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 959 James Winterbottom (james.winterbottom@andrew.com). 961 Schema: The XML for this schema can be found as the entirety of 962 Section 6 of this document. [IANA Note: The pattern attribute for 963 naiType does not contain whitespace.] 965 7.3. Registration of HELD 'badIdentifier' Error Code 967 This section registers the "badIdentifier" error code in the "Geopriv 968 HELD Registries, Error codes for HELD" IANA registry. 970 badIdentifier This error code indicates that a Device identifier 971 used in the HELD request was either: not supported by the LIS, 972 badly formatted, or not one for which the requester was authorized 973 to make a request. 975 8. Acknowledgements 977 The the NENA VoIP location working group provided assistance in the 978 definition of the schema used in this document. Special thanks go to 979 Barbara Stark, Guy Caron, Nadine Abbott, Jerome Grenier and Martin 980 Dawson. Bob Sherry provided input on use of URIs. Thanks to Adam 981 Muhlbauer and Eddy Corbett for providing further corrections. 982 Bernard Aboba provided excellent feedback on use cases and the 983 security model; Bernard, along with Alan DeKok, also helped resolve 984 an issue with NAIs. Ray Bellis provided motivation for the protocol 985 port parameters. Marc Linsner and Alissa Cooper provided guidance 986 and text (respectively) that greatly clarified the discussion 987 relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for 988 forcing this to be practical. 990 9. References 992 9.1. Normative references 994 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 995 August 1980. 997 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 998 September 1981. 1000 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1001 RFC 793, September 1981. 1003 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1004 Requirement Levels", BCP 14, RFC 2119, March 1997. 1006 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1007 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1008 Authentication: Basic and Digest Access Authentication", 1009 RFC 2617, June 1999. 1011 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1012 "Remote Authentication Dial In User Service (RADIUS)", 1013 RFC 2865, June 2000. 1015 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1016 and M. Carney, "Dynamic Host Configuration Protocol for 1017 IPv6 (DHCPv6)", RFC 3315, July 2003. 1019 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1020 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1022 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1023 10646", STD 63, RFC 3629, November 2003. 1025 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1026 January 2004. 1028 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1029 Resource Identifier (URI): Generic Syntax", STD 66, 1030 RFC 3986, January 2005. 1032 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1033 Network Access Identifier", RFC 4282, December 2005. 1035 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1036 Architecture", RFC 4291, February 2006. 1038 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1039 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1041 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 1042 Identifiers for Dynamic Host Configuration Protocol 1043 Version Four (DHCPv4)", RFC 4361, February 2006. 1045 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1046 RFC 4960, September 2007. 1048 [RFC5890] Klensin, J., "Internationalized Domain Names for 1049 Applications (IDNA): Definitions and Document Framework", 1050 RFC 5890, August 2010. 1052 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 1053 RFC 5985, September 2010. 1055 [W3C.REC-xml-names11-20060816] 1056 Hollander, D., Bray, T., Layman, A., and R. Tobin, 1057 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 1058 Consortium Recommendation REC-xml-names11-20060816, 1059 August 2006, 1060 . 1062 [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area 1063 Networks: Overview and Architecture", 802, February 2002. 1065 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 1066 Registration Authority", March 1997, . 1069 [E.164] ITU-T, "E.164 : The international public telecommunication 1070 numbering plan", ITU-T Recommendation E.164, 1071 February 2005. 1073 [E.213] ITU-T, "E.213 : Telephone and ISDN numbering plan for land 1074 mobile stations in public land mobile networks (PLMN)", 1075 ITU-T Recommendation E.213, November 1988. 1077 [TS.3GPP.23.003] 1078 3GPP, "Numbering, addressing and identification", 3GPP 1079 TS 23.003 9.4.0, September 2010. 1081 [TIA.EIA.IS-2000-6] 1082 TIA/EIA, "Analog Signaling Standard for CDMA 2000 Spread 1083 Spectrum Systems", TIA/EIA/IS-2000-6-C, May 2002. 1085 [WiMAX-T33-110-R015v01-B] 1086 WiMAX Forum, "Protocols and Procedures for Location Based 1087 Services", WiMAX Forum Network Architecture T33-110- 1088 R015v01-B, May 2009. 1090 9.2. Informative references 1092 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1093 E. Lear, "Address Allocation for Private Internets", 1094 BCP 5, RFC 1918, February 1996. 1096 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 1097 Address Behaviour Today", RFC 2101, February 1997. 1099 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1100 Configuration Protocol Option for Coordinate-based 1101 Location Configuration Information", RFC 3825, July 2004. 1103 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1104 RFC 3966, December 2004. 1106 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 1107 Polk, J., and J. Rosenberg, "Common Policy: A Document 1108 Format for Expressing Privacy Preferences", RFC 4745, 1109 February 2007. 1111 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 1112 (DHCPv4 and DHCPv6) Option for Civic Addresses 1113 Configuration Information", RFC 4776, November 2006. 1115 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1116 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1118 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1119 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1121 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 1122 Location Configuration Protocol: Problem Statement and 1123 Requirements", RFC 5687, March 2010. 1125 [I-D.ietf-geopriv-arch] 1126 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 1127 Tschofenig, H., and H. Schulzrinne, "An Architecture for 1128 Location and Location Privacy in Internet Applications", 1129 draft-ietf-geopriv-arch-03 (work in progress), 1130 October 2010. 1132 [I-D.ietf-ecrit-phonebcp] 1133 Rosen, B. and J. Polk, "Best Current Practice for 1134 Communications Services in support of Emergency Calling", 1135 draft-ietf-ecrit-phonebcp-16 (work in progress), 1136 October 2010. 1138 Authors' Addresses 1140 James Winterbottom 1141 Andrew Corporation 1142 Andrew Building (39) 1143 Wollongong University Campus 1144 Northfields Avenue 1145 Wollongong, NSW 2522 1146 AU 1148 Phone: +61 2 4221 2938 1149 Email: james.winterbottom@andrew.com 1151 Martin Thomson 1152 Andrew Corporation 1153 Andrew Building (39) 1154 Wollongong University Campus 1155 Northfields Avenue 1156 Wollongong, NSW 2522 1157 AU 1159 Phone: +61 2 4221 2915 1160 Email: martin.thomson@andrew.com 1162 Hannes Tschofenig 1163 Nokia Siemens Networks 1164 Linnoitustie 6 1165 Espoo 02600 1166 Finland 1168 Phone: +358 (50) 4871445 1169 Email: Hannes.Tschofenig@gmx.net 1170 URI: http://www.tschofenig.priv.at 1172 Richard Barnes 1173 BBN Technologies 1174 9861 Broken Land Pkwy, Suite 400 1175 Columbia, MD 21046 1176 USA 1178 Phone: +1 410 290 6169 1179 Email: rbarnes@bbn.com