idnits 2.17.1 draft-thomson-geopriv-location-dependability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1179. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1203. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2007) is 6273 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 821 ** Downref: Normative reference to an Informational RFC: RFC 3076 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-00 ** 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. 'X509v3' -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft J. Winterbottom 4 Intended status: Standards Track Andrew 5 Expires: August 26, 2007 February 22, 2007 7 Digital Signature Methods for Location Dependability 8 draft-thomson-geopriv-location-dependability-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 26, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The dependability of location information is closely related to the 42 degree of trust placed in the source of that information. This 43 document describes techniques that can be used to mitigate the impact 44 of falsifying location information. The application of digital 45 signatures is described, relating these methods to the attacks that 46 they address. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.1. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.2. Basic Countermeasures . . . . . . . . . . . . . . . . . . 6 55 2.3. Signing Location Information . . . . . . . . . . . . . . . 6 56 3. PIDF-LO Signature . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1. Signature Design . . . . . . . . . . . . . . . . . . . . . 7 58 3.2. Signed Elements and Semantics . . . . . . . . . . . . . . 7 59 3.3. Signature Algorithms . . . . . . . . . . . . . . . . . . . 9 60 3.4. LIS/Signer Identification . . . . . . . . . . . . . . . . 9 61 4. Limited Validity . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.1. Validity Elements . . . . . . . . . . . . . . . . . . . . 10 63 5. Signing for a User . . . . . . . . . . . . . . . . . . . . . . 11 64 5.1. The 'entity' Attribute . . . . . . . . . . . . . . . . . . 11 65 5.2. Target Identity . . . . . . . . . . . . . . . . . . . . . 12 66 5.3. Protecting User Anonymity . . . . . . . . . . . . . . . . 12 67 5.4. Authenticated Identity . . . . . . . . . . . . . . . . . . 13 68 5.5. Multiple Identity Attack . . . . . . . . . . . . . . . . . 13 69 6. Target Identity Element . . . . . . . . . . . . . . . . . . . 14 70 6.1. Identity Types . . . . . . . . . . . . . . . . . . . . . . 14 71 6.2. Identity Hashing . . . . . . . . . . . . . . . . . . . . . 14 72 6.3. Authentication Indicator . . . . . . . . . . . . . . . . . 15 73 7. Signature Validation . . . . . . . . . . . . . . . . . . . . . 16 74 8. Code and Examples . . . . . . . . . . . . . . . . . . . . . . 17 75 8.1. Dependability Data Schema . . . . . . . . . . . . . . . . 17 76 8.2. PIDF-LO Transforms . . . . . . . . . . . . . . . . . . . . 18 77 8.2.1. PIDF-LO Tuple-only Transform . . . . . . . . . . . . . 19 78 8.2.2. PIDF-LO Selective Transform . . . . . . . . . . . . . 20 79 8.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 9. Location Reference Attribution . . . . . . . . . . . . . . . . 25 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 82 10.1. Signature Rules . . . . . . . . . . . . . . . . . . . . . 26 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 84 11.1. URN Sub-Namespace Registration for 85 urn:ietf:params:xml:ns:pidf:geopriv10:dsig . . . . . . . . 27 86 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 27 87 11.3. URN Sub-Namespace Registration for 88 urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity . . . 28 89 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 91 13.1. Normative References . . . . . . . . . . . . . . . . . . . 30 92 13.2. Informative References . . . . . . . . . . . . . . . . . . 30 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 94 Intellectual Property and Copyright Statements . . . . . . . . . . 32 96 1. Introduction 98 Location information about a particular person or device is critical 99 to a number of applications. The integrity of this information -- 100 whether or not it can be relied upon for correctness -- is also 101 important to the user of the data. This is especially important if 102 the recipient of location information expends resources based on the 103 information. 105 The quitessential example of an application where the veracity of 106 location information is critical is emergency calling. Location 107 information is used both by routing functions to determine the 108 correct Public Safety Answering Point (PSAP) and by the selected PSAP 109 to determine where to send personnel. If location information were 110 faked, the call could be directed to the wrong PSAP, or personnel 111 could be directed to an incorrect location. In either case, an 112 attacker wastes PSAP resources and risks delaying their life-critical 113 interventions for other legitimate emergency callers. 115 This document details several cryptographic methods that limit the 116 scope of attacks on location recipients based on faked or stolen 117 location information. Methods for applying digital signatures are 118 described so that a location recipient can identify the source of the 119 location information, either Location Information Server (LIS) or 120 Target. Identifying the source allows the location recipient to make 121 a judgement on whether or not to trust the content of the location 122 information. 124 Ultimately, these methods are limited in practicality by the 125 transient nature of the relationships between LIS (the access 126 network) and the Target. Because these relationships can be 127 arbitrary and temporary, schemes like authentication are not always 128 feasible. The basic goal of this draft is to both limit the scope of 129 attacks and to provide as much information to the location recipient 130 as possible so that they can make a decision on whether or not to act 131 on the location information they are provided. 133 1.1. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 2. Goals 141 This document describes several measures that can be applied to limit 142 attacks that rely on using faked or stolen location information. 143 These attacks leave a user of location information vulnerable to 144 exploitation by an attacker. 146 The measures outlined in this document are designed to limit exposure 147 to the following attacks: 149 Place Shifting: In place shifting, an attacker selects any location 150 (presumably somewhere other than where they are currently located) 151 and constructs a PIDF-LO based on that information. 153 Time Shifting: In a time shifting, or replay, attack the attacker 154 uses location information that was valid in the past, but is no 155 longer valid because the attacker has moved since the location was 156 generated. 158 Location Theft: An attacker that is able to observe the Target's 159 location information can replay this information and thereby 160 appear to be at the same location. 162 Location Swapping: Two colluding attackers can conspire to fake 163 location by exchanging location information. One attacker can 164 pretend to be at the other's location. 166 These attacks are a subset of those described in 167 [I-D.ietf-geopriv-l7-lcp-ps]. 169 2.1. Non-Goals 171 The measures outlined in this document cannot hope to address all 172 possible cases of fraud. This section outlines general areas where 173 this document does not provide guidance; more specific limitations 174 are included in the relevant sections. 176 Attacks where the authenticated identity of the Target can be 177 reliably mimicked are not included. This includes active collusion, 178 as well as any attacks, network-based or otherwise, on the Target 179 host that result in complete access to the Target's credentials. In 180 addition, this includes attacks that require cooperation between the 181 attacker and Target. If the attacker is able to gain access to the 182 Target's private key, then to all cryptographic means the attacker 183 can pretend to be the Target. 185 Methods for determining trust in either LIS or Target are out of 186 scope for this document. This document only describes the means by 187 which an identity can be verified; the decision over whether or not 188 to trust the entity is left to the location recipient. Means for 189 establishing trust will be the topic of a separate work. 191 Note that where certificate chains are used for authentication, a 192 domain name-based certificate does not necessarily indicate 193 trustworthiness in the provision of location information. Therefore, 194 verification of LIS identity through a certificate alone is not 195 enough to ensure that the location recipient can trust the LIS, the 196 recipient needs to use additional criteria to decide on whether to 197 trust the LIS. 199 2.2. Basic Countermeasures 201 A good minimum requirement for the exchange of location information 202 is that location information is protected from interception and 203 modification by third parties in all protocol exchanges. Location 204 protocols that use TLS [RFC4346] are able to meet this requirement. 205 Confidentiality from third parties and integrity protection are 206 required for all location using-protocols [RFC3693]. 208 2.3. Signing Location Information 210 A digital signature provides data integrity and authentication of the 211 source of information. This document describes how XML-Signature 212 [RFC3275] can be applied to a Presence Information Data Format - 213 Location Object (PIDF-LO) [RFC4119]. It also describes the benefits 214 of signing and how signing can be practically applied. 216 3. PIDF-LO Signature 218 A location recipient can use the signature on a location object to 219 authenticate the identity of the LIS. This is done through the 220 certificate that the LIS attaches with the signature. The signature 221 also ensures that the contents have not been modified since the LIS 222 signed the location object. 224 It is important to specify the semantics of a certificate of this 225 nature. In essence, information that is signed SHOULD be verifiable 226 by the LIS. However, in some cases it is expedient to include some 227 unverifiable information (as is shown in later sections). Therefore, 228 this document assigns a strict semantic to each signed element in the 229 location object. 231 3.1. Signature Design 233 This document uses the XML-Signature [RFC3275] enveloped signature 234 type; that is, signature elements are included within the normal 235 structure of the PIDF-LO document. This ensures that the location 236 object does not appear to be any different from a regular PIDF-LO 237 document. This permits use of the document in any protocol that 238 carries PIDF-LO without requiring any changes to the protocol. 239 Applications that rely on PIDF-LO can simply ignore the signature 240 elements if they are not supported. 242 A signature is applied to a single tuple within the PIDF document. 243 This means that signed location information can be included in a 244 composite presence document without destroying the signature. 246 It is also a goal of the signature design to ensure that if unsigned 247 elements are removed from the PIDF-LO, the document remains a valid 248 PIDF-LO. This keeps the PIDF-LO usable if the signature and any 249 unsigned data are stripped out. This is particularly important when 250 the signature rules (Section 10.1) are applied. 252 3.2. Signed Elements and Semantics 254 When location information is signed by a LIS, each unit of data in 255 the signed document is given certain significance. A location 256 recipient needs to know what significance the LIS has given to each 257 field before it can base any decision on the contents of that field. 259 The following list describes each of the elements that are included 260 in a signed LO, justifies their inclusion and outlines the intended 261 semantics of each being signed: 263 presence (urn:ietf:params:xml:ns:pidf): The root element of a 264 presence document, the "presence" element, is signed. The 265 "entity" attribute is also signed. The "entity" attribute SHOULD 266 contain an identifier generated by the LIS, see Section 5 and 267 Section 5.3. 269 tuple (urn:ietf:params:xml:ns:pidf): Only the tuple that contains 270 location information is signed. The "id" attribute is signed to 271 ensure a valid PIDF-LO is produced. 273 geopriv (urn:ietf:params:xml:ns:pidf:geopriv10): The "geopriv" 274 element is signed, along with select elements within it. 276 location-info (urn:ietf:params:xml:ns:pidf:geopriv10): The most 277 important element of the PIDF-LO, "location-info" contains 278 location data. This element and all its contents are signed. 280 usage-rules (urn:ietf:params:xml:ns:pidf:geopriv10): Usage rules are 281 included to ensure the validity of the PIDF-LO. An empty 282 "usage-rules" element is valid. The contents of these are not 283 signed to allow a user to enter their preferences upon receipt of 284 the signed LO. No decisions can be made on the unsigned content 285 of usage rules. 287 method (urn:ietf:params:xml:ns:pidf:geopriv10): The method parameter 288 is included, and consequently signed, only if known. The LIS 289 SHOULD verify the accuracy of this field, but MAY opt to include 290 the element without validation. An unvalidated method is allowed 291 because of the informational nature of the data it contains. 292 Method is a metadata element and therefore is not a suitable basis 293 for decision making, especially where a similar decision can be 294 based on location information. A recipient SHOULD NOT use the 295 value of this field as the basis for any decision. 297 All elements defined in this document: This document defines a 298 number of elements that are designed for inclusion in the tuple. 299 These elements limit the effectiveness of certain attacks. 300 Validity intervals and Target identity are defined in Section 4, 301 Section 5. 303 This document defines two transforms that can be applied to a PIDF-LO 304 in order to limit what is signed Section 8.2. The first is a 305 selective transform that only selects the elements listed above. The 306 second simply selects the enveloping tuple. The LIS MAY choose not 307 to use either transform, but in doing so, all unverified elements 308 MUST be removed from the signed document. 310 3.3. Signature Algorithms 312 As specified in RFC 3275 [RFC3275], implementations of this 313 specification MUST provide the following algorithms: 315 digest algorithm: The SHA1 digest, as identified by the URN 316 "http://www.w3.org/2000/09/xmldsig#sha1". 318 signature algorithm: DSA with SHA1, as identified by the URN 319 "http://www.w3.org/2000/09/xmldsig#dsa-sha1". 321 canonicalization method: Canonical XML [RFC3076], as identified by 322 the URN "http://www.w3.org/TR/2001/REC-xml-c14n-20010315". 324 transforms: The enveloped signature transform, as identified by the 325 URN "http://www.w3.org/2000/09/xmldsig#enveloped-signature"; and 326 the transforms defined in this document: the tuple-only transform 327 (Section 8.2.1), as identified by the URN 328 "urn:ietf:params:xml:ns:pidf:geopriv10:dsig#tuple" and the 329 selective transform (Section 8.2.2), as identified by the URN 330 "urn:ietf:params:xml:ns:pidf:geopriv10:dsig#selective". 332 It is also RECOMMENDED that the PKCS1 (RSA-SHA1) signature algorithm, 333 as idenfied by "http://www.w3.org/2000/09/xmldsig#rsa-sha1" is also 334 supported. 336 3.4. LIS/Signer Identification 338 RFC 3275 [RFC3275] describes a number of methods for describing the 339 key used to sign the document. For the purpose of signing a location 340 object, the "KeyInfo" element MUST be provided in the "Signature" 341 element. 343 The LIS MUST include an X.509v3 certificate in the signature. This 344 can be either by including an "X509Certificate" element, or by 345 referencing another certificate. 347 A reference to a certificate within the same document may be made 348 using a fragment identifier URI. Internal references could be 349 applicable where multiple signatures are applied to different parts 350 of the document. 352 The LIS SHOULD NOT reference an external source unless there is a 353 reasonable expectation that the location recipient can successfully 354 retrieve the certificate. A reference to an external certificate 355 MUST be described by URI in the "RetrievalMethod" element. The 356 scheme for the the RetrievalMethod URI MUST be "https:". 358 4. Limited Validity 360 The simplest attack to address is the Time Shifting attack. The LIS 361 can specify a limited time period where the location information can 362 be considered valid. Applying a signature ensures that the 363 information is not tampered with. 365 A known limitation of this method is that the information could 366 become invalid at any time after the LIS signs the document. Once 367 location is generated, the Target can move at any time, thereby 368 invalidating the location object. Therefore, the LIS SHOULD make the 369 time period covered by the signature as short as possible to limit 370 the impact of such movement. The LIS can base any chosen period on 371 any knowledge it has about the mobility or current speed of the 372 Target. 374 Location recipients MAY choose to implement a minimum age policy for 375 locations, choosing to further restrict the validity interval to 376 limit the chances of this occurring. It is RECOMMENDED that the 377 "from" element is used in this case, since the LIS is expected to 378 validate location before it signs location information. 380 4.1. Validity Elements 382 A "validity" element is defined with two sub-elements, "from" and 383 "until". 385 The "from" element contains the time that the LIS signs the location 386 information. Note that this could differ from the time that the 387 location was generated, which is included in the PIDF "timestamp" 388 element. 390 The "until" element contains the last time that the signature can be 391 considered valid. Choice of an appropriate validity interval is left 392 to LIS implementations; however, it is RECOMMENDED that this period 393 not exceed one day. The period chosen SHOULD also consider the type 394 of network access in use -- location becomes invalid faster in more 395 mobile networks. 397 The signature MUST NOT be considered valid if the current time is 398 outside of the interval specified in these elements. 400 5. Signing for a User 402 Signing location information alone, even with a limited validity 403 period does not ensure that it is not reused. Signing some sort of 404 user identifier with the location object provides an additional 405 degree of protection. Most importantly, the location recipient is 406 able to detect duplicate location objects for the same Target. In 407 addition, if some extra data is included from the Target, the 408 location recipient is also able to link the location object with a 409 user identity. 411 5.1. The 'entity' Attribute 413 The "entity" attribute of a presence document is intended to convey 414 the identity of the Target. The LIS does not necessarily know this 415 identity. Nor does the LIS necessarily have the means to 416 authenticate the Target. 418 It is RECOMMENDED that this field be generated by the LIS. The LIS 419 SHOULD construct an "unlinked pseudonym" for the Target that does not 420 contain any possible identifying information for the target. The 421 simplest way to meet this requirement is to generate a "pres:" URI 422 randomly, using a random sequence of characters and the host name of 423 the LIS (e.g., "pres:f6pc98w1pd49s0p@lis.example.com"). 425 An unlinked pseudonym provides a limited means of ensuring that 426 location information is not reused or replayed. The presentity 427 identifier used acts as a serial number for each location object, 428 allowing each to be uniquely identified. A location recipient is 429 able to use this identifier to detect multiple uses of the same piece 430 of location information. This limits the effectiveness of replay 431 attacks. 433 Presentity identifiers can be reused for the same Target, provided 434 that the LIS is able to verify that the Target is the same. This 435 depends on the means by which location is acquired from the LIS; if 436 session data that links subsequent requests exists, the LIS MAY reuse 437 the presentity identifier. Note that the the Target can initiate a 438 new session to ensure that a new identifier is generated and thereby 439 ensure that their previous and current positions cannot be correlated 440 using the presentity identifier. 442 This does not prevent the use of a "real" presentity in this field. 443 If the LIS is able to authenticate the Target, and the Target grants 444 permission to the LIS to use this field, the LIS can include this 445 information in the "entity" field. These conditions are hard to 446 meet, which leads to two alternative means of including Target 447 identity, described in the following sections. 449 5.2. Target Identity 451 The unlinked pseudonym used by the LIS acts as an anonymous 452 identifier to a location recipient. The only information that this 453 provides is that two location objects were generated for the same 454 (anonymous) Target. The location recipient might also wish to link 455 the location object to the identity of a particular user. For 456 example, a PSAP might want to link the location object to the 457 authenticated identity of a emergency caller. 459 To achieve this linkage between location object and the Target's 460 identity, the Target sends its identity to the LIS. The LIS includes 461 this identifier in the signed location object, effectively linking 462 the identity to the location information. 464 A location recipient verifies that location information was signed 465 for a particular Target by authenticating the Target and comparing 466 the authenticated identity against the one in the signed location 467 object. 469 The LIS is not expected to authenticate this identity information, 470 although it MAY do so. This means that an attacker within the 471 network could request a signed location object with any identity they 472 choose. However, the location object could only be used by an entity 473 that can prove that they have the chosen identity, which limits the 474 number of potential attackers. 476 5.3. Protecting User Anonymity 478 The problem with sending the Target's identity to the LIS is that the 479 Target might not wish to provide this information to the access 480 network operator. 482 This can be addressed by using a cryptographic hash of the user 483 identity in place of the actual identifier. Since the LIS does not 484 necessarily authenticate the identity, this information provides the 485 same attributes as the real identity. Since the hash is not 486 reversible, the LIS is unable to identify the Target, but the hash 487 cannot be generated from any identifier other than the one used by 488 the Target. 490 The location recipient authenticates the Target's identity, then 491 compares a hash of the identity to the hash that is included in the 492 location object to verify that the identity matches. 494 5.4. Authenticated Identity 496 With the above solution, one easy collusion attack exists. One 497 attacker at the actual location requests a location object with 498 another attacker's identity. The second, potentially remote, 499 attacker is able to use this object. If the first attacker is 500 authenticated by the LIS, this attack is limited, because it requires 501 that both attackers have access to the same authentication 502 credentials. 504 The effectiveness of this approach is limited by the ability of the 505 LIS to authenticate arbitrary users in the access network. Location 506 recipients cannot rely on the LIS performing authentication. 508 5.5. Multiple Identity Attack 510 The schemes described in this section rely on the Target providing an 511 identity. A potential attack uses a single attacker in the access 512 network that requests location information using a number of 513 different identities. The attacker requests multiple location 514 objects, using a different identity each time. These objects are 515 passed to any number of other attackers, who are each able to 516 authenticate with the identity that is included in the location 517 object. This potentially allows a large number of distributed 518 attackers to use the same location information to perform a denial of 519 service attack. 521 In some scenarios, multiple identities can be valid. Examples in 522 Section 3 of [I-D.ietf-geopriv-l7-lcp-ps] show that multiple hosts 523 can appear from the same network demarcation point. Ideally, the LIS 524 would still serve these hosts individually because they each have a 525 valid reason to acquire location information. However, to prevent an 526 attack where a user requests large numbers of location objects with 527 different identity information, the LIS SHOULD limit the number of 528 identities that can be served from any particular network point. 529 Authenticating the Targets in this scenario could provide some 530 additional surety that each is legitimate. If multiple Targets 531 legitimately exist at the same location, then these Targets can 532 authenticate with the LIS. The LIS MAY use a higher limit for 533 authenticated Targets. 535 6. Target Identity Element 537 This document defines an XML "identity" element that can be used to 538 include identity information in a PIDF-LO. This element is used in 539 addition to a randomized "entity" attribute for several reasons: a 540 randomized "entity" attribute can be used to detect replays; the 541 identity is not necessarily authenticated; and the content can be 542 other than a presentity identifier. 544 6.1. Identity Types 546 The content of this element is dependent on the type associated with 547 the identifier. The "type" attribute is used to define the nature of 548 the identity that is included. Two values are provided by default: 550 URI: A value of 551 "urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity#uri" for the 552 type attribute indicates that the contents are a URI. This URI 553 can include a presentity URI, or other URI that identifies the 554 target; for example a SIP URI. This type MUST be supported. 556 An X.509 certificate: A value of 557 "urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity#x509" 558 indicates that the contents are an X.509v3 certificate [X509v3], 559 in the format described in [RFC3275] for "X509Certificate". 561 New identity types are identified by URNs, which means that 562 registration is not required to add new types. A location recipient 563 that does not support a particular identity type MUST treat the 564 location object as if no identity information were included. 566 6.2. Identity Hashing 568 To allow for anonymity, the content of the "identity" element MAY be 569 hashed and the hash value included in this element instead. The 570 "hash" attribute indicates whether the value has been hashed. A 571 reserved value of "##none" indicates that the actual value is 572 included. Otherwise, the attribute includes a hash algorithm 573 identifier, as defined in [RFC3275]. The SHA1 algorithm MUST be 574 supported; this is identified by the URN 575 "http://www.w3.org/2000/09/xmldsig#sha1". 577 Each different identity type requires a procedure for obtaining the 578 bytes that are hashed. 580 URI: For the URI type, the input to the hash algorithm is the UTF-8 581 bytes of the URI. 583 X.509: For the X.509 type, the input to the hash algorithm is the 584 binary value of the certificate; that is, after the base64 585 encoding [RFC2045] is decoded. 587 If the "hash" attribute is present and set to a value other than 588 "##none", the contents of the "identity" element are always the 589 base64 encoded result from the hash function. 591 6.3. Authentication Indicator 593 If the LIS is able to authenticate the Target, the LIS can indicate 594 this in the "authenticated" attribute. 596 This indicator can be used irrespective of the value of the "hash" 597 attribute. This indicates to the location recipient that user 598 identity included in the "identity" element was authenticated by the 599 LIS. 601 7. Signature Validation 603 A location recipient performs the following steps to validate a 604 signed location object: 606 1. Authenticate the entity that provided the location information 607 (the sender). 609 2. Check the integrity of the digital certificate. 611 3. Extract the identity of the LIS from the digital certificate. 613 4. Remove all unsigned components from the location object. 615 5. Ensure the validity interval from the location object covers the 616 present time. 618 6. Check that the authenticated identity of the sender matches the 619 identity in the location object, or that a hash of this identity 620 matches the hashed identity in the location object. 622 Once this process is complete, the location recipient has the 623 following information upon which to base any policy decision: 625 o Whether the location object was signed. 627 o Whether the signature on the location object was valid. 629 o The identity of the sender. 631 o The identity of the LIS. 633 o Whether the LIS authenticated the sender in generating the 634 location object. 636 o The presentity identifier generated by the LIS that distinguishes 637 this location object. 639 Policies are set by individual location recipients and are dictated 640 by a range of factors. Even a failure in signature validation does 641 not necessarily require that the location recipient reject the 642 location information. 644 For instance, a PSAP might not reject an emergency call with no 645 signature. The PSAP could instead place a lower priority on such a 646 call so that in a busy period the call is queued behind calls that 647 contained valid signatures. Similarly, un-authenticated calls could 648 be given similar treatment. 650 8. Code and Examples 652 8.1. Dependability Data Schema 654 The following XML Schema [W3C.REC-xmlschema-1-20041028] defines the 655 "dependability" element. This element is intended for use in a 656 PIDF-LO within a "tuple". 658 659 666 667 669 GEOPRIV PIDF-LO Dependability Elements 670 671 672 674 This document defines dependability elements for PIDF-LO. 675 676 678 680 681 682 683 684 685 686 687 689 690 691 692 693 694 695 697 698 699 700 702 704 705 706 707 708 709 710 711 712 713 714 716 719 720 721 723 725 8.2. PIDF-LO Transforms 727 The transforms defined in this section select certain parts of a 728 PIDF-LO document for signing. These transforms ensure that only one 729 tuple is signed, with varying amounts of content. This allows 730 location information to be composed with other tuples and for 731 independent signatures on multiple tuples. 733 The LIS MUST use one of these transforms to avoid the implication 734 that only the tuple is signed (where in fact the entire document 735 would be signed). The enveloped signature transform MUST also be 736 used. 738 These transforms can be implemented by substituting instances of 739 transforms (identified by URNs) with the XPath transforms below. 740 However, equivalent implementations using other means might provide 741 better performance. 743 8.2.1. PIDF-LO Tuple-only Transform 745 The following XPath filter [RFC3275] selects the first "tuple" 746 descendant of the signature element and all its contents. The 747 "presence" element that is the immediate parent of the "tuple" is 748 also selected. This transform is identified by the URN 749 "urn:ietf:params:xml:ns:pidf:geopriv10:dsig#tuple". 751 754 757 758 (count(ancestor-or-self::pidf:tuple[1] 759 | here()/ancestor::pidf:tuple[1]) == 1) 761 762 or (count(self::pidf:presence 763 | here()/ancestor::pidf:presence[1]) = 1) 765 767 or ((count(parent::pidf:presence 768 | here()/ancestor::pidf:presence[1]) = 1) 769 and (count(self::node() | parent::*/attribute::* 770 | parent::*/namespace::*) + 1 771 == (count(self::node()) + count(parent::*/attribute::*) 772 + count(parent::*/namespace::*)))) 773 774 776 8.2.2. PIDF-LO Selective Transform 778 Similar to the tuple-only transform, this transform selects a single 779 "tuple" element and its parent "presence" element. In contrast, this 780 transform only selects those elements listed in Section 3.2. This 781 transform allows a Target to make adjustments to non-critical 782 elements in the PIDF-LO after the signed PIDF-LO is received from the 783 LIS. In particular, this allows the Target to set the content of the 784 "usage-rules" element and other PIDF data, like contact information. 785 This transform is identified by the URN 786 "urn:ietf:params:xml:ns:pidf:geopriv10:dsig#selective". 788 791 796 797 (count(self::pidf:presence 798 | here()/ancestor::pidf:presence[1]) = 1) 800 801 or ((count(ancestor-or-self::pidf:tuple[1] 802 | here()/ancestor::pidf:tuple[1]) == 1) 803 and (self::pidf:tuple or self::pidf:status 804 or ancestor-or-self::pidf:timestamp 805 or self::gp:geopriv or self::gp:usage-rules 806 or ancestor-or-self::gp:method 807 or ancestor-or-self::gp:location-info 808 or ancestor-or-self::dep:dependability)) 810 811 812 or ((count(self::node() | parent::*/attribute::* 813 | parent::*/namespace::*) + 1 814 == (count(self::node()) + count(parent::*/attribute::*) 815 + count(parent::*/namespace::*))) 816 and parent::*[ 817 (count(self::pidf:presence 818 | here()/ancestor::pidf:presence[1]) = 1) 820 or ((count(ancestor-or-self::pidf:tuple[1] 821 | here()/ancestor::pidf:tuple[1]) == 1) 823 and (self::pidf:tuple or self::pidf:status 824 or self::gp:geopriv or self::gp:usage-rules)) 825 ]) 826 827 829 8.3. Example 831 The following PIDF-LO document has been signed using the selective 832 transform. [[NOTE: A proper example, with a verifiable signature, 833 will be created in a later version of this draft.]] 835 836 840 841 842 843 844 845 846 -34.407 150.88001 34 847 848 849 850 851 no 852 853 2004-12-01T21:28:43+10:00 854 855 856 857 858 860 861 2007-02-16T16:25:24+11:00 862 2007-02-17T16:25:24+11:00 863 864 866 pres:user@example.com 867 869 870 872 874 875 876 878 880 881 883 884 60NvZvtdTB+7UnlLp/H24p7h4bs= 885 886 887 888 889 juS5RhJ884qoFR8flVXd/rbrSDVGn40CapgB7qeQiT+rr0NekEQ6BHhUA 890 8dT3+BCTBUQI0dBjlml9lwzENXvS83zRECjzXbMRTUtVZiPZG2pqKPnL2 891 YU3A9645UCjTXU+jgFumv7k78hieAGDzNci+PQ9KRmm//icT7JaYztgt4= 892 893 894 895 896 MIICeDCCAeGgAwIBAgIEOd3+iDANBgkqhkiG9w0BAQQFADBbMQsw 897 CQYDVQQGEwJJRTEPMA0GA1UECBMGRHVibGluMSUwIwYDVQQKExxC 898 YWx0aW1vcmUgVGVjaG5vbG9naWVzLCBMdGQuMRQwEgYDVQQDEwtU 899 ZXN0IFJTQSBDQTAeFw0wMDEwMDYxNjMyMDdaFw0wMTEwMDYxNjMy 900 MDRaMF0xCzAJBgNVBAYTAklFMQ8wDQYDVQQIEwZEdWJsaW4xJTAj 901 BgNVBAoTHEJhbHRpbW9yZSBUZWNobm9sb2dpZXMsIEx0ZC4xFjAU 902 BgNVBAMTDU1lcmxpbiBIdWdoZXMwgZ8wDQYJKoZIhvcNAQEBBQAD 903 gY0AMIGJAoGBALgorpKYDmjpq6tXz1Ex9wgF8bhZj47JkuI50ysa 904 79MNSSnF7SdjN2pGldXf5Gq7yZZnmqNtIzcva/v7ysIm4zO+xft2 905 yJHjBBpgCFJxXIiZEfooTu2+HE7mJxIvMR7buIjJ+hjgwaBM6hUG 906 HXfKeL62QbL7OOJ060vKssoW2uuPAgMBAAGjRzBFMB4GA1UdEQQX 907 MBWBE21lcmxpbkBiYWx0aW1vcmUuaWUwDgYDVR0PAQH/BAQDAgeA 908 MBMGA1UdIwQMMAqACEngrZIVgu03MA0GCSqGSIb3DQEBBAUAA4GB 909 AHJu4JVq/WnXK2oqqfLWqes5vHOtfX/ZhCjFyDMhzslI8am62gZe 910 dwZ9IIZIwlNRMvEDQB2zds/eEBnIAQPl/yRLCLOfZnbA8PXrbFP5 911 igs3qQWScBUjZVjik748HU2sUVZOa90c0mJl2vJs/RwyLW7/uCAf 912 C/I/k9xGr7fneoIW 913 914 915 916 917 918 This note may be changed without affecting the signature. 919 920 2005-05-18T15:03:39.362+10:00 921 922 923 Once the signature has been checked, the following document is 924 extracted. Only these elements have been included in the signature. 925 Whitespace has been added to this example to improve readability. 927 931 932 933 934 935 936 937 -34.407 150.88001 34 938 939 940 941 942 943 944 946 947 2007-02-16T16:25:24+11:00 948 2007-02-17T16:25:24+11:00 949 950 952 pres:user@example.com 953 954 2005-05-18T15:03:39.362+10:00 955 956 958 9. Location Reference Attribution 960 Digital signatures are less useful when location is provided by 961 reference. In this case, the location recipient acquires location 962 information directly from the LIS. 964 The location recipient is able to authenticate the LIS when it 965 establishes a session to retrieve location information (and indeed, 966 this authentication is necessary to protect against other forms of 967 attack). This authentication process reveals to the location 968 recipient the same information that would be included in a digital 969 signature. Therefore, signing the result of a location deference is 970 not necessary, unless the dereferencing entity intends to then pass 971 the location object to another entity (note that this MUST be 972 permitted by the usage rules). 974 Similar constraints apply to a location object that is retrieved by 975 reference as those that apply to a signed location object (that is, a 976 by-value location object). The location object that is retrieved by 977 reference needs to include the same identity information that would 978 be included in a signed location object. 980 Validity elements are less critical, since it can be assumed that the 981 LIS does not provide location information unless it is current. The 982 LIS MAY include validity elements to provide an indication of the 983 limits of the objects validity. 985 10. Security Considerations 987 This entire document is about the security properties of location 988 objects. 990 10.1. Signature Rules 992 Three rules that relate to the treatment of signed information are 993 described in [RFC3275]. These rules are _Only What is Signed is 994 Secure_, _Only What is "Seen" Should be Signed_, and _"See" What is 995 Signed_. These should apply when a location recipient evaluates and 996 uses a location object. These especially apply when displaying 997 location information to a user. 999 11. IANA Considerations 1001 This section registers the dependability elements schema and related 1002 namespace URNs with IANA. 1004 11.1. URN Sub-Namespace Registration for 1005 urn:ietf:params:xml:ns:pidf:geopriv10:dsig 1007 This section registers a new XML namespace, 1008 "urn:ietf:params:xml:ns:pidf:geopriv10:dsig", as per the guidelines 1009 in [RFC3688]. 1011 URI: urn:ietf:params:xml:ns:pidf:geopriv10:dsig 1013 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1014 Martin Thomson (martin.thomson@andrew.com). 1016 XML: 1018 BEGIN 1019 1020 1022 1023 1024 GEOPRIV Dependability Elements 1025 1026 1027

Namespace for GEOPRIV Dependability Elements

1028

urn:ietf:params:xml:ns:pidf:geopriv10:dsig

1029 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1030 with the RFC number for this specification.]] 1031

See RFCXXXX.

1032 1033 1034 END 1036 Note: Two fragment identifiers ("#tuple" and "#selective") are added 1037 to this URN to identify the two transforms defined in RFCXXXX. 1039 11.2. XML Schema Registration 1041 This section registers an XML schema as per the guidelines in 1042 [RFC3688]. 1044 URI: urn:ietf:params:xml:schema:pidf:geopriv10:dsig 1046 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1047 Martin Thomson (martin.thomson@andrew.com). 1049 Schema: The XML for this schema can be found in Section 8.1 of this 1050 document, between "" and "" 1051 (inclusive). 1053 11.3. URN Sub-Namespace Registration for 1054 urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity 1056 This section registers a new XML namespace, 1057 "urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity", as per the 1058 guidelines in [RFC3688]. 1060 URI: urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity 1062 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1063 Martin Thomson (martin.thomson@andrew.com). 1065 XML: 1067 BEGIN 1068 1069 1071 1072 1073 GEOPRIV Dependability Elements 1074 1075 1076

Namespace for GEOPRIV Dependability Elements: 1077 Identity Identifiers

1078

urn:ietf:params:xml:ns:pidf:geopriv10:dsig:identity

1079 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1080 with the RFC number for this specification.]] 1081

See RFCXXXX.

1082 1083 1084 END 1086 Note: Two fragment identifiers ("#uri" and "#x509") are added to 1087 this URN to identify the two types of identity defined in RFCXXXX. 1089 12. Acknowledgements 1091 The authors would like to acknowledge the contribution of the GEOPRIV 1092 WG; the L7 design team; Hannes Tschofenig and Henning Schulzrinne. 1094 13. References 1096 13.1. Normative References 1098 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1099 Extensions (MIME) Part One: Format of Internet Message 1100 Bodies", RFC 2045, November 1996. 1102 [RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076, 1103 March 2001. 1105 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 1106 Language) XML-Signature Syntax and Processing", RFC 3275, 1107 March 2002. 1109 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1110 Format", RFC 4119, December 2005. 1112 [I-D.ietf-geopriv-l7-lcp-ps] 1113 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 1114 Location Configuration Protocol; Problem Statement and 1115 Requirements", draft-ietf-geopriv-l7-lcp-ps-00 (work in 1116 progress), January 2007. 1118 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1119 Requirement Levels", BCP 14, RFC 2119, March 1997. 1121 [X509v3] ITU-T Recommendation, "Information Technology - Open 1122 Systems Interconnection - The Directory Authentication 1123 Framework", ISO/IEC 9594-8:1997, 1997. 1125 [W3C.REC-xmlschema-1-20041028] 1126 Beech, D., Thompson, H., Maloney, M., and N. Mendelsohn, 1127 "XML Schema Part 1: Structures Second Edition", World Wide 1128 Web Consortium Recommendation REC-xmlschema-1-20041028, 1129 October 2004, 1130 . 1132 13.2. Informative References 1134 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1135 January 2004. 1137 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1138 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1140 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1141 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1143 Authors' Addresses 1145 Martin Thomson 1146 Andrew 1147 PO Box U40 1148 Wollongong University Campus, NSW 2500 1149 AU 1151 Phone: +61 2 4221 2915 1152 Email: martin.thomson@andrew.com 1153 URI: http://www.andrew.com/ 1155 James Winterbottom 1156 Andrew 1157 PO Box U40 1158 Wollongong University Campus, NSW 2500 1159 AU 1161 Phone: +61 2 4221 2938 1162 Email: james.winterbottom@andrew.com 1163 URI: http://www.andrew.com/ 1165 Full Copyright Statement 1167 Copyright (C) The IETF Trust (2007). 1169 This document is subject to the rights, licenses and restrictions 1170 contained in BCP 78, and except as set forth therein, the authors 1171 retain all their rights. 1173 This document and the information contained herein are provided on an 1174 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1175 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1176 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1177 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1178 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1179 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1181 Intellectual Property 1183 The IETF takes no position regarding the validity or scope of any 1184 Intellectual Property Rights or other rights that might be claimed to 1185 pertain to the implementation or use of the technology described in 1186 this document or the extent to which any license under such rights 1187 might or might not be available; nor does it represent that it has 1188 made any independent effort to identify any such rights. Information 1189 on the procedures with respect to rights in RFC documents can be 1190 found in BCP 78 and BCP 79. 1192 Copies of IPR disclosures made to the IETF Secretariat and any 1193 assurances of licenses to be made available, or the result of an 1194 attempt made to obtain a general license or permission for the use of 1195 such proprietary rights by implementers or users of this 1196 specification can be obtained from the IETF on-line IPR repository at 1197 http://www.ietf.org/ipr. 1199 The IETF invites any interested party to bring to its attention any 1200 copyrights, patents or patent applications, or other proprietary 1201 rights that may cover technology that may be required to implement 1202 this standard. Please address the information to the IETF at 1203 ietf-ipr@ietf.org. 1205 Acknowledgment 1207 Funding for the RFC Editor function is provided by the IETF 1208 Administrative Support Activity (IASA).