idnits 2.17.1 draft-elwell-sip-e2e-identity-important-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 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 25, 2009) is 5538 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-07) exists of draft-ietf-sip-dtls-srtp-framework-05 == Outdated reference: A later version (-09) exists of draft-ietf-sipping-sbc-funcs-08 == Outdated reference: A later version (-15) exists of draft-ietf-sip-certs-07 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG J. Elwell 3 Internet-Draft Siemens Enterprise Communications 4 Intended status: Informational February 25, 2009 5 Expires: August 29, 2009 7 End-to-End Identity Important in the Session Initiation Protocol (SIP) 8 draft-elwell-sip-e2e-identity-important-03.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 29, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document surveys existing mechanisms in the Session Initiation 47 Protocol (SIP) for identifying and authenticating the source of a SIP 48 request (or caller identification). It describes how identification 49 and authentication are not always end-to-end and the problems that 50 this can lead to, particularly since media security based on 51 techniques such as DTLS-SRTP is dependent on end-to-end authenticated 52 identification of parties. 54 This work is being discussed on the sip@ietf.org mailing list. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Overview of existing mechanisms and their shortcomings . . . . 6 61 3.1. The From header field URI . . . . . . . . . . . . . . . . 6 62 3.2. The P-Asserted-Identity (PAI) header field . . . . . . . . 6 63 3.3. Authenticated Identity Body (AIB) . . . . . . . . . . . . 7 64 3.4. SIP Certs . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.5. SIP Identity . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.6. Return routability checks . . . . . . . . . . . . . . . . 9 67 3.7. Problems with SIP URIs based on E.164 numbers . . . . . . 9 68 3.8. Other causes of URI change at intermediate domains . . . . 10 69 3.9. Problems with PSTN interworking . . . . . . . . . . . . . 10 70 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 13 74 4.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 14 76 4.6. Example 6 . . . . . . . . . . . . . . . . . . . . . . . . 14 77 4.7. Example 7 . . . . . . . . . . . . . . . . . . . . . . . . 14 78 4.8. Example 8 . . . . . . . . . . . . . . . . . . . . . . . . 15 79 4.9. Example 9 . . . . . . . . . . . . . . . . . . . . . . . . 15 80 4.10. Example 10 . . . . . . . . . . . . . . . . . . . . . . . . 16 81 4.11. Example 11 . . . . . . . . . . . . . . . . . . . . . . . . 16 82 4.12. Example 12 . . . . . . . . . . . . . . . . . . . . . . . . 16 83 5. Why end-to-end identification is important . . . . . . . . . . 17 84 6. Why end-to-end authenticated identification is important . . . 19 85 7. Why B2BUAs break SIP Identity signatures . . . . . . . . . . . 20 86 7.1. Changing the SDP body part . . . . . . . . . . . . . . . . 20 87 7.2. Changing the Contact and Call-Id header fields . . . . . . 21 88 7.3. Changing the From URI . . . . . . . . . . . . . . . . . . 21 89 7.4. Changing the To URI . . . . . . . . . . . . . . . . . . . 22 90 7.5. Protocol repair . . . . . . . . . . . . . . . . . . . . . 22 91 8. Analysis of changes to SIP requests by B2BUAs . . . . . . . . 23 92 8.1. addr-spec of From header field . . . . . . . . . . . . . . 23 93 8.2. addr-spec of To header field . . . . . . . . . . . . . . . 24 94 8.3. call-id of Call-Id header field and digit of CSeq 95 header field . . . . . . . . . . . . . . . . . . . . . . . 24 97 8.4. method of CSeq header field . . . . . . . . . . . . . . . 25 98 8.5. Date header field . . . . . . . . . . . . . . . . . . . . 25 99 8.6. addr-spec of Contact header field . . . . . . . . . . . . 25 100 8.7. SDP body part . . . . . . . . . . . . . . . . . . . . . . 25 101 8.8. Other body parts . . . . . . . . . . . . . . . . . . . . . 26 102 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26 103 10. Requirements for end-to-end authenticated identification . . . 27 104 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28 105 12. Security considerations . . . . . . . . . . . . . . . . . . . 29 106 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 107 14. Informative References . . . . . . . . . . . . . . . . . . . . 29 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 1. Introduction 112 The Session Initiation Protocol (SIP) [RFC3261] provides two basic 113 mechanisms for identifying users involved in a session or call: the 114 From header field URI [RFC3261] and the P-Asserted-Identity header 115 field [RFC3325]. Used alone, these are vulnerable to misuse, but two 116 mechanisms exist for providing authentication of the From header 117 field URI: Authenticated Identity Body [RFC3893] and the Identity 118 and Identity-Info header fields (SIP Identity, [RFC4474]). These 119 various mechanisms provide to the recipient of a SIP request (the 120 User Agent Server, UAS, and its user) identification (with or without 121 authentication) of the source of a SIP request (the User Agent 122 Client, UAC). The identifier given as the source of a request is 123 generally assigned to a user. However, a UAC will have been given 124 the necessary credentials to use this identifier on behalf of a user, 125 so the use of such an identifier to indicate the source of a request 126 strictly speaking means that the request has come from a UAC with the 127 credentials of the user. Implicitly it means the request has come 128 from the user, assuming that the user concerned really is the user of 129 the UAC. This depends on the UAC's user interface (e.g., whether it 130 requires the user to enter a PIN to unlock the user's credentials) 131 and also on human behaviour (e.g., whether the user refuses to allow 132 his/her unlocked device to be used by somebody else). 134 Further, by binding an end of a secure bidirectional medium using 135 SRTP [RFC3711] to a SIP request whose source has been identified, the 136 recipient of that SIP request can know the identity of the user who 137 is the source and sink of that medium. This is the principle behind 138 DTLS-SRTP [I-D.ietf-sip-dtls-srtp-framework], which uses certificates 139 in the endpoints to agree a security context for SRTP. DTLS-SRTP 140 also exchanges fingerprints of those certificates in SIP messages, 141 thereby binding the media to those SIP messages. If a SIP message 142 carrying such a certificate fingerprint also includes the 143 authenticated identification of the user on behalf of which the SIP 144 message has been sent, the secure media are bound to that user. 145 DTLS-SRTP currently relies on the From header field URI and SIP 146 Identity to achieve this. 148 This is the theory, but there are a number of practical 149 considerations that make this very difficult to deploy in many 150 situations, particularly when there are intermediaries that change 151 identification information or break signatures. This has led to a 152 number of proposed work-arounds, but has also has led to a 153 questioning of the need for end-to-end authenticated identification. 154 This document explains why end-to-end authenticated identification is 155 important. 157 Although the primary function of SIP is to initiate sessions (Session 158 Initiation Protocol), it also includes some methods for use outside 159 the context of a session, e.g., MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH. 160 Although the main focus of this document is on identifying users 161 involved in sessions, many of the considerations apply equally to 162 other uses of SIP. 164 2. Terminology 166 This document uses the following terms: 168 end-to-end In the context of a SIP request, operating from the 169 domain of the UAC to the domain of the UAS. 171 end-to-end identification The delivery of an identifier representing 172 the source of a request unchanged from the domain of the UAC to 173 the domain of the UAS. 175 end-to-end authenticated identification The delivery of an 176 identifier representing the source of a request together with 177 evidence of authenticity unchanged from the domain of the UAC to 178 the domain of the UAS. 180 End-to-end identification or end-to-end authenticated identification 181 can originate at the UAC and terminate at the UAS, in which case it 182 is truly end-to-end. However, for the use cases considered in this 183 document, it is generally sufficient that end-to-end identification 184 or end-to-end authenticated identification originate within the 185 domain of the UAC. For example, a proxy or B2BUA in that domain can 186 insert the correct identifier, based on digest authentication of the 187 UAC, and (in the case of authenticated identification) can provide 188 evidence of authenticity. On the receiving side, it might be 189 sufficient for the domain of the UAS to verify the evidence of 190 authenticity and communicate that somehow to the UAS. In such cases, 191 the term end-to-end is, strictly speaking, shorthand for end-domain- 192 to-end-domain. With end-to-end identification or end-to-end 193 authenticated identification, the important thing is that 194 intermediate domains play no part in providing the identifier or 195 evidence of authenticity. 197 In contrast to end-to-end identification or end-to-end authenticated 198 authentication, hop-by-hop identification or hop-by-hop authenticated 199 identification involves an intermediate domain modifying the 200 identifier or providing evidence of authenticity, leading to the need 201 for transitive trust. 203 It should also be noted that end-to-end identification or 204 authenticated identification operates only within the SIP 205 environment. Where PSTN interworking is involved, the end domain is 206 the domain of the SIP-PSTN gateway. True end-to-end operation 207 depends on the PSTN, is outside the scope of this document, and in 208 practice is probably unachievable. 210 3. Overview of existing mechanisms and their shortcomings 212 3.1. The From header field URI 214 Although a UAC should place its Address of Record (AoR) in the From 215 header field of a SIP request, it is a well known fact that in 216 practice a UAC is free to place any value there. SIP proxies are not 217 allowed to change the value, but a SIP proxy could demand that the 218 UAC authenticate itself (using SIP digest authentication) and reject 219 a request if the From URI does not match the authenticated user. A 220 B2BUA could also do this, or could rectify the From URI and forward 221 the request, as an alternative to rejecting the request. 223 However, a user is likely to have a SIP digest authentication shared 224 secret only with a SIP entity (proxy or B2BUA) in the same domain, 225 and any downstream SIP entities (in other domains) will not be in a 226 position to challenge for digest authentication. Those SIP entities 227 will have no means of knowing whether the request has been validated 228 by an entity in the source user's domain, and therefore no means of 229 trusting the From URI. 231 3.2. The P-Asserted-Identity (PAI) header field 233 This was introduced to counter some of the problems with the From 234 URI. A SIP entity that has validated the source of a SIP request can 235 include a PAI header field containing the validated URI, which may 236 differ from the From URI. A downstream entity in the same trust 237 domain will place some trust in this value. Entities within the same 238 trust domain must exchange SIP messages over a secure transport 239 (e.g., TLS), so that the upstream entity is authenticated. That 240 upstream entity is then trusted to provide a correct identifier in 241 the PAI header field. In the context of a session or call, PAI in 242 the INVITE request can assert the identifier of the calling user and 243 PAI in a request in the reverse direction can assert the identifier 244 of the connected user. 246 This mechanism was introduced for use in closed environments where a 247 trust domain could be established, rather than for use on the 248 Internet. However, it has seen very considerable deployment. 250 The problem lies in its notion of transitive trust, i.e., A asserts 251 an identifier and sends it over a secure transport to B. B trusts the 252 assertion, and passes the assertion on over a secure transport to C. 253 C trusts B, and passes the assertion on over a secure transport to D, 254 and so on. D trusts C, and has to rely on C's trust of any upstream 255 entities (in this case B). C has to rely on B's trust of any 256 upstream entities (in this case A). The problem is, a downstream 257 entity does not know the entire upstream path of trust, so in 258 trusting its neighbour it does not know who else it is being forced 259 to trust. As SIP continues to grow, eventually a bad actor or 260 malicious site will be trusted by another party many hops away. 262 Furthermore, when an entity receives a request from outside its trust 263 domain it can place a default value in the PAI header field when 264 forwarding the request. For example, when a service provider 265 receives a request from an enterprise, if it does not trust the PAI 266 received from the enterprise it is common practice to insert the 267 default number for the enterprise, e.g., that of an attendant or 268 reception desk. This can be misleading, particularly if the request 269 originated outside the enterprise and has been forwarded by the 270 enterprise to the service provider. Arguably it also violates 271 [RFC3325], since the default number is being placed into PAI without 272 having authenticated that number as the source of the SIP request. 273 This practice can also cause the PAI URI to deviate from the From URI 274 (typically they are the same in many simple situations), causing a 275 dilemma for the UAS - which one to present to the user (or a dilemma 276 for the user if both are presented). 278 3.3. Authenticated Identity Body (AIB) 280 With AIB [RFC3893], the UAC copies the From URI and some other header 281 fields into a body of the SIP request and signs it using S/MIME 282 [RFC3851]. The ability to include S/MIME in [RFC3261] (and likewise 283 PGP [RFC2015] in the original version of SIP [RFC2543]) demonstrates 284 that end-to-end security has always been considered important in SIP, 285 and AIB binds the From URI to the end-to-end authentication that 286 S/MIME provides. In the context of a session or call, AIB in the 287 INVITE request can provide authenticated identification of the 288 calling user and AIB in the 200 response or in a request in the 289 reverse direction can provide authenticated identification of the 290 connected user. 292 AIB has not been deployed because S/MIME has not been deployed, and 293 that in turn can probably be blamed on the need for each SIP UA to 294 have its own certificate and private key and the infrastructure 295 needed to manage that. However, the mechanism is in theory capable 296 of true end-to-end authenticated identification. 298 3.4. SIP Certs 300 A partial solution to the certificate problem associated with S/MIME 301 and hence AIB is available in [I-D.ietf-sip-certs]. This allows a 302 SIP UA to retrieve its user's certificate from a certificate store. 303 However, a certificate per user is still required, and this appears 304 to be a barrier. 306 3.5. SIP Identity 308 SIP Identity addresses the impracticalities of AIB by having a SIP 309 entity that has validated the source of a SIP request (e.g., using 310 SIP digest authentication) place a signature over the From header 311 field URI and other parts of the message to assert the correctness of 312 the From URI and provide integrity protection over the signed parts. 313 The signature is placed in the Identity header field and information 314 needed for validating the signature is placed in the Identity-Info 315 header field. This provides authenticated identification between the 316 source domain and the UAS, or between the source domain and a 317 verifying entity in the destination domain. Therefore it can be 318 considered to provide end-domain-to-end-domain authentication. In 319 the context of a session or call, SIP Identity in the INVITE request 320 can provide authenticated identification of the calling user and SIP 321 Identity in the reverse direction [RFC4916] can provide authenticated 322 identification of the connected user. DTLS-SRTP relies on SIP 323 Identity to bind SRTP media to a calling or connected user. 325 However, SIP Identity has seen little (if any) deployment, and that 326 is partly due to lack of a perceived need (many regard PAI as 327 sufficient) and partly because it has been shown not to work in many 328 common situations. Concerning the need for SIP Identity (or a 329 similar mechanism), sections 4, 5 and 6 show why end-to-end (or end- 330 domain-to-end-domain) authenticated identification is important, and 331 therefore why PAI is insufficient. 333 The reason SIP Identity does not work in common situations is that 334 B2BUAs, and in particular Session Border Controllers (SBCs), have 335 reasons to change some parts of the signed information when 336 forwarding a SIP request, thus breaking the signature. The broken 337 signature can either be forwarded as is (which has no value), can be 338 removed, or can be replaced with a new signature. This last option, 339 if carried out by an intermediate domain, means that authenticated 340 identification is no longer end-domain-to-end-domain. Moreover, an 341 entity can generate a new signature only if the domain part of the 342 From URI matches the domain's certificate, and hence the From URI 343 will need to change to match the new signing domain (an action that 344 in principle is feasible with E.164-based SIP URIs), so the 345 identifier is now no longer end-to-end. The breaking of signatures 346 by intermediaries is discussed further in Section 7. 348 3.6. Return routability checks 350 In the absence of a means for delivering authenticated identification 351 to a UAS, the UAS (or its domain proxy or B2BUA) can gain some 352 measure of confidence in the delivered identifier by attempting to 353 send a return request, using the received identifier as target. The 354 result of the return request should provide some evidence that the 355 source of the original request (the UAS or its domain) has been 356 reached. This assumes that intermediate domains are not malicious, 357 and will route correctly even though they are unable to cooperate in 358 the provision of end-to-end authenticated identification. 360 One proposal for a return routability check is in 361 [I-D.kuthan-sip-derive]. In that proposal, the return request is a 362 SUBSCRIBE request for the dialog event package with a filter for 363 information about the dialog that the original request is attempting 364 to establish. Evidence that the source of the request has been 365 reached is achieved if the SUBSCRIBE request is successful and if a 366 NOTIFY request identifying that same dialog is received, the 367 assumption being that any other recipient of the SUBSCRIBE request 368 would know nothing about that dialog. This particular proposal has 369 some limitations. For example, it requires the UAC to support 370 filtering, it will not work through B2BUAs that change dialog 371 identifiers and it does not apply to requests that do not involve 372 dialogs. However, the principle of return routability checking may 373 yield a solution that gives a better-than-nothing assertion of the 374 correctness of an identifier. 376 3.7. Problems with SIP URIs based on E.164 numbers 378 If a user receives a caller or connected identifier in the form of a 379 SIP URI containing a global E.164 number (e.g., 380 sip:+123456789@example.com;user=phone), and if this information is 381 made available to the user, how would the user interpret it? The 382 user might recognise the telephone number and ignore the domain part. 383 The user might treat the domain part as significant and disregard the 384 number (particularly if she fails to recognise the number). Or the 385 user might take account of both items of information. 387 Problems arise when the user attaches importance to the domain part, 388 because there is no defined meaning for the domain part (other than 389 that by routing a request to that URI to that domain, that domain 390 should be able to route it onwards towards the user of the telephone 391 number). In practice, the domain part is often changed by 392 intermediate domains (typically to reflect their own domain), so a 393 request starting out with sip:+123456789@mybank.com;user=phone in the 394 From or PAI header field could end up with 395 sip:+123456789@serviceprovider.net;user=phone in that header field 396 when delivered to the UAS, where serviceprovider.net is the last 397 domain it passed through. The recipient would not see that the 398 request really originated in mybank.com, and this information may 399 have been important to the recipient. 401 Moreover, any such change of From URI breaks the SIP Identity 402 signature, as described earlier. 404 Clearly these problems do not exist with tel URIs [RFC3966] since 405 there is no domain part and therefore no scope for change. Therefore 406 they have the advantage of not providing a false or misleading domain 407 part, but the disadvantage of not providing a domain part at all for 408 users who would benefit from this information. Also tel URIs cannot 409 be used with SIP Identity. 411 The E.164 problem is described in more detail in 412 [I-D.elwell-sip-e164-problem-statement]. 414 3.8. Other causes of URI change at intermediate domains 416 As described in Section 3.7, intermediate domains can change a URI 417 based on an E.164 number, such that the recipient does not receive 418 the original identifier. This is not the sole circumstance in which 419 intermediate domains are known to change an identifier identifying 420 the source of a SIP request. Another circumstance is where a domain 421 does not accept a received identifier as a valid source and 422 substitutes a default value. This often occurs when an enterprise 423 submits an identifier to a service provider, the identifier not being 424 within the range recognised by the service provider as belonging to 425 that enterprise. There are legitimate reasons why an enterprise 426 might submit an identifier outside the recognised range, as 427 highlighted by some of the examples in Section 4. When delivered to 428 the UAS, the new identifier might be misleading. 430 3.9. Problems with PSTN interworking 432 A PSTN gateway will generally deliver a number received from PSTN as 433 the From or PAI URI. The gateway has no means of validating that 434 number and has either to trust the PSTN or disregard the number 435 (placing its own identifier or an anonymous value in the From URI). 436 There are known means of a false caller number in PSTN (depending on 437 country), and therefore trusting a number from PSTN can be dangerous. 439 Furthermore, from a DTLS-SRTP perspective, it can be dangerous to 440 assume that media are secured all the way to a PSTN user. First, the 441 PSTN has known vulnerabilities in terms of interception of calls for 442 legal or other reasons. Second, there is no way of detecting whether 443 the PSTN user is attached to the PSTN via an unsecured IP network. 444 Therefore, at best, a call can be considered secure only as far as 445 the gateway and true end-to-end (or end-domain-to-end-domain) 446 security is not achievable. Solutions are required to the problem of 447 misleading the user concerning the end-to-end security status of a 448 call to/from PSTN, but this issue is not discussed further in this 449 document. 451 4. Examples 453 In Section 3.7 and Section 3.8 it was shown how the identifier 454 representing the source of SIP request can be modified by SIP 455 intermediaries before being delivered to the UAS. Furthermore, 456 Section 3.5 mentioned how an intermediate domain could change the 457 From URI in order to "fix" a broken RFC 4474 signature. In these 458 cases, identification delivery is not end-to-end and often fails to 459 deliver information needed by the recipient. In this section a 460 number of example use cases are given, only some of which deliver 461 end-to-end identification. 463 Where a SIP intermediary modifies the From URI, it can do so in 464 several ways: 466 o conversion, whereby a SIP intermediary substitutes an identifier 467 that does not identify the original source of the SIP request 468 (e.g., substituting a default identifier for the enterprise 469 concerned); 471 o translation, whereby a SIP intermediary substitutes a form of 472 identifier that still identifies the original source of the SIP 473 request (e.g., by adding prefix digits or a phone-context 474 parameter to make it globally unique, or by changing the domain 475 part of an E.164-based SIP URI); 477 o normalisation (e.g., removing whitespace, adding "+", converting 478 from dial string by removing prefix digits such as "0"). 480 Of these, conversion is the most problematic, because it results in 481 an identifier that no longer identifies the originator of the 482 request. This means that it will probably prevent a return SIP 483 request (e.g., a return call) reaching the user who originated the 484 original request. 486 Translation might cause difficulties for the user recognizing the 487 source of the request or for the UAS trying to match entries in a 488 phone book or white list. It might also cause return routability to 489 fail if the result is not globally unique. 491 Normalisation might actually help recognition and matching. Note 492 that the addition of removal or "user=phone" in practice might be 493 considered normalisation, although in theory two URIs differing only 494 in the presence or absence of user=phone identify different entities. 496 All three forms of modification break any SIP Identity signature, so 497 even if they do not prevent end-to-end identification, they prevent 498 end-to-end authenticated identification (see Section 6. 500 In the figures associated with the examples below, caller 501 identification is shown in the From header field URI, but a similar 502 problem can arise with PAI. 504 The examples are all to do with caller identification (where the 505 called user wants to know who is calling), but corresponding examples 506 can be derived for connected identification (where the caller wants 507 some assurance that the correct called party has been reached). 509 4.1. Example 1 511 Consider a call from an employee Bob at bank.com to Alice, who 512 obtains a SIP service from service provider sp.net. Alice would be 513 prepared to accept a call from her bank. Bob's identifier is 514 sip:bob@bank.com. In this case, hopefully Alice would receive this 515 identifier unchanged. She might not know Bob, but at least she knows 516 the call is from her bank and can accept the call on that basis. 518 bank.com sp.net Alice 519 From:sip:bob@bank.com From:sip:bob@bank.com 520 -----------------------> ------------------------> 522 This example delivers end-to-end identification, but in practice it 523 is likely that any RFC 4474 signature provided by the originating 524 domain will be broken because an intermediate B2BUA modifies signed 525 information. 527 4.2. Example 2 529 Suppose the service provider removes Bob's identifier and substitutes 530 the default for the bank, based on the bank's default telephone 531 number +123456000 and the bank's domain name. Alice would receive 532 sip:+123456000@bank.com;user=phone. This is an example of 533 conversion. 535 bank.com sp.net Alice 536 From:sip:bob@bank.com From:sip:+123456000@bank.com;user=phone 537 --------------------> ----------------------------------> 539 This example does not deliver end-to-end identification. In this 540 case Alice still knows the call is from her bank but there is no 541 indication of who at the bank is calling. Furthermore, if she were 542 to make a return call to the bank, it would arrive at a default user 543 (e.g., attendant, receptionist) and would not reach Bob. This may be 544 what the bank desires (in which case it would not disclose Bob's 545 identifier to the service provider), but in many cases it may not be 546 what the bank desires. 548 4.3. Example 3 550 Suppose the service provider removes Bob's identifier and substitutes 551 the default for the bank, based on the bank's default telephone 552 number +123456000 and the service provider's domain name. Alice 553 would receive sip:+123456000@sp.net;user=phone. This is an example 554 of conversion. 556 bank.com sp.net Alice 557 From:sip:bob@bank.com From:sip:+123456000@sp.net;user=phone 558 --------------------> ----------------------------------> 560 This example does not deliver end-to-end identification. In this 561 case Alice cannot tell from the received identifier that the call is 562 from her bank, unless she happens to recognise the telephone number. 563 This is no worse than PSTN (or no worse than if a tel: URI were used 564 in SIP), but SIP has the potential to be better than PSTN. As for 565 example 2, there is also a problem with return calls. 567 4.4. Example 4 569 Bob's identifier is sip:+123456789@bank.com;user=phone. If the 570 service provider delivers this to Alice she will see it is from her 571 bank. She may or may not recognise the telephone number as belonging 572 to Bob or to the bank. 574 bank.com sp.net Alice 575 From:sip:+123456789 From:sip:+123456789 576 @bank.com;user=phone @bank.com;user=phone 577 --------------------> ----------------------> 579 This example delivers end-to-end identification, but in practice it 580 is likely that any RFC 4474 signature provided by the originating 581 domain will be broken because an intermediate B2BUA modifies signed 582 information. 584 4.5. Example 5 586 Suppose the service provider substitutes its own domain name for the 587 bank's domain name. Alice would receive 588 sip:+123456789@sp.net;user=phone. This is an example of translation. 590 bank.com sp.net Alice 591 From:sip:+123456789 From:sip:+123456789 592 @bank.com;user=phone @sp.net;user=phone 593 --------------------> ----------------------> 595 This example does not deliver end-to-end identification. In this 596 case Alice cannot see that the call is from her bank, unless she 597 happens to recognise the telephone number. However, the number is 598 delivered end-to-end, which may be sufficient for some purposes. 600 4.6. Example 6 602 Suppose the service provider substitutes its own domain name for the 603 bank's domain name, and also substitutes the default telephone number 604 for the bank. Alice would receive sip:+123456000@sp.net;user=phone. 605 This is an example of conversion. 607 bank.com sp.net Alice 608 From:sip:+123456789 From:sip:+123456000 609 @bank.com;user=phone @sp.net;user=phone 610 --------------------> ----------------------> 612 This example does not deliver end-to-end identification. Alice 613 receives the same identifier as in example 3, and the same 614 considerations apply. 616 4.7. Example 7 618 Consider a call from Carol at client.org to Dave at example.com. 619 Dave is working at home and has arranged for calls to be forwarded to 620 him via his SIP service provider sp.net. Suppose Carol's identifier 621 is carol@client.org and this identifier reaches example.com, where it 622 is forwarded, with the INVITE request, to sp.net. If sp.net delivers 623 this unchanged to Dave at home, Dave will see that the call is from 624 Carol at his client and can accept the call on that basis. Also he 625 can make a return call, e.g., if he is unable to answer at the time 626 and Carol's identifier is stored in his missed call log. 628 client.org example.com sp.net Alice 629 From:sip:carol From:sip:carol From:sip:carol 630 @client.org @client.org @client.org 631 -------------> --------------> ---------------> 633 This example delivers end-to-end identification, but in practice it 634 is likely that any RFC 4474 signature provided by the originating 635 domain will be broken because an intermediate B2BUA modifies signed 636 information. 638 4.8. Example 8 640 Suppose the service provider does not accept sip:carol@client.org as 641 an identifier received from example.com and substitutes the default 642 identifier for example.com, based on its default number and its 643 domain name (sip:+123456000@example.com;user=phone). This is an 644 example of conversion. 646 client.org example.com sp.net Alice 647 From:sip:carol From:sip:carol From:sip:+123456000 648 @client.org @client.org @example.com 649 ;user=phone 650 -------------> --------------> ------------------> 652 This example does not deliver end-to-end identification. Dave will 653 now see that the call comes from his own company, and will not have a 654 clue that it comes from his client. Similarly if the service 655 provider's domain name is used (sip:+123456000@sp.net;user=phone), 656 Dave would presumably recognise his company's own default telephone 657 number but would not see that the call is from his client. Also any 658 attempted return call would just go to his company's default 659 answering point. 661 4.9. Example 9 663 Suppose Carol's identifier is E.164-based: 664 sip:+123498765@client.org;user=phone. If this is delivered to Dave, 665 he will see the calling telephone number, which he may recognise (or 666 software in his phone may match it with an existing contact) and he 667 will also see that it is from client.org. 669 client.org example.com sp.net Alice 670 From:sip:+123498765 From:sip:+123498765 From:sip:+123498765 671 @client.org @client.org @client.org 672 ;user=phone ;user=phone ;user=phone 673 ------------------> ------------------> ------------------> 675 This example delivers end-to-end identification, but in practice it 676 is likely that any RFC 4474 signature provided by the originating 677 domain will be broken because an intermediate B2BUA modifies signed 678 information. 680 4.10. Example 10 682 Suppose the identifier in the last example is not accepted by the 683 service provider, not only because of the domain part (client.org 684 rather than example.com) but also because the telephone number does 685 not fall within the range assigned to example.com. As in example 8 686 it might substitute a default identifier. This is an example of 687 conversion. 689 client.org example.com sp.net Alice 690 From:sip:+123498765 From:sip:+123498765 From:sip:+123456000 691 @client.org @client.org @sp.net 692 ;user=phone ;user=phone ;user=phone 693 ------------------> ------------------> ------------------> 695 This example does not deliver end-to-end identification. 696 Consequences are similar to those in example 8. 698 4.11. Example 11 700 Eve in the US office of enterprise e.com 701 (sip:+123456789@e.com;user=phone) makes a call to Fred, who has a UK 702 telephone number (+44...) and is served by UK service provider 703 uksp.net. The US proxy in e.com forwards the request to the UK proxy 704 of e.com, where the call "breaks out" to uksp.net. The service 705 provider does not accept a non-UK identifier and substitutes a 706 default value for the enterprise (sip:+445678000@e.com;user=phone). 707 This is an example of conversion. 709 e.com uksp.net Fred 710 From:sip:+123456789 From:sip:+445678000 711 @e.com;user=phone @e.com;user=phone 712 --------------------> ------------------------> 714 This example does not deliver end-to-end identification. In this 715 case Fred still knows the call is from e.com, but is not aware that 716 Eve is calling or that that the caller is in the US. 718 4.12. Example 12 720 Suppose the service provider uses its own domain name in the modified 721 SIP URI. 723 e.com uksp.net Fred 724 From:sip:+123456789 From:sip:+445678000 725 @e.com;user=phone @uksp.net;user=phone 726 --------------------> ------------------------> 728 This example does not deliver end-to-end identification and is 729 another example of conversion. In this case Fred does not know that 730 the call is from e.com (unless he happens to recognise the UK 731 telephone number). Also Fred is not aware that Eve is calling or 732 that that the caller is in the US. 734 5. Why end-to-end identification is important 736 The conclusions from the different examples above can be summarized 737 as follows. 739 +------------+-------------------------------------------------+ 740 | Example 1 | Delivers end-to-end identification | 741 +------------+-------------------------------------------------+ 742 | Example 2 | Delivers end-to-end identification, but only | 743 | | domain, not user | 744 +------------+-------------------------------------------------+ 745 | Example 3 | Fails to deliver end-to-end identification | 746 | | (substitutes telephone number instead) | 747 +------------+-------------------------------------------------+ 748 | Example 4 | Delivers end-to-end identification | 749 +------------+-------------------------------------------------+ 750 | Example 5 | Delivers end-to-end identification, but only | 751 | | the telephone number, not the domain | 752 +------------+-------------------------------------------------+ 753 | Example 6 | Fails to deliver end-to-end identification | 754 | | (changes telephone number and domain) | 755 +------------+-------------------------------------------------+ 756 | Example 7 | Delivers end-to-end identification | 757 +------------+-------------------------------------------------+ 758 | Example 8 | Fails to deliver end-to-end identification | 759 | | (forwarding enterprise's identity instead) | 760 +------------+-------------------------------------------------+ 761 | Example 9 | Delivers end-to-end identification | 762 +------------+-------------------------------------------------+ 763 | Example 10 | Fails to deliver end-to-end identification | 764 | | (forwarding enterprise's identity instead) | 765 +------------+-------------------------------------------------+ 766 | Example 11 | Fails to deliver end-to-end identification | 767 | | (delivers domain but changes telephone number) | 768 +------------+-------------------------------------------------+ 769 | Example 12 | Fails to deliver end-to-end identification | 770 | | (changes telephone number and domain) | 771 +------------+-------------------------------------------------+ 773 Examples 1, 4, 7 and 9 are fine, because identification of the caller 774 is end-to-end (although, as pointed out, any RFC 4474 signature might 775 be broken). In the remaining examples, identification is not end-to- 776 end, leading to problems. 778 More complex examples can be derived with more domains involved. 779 Clearly the more domains involved, the more there is scope for 780 failure to deliver an identifier end-to-end, and the greater the 781 consequences for the recipient, both in terms of recognising the 782 source of the call and being able to make a return call. These 783 examples illustrate the importance of delivering an identifier end- 784 to-end, without changing it at intermediate domains. 786 6. Why end-to-end authenticated identification is important 788 Assuming an identifier is delivered end-to-end, where authenticated 789 identification is required it is important that the assertion of 790 authenticity is provided at source, or at least in the originating 791 domain. This is what SIP Identity aims to achieve. However, because 792 of the difficulties with SIP Identity, as described in Section 3.5, 793 some have asked why hop-by-hop assertions are insufficient. PAI is 794 one solution to hop-by-hop assertions. Another possibility would be 795 for each domain to provide its own cryptographic signature. Note 796 that SIP Identity does not allow this, because the signer has to have 797 the same domain name as that in the From URI, so only the originating 798 domain can sign (unless the identifier is also changed, which would 799 mean that requirements for end-to-end identification would not be 800 met). 802 With end-to-end authentication, the relying party has to trust the 803 originating domain, which also means trusting the certificate chain 804 up to the top level certification authority. This is similar to 805 other applications using PKI-based security, such as secure web 806 pages. In many cases there will just be the signing domain's 807 certificate and a single CA certificate. The relying party can see 808 the whole chain and make its own judgements. 810 With hop-by-hop authentication based on PAI, the relying party knows 811 only that the upstream neighbour domain is asserting that domain. It 812 does not know how many further upstream domains there are, what those 813 domains are, and how far the trust domain extends. Just because the 814 relying party trusts its own domain and perhaps its upstream 815 neighbour domain, does not mean that it would trust further domains 816 that its upstream neighbour domain trusts. 818 For example, consider a call from Alice in enterprise1.biz 819 (sip:alice@enterprise1.biz), via service provider sp1.net, via second 820 service provider sp2.org, and terminating at Bob in enterprise2.com 821 (sip:bob@enterprise2.com). The call is routed that way because 822 enterprise1.biz routes all external calls through sp1.net, and 823 enterprise2.com only accepts external calls that have arrived via 824 sp2.org. Bob is happy to accept a secure call from enterprise1.biz. 825 With hop-by-hop authentication, Bob would have to rely on an 826 assertion by enterprise2.com, which in turn would rely on an 827 assertion by sp2.org, and so on. Bob has no visibility of the 828 upstream entities, although he would probably be aware of his 829 enterprise's own service provider (sp2.org). He would be unlikely to 830 be aware of sp1.net, and even if he were aware, he may not have heard 831 of sp1.net and may not wish to trust such an assertion. It could be 832 that sp1.net is located in a country where practices are not of the 833 standard expected in Bob's country. 835 Suppose also that DTLS-SRTP is to be used to secure media between 836 Alice and Bob. If authentication is hop-by hop, Bob can be sure that 837 media is secured as far as sp2.org, but cannot be sure that there is 838 no man-in-the-middle between sp2.org and enterpise1.biz. End-to-end 839 authentication is required to give Bob the assurance he needs. 841 Referring back to the examples in Section 4, those that deliver end- 842 to-end identification have the potential to deliver end-to-end 843 authentication, but in practice, SIP Identity as specified in 844 [RFC4474] is often broken by the actions of B2BUAs. The remaining 845 examples, because they do not deliver end-to-end identification, 846 cannot deliver end-to-end authentication. In addition, normlisation 847 of the From URI breaks SIP Identity. 849 7. Why B2BUAs break SIP Identity signatures 851 As mentioned in Section 3.5, SIP Identity signatures are broken when 852 B2BUAs (in particular SBCs) modify signed parts of a SIP request when 853 forwarding. This prevents the provision of end-to-end (or end- 854 domain-to-end-domain) authenticated identification. 856 Common functions of SBCs are described in 857 [I-D.ietf-sipping-sbc-funcs]. To achieve some of these functions, an 858 SBC could act as a proxy, but to achieve other function an SBC might 859 need to act as a B2BUA in a way that is harmful to end-to-end 860 authenticated identification. 862 7.1. Changing the SDP body part 864 Because SIP Identity signs the entire body of a SIP request, this 865 includes any SDP body part, which typically is present in an INVITE 866 request, for example. For reasons of media steering, SBCs frequently 867 modify IP addresses and ports in SDP in order to force media to take 868 a particular path, e.g., to ensure it does indeed pass through the 869 operator's network, or to force it along a route that can provide 870 appropriate quality of service. Also an SBC might modify SDP in 871 order to limit bandwidth to what is available or authorised, e.g., by 872 stripping out bandwidth-hungry codecs and forcing endpoints to select 873 low bandwidth codecs. SBCs, together with an associated media relay, 874 often carry out NAT traversal functions, resulting in a need to 875 modify SDP. Although NAT traversal can be achieved by other means 876 such as ICE, which does not require modification of SDP at the point 877 of NAT traversal, such means are dependent on endpoint support. 878 Furthermore SBCs sometimes use an associated media relay to perform 879 conversion between IP versions (IPv4 and IPv6), again requiring 880 modifications to SDP. More details are given in 881 [I-D.ietf-sipping-sbc-funcs], but the result is that SBCs frequently 882 modify SDP and will therefore break a SIP Identity signature. 884 It should be noted that end-to-end authenticated identification does 885 not necessarily need to traverse some SDP-modifying functions that 886 SBCs or other intermediaries perform. For example, if an SBC steers 887 media through a media relay that decrypts and re-encrypts media 888 (e.g., for call recording purposes), media encryption is not end-to- 889 end, and therefore end-to-end authenticated identification can be 890 considered inappropriate. If SIP Identity is used to bind media 891 security to the source of a SIP request, the identified source should 892 correspond to the place where media security terminates, which is the 893 media relay. Any attempt at trying to pretend security is end-to-end 894 would conceal the possibility of a man-in-the-middle attack. 895 Similarly, if an SBC steers media through a transcoder, the 896 transcoder can potentially change the media, so again end-to-end 897 authenticated identification can be considered inappropriate. In 898 this case, if the media is secured, the transcoder would also need to 899 decrypt and re-encrypt. 901 7.2. Changing the Contact and Call-Id header fields 903 B2BUAs, including SBCs, often modify Contact and Call-Id header 904 fields. One reason is for topology hiding, if these fields convey 905 information that might reveal information about the rest of an 906 operator's network (e.g., by identifying specific gateways behind the 907 SBC). Another reason for changing Contact is to replace IP addresses 908 by host names. 910 Another reason is because of 3rd party call control (3PCC) functions 911 performed by an SBC. For example, if a B2BUA uses 3PCC techniques to 912 perform transfer, a call leg on one side will be joined to a call leg 913 on the other side, that was not part of the original call, and 914 therefore it will necessarily have a different Call-Id value, as well 915 as different To and From tags. The resulting call will have 916 different Call-Id and tag values on either side of the B2BUA. In 917 other words, it will comprise a concatenation of two different 918 dialogs, even if the original call comprised only a single dialog. 919 Therefore when a request is sent end-to-end along the new call, 920 Call-Id and tag values will need to be changed as the request passes 921 through the B2BUA. Also the Contact URI might need to change. These 922 actions will break any SIP Identity signature. 924 7.3. Changing the From URI 926 Changing the From header field URI when forwarding a request will 927 break a SIP Identity signature. Reasons for changing the URI are 928 discussed in [I-D.kaplan-sip-uris-change]. In particular, it is 929 common practice to modify the host part to reflect a domain's own 930 domain name when entering a domain, or to reflect the next domain's 931 name when exiting a domain. Reasons are not entirely clear, but one 932 reason might be to adapt to broken implementations that cannot accept 933 other domain names. Another reason might be to hide a domain's 934 relationship with other domains. Changing the host part of a SIP URI 935 based on a fully qualified E.164 number does not necessarily 936 invalidate the user part, i.e., the E.164 number can still be 937 considered valid, whatever the domain part. However, some of the 938 examples in Section 4 require the original domain part to be 939 delivered, and therefore by changing the domain part, end-to-end 940 identification cannot be claimed. With SIP URIs not based on E.164 941 numbers (e.g., based on a name), changing is less straightforward, 942 although it can in theory be done by encapsulating the entire 943 original URI in the user part of the new URI, together with a new 944 domain part, resulting in a complex URI that might not be interpreted 945 correctly by the UAS or its user. 947 Other reasons for From URI changing are given in 948 [I-D.kaplan-sip-uris-change], but some of these disappear if good 949 practices are observed, such as avoiding IP addresses in host parts, 950 avoiding non-normalised forms of user parts (e.g., containing prefix 951 digits or without country code), and avoiding identifiers based on 952 host names rather than domain names. 954 Although on the one hand, changing a From URI can break a SIP 955 Identity signature, changing the From URI can also be part of the 956 solution for rectifying a broken SIP Identity signature, since re- 957 signing the request requires the From URI to have a domain part the 958 same as the signing domain. Therefore whether or not the From URI 959 has changed anyway, re-signing a request will involve changing the 960 From URI unless the request is still within the original domain. 961 Although re-signing can rectify a broken SIP Identity signature, it 962 does not lead to end-to-end authenticated identification. Also, for 963 URIs not based on E.164 numbers, changes result in complex URIs that 964 might not be interpreted correctly. Furthermore, re-signing by an 965 intermediate domain imposes greater computational costs on that 966 domain, for the benefit of end domains. 968 7.4. Changing the To URI 970 Changing the To header field URI when forwarding a request will break 971 a SIP Identity signature. Reasons for change are similar to some of 972 the reasons for changing the From URI. 974 7.5. Protocol repair 976 Protocol repair by an SBC or B2BUA can break a SIP Identity signature 977 if the repair impacts any of the signed elements. Of the signed 978 elements, SDP is certainly an area that has attracted many bad 979 implementations and is a prime target for repair, to avoid an error 980 being perpetuated as a SIP request traverses domains. Whilst this 981 can be seen as beneficial in some circumstances, cosmetic repairs are 982 unnecessary and some repairs can be harmful in other ways (e.g., 983 "repairing" a valid new extension to SIP or SDP that is not supported 984 and therefore not understood by the SBC). 986 8. Analysis of changes to SIP requests by B2BUAs 988 This section analyses in more detail those parts of a SIP request 989 that are signed by RFC 4474 to see which parts really need to be 990 allowed to be changed by B2BUAs (i.e., any mechanism for end-to-end 991 authenticated identification needs to be tolerant of such changes) 992 and which do not need to be changed (i.e., any mechanism for end-to- 993 end authenticated identification can expect to fail in the presence 994 of such changes). Any identity-related header fields not signed by 995 RFC 4474 (e.g., History-Info, Geolocation) are not considered. 997 8.1. addr-spec of From header field 999 Conversion of the From URI is generally harmful, in that after 1000 conversion the From URI no longer identifies the source of the 1001 request. Conversion might involve just a change of user-info part, 1002 such that the domain is still correct, or might involve a change of 1003 domain too. Therefore it is not required that a mechanism for end- 1004 to-end authenticated identification be tolerant of conversion of the 1005 From URI. 1007 Translation of the From URI is generally less harmful, in that after 1008 translation it still identifies the source of the request. However, 1009 there are several sub-categories of translation, each with different 1010 consequences: 1012 o Translating from a non-global URI to a global URI is generally 1013 helpful, but on the other hand could and should be done by the 1014 originating domain before signing the request, thereby removing 1015 the need for this form of translation by B2BUAs in intermediate 1016 domains. 1018 o Translation involving changing the domain part of an E.164-based 1019 SIP URI is harmful, since the domain from which the request 1020 originated is lost. 1022 o Translation of a name-based SIP URI to an alias number-based SIP 1023 URI or vice versa with the same domain part may or may not be 1024 harmful, depending on whether the translated URI is meaningful to 1025 the UAS its user. 1027 o Translation of a name- or number-based SIP URI to a TEL URI is 1028 harmful in that the domain is lost. Effectively this is what has 1029 to be done at PSTN gateways, where it cannot be avoided, but it 1030 should not be done by B2BUAs. In any case, RFC 4474 cannot be 1031 used with a TEL URI. 1033 Normalisation in general is not harmful, although it should be 1034 carried out at the originating domain before signing. 1036 Any form of modification of the From URI (conversion, translation or 1037 normalization) is either harmful if carried out by an intermediate 1038 domain or is better carried out by the originating domain. Therefore 1039 a mechanism for end-to-end authenticated identification does not need 1040 to be tolerant of changes to the From URI by intermediate domains. 1042 TODO. Do changes to phone-context or to any URI parameters need to 1043 be considered explicitly, or are they all covered by conversion, 1044 translation or normalisation? 1046 8.2. addr-spec of To header field 1048 Although the To URI does not identify the caller, it does identify 1049 the original targeted user. Any normalisation or translation to a 1050 globally unique identifier should be carried out by the originating 1051 domain, in which case there should be no reason for modification by 1052 an intermediate domain. Therefore a mechanism for end-to-end 1053 authenticated identification does not need to be tolerant of changes 1054 to the To URI by intermediate domains. 1056 8.3. call-id of Call-Id header field and digit of CSeq header field 1058 These do not impact the identity characteristics of a request. For 1059 topology hiding and 3PCC reasons, B2BUAs on the path of a call may 1060 modify call-id and digit when forwarding a request. Therefore a 1061 mechanism for end-to-end authenticated identification needs to be 1062 tolerant of changes to call-id and digit by intermediate domains. 1064 Note that although call-id and digit were apparently included in the 1065 RFC 4474 signature for replay prevention purposes, it is not clear 1066 that this would work. There are cases related to forking, 1067 redirection and retransmission over UDP transport where the verifier 1068 could legitimately receive repeated requests with the same call-id 1069 and digit values, perhaps with different values in the Request-URI by 1070 intermediate domains. 1072 8.4. method of CSeq header field 1074 This does not impact the identity characteristics of a request. It 1075 seems very unlikely that an SBC would modify this field. Therefore a 1076 mechanism for end-to-end authenticated identification does not need 1077 to be tolerant of changes to method by intermediate domains. 1079 8.5. Date header field 1081 This does not impact the identity characteristics of a request, but 1082 in RFC 4474 it is essential to provisions for preventing replay 1083 attacks. Therefore a mechanism for end-to-end authenticated 1084 identification does not need to be tolerant of changes to method by 1085 intermediate domains. 1087 8.6. addr-spec of Contact header field 1089 Substitution of a B2BUA's own contact URI (e.g., for topology hiding 1090 or 3PCC reasons) does not impact the identity characteristics of a 1091 request, as far as the current call is concerned. If a substituted 1092 contact URI is subsequently used as the target of a separate request, 1093 outside the context of the original dialog, the B2BUA would need to 1094 be able to restore the original contact URI and forward the request, 1095 even if the original dialog has terminated, which requires some 1096 stateful or algorithmic mechanism at the B2BUA, but B2BUAs should be 1097 able to do this. 1099 Although substitution of the Contact URI does not impact end-to-end 1100 identification, it was apparently included in the RFC 4474 signature 1101 for replay prevention purposes. It is not clear whether it really 1102 helps prevent replay, since a man-in-the-middle can pervert the 1103 routing of subsequent mid-dialog requests by manipulating Record- 1104 Route (which is not signed) rather than Contact. 1106 8.7. SDP body part 1108 For media steering purposes, B2BUAs in intermediate domains need to 1109 modify the IP address c-lines and the port in m-lines. This does not 1110 impact the identity characteristics of a request, although it means 1111 that the IP address and port for media cannot be assumed to relate to 1112 the source of the SIP request. In that sense, media steering in this 1113 way is harmful, in that a man-in-the-middle could become the media 1114 terminator. This is not a problem if SRTP is used and there is a 1115 mechanism for authenticating the media terminator during key 1116 establishment (e.g., by binding the media terminator to authenticated 1117 source of a SIP request) - in this situation the IP address and port 1118 are unimportant. 1120 Clearly an a=fingerprint line should not be modified by intermediate 1121 domains, since this would destroy authentication for the media 1122 concerned (whether this uses SRTP, TLS or some other secure 1123 transport). 1125 Insertion of m-lines can be harmful, since this introduces media that 1126 does not potentially does not terminate where the request originated 1127 (unless they use the same IP addresses and ports as existing media). 1128 Adding media to provide alternatives to what is already proposed can 1129 sometimes be helpful (e.g., RTP/AVP as an alternative to or instead 1130 of RTP/AVPF, to assist interoperability) but can also be harmful 1131 (e.g., adding RTP/AVP as an alternative to or instead of RTP/SAVP, 1132 since that could also be seen as a bid-down attack). 1134 SDP capability negotiation complicates the picture even further, 1135 since the various attribute lines (e.g., a=pcfg, a=tcap, etc.) can 1136 modify the meaning of the SDP in very many ways, some of which might 1137 be harmful and others might be helpful. For example, if providing 1138 media steering, a B2BUA might legitimately want to modify ports and 1139 IP addresses related to media being negotiated. 1141 Formatting changes to SDP (e.g., removal or insertion of white 1142 space), although in most respects harmless, but on the other hand 1143 there is no justification for an intermediate domain to do this. 1145 This seems to indicate that a mechanism for end-to-end authenticated 1146 identification needs to be tolerant of some types of change to SDP by 1147 intermediate domains but should be intolerant of others types of 1148 change. Any mechanism must take account of future evolution of SDP, 1149 perhaps by being tolerant of specific changes (e.g., IP address in 1150 c-line and port in m-line) but intolerant of changes to the rest, 1151 including any future extensions. 1153 8.8. Other body parts 1155 There is generally no justification for an intermediate domain to 1156 add, modify or delete other body parts (e.g., PIDF-LO, SAML 1157 assertions), and therefore any mechanism for end-to-end authenticated 1158 identification should be intolerant of such changes. 1160 9. Conclusions 1162 This document has demonstrated the importance of end-to-end (or at 1163 least end-domain-to-end-domain) identification and authenticated 1164 identification in SIP. Although in many simple cases hop-by-hop 1165 identification or hop-by-hop assertions can be shown to be adequate, 1166 there are many cases where this is simply not the case. 1168 This document has also illustrated why current mechanisms are unable 1169 to deliver end-to-end authenticated identification in many practical 1170 situations. In particular, SIP Identity [RFC4474] will not work in 1171 practical situations, because B2BUAs in intermediate domains modify 1172 certain aspects of SIP requests, resulting in the signature being 1173 broken. A good example of a change that breaks the signature is 1174 media steering, whereby a B2BUA modifies IP addresses and ports in 1175 SDP to ensure that media is steered onto a path that can provide the 1176 appropriate quality of service. 1178 The problem can be broken down into two parts: 1180 o Loss of end-to-end authenticated identification caused by the 1181 breaking of SIP Identity signatures on non-E.164-based SIP URIs by 1182 B2BUAs in intermediate domains performing legitimate functions 1183 such as media steering. 1185 o Loss of end-to-end authenticated identification caused by the 1186 breaking of SIP Identity signatures on E.164-based SIP URIs by 1187 B2BUAs in intermediate domains performing legitimate functions 1188 such as media steering, and also by B2BUAs modifying the URI by 1189 changing the domain part and possibly creating a new SIP Identity 1190 signature. 1192 The second part may be harder to solve than the first part. This is 1193 discussed further in [I-D.rosenberg-sip-rfc4474-concerns], which 1194 concludes that there is no simple remedy and instead just the 1195 problems associated with phone numbers and RFC 4474 be documented. 1197 It is assumed that end-to-end authenticated identification is not 1198 achievable when PSTN is involved, as discussed in Section 3.9. 1200 Any solution for end-to-end authenticated identification must be 1201 tolerant of certain legitimate changes to SIP requests as they 1202 traverse intermediate domains. Details of which changes are to be 1203 tolerant need further work, although Section 8 provides some 1204 considerations. 1206 10. Requirements for end-to-end authenticated identification 1208 Consider the following legitimate call from user1 at UA1 in 1209 enterprise1 to user2 at UA2 in enterprise2, via intermediate domains 1210 ITSP-A, ITSP-B and ITSP-C: 1212 +----------+ +----------+ +----------+ 1213 +---+ SBC SBC +---+ SBC SBC +---+ SBC SBC +---+ 1214 | +----------+ +----------+ +----------+ | 1215 | ITSP-A ITSP-B ITSP-C | 1216 | | 1217 +------+------+ +------+------+ 1218 | enterprise1 | | enterprise2 | 1219 +------+------+ +------+------+ 1220 | | 1221 user1/UA1 user2/UA2 1222 From:sip:user1@enterprise1.com 1223 To:sip:user2@enterprise2.com 1225 We need to differentiate the above legitimate call from the following 1226 illegitimate call where user3 at UA3 in enterprise3 is calling UA2 1227 and is spoofing the identity of user1: 1229 user3/UA3 1230 | 1231 +------+------+ 1232 | enterprise3 | 1233 +------+------+ 1234 | 1235 +----------+ +----+-----+ +----------+ 1236 +---+ SBC SBC +---+ SBC SBC +---+ SBC SBC +---+ 1237 | +----------+ +----------+ +----------+ | 1238 | ITSP-A ITSP-B ITSP-C | 1239 | | 1240 +------+------+ +------+------+ 1241 | enterprise1 | | enterprise2 | 1242 +------+------+ +------+------+ 1243 | | 1244 user1/UA1 user2/UA2 1246 This needs to work both where user1's AoR is not E.164-based (as 1247 shown in the figures) and preferably also where user1's AoR is E.164- 1248 based (e.g., sip:+123456789@enterprise1.com;user=phone). However, 1249 the latter may not be achievable. 1251 TODO: Add specific requirements. 1253 11. IANA considerations 1255 This document requires no IANA actions. 1257 12. Security considerations 1259 Authentication of parties involved in a call is an essential part of 1260 this document and is fully discussed in the preceding sections. 1261 There are no other security considerations. 1263 13. Acknowledgements 1265 The author received valuable comments from Keith Drage, Kai Fischer, 1266 Cullen Jennings, Hadriel Kaplan, Eric Rescorla, Hannes Tschofenig, 1267 Adam Uzelac, Dean Willis, Dan Wing and Dan York during drafting. 1269 14. Informative References 1271 [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy 1272 (PGP)", RFC 2015, October 1996. 1274 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1275 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1276 March 1999. 1278 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1279 Extensions (S/MIME) Version 3.1 Message Specification", 1280 RFC 3851, July 2004. 1282 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1283 A., Peterson, J., Sparks, R., Handley, M., and E. 1284 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1285 June 2002. 1287 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1288 Extensions to the Session Initiation Protocol (SIP) for 1289 Asserted Identity within Trusted Networks", RFC 3325, 1290 November 2002. 1292 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1293 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1294 RFC 3711, March 2004. 1296 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1297 Authenticated Identity Body (AIB) Format", RFC 3893, 1298 September 2004. 1300 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1301 RFC 3966, December 2004. 1303 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1304 Authenticated Identity Management in the Session 1305 Initiation Protocol (SIP)", RFC 4474, August 2006. 1307 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1308 Protocol (SIP)", RFC 4916, June 2007. 1310 [I-D.elwell-sip-e164-problem-statement] 1311 Elwell, J., "SIP E.164 Problem Statement", 1312 draft-elwell-sip-e164-problem-statement-01 (work in 1313 progress), October 2008. 1315 [I-D.kaplan-sip-uris-change] 1316 Kaplan, H., "Why URIs Are Changed Crossing Domains", 1317 draft-kaplan-sip-uris-change-00 (work in progress), 1318 February 2008. 1320 [I-D.ietf-sip-dtls-srtp-framework] 1321 Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1322 for Establishing an SRTP Security Context using DTLS", 1323 draft-ietf-sip-dtls-srtp-framework-05 (work in progress), 1324 October 2008. 1326 [I-D.ietf-sipping-sbc-funcs] 1327 Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen, 1328 A., and M. Bhatia, "Requirements from SIP (Session 1329 Initiation Protocol) Session Border Control Deployments", 1330 draft-ietf-sipping-sbc-funcs-08 (work in progress), 1331 January 2009. 1333 [I-D.ietf-sip-certs] 1334 Jennings, C. and J. Fischl, "Certificate Management 1335 Service for The Session Initiation Protocol (SIP)", 1336 draft-ietf-sip-certs-07 (work in progress), November 2008. 1338 [I-D.kuthan-sip-derive] 1339 Kuthan, J., Sisalem, D., Coeffic, R., and V. Pascual, 1340 "Dialog Event foR Identity VErification", 1341 draft-kuthan-sip-derive-00 (work in progress), 1342 October 2008. 1344 [I-D.rosenberg-sip-rfc4474-concerns] 1345 Rosenberg, J., "Concerns around the Applicability of RFC 1346 4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in 1347 progress), February 2008. 1349 Author's Address 1351 John Elwell 1352 Siemens Enterprise Communications 1354 Phone: +44 1908 855608 1355 Email: john.elwell@siemens.com