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

Namespace for HELD Device Identity Parameters

908

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

909 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 910 with the RFC number for this specification.]] 911

See RFCXXXX.

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