idnits 2.17.1 draft-ietf-sip-asserted-identity-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 33 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 363 has weird spacing: '... where prox...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If an P-Asserted-Identity header is already present in the message that a proxy receives from an entity that it does not trust, the proxy MAY use this information as a hint suggesting which of multiple valid identities for the authenticated user should be asserted. If such a hint does not correspond to any valid identity known to the proxy for that user, the proxy MUST not forward the user-provided P-Asserted-Identity header. In this case, the proxy can add an P-Asserted-Identity header of its own construction, or it can reject the request (for example, with a 403 Forbidden). -- 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 (June 6, 2002) is 7989 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) == Outdated reference: A later version (-01) exists of draft-ietf-sip-privacy-general-00 ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) == Outdated reference: A later version (-02) exists of draft-ietf-sipping-nai-reqs-01 == Outdated reference: A later version (-01) exists of draft-peterson-sip-identity-00 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG C. Jennings 3 Internet-Draft Cisco Systems 4 Expires: December 5, 2002 J. Peterson 5 NeuStar, Inc. 6 M. Watson 7 Nortel Networks 8 June 6, 2002 10 Private Extensions to the Session Initiation Protocol (SIP) for 11 Asserted Identity within Trusted Networks 12 draft-ietf-sip-asserted-identity-01 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 5, 2002. 37 Copyright Notice 39 Copyright (C) The Internet Society (2002). All Rights Reserved. 41 Abstract 43 This document describes private extensions to SIP that enable a 44 network of trusted SIP servers to assert the identity of 45 authenticated users , and the application of existing privacy 46 mechanisms to the identity problem. The use of these extensions is 47 only applicable inside an administrative domain with previously 48 agreed-upon policies for generation, transport and usage of such 49 information. This document does NOT offer a general privacy or 50 identity model suitable for use between different trust domains, or 51 use in the Internet at large. 53 Table of Contents 55 1. Applicability Statement . . . . . . . . . . . . . . . . . . 3 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Hints for Multiple Identities . . . . . . . . . . . . . . . 6 61 7. Requesting Privacy . . . . . . . . . . . . . . . . . . . . . 7 62 8. User Agent Server Behavior . . . . . . . . . . . . . . . . . 7 63 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 64 9.1 The P-Asserted-Identity Header . . . . . . . . . . . . . . . 8 65 9.2 The "id" Privacy Type . . . . . . . . . . . . . . . . . . . 9 66 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 10.1 Network Asserted Identity passed to trusted gateway . . . . 9 68 10.2 Network Asserted Identity Withheld . . . . . . . . . . . . . 11 69 11. Example of Spec(T) . . . . . . . . . . . . . . . . . . . . . 13 70 11.1 Protocol requirements . . . . . . . . . . . . . . . . . . . 13 71 11.2 Authentication requirements . . . . . . . . . . . . . . . . 13 72 11.3 Security requirements . . . . . . . . . . . . . . . . . . . 13 73 11.4 Scope of Trust Domain . . . . . . . . . . . . . . . . . . . 13 74 11.5 Implicit handling when no Privacy header is present . . . . 13 75 12. Security Considerations . . . . . . . . . . . . . . . . . . 14 76 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 77 13.1 Registration of "P-Asserted-Identity" SIP header field . . . 14 78 13.2 Registration of "id" privacy type for SIP Privacy header . . 14 79 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 80 Normative References . . . . . . . . . . . . . . . . . . . . 15 81 Informational References . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 83 Full Copyright Statement . . . . . . . . . . . . . . . . . . 17 85 1. Applicability Statement 87 This document describes private extensions to SIP [1] that enable a 88 network of trusted SIP servers to assert the identity of end users or 89 end systems, and to convey indications of end-user requested privacy. 90 The use of these extensions is only applicable inside a 'Trust 91 Domain' as defined in Short term requirements for Network Asserted 92 Identity [5]. Nodes in such a Trust Domain are explicitly trusted by 93 its users and end-systems to publicly assert the identity of each 94 party, and to be responsible for withholding that identity outside of 95 the Trust Domain when privacy is requested. The means by which the 96 network determines the identity to assert is outside the scope of 97 this document (though it commonly entails some form of 98 authentication). 100 A key requirement of [5] is that the behavior of all nodes within a 101 given Trust Domain 'T' is known to comply to a certain set of 102 specifications known as 'Spec(T)'. Spec(T) MUST specify behavior for 103 the following: 105 1. The manner in which users are authenticated 107 2. The mechanisms used to secure the communication among nodes 108 within the Trust Domain 110 3. The mechanisms used to secure the communication between UAs and 111 nodes within the Trust Domain 113 4. The manner used to determine which hosts are part of the Trust 114 Domain 116 5. The default privacy handling when no Privacy header field is 117 present 119 6. That nodes in the Trust Domain are compliant to SIP [1] 121 7. That nodes in the Trust Domain are compliant to this document 123 8. Privacy handling for identity as described in Section 7. 125 An example of a suitable Spec(T) is shown in Section 11. 127 This document does NOT offer a general privacy or identity model 128 suitable for inter-domain use or use in the Internet at large. Its 129 assumptions about the trust relationship between the user and the 130 network may not apply in many applications. For example, these 131 extensions do not accommodate a model whereby end users can 132 independently assert their identity by use of the extensions defined 133 here. Furthermore, since the asserted identities are not 134 cryptographically certified, they are subject to forgery, replay, and 135 falsification in any architecture that does not meet the requirements 136 of [5]. 138 The asserted identities also lack an indication of who specifically 139 is asserting the identity, and so it must be assumed that the Trust 140 Domain is asserting the identity. Therefore, the information is only 141 meaningful when securely received from a node known to be a member of 142 the Trust Domain. 144 Despite these limitations, there are sufficiently useful specialized 145 deployments that meet the assumptions described above, and can accept 146 the limitations that result, to warrant informational publication of 147 this mechanism. An example deployment would be a closed network 148 which emulates a traditional circuit switched telephone network. 150 2. Conventions 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC-2119 [3]. 156 Throughout this document requirements for or references to proxy 157 servers or proxy behavior apply similarly to other intermediaries 158 within a Trust Domain (ex: B2BUAs). 160 The terms Identity, Network Asserted Identity and Trust Domain in 161 this document have meanings as defined in [5]. 163 3. Introduction 165 Various providers offering a telephony service over IP networks have 166 selected SIP as a call establishment protocol. Their environments 167 require a way for trusted network elements operated by the service 168 providers (for example SIP proxy servers) to communicate the identity 169 of the subscribers to such a service, yet also need to withhold this 170 information from entities that are not trusted when necessary. Such 171 networks typically assume some level of transitive trust amongst 172 providers and the devices they operate. 174 These networks need to support certain traditional telephony services 175 and meet basic regulatory and public safety requirements. These 176 include Calling Identity Delivery services, Calling Identity Delivery 177 Blocking, and the ability to trace the originator of a call. While 178 baseline SIP can support each of these services independently, 179 certain combinations cannot be supported without the extensions 180 described in this document. For example, a caller that wants to 181 maintain privacy and consequently provides limited information in the 182 SIP From header field will not be identifiable by recipients of the 183 call unless they rely on some other means to discover the identity of 184 the caller. Masking identity information at the originating user 185 agent will prevent certain services, e.g., call trace, from working 186 in the Public Switched Telephone Network (PSTN) or being performed at 187 intermediaries not privy to the authenticated identity of the user. 189 This document attempts to provide a network asserted identity service 190 using a very limited, simple mechanism, based on requirements in [5]. 191 This work is derived from a previous attempt, [6], to solve several 192 problems related to privacy and identity in Trust Domains . A more 193 comprehensive mechanism, [7] which uses cryptography to address this 194 problem is the subject of current study by the SIP working group. 196 Providing privacy in a SIP network is more complicated than in the 197 PSTN. In SIP networks, the participants in a session typically are 198 normally able to exchange IP traffic directly without involving any 199 SIP service provider. The IP addresses used for these sessions may 200 themselves reveal private information. A general purpose mechanism 201 for providing privacy in a SIP environment is discussed in [2]. This 202 document applies that privacy mechanism to the problem of network 203 asserted identity. 205 4. Overview 207 The mechanism proposed in this document relies on a new header field 208 called 'P-Asserted-Identity' that contains a URI (commonly a SIP URI) 209 and an optional display-name, for example: 211 P-Asserted-Identity: "Cullen Jennings" 213 A proxy server which handles a message can, after authenticating the 214 originating user in some way (for example: Digest authentication), 215 insert such a P-Asserted-Identity header field into the message and 216 forward it to other trusted proxies. A proxy that is about to 217 forward a message to a proxy server or UA that it does not trust MUST 218 remove all the P-Asserted-Identity header field values if the user 219 requested that this information be kept private. Users can request 220 this type of privacy as described in Section 7. 222 The formal syntax for the P-Asserted-Identity header is presented in 223 Section 9. 225 5. Proxy Behavior 227 A proxy in a Trust Domain can receive a message from a node that it 228 trusts, or a node that it does not trust. When a proxy receives a 229 message from a node it does not trust and it wishes to add a P- 230 Asserted-Identity header field, the proxy MUST authenticate the 231 originator of the message, and use the identity which results from 232 this authentication to insert a P-Asserted-Identity header field into 233 the message. 235 If the proxy receives a message (request or response) from a node 236 that it trusts, it can use the information in the P-Asserted-Identity 237 header field, if any, as if it had authenticated the user itself. 239 If there is no P-Asserted-Identity header field present, a proxy MAY 240 add one containing at most one SIP or SIP URIs, and at most one tel 241 URL. If the proxy received the message from an element that it does 242 not trust and there is a P-Asserted-Identity header present which 243 contains a SIP or SIP URI, the proxy MUST replace that SIP or SIPS 244 URI with a single SIP or SIP URI or remove it. Similarly, if the 245 proxy received the message from an element that it does not trust and 246 there is a P-Asserted-Identity header present which contains a tel 247 URI, the proxy MUST replace that tel URI with a single tel URI or 248 remove it. 250 When a proxy forwards a message to another node, it must first 251 determine if it trusts that node or not. If it trusts the node, the 252 proxy does not remove any P-Asserted-Identity header fields that it 253 generated itself, or that it received from a trusted source. If it 254 does not trust the element, then the proxy MUST examine the Privacy 255 header field (if present) to determine if the user requested that 256 asserted identity information be kept private. 258 6. Hints for Multiple Identities 260 If an P-Asserted-Identity header is already present in the message 261 that a proxy receives from an entity that it does not trust, the 262 proxy MAY use this information as a hint suggesting which of multiple 263 valid identities for the authenticated user should be asserted. If 264 such a hint does not correspond to any valid identity known to the 265 proxy for that user, the proxy MUST not forward the user-provided P- 266 Asserted-Identity header. In this case, the proxy can add an P- 267 Asserted-Identity header of its own construction, or it can reject 268 the request (for example, with a 403 Forbidden). 270 A user agent only sends a hint to proxy server in a Trust Domain; 271 user agents MUST NOT populate the P-Asserted-Identity header in a 272 message that is not sent directly to a proxy that is trusted by the 273 user agent. Were a user agent to send a message containing a P- 274 Asserted-Identity header to a node outside a Trust Domain, then the 275 hinted identity might not be managed appropriately by the network, 276 which could have negative ramifications for privacy. 278 7. Requesting Privacy 280 Parties who wish to request the removal of P-Asserted-Identity header 281 fields before they are transmitted to an element that is not trusted 282 may add the "id" privacy token to the Privacy header field. The 283 Privacy header field is defined in [6]. If this token is present, 284 proxies MUST remove all the P-Asserted-Identity header fields before 285 forwarding messages to elements that are not trusted. If the Privacy 286 header field value is set to "none" then the proxy MUST NOT remove 287 the P-Asserted-Identity header fields. 289 When a proxy is forwarding the request to an element that is not 290 trusted and there is no Privacy header field, the proxy MAY include 291 the P-Asserted-Identity header field or it MAY remove it. This 292 decision is a policy matter of the Trust Domain and MUST be specified 293 in Spec(T). It is RECOMMENDED that unless local privacy policies 294 prevent it, the P-Asserted-Identity header fields SHOULD NOT be 295 removed, since removal may cause services based on Asserted Identity 296 to fail. 298 However, it should be noted that unless all users of the Trust Domain 299 have access to appropriate privacy services, forwarding of the P- 300 Asserted-Identity may result in disclosure of information which was 301 not requested by and could not be prevented by the user. It is 302 therefore STRONGLY RECOMMENDED that all users have access to privacy 303 services as described in this document. 305 Formal specification of the "id" Privacy header priv-value is 306 described in Section 9.2. Some general guidelines for when users 307 require privacy are given in [2]. 309 If multiple P-Asserted-Identity headers field values are present in a 310 message, and privacy of the P-Asserted-Identity header field is 311 requested, then all instances of the header field values MUST be 312 removed before forwarding the request to an entity that is not 313 trusted. 315 8. User Agent Server Behavior 317 Typically, a user agent renders the value of a P-Asserted-Identity 318 header field that it receives to its user. It may consider the 319 identity provided by a Trust Domain to be privileged, or 320 intrinsically more trustworthy than the From header field of a 321 request. However, any specific behavior is specific to 322 implementations or services. This document also does not mandate any 323 user agent handling for multiple P-Asserted-Identity header field 324 values that happen to appear in a message (such as a SIP URI 325 alongside a tel URL). 327 However, if a User Agent Server receives a message from a previous 328 element that it does not trust, it MUST NOT use the P-Asserted- 329 Identity header field in any way. 331 If a UA is part of the Trust Domain from which it received a message 332 containing a P-Asserted-Identity header field, then it can use the 333 value freely but it MUST ensure that it does not forward the 334 information to any element that is not part of the Trust Domain. 336 If a UA is not part of the Trust Domain from which it received a 337 message containing a P-Asserted-Identity header field, then it can 338 assume this information does not need to be kept private. 340 9. Formal Syntax 342 The following syntax specification uses the augmented Backus-Naur 343 Form (BNF) as described in RFC-2234 [4]. 345 9.1 The P-Asserted-Identity Header 347 The P-Asserted-Identity header field is used among trusted SIP 348 entities (typically intermediaries) to carry the identity of the user 349 sending a SIP message as it was verified by authentication. 351 PAssertedID = "P-Asserted-Identity" HCOLON *(COMMA PAssertedID-value) 352 PAssertedID-value = name-addr / addr-spec 354 A P-Asserted-Identity header field value MUST consist of exactly one 355 name-addr or addr-spec. There may be one or two P-Asserted-Identity 356 values. If there is one value, it MUST be a sip, sips, or tel URI. 357 If there are two values, one value MUST be a sip or sips URI and the 358 other MUST be a tel URI. It is worth noting that proxies can (and 359 will) add and remove this header field. 361 This document adds the following entry to Table 2 of [1]: 363 Header field where proxy ACK BYE CAN INV OPT REG 364 ------------ ----- ----- --- --- --- --- --- --- 365 P-Asserted-Identity adr - o - o o - 367 SUB NOT REF INF UPD PRA 368 --- --- --- --- --- --- 369 o o o - - - 371 9.2 The "id" Privacy Type 373 This specification adds a new privacy type ("priv-value") to the 374 Privacy header, defined in [2]. The presence of this privacy type in 375 a Privacy header field indicates that the user would like the Network 376 Asserted Identity to be kept private with respect to SIP entities 377 outside the Trust Domain with which the user authenticated. Note 378 that a user requesting multiple types of privacy MUST include all of 379 the requested privacy types in its Privacy header field value. 381 priv-value = "id" 383 Example: 385 Privacy: id 387 10. Examples 389 10.1 Network Asserted Identity passed to trusted gateway 391 In this example, proxy.cisco.com creates a P-Asserted-Identity header 392 field from an identity it discovered from SIP Digest authentication. 393 It forwards this information to a trusted proxy which forwards it to 394 a trusted gateway. Note that these examples consist of partial SIP 395 messages that illustrate only those headers relevant to the 396 authenticated identity problem. 398 * F1 useragent.cisco.com -> proxy.cisco.com 400 INVITE sip:+14085551212@cisco.com SIP/2.0 401 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123 402 To: 403 From: "Anonymous" ;tag=9802748 404 Call-ID: 245780247857024504 405 CSeq: 1 INVITE 406 Max-Forwards: 70 407 Privacy: id 409 * F2 proxy.cisco.com -> useragent.cisco.com 411 SIP/2.0 407 Proxy Authorization 412 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123 413 To: ;tag=123456 414 From: "Anonymous" ;tag=9802748 415 Call-ID: 245780247857024504 416 CSeq: 1 INVITE 417 Proxy-Authenticate: .... realm="sip.cisco.com" 419 * F3 useragent.cisco.com -> proxy.cisco.com 421 INVITE sip:+14085551212@cisco.com SIP/2.0 422 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124 423 To: 424 From: "Anonymous" ;tag=9802748 425 Call-ID: 245780247857024504 426 CSeq: 2 INVITE 427 Max-Forwards: 70 428 Privacy: id 429 Proxy-Authorization: .... realm="sip.cisco.com" user="fluffy" 431 * F4 proxy.cisco.com -> proxy.pstn.net (trusted) 433 INVITE sip:+14085551212@proxy.pstn.net SIP/2.0 434 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124 435 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc 436 To: 437 From: "Anonymous" ;tag=9802748 438 Call-ID: 245780247857024504 439 CSeq: 2 INVITE 440 Max-Forwards: 69 441 P-Asserted-Identity: "Cullen Jennings" 442 P-Asserted-Identity: tel:+14085264000 443 Privacy: id 445 * F5 proxy.pstn.net -> gw.pstn.net (trusted) 447 INVITE sip:+14085551212@gw.pstn.net SIP/2.0 448 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124 449 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc 450 Via: SIP/2.0/TCP proxy.pstn.net;branch=z9hG4bK-a1b2 451 To: 452 From: "Anonymous" ;tag=9802748 453 Call-ID: 245780247857024504 454 CSeq: 2 INVITE 455 Max-Forwards: 68 456 P-Asserted-Identity: "Cullen Jennings" 457 P-Asserted-Identity: tel:+14085264000 458 Privacy: id 460 10.2 Network Asserted Identity Withheld 462 In this example, the User Agent sends an INVITE to the first proxy, 463 which authenticates this with SIP Digest. The first proxy creates a 464 P-Asserted-Identity header field and forwards it to a trusted proxy 465 (outbound.cisco.com). The next proxy removes the P-Asserted-Identity 466 header field, and the request for Privacy before forwarding this 467 request onward to the biloxi.com proxy server which it does not 468 trust. 470 * F1 useragent.cisco.com -> proxy.cisco.com 472 INVITE sip:bob@biloxi.com SIP/2.0 473 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111 474 To: 475 From: "Anonymous" ;tag=9802748 476 Call-ID: 245780247857024504 477 CSeq: 1 INVITE 478 Max-Forwards: 70 479 Privacy: id 481 * F2 proxy.cisco.com -> useragent.cisco.com 482 SIP/2.0 407 Proxy Authorization 483 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111 484 To: ;tag=123456 485 From: "Anonymous" ;tag=9802748 486 Call-ID: 245780247857024504 487 CSeq: 1 INVITE 488 Proxy-Authenticate: .... realm="cisco.com" 490 * F3 useragent.cisco.com -> proxy.cisco.com 492 INVITE sip:bob@biloxi.com SIP/2.0 493 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123 494 To: 495 From: "Anonymous" ;tag=9802748 496 Call-ID: 245780247857024504 497 CSeq: 2 INVITE 498 Max-Forwards: 70 499 Privacy: id 500 Proxy-Authorization: .... realm="cisco.com" user="fluffy" 502 * F4 proxy.cisco.com -> outbound.cisco.com (trusted) 504 INVITE sip:bob@biloxi SIP/2.0 505 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123 506 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234 507 To: 508 From: "Anonymous" ;tag=9802748 509 Call-ID: 245780247857024504 510 CSeq: 2 INVITE 511 Max-Forwards: 69 512 P-Asserted-Identity: "Cullen Jennings" 513 Privacy: id 515 * F5 outbound.cisco.com -> proxy.biloxi.com (not trusted) 517 INVITE sip:bob@biloxi SIP/2.0 518 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123 519 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234 520 Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345 521 To: 522 From: "Anonymous" ;tag=9802748 523 Call-ID: 245780247857024504 524 CSeq: 2 INVITE 525 Max-Forwards: 68 526 Privacy: id 528 * F6 proxy.biloxi.com -> bobster.biloxi.com 530 INVITE sip:bob@bobster.biloxi.com SIP/2.0 531 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123 532 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234 533 Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345 534 Via: SIP/2.0/TCP proxy.biloxi.com;branch=z9hG4bK-d456 535 To: 536 From: "Anonymous" ;tag=9802748 537 Call-ID: 245780247857024504 538 CSeq: 2 INVITE 539 Max-Forwards: 67 540 Privacy: id 542 11. Example of Spec(T) 544 The integrity of the mechanism described in this document relies on 545 one node knowing (through configuration) that all of the nodes in a 546 Trust Domain will behave in a predetermined way. This requires the 547 predetermined behavior to be clearly defined and for all nodes in the 548 Trust Domain to be compliant. The specification set that all nodes 549 in a Trust Domain T must comply with is termed 'Spec(T)'. 551 The remainder of this section presents an example Spec(T), which is 552 not normative in any way. 554 11.1 Protocol requirements 556 The following specifications MUST be supported: 558 1. SIP [1] 560 2. This document. 562 11.2 Authentication requirements 564 Users MUST be authenticated using SIP Digest Authentication. 566 11.3 Security requirements 568 Connections between nodes within the Trust Domain and between UAs and 569 nodes in the Trust Domain MUST use TLS using a cipher suite of 570 RSA_WITH_AES_128_CBC_SHA1. Mutual authentication between nodes in 571 the trust domain MUST be performed and confidentiality MUST be 572 negotiated. 574 11.4 Scope of Trust Domain 576 The Trust Domain specified in this agreement consists of hosts which 577 posses a valid certificate which is a) signed by examplerootca.org; 578 b) whose subjectAltName ends with one of the following domain names: 579 trusted.div1.carrier-a.net, trusted.div2.carrier-a.net, sip.carrier- 580 b.com; and c) whose domain name corresponds to the hostname in the 581 subjectAltName in the certificate. 583 11.5 Implicit handling when no Privacy header is present 585 The elements in the trust domain must support the 'id' privacy 586 service therefore absence of a Privacy header can be assumed to 587 indicate that the user is not requesting any privacy. If no Privacy 588 header field is present in a request, elements in this Trust Domain 589 MUST act as if no privacy is requested. 591 12. Security Considerations 593 The mechanism provided in this document is a partial consideration of 594 the problem of identity and privacy in SIP. For example, these 595 mechanisms provide no means by which end users can securely share 596 identity information end-to-end without a trusted service provider. 597 Identity information which the user designates as 'private' can be 598 inspected by any intermediaries participating in the Trust Domain. 599 This information is secured by transitive trust, which is only as 600 reliable as the weakest link in the chain of trust. 602 When a trusted entity sends a message to any destination with that 603 party's identity in a P-Asserted-Identity header field, the entity 604 MUST take precautions to protect the identity information from 605 eavesdropping and interception to protect the confidentiality and 606 integrity of that identity information. The use of transport or 607 network layer hop-by-hop security mechanisms, such as TLS or IPSec 608 with appropriate cipher suites, can satisfy this requirement. 610 13. IANA Considerations 612 13.1 Registration of "P-Asserted-Identity" SIP header field 614 This document defines a new private SIP header field, "P-Asserted- 615 Identity". As recommended by the policy of the Transport Area, this 616 header should be registered by the IANA in the SIP header registry, 617 using the RFC number of this document as its reference. 619 Name of Header: P-Asserted-Identity 621 Short form: none 623 Registrant: Cullen Jennings 624 fluffy@cisco.com 626 Normative description: 627 Section 9.1 of this document 629 13.2 Registration of "id" privacy type for SIP Privacy header 631 Name of privacy type: id 633 Short Description: Privacy requested for Third-Party Asserted Identity 635 Registrant: Cullen Jennings 636 fluffy@cisco.com 638 Normative description: 639 Section 9.2 of this document 641 14. Acknowledgements 643 Thanks to Bill Marshall and Flemming Andreason[6], Mark Watson[5], 644 and Jon Peterson[7] for authoring drafts which represent the bulk of 645 the text making up this document. Thanks to many people for useful 646 comments including Jonathan Rosenberg, Rohan Mahy and Paul Kyzivat. 648 Normative References 650 [1] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation 651 Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), 652 February 2002. 654 [2] Peterson, J., "A Privacy Mechanism for the Session Initiation 655 Protocol (SIP)", draft-ietf-sip-privacy-general-00 (work in 656 progress), May 2002. 658 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 659 Levels", BCP 14, RFC 2119, March 1997. 661 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 662 Specifications: ABNF", RFC 2234, November 1997. 664 Informational References 666 [5] Watson, M., "Short term requirements for Network Asserted 667 Identity", draft-ietf-sipping-nai-reqs-01 (work in progress), 668 May 2002. 670 [6] Andreasen, F., "SIP Extensions for Network-Asserted Caller 671 Identity and Privacy within Trusted Networks", draft-ietf-sip- 672 privacy-04 (work in progress), March 2002. 674 [7] Peterson, J., "Enhancements for Authenticated Identity 675 Management in the Session Initiation Protocol (SIP)", draft- 676 peterson-sip-identity-00 (work in progress), April 2002. 678 Authors' Addresses 680 Cullen Jennings 681 Cisco Systems 682 170 West Tasman Drive 683 MS: SJC-21/3 684 San Jose, CA 95134 685 USA 687 Phone: +1 408 527-9132 688 EMail: fluffy@cisco.com 690 Jon Peterson 691 NeuStar, Inc. 692 1800 Sutter Street, Suite 570 693 Concord, CA 94520 694 USA 696 Phone: +1 925/363-8720 697 EMail: Jon.Peterson@NeuStar.biz 699 Mark Watson 700 Nortel Networks 701 Maidenhead Office Park (Bray House) 702 Westacott Way 703 Maidenhead, Berkshire 704 England 706 Phone: +44 (0)1628-434456 707 EMail: mwatson@nortelnetworks.com 709 Full Copyright Statement 711 Copyright (C) The Internet Society (2002). All Rights Reserved. 713 This document and translations of it may be copied and furnished to 714 others, and derivative works that comment on or otherwise explain it 715 or assist in its implementation may be prepared, copied, published 716 and distributed, in whole or in part, without restriction of any 717 kind, provided that the above copyright notice and this paragraph are 718 included on all such copies and derivative works. However, this 719 document itself may not be modified in any way, such as by removing 720 the copyright notice or references to the Internet Society or other 721 Internet organizations, except as needed for the purpose of 722 developing Internet standards in which case the procedures for 723 copyrights defined in the Internet Standards process must be 724 followed, or as required to translate it into languages other than 725 English. 727 The limited permissions granted above are perpetual and will not be 728 revoked by the Internet Society or its successors or assigns. 730 This document and the information contained herein is provided on an 731 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 732 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 733 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 734 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 735 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 737 Acknowledgement 739 Funding for the RFC Editor function is currently provided by the 740 Internet Society.