idnits 2.17.1 draft-ietf-sip-referredby-05.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 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (March 22, 2004) is 7332 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 1005 == Outdated reference: A later version (-03) exists of draft-ietf-sip-authid-body-02 == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-01 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-01 -- Obsolete informational reference (is this intentional?): RFC 2822 (ref. '9') (Obsoleted by RFC 5322) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sparks 3 Internet-Draft dynamicsoft 4 Expires: September 20, 2004 March 22, 2004 6 The SIP Referred-By Mechanism 7 draft-ietf-sip-referredby-05 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on September 20, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 The SIP REFER method provides a mechanism where one party (the 38 referrer) gives a second party (the referee) an arbitrary URI to 39 reference. If that URI is a SIP URI, the referee will send a SIP 40 request, often an INVITE, to that URI (the refer target). This 41 document extends the REFER method allowing the referrer to provide 42 information about the REFER request to the refer target using the 43 referee as an intermediary. This information includes the identity of 44 the referrer and the URI to which the referrer referred. The 45 mechanism utilizes S/MIME to help protect this information from a 46 malicious intermediary. This protection is optional, but a recipient 47 may refuse to accept a request unless it is present. 49 Table of Contents 51 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Requirements notation . . . . . . . . . . . . . . . . . . . . 3 53 2. The Referred-By Mechanism . . . . . . . . . . . . . . . . . . 4 54 2.1 Referrer behavior . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2 Referee behavior . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.3 Refer Target behavior . . . . . . . . . . . . . . . . . . . . 5 57 3. The Referred-By Header Field . . . . . . . . . . . . . . . . . 6 58 4. The Referred-By Token . . . . . . . . . . . . . . . . . . . . 7 59 4.1 Refer target inspection of a Referred-By token . . . . . . . . 8 60 5. The 429 Provide Referrer Identity error response . . . . . . . 8 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 6.1 Identifying the referee in the Referred-by Token . . . . . . . 10 63 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 7.1 Basic REFER . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 7.2 Insecure REFER . . . . . . . . . . . . . . . . . . . . . . . . 14 66 7.3 Requiring Referrer Identity . . . . . . . . . . . . . . . . . 14 67 7.4 Nested REFER . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 69 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 70 Normative References . . . . . . . . . . . . . . . . . . . . . 23 71 Informative References . . . . . . . . . . . . . . . . . . . . 23 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23 73 Intellectual Property and Copyright Statements . . . . . . . . 24 75 1. Overview 77 The SIP REFER method [2] provides a mechanism where one party (the 78 referrer) provides a second party (the referee) with an arbitrary URI 79 to reference. If that URI is a SIP URI, the referee will send a SIP 80 request, often an INVITE, to that URI (the refer target). Nothing 81 provided in [2] distinguishes this referenced request from any other 82 request the referee might have sent to the refer target. 84 Referrer Referee Refer Target 85 | | | 86 | REFER | | 87 | Refer-To: target | | 88 |----------------->| INVITE target | 89 | |------------------->| 91 There are applications of REFER, such as call transfer [8], where it 92 is desirable to provide the refer target with certain information 93 about the referrer and the REFER request itself. This information may 94 include, but is not limited to, the referrer's identity, the referred 95 to URI, and the time of the referral. The refer target can use this 96 information when deciding whether to admit the referenced request. 97 This draft defines one set of mechanisms to provide that information. 99 All of the mechanisms in this draft involve placing information in 100 the REFER request that the referee copies into the referenced 101 request. This necessarily establishes the referee as an eavesdropper 102 and places the referee in a position to launch man-in-the-middle 103 attacks on that information. 105 At the simplest level, this draft defines a mechanism for carrying 106 the referrer's identity, expressed as a SIP URI in a new header: 107 Referred-By. The refer target can use that information, even if it 108 has not been protected from the referee, at the perils and with the 109 limitations documented here. The draft proceeds to define an S/MIME 110 based mechanism for expressing the identity of the referrer and 111 capturing other information about the REFER request, allowing the 112 refer target to detect tampering (and other undesirable behaviors) by 113 the referee. 115 1.1 Requirements notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in BCP 14, RFC 2119 [1]. 121 2. The Referred-By Mechanism 123 The following figure summarizes how Referred-By information is 124 carried to the Refer Target. The Referrer provides a Referred-By 125 header with its SIP address-of-record, optionally associating an S/ 126 MIME protected token reflecting the identity of the referrer and 127 details of the REFER request. The Referee copies this header and the 128 token, if provided, into the triggered request (shown here as an 129 INVITE). 131 Referrer Referee Refer Target 132 | | | 133 | REFER | | 134 | Refer-To: target | | 135 | Referred-By: referrer;cid=X | | 136 | | | 137 | (one of the body parts is) | | 138 | Content-ID: X | | 139 | | | 140 |----------------------------->| | 141 | | INVITE target | 142 | | Referred-By: referrer;cid=X | 143 | | | 144 | | (one of the body parts is) | 145 | | Content-ID: X | 146 | | | 147 | |---------------------------->| 149 2.1 Referrer behavior 151 A UA sending a REFER request (a referrer) MAY provide a Referred-By 152 header field value in the request. A REFER request MUST NOT contain 153 more than one Referred-By header field value. 155 A referrer MAY include a Referred-By token in a REFER request. A 156 REFER request containing a Referred-By token MUST contain a 157 Referred-By header field value with a cid parameter value equal to 158 the Content-ID of the body part containing the token. 160 The referrer will receive a NOTIFY with a message/sipfrag [4] body 161 indicating a final response of 429 "Provide Referrer Identity" to the 162 referenced request if the refer target requires a valid Referred-By 163 token to accept the request. This can occur when either no token is 164 provided or a provided token is invalid. 166 The referrer will receive a 429 "Provide Referrer Identity" response 167 to the REFER if the referee requires a Referred-By token to be 168 present in order to accept the REFER. 170 If a referrer wishes to reattempt to refer a referee after receiving 171 a 429 response or a NOTIFY containing a 429, it MAY submit a new 172 REFER request containing a Referred-By token. 174 2.2 Referee behavior 176 A UA accepting a REFER request (a referee) to a SIP URI (using either 177 the sip: or sips: scheme) MUST copy any Referred-By header field 178 value and token into the referenced request without modification. 180 A referee MAY reject a REFER request that does not contain a 181 Referred-By token with a 429 "Provide Referrer Identity" response. A 182 referee SHOULD NOT reject a request that contains a Referred-By token 183 encrypted to a key it does not possess simply because it cannot 184 decrypt the token. (One scenario where such rejection would be 185 appropriate is when the referee is attempting to remain anonymous 186 (see Section 6.1)). Note that per [3] the referee should still be 187 able to verify the signature of such an encrypted token. 189 A referee SHOULD present the same identity to the referrer and the 190 refer target. 192 2.3 Refer Target behavior 194 A UA receiving a non-REFER SIP request MAY inspect the request for a 195 Referred-By header field and token. 197 If a Referred-By header field value is not present, this UA can not 198 distinguish this request from any other the UA acting as the referee 199 might have sent. Thus, the UA would apply exactly the admissions 200 policies and processing described in [5] to the request. 202 If a Referred-By header field value is present, the receiving UA can 203 consider itself a refer target and MAY apply additional admission 204 policies based on the contents of the Referred-By header field and 205 token. 207 The referee is in a position to modify the contents of the 208 Referred-By header field value, or falsely provide one even if no 209 REFER actually exists. If such behavior could affect admission policy 210 (including influencing the agent's user by rendering misleading 211 content), the refer target SHOULD require that a valid Referred-By 212 token be present. 214 The refer target MAY reject a request if no Referred-By token is 215 present or if the token is stale using the 429 "Provide Referrer 216 Identity" error response defined in Section 5. The 428 error response 217 from [7] is not appropriate for this purpose - it is needed for the 218 refer target to request an authentication token from the referee. 220 If no Referred-By token is present, the refer target MAY proceed with 221 processing the request. If the agent provides any information from 222 the Referred-By header to its user as part of processing the request, 223 it MUST notify the user that the information is suspect. 225 The refer target MUST reject an otherwise well-formed request with an 226 invalid Referred-By token (see Section 4) with a 429 error response. 228 3. The Referred-By Header Field 230 Referred-By is a request header field as defined by [5]. It can 231 appear in any request. It carries a SIP URI representing the identity 232 of the referrer and, optionally, the Content-ID of a body part (the 233 Referred-By token) that provides a more secure statement of that 234 identity. 236 Referred-By = ("Referred-By" / "b") HCOLON referrer-uri 237 *( SEMI (referredby-id-param / generic-param) ) 239 referrer-uri = ( name-addr / addr-spec ) 241 referredby-id-param = "cid" EQUAL sip-clean-msg-id 243 sip-clean-msg-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT 245 dot-atom = atom *( "." atom ) 247 atom = 1*( alphanum / "-" / "!" / "%" / "*" / 248 "_" / "+" / "'" / "`" / "~" ) 250 Since the Content-ID appears as a SIP header parameter value which 251 must conform to the expansion of gen-value defined in [5], this 252 grammar produces values in the intersection of the expansions of 253 gen-value and msg-id from [9]. The double-quotes surrounding the 254 sip-clean-msg-id MUST be replaced with left and right angle brackets 255 to derive the Content-ID used in the message's MIME body. For 256 example, 258 Referred-By: sip:r@ref.example;cid="2UWQFN309shb3@ref.example" 259 indicates the token is in the body part containing 261 Content-ID: <2UWQFN309shb3@ref.example> 263 The Referred-By header field MAY appear in any SIP request, but is 264 meaningless for ACK and CANCEL. Proxies do not need to be able to 265 read Referred-By header field values and MUST NOT remove or modify 266 them. 268 The following row should be interpreted as if it appeared in Table 3 269 of RFC 3261. 271 Header field where proxy ACK BYE CAN INV OPT REG 272 ___________________________________________________________________ 273 Referred-By R - o - o o o 275 4. The Referred-By Token 277 The Referred-By token is an Authenticated Identity Body as defined by 278 [3]. This body part MUST be identified with a MIME [6] Content-ID: 279 field. 281 The sipfrag inside a Referred-By token MUST contain copies of the 282 Refer-To, Referred-By, and Date header fields from the REFER request. 284 The token SHOULD NOT contain the Call-ID header field from the REFER 285 request as that information is not useful to the refer target and may 286 even be an information leak. The token SHOULD NOT contain the From 287 header field from the REFER request since the identity being claimed 288 is represented in the Referred-By header field. 290 The token MAY contain the To header field from the REFER request, but 291 it SHOULD NOT be included unless the referrer has cryptographically 292 identified the referee. Some ways this authentication can be achieved 293 include inspecting the certificates used in a TLS association between 294 the referrer and the referee or encrypting the Refer-To header in the 295 REFER request using the S/MIME encryption techniques detailed in [5]. 297 When inspecting the certificates used to establish TLS associations, 298 the identity asserted in the token's To header field URI is compared 299 to the subjectAltNames from the referee's certificate. The sip and 300 sips URI schemes MUST be treated as equivalent for this comparison. 301 If the URI is an exact match, confidence in the authentication is 302 high and the To header field MAY be added to the token. If the 303 certificate subjects contain only a hostname matching the hostname 304 portion of the URI, an application level warning SHOULD be issued to 305 the referrer agent's user seeking that user's consent before 306 including the To header field in the token. 308 Including the To header field in the token significantly strengthens 309 the claim being asserted by the token, but may have privacy 310 implications as discussed in Section 6.1. 312 Additional header fields and body parts MAY be included in the token. 314 As described in [3], a Referred-By token MAY be encrypted as well as 315 signed. The subjectAltName of the certificate used for these 316 operations SHOULD exactly match the identity claimed in the 317 referrer-uri in the Referred-By header field in the token. 319 4.1 Refer target inspection of a Referred-By token 321 A refer target MUST treat a Referred-By token with an invalid 322 signature as an invalid token. A target SHOULD treat a token with an 323 aged Date header field value as invalid. 325 A target SHOULD verify that the request it receives matches the 326 reference in the Refer-To header field in the token. This 327 verification SHOULD include at least the request method and any 328 indicated end-to-end header field values. Note that the URI in the 329 Refer-To header field may not match the request URI in the received 330 request due to request retargetting between the referee and the refer 331 target. 333 The target SHOULD verify that the identity in the Referred-By header 334 field in the token exactly matches the SubjectAltName from the 335 signing certificate, reporting discrepancies to its user as described 336 in [3]. 338 If the token contains a To header field, the target SHOULD verify 339 that the identity it expresses matches the referrer. One way of 340 verifying this is to exactly match the identity in the token's To 341 header field with the subjectAltName of the certificate used by the 342 referee to sign the aib protecting the request itself. The 428 343 response defined in [7] can be used to request such an aib if one is 344 not already present. 346 5. The 429 Provide Referrer Identity error response 348 The 429 client error response code is used by a refer target to 349 indicate that the referee must provide a valid Referred-By token. As 350 discussed in the behavior section, the referee will forward this 351 error response to the referrer in a NOTIFY as the result of the 352 REFER. The suggested text phrase for the 429 error response is 353 "Provide Referrer Identity". 355 6. Security Considerations 357 This mechanism defined in this specification relies on an 358 intermediary (the referee) to forward information from the referrer 359 to the refer target. This necessarily establishes the referee as an 360 eavesdropper of that information and positions him perfectly to 361 launch man-in-the-middle attacks using the mechanism. 363 A SIP proxy is similarly positioned. Protecting SIP messaging from 364 malicious proxy implementations is discussed in [5]. In contrast to a 365 proxy, the referee's agent is an endpoint. Proxies will typically be 366 managed and monitored by service providers. Malicious behavior by a 367 proxy is more likely to be noticed and result in negative 368 repercussions for the provider than malicious behavior by an endpoint 369 would be. The behavior of an endpoint can be entirely under the 370 control of a single user. Thus, it is more feasible for an endpoint 371 acting as referee to behave maliciously than it is for a proxy being 372 operated by a service provider. 374 This specification uses an S/MIME based mechanism to enable the refer 375 target to detect manipulation of the Referred-By information by the 376 referee. Use of this protection is optional! The community has 377 asserted that there are systems where trust in the validity of this 378 information is either not important or can be established through 379 other means. Any implementation choosing not to use this optional 380 mechanism needs to provide its own defense to the following risks: 382 o The Referred-By information is highly likely to influence request 383 admission policy. For instance, it may be displayed to the user of 384 the agent with a "This call was transferred to you by X. Accept?" 385 prompt. A malicious referee can unduly influence that policy 386 decision by providing falsified referred-by information. This 387 includes falsely claiming to have been referred in the first 388 place. (The S/MIME mechanism protects the information with a 389 signature, hampering the referee's ability to inject or modify 390 information without knowing the key used for that signature). 391 o A referee is by definition an eavesdropper of the referred-by 392 information. Parts of that information may be sensitive. (The S/ 393 MIME mechanism allows encryption). 394 o The referee may store any referred-by information it sees and 395 paste it into future unrelated requests. (The S/MIME mechanism 396 allows detection of stale assertions by covering a timestamp with 397 the signature and allows detection of use in unrelated requests by 398 covering the Refer-To header field with the signature). 400 The mechanisms in this specification do NOT prevent the referee from 401 deleting ALL referred-by information from the referenced request. A 402 refer target can not detect such deletion. This introduces no new 403 problems since removing all referred-by information from a referenced 404 request transforms it into an ordinary SIP request as described in 405 [5]. Thus the referee gains no new influence over processing logic at 406 the refer target by removing the referred-by information. 408 Refer targets can protect themselves from the possibility that a 409 malicious referee removed a token (leaving an unsecured identity in 410 the Referred-By header field) by using the 429 error response. 412 Applications using the mechanisms in this draft may be able to take 413 advantage of pre-existing relationships between the participants to 414 mitigate the risks of its use. In some transfer scenarios, A has the 415 choice of referring B to C or referring C to B. If A and B have a 416 pre-existing trust relationship leading A to have greater confidence 417 that B will not behave maliciously (B is A's administrative assistant 418 for example), referring B to C may make more sense. 420 This mechanism involves two SIP requests between three endpoints, the 421 REFER and the referenced request. The content of those messages 422 (including the referred-by information) is subject to the security 423 considerations and protection mechanisms documented in [5]. 425 Proxies between the participants may collect referred-by information 426 and reinsert it in future requests or make it available to hostile 427 endpoints. The end-to-end confidentiality capabilities discussed in 428 [5] can help reduce risk of exposing sensitive referred-by 429 information to these proxies. The abuse possibilities in subsequent 430 requests by proxies (or endpoints that they may leak information to) 431 between the referee and the refer target are identical to abuse by 432 the referee and the considerations discussed for malicious referee 433 applies. The abuse possibilities in subsequent requests by proxies 434 (or endpoints that they may leak information to) between the referrer 435 and the referee are similar to those discussed for the presentation 436 of Authenticated Identity Bodies in [7]. 438 6.1 Identifying the referee in the Referred-by Token 440 To a refer target, a Referred-By token minimally asserts "The 441 identity expressed by this Referred-By header field asked at the time 442 indicated in this Date header field that the request indicated by 443 this Refer-To header field be sent". This assertion makes no claims 444 at all about who is being asked to send the request. This is 445 sufficient to enable policies such as "Accept any requests referred 446 by Alice", but not "Only accept requests from Bob if he can prove 447 that Alice referred him to us". Thus, there is an opportunity for a 448 cut-and-paste attack. If Mallory sees Alice refer Carol to us using a 449 minimal token, he can copy that token into his own request (as long 450 as it matches what is indicated in the embedded Refer-To header), and 451 it will appear to us that Alice referred Mallory to us. This risk is 452 best mitigated by protecting the REFER Alice sends to Carol from 453 eavesdropping, using TLS or the S/MIME mechanisms detailed in [5]. 455 Including the To header field from the REFER request in the 456 Referred-by token enables the "Only accept requests from Bob if he 457 can prove that Alice referred him to us". Alice is constrained to add 458 this header to the token only if she is sure she is sending the REFER 459 request to Bob. We, in turn, ensure it was Bob that sent the 460 referrenced request to us in addition to validating Alice's signature 461 of the token. Mallory's earlier attack is not effective with this 462 token. 464 Including the To header field in the Referred-By token has privacy 465 implications, however. Carol, above, might wish to contact us 466 anonymously. That wish would be defeated if Carol's identity appeared 467 in the token Alice created. If Alice encrypted the token to us, Carol 468 will not even be aware of the information leak. To protect herself 469 when she wishes anonymity, Carol will have to reject any REFER 470 requests containing a Referred-By token she can not inspect. 472 7. Examples 474 7.1 Basic REFER 476 This example shows the secured Referred-By mechanism applied to a 477 REFER to an SIP INVITE URI. 479 Details are shown only for those messages involved in exercising the 480 mechanism defined in this document. 482 Referrer Referee Refer Target 483 | F1 REFER | | 484 |-------------------------->| | 485 | 202 Accepted | | 486 |<--------------------------| | 487 | NOTIFY | | 488 |<--------------------------| F2 INVITE | 489 | 200 OK |--------------------------->| 490 |-------------------------->| 200 OK | 491 | |<---------------------------| 492 | | ACK | 493 | NOTIFY |--------------------------->| 494 |<--------------------------| | 495 | 200 OK | | 496 |-------------------------->| | 497 | | | 499 F1 REFER sip:referee@referee.example SIP/2.0 500 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842 501 To: sip:referee@referee.example 502 From: sip:referrer@referrer.example;tag=39092342 503 Call-ID: 2203900ef0299349d9209f023a 504 CSeq: 1239930 REFER 505 Max-Forwards: 70 506 Contact: 507 Refer-To: 508 Referred-By: 509 ;cid="20398823.2UWQFN309shb3@referrer.example" 510 Content-Type: multipart/mixed; boundary=unique-boundary-1 511 Content-Length: (appropriate value) 513 --unique-boundary-1 514 Content-Type: multipart/signed; 515 protocol="application/pkcs7-signature"; 516 micalg=sha1; boundary=dragons39 517 Content-ID: <20398823.2UWQFN309shb3@referrer.example> 518 Content-Length: (appropriate value) 520 --dragons39 521 Content-Type: message/sipfrag 522 Content-Disposition: aib; handling=optional 524 Date: Thu, 21 Feb 2002 13:02:03 GMT 525 Refer-To: 526 Referred-By: 527 ;cid="20398823.2UWQFN309shb3@referrer.example" 529 --dragons39 530 Content-Type: application/pkcs7-signature; name=smime.p7s 531 Content-Transfer-Encoding: base64 532 Content-Disposition: attachment; filename=smime.p7s; 533 handling=required 535 (appropriate signature goes here) 537 --dragons39-- 538 --unique-boundary-1-- 540 F2 INVITE sip:refertarget@target.example SIP/2.0 541 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac 542 To: 543 From: ;tag=2909034023 544 Call-ID: fe9023940-a3465@referee.example 545 CSeq: 889823409 INVITE 546 Max-Forwards: 70 547 Contact: 548 Referred-By: 549 ;cid="20398823.2UWQFN309shb3@referrer.example" 550 Content-Type: multipart/mixed; boundary=my-boundary-9 551 Content-Length: (appropriate value) 553 --my-boundary-9 554 Content-Type: application/sdp 555 Content-Length: (appropriate value) 557 v=0 558 o=referee 2890844526 2890844526 IN IP4 referee.example 559 s=Session SDP 560 c=IN IP4 referee.example 561 t=0 0 562 m=audio 49172 RTP/AVP 0 563 a=rtpmap:0 PCMU/8000 565 --my-boundary-9 566 Content-Type: multipart/signed; 567 protocol="application/pkcs7-signature"; 568 micalg=sha1; boundary=dragons39 569 Content-ID: <20398823.2UWQFN309shb3@referrer.example> 570 Content-Length: (appropriate value) 572 --dragons39 573 Content-Type: message/sipfrag 574 Content-Disposition: aib; handling=optional 576 Date: Thu, 21 Feb 2002 13:02:03 GMT 577 Refer-To: 578 Referred-By: 579 ;cid="20398823.2UWQFN309shb3@referrer.example" 581 --dragons39 582 Content-Type: application/pkcs7-signature; name=smime.p7s 583 Content-Transfer-Encoding: base64 584 Content-Disposition: attachment; filename=smime.p7s; 585 handling=required 587 (appropriate signature goes here) 589 --dragons39-- 590 --my-boundary-9-- 592 7.2 Insecure REFER 594 The flow for this example is the same as that of Section 7.1. Here, 595 the referrer has opted to not include a Referred-By token, and the 596 refer target is willing to accept the referenced request without one. 598 F1 REFER sip:referee@referee.example SIP/2.0 599 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842 600 To: 601 From: ;tag=39092342 602 Call-ID: 2203900ef0299349d9209f023a 603 CSeq: 1239930 REFER 604 Max-Forwards: 70 605 Contact: 606 Refer-To: 607 Referred-By: 608 Content-Length: 0 610 F2 INVITE sip:refertarget@target.example SIP/2.0 611 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac 612 To: 613 From: ;tag=2909034023 614 Call-ID: fe9023940-a3465@referee.example 615 CSeq: 889823409 INVITE 616 Max-Forwards: 70 617 Contact: 618 Referred-By: 619 Content-Type: application/sdp 620 Content-Length: (appropriate value) 622 v=0 623 o=referee 2890844526 2890844526 IN IP4 referee.example 624 s=Session SDP 625 c=IN IP4 referee.example 626 t=0 0 627 m=audio 49172 RTP/AVP 0 628 a=rtpmap:0 PCMU/8000 630 7.3 Requiring Referrer Identity 632 In contrast to the example in Section 7.2, the refer target requires 633 a Referred-By token to accept the referenced request. The referrer 634 chooses to provide an encrypted token (note that the block surrounded 635 by asterisks represents encrypted content). F1 and F2 are identical 636 to the messages detailed in Section 7.2. 638 Referrer Referee Refer Target 639 | F1 REFER | | 640 |-------------------------->| | 641 | 202 Accepted | | 642 |<--------------------------| | 643 | NOTIFY | | 644 |<--------------------------| F2 INVITE | 645 | 200 OK |--------------------------->| 646 |-------------------------->| F3 429 Provide Referrer Identity 647 | |<---------------------------| 648 | | ACK | 649 | F4 NOTIFY |--------------------------->| 650 |<--------------------------| | 651 | 200 OK | | 652 |-------------------------->| | 653 | F5 REFER | | 654 |-------------------------->| | 655 | 202 Accepted | | 656 |<--------------------------| | 657 | NOTIFY | | 658 |<--------------------------| F6 INVITE | 659 | 200 OK |--------------------------->| 660 |-------------------------->| 200 OK | 661 | |<---------------------------| 662 | | ACK | 663 | NOTIFY |--------------------------->| 664 |<--------------------------| | 665 | 200 OK | | 666 |-------------------------->| | 667 | | | 669 F3 SIP/2.0 429 Provide Referrer Identity 670 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac 671 To: ;tag=392093422302334 672 From: ;tag=2909034023 673 Call-ID: fe9023940-a3465@referee.example 674 CSeq: 889823409 INVITE 675 Content-Length: 0 677 F4 NOTIFY sip:referrer@referrer.example SIP/2.0 678 Via: SIP/2.0/UDP referee.example;branch=z9hG4bK2934209da390 679 To: ;tag=39092342 680 From: ;tag=199949923 681 Call-ID: 2203900ef0299349d9209f023a 682 CSeq: 3920390 NOTIFY 683 Event: refer;id=1239930 684 Subscription-State: terminated 685 Content-Type: message/sipfrag 686 Content-Length: (appropriate value) 688 SIP/2.0 429 Provide Referrer Identity 690 F5 REFER sip:referee@referee.example SIP/2.0 691 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK98823423 692 To: 693 From: ;tag=39092342 694 Call-ID: 2203900ef0299349d9209f023a 695 CSeq: 1239931 REFER 696 Max-Forwards: 70 697 Contact: 698 Refer-To: 699 Referred-By: 700 ;cid="20342EFXEI.390sdefn2@referrer.example" 701 Content-Type: multipart/mixed; boundary=unique-boundary-1 702 Content-Length: (appropriate value) 704 --unique-boundary-1 705 Content-Type: multipart/signed; 706 protocol="application/pkcs7-signature"; 707 micalg=sha1; boundary=boundary42 708 Content-ID: <20342EFXEI.390sdefn2@referrer.example> 709 Content-Length: (appropriate value) 711 --boundary42 712 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 713 name=smime.p7m 714 Content-Transfer-Encoding: base64 715 Content-Disposition: attachment; filename=smime.p7m 716 handling=required 717 Content-Length: (appropriate value) 719 *********************************************************** 720 * Content-Type: message/sipfrag * 721 * Content-Disposition: aib; handling=optional * 722 * * 723 * Date: Thu, 21 Feb 2002 13:02:03 GMT * 724 * Refer-To: * 725 * Referred-By: * 726 * ;cid="20342EFXEI.390sdefn2@referrer.example" * 727 *********************************************************** 729 --boundary42 730 Content-Type: application/pkcs7-signature; name=smime.p7s 731 Content-Transfer-Encoding: base64 732 Content-Disposition: attachment; filename=smime.p7s; 733 handling=required 735 (appropriate signature) 737 --boundary42-- 739 F6 INVITE sip:refertarget@target.example SIP/2.0 740 Via: SIP/2.0/UDP referee.example;branch=z9hG4bK3920390423 741 To: 742 From: ;tag=1342093482342 743 Call-ID: 23499234-9239842993@referee.example 744 CSeq: 19309423 INVITE 745 Max-Forwards: 70 746 Referred-By: 747 ;cid="20342EFXEI.390sdefn2@referrer.example" 748 Contact: 749 Content-Type: multipart/mixed; boundary=my-boundary-9 750 Content-Length: (appropriate value) 752 --my-boundary-9 753 Content-Type: application/sdp 754 Content-Length: (appropriate value) 756 v=0 757 o=referee 2890844526 2890844526 IN IP4 referee.example 758 s=Session SDP 759 c=IN IP4 referee.example 760 t=0 0 761 m=audio 49172 RTP/AVP 0 762 a=rtpmap:0 PCMU/8000 764 --my-boundary-9 765 Content-Type: multipart/signed; 766 protocol="application/pkcs7-signature"; 767 micalg=sha1; boundary=boundary42 768 Content-ID: <20342EFXEI.390sdefn2@referrer.example> 769 Content-Length: (appropriate value) 771 --boundary42 772 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 773 name=smime.p7m 775 Content-Transfer-Encoding: base64 776 Content-Disposition: attachment; filename=smime.p7m 777 handling=required 778 Content-Length: (appropriate value) 780 *********************************************************** 781 * Content-Type: message/sipfrag * 782 * Content-Disposition: aib; handling=optional * 783 * * 784 * Date: Thu, 21 Feb 2002 13:02:03 GMT * 785 * Refer-To: * 786 * Referred-By: * 787 * ;cid="20342EFXEI.390sdefn2@referrer.example" * 788 *********************************************************** 790 --boundary42 791 Content-Type: application/pkcs7-signature; name=smime.p7s 792 Content-Transfer-Encoding: base64 793 Content-Disposition: attachment; filename=smime.p7s; 794 handling=required 796 (appropriate signature) 798 --boundary42-- 799 --my-boundary-9-- 801 7.4 Nested REFER 803 The Refer-To URI may be a SIP URI indicating the REFER method. 804 Consider The following URI which A uses to refer B to send a REFER 805 request to C which refers C to send an INVITE to D. 807 Note that A provides a Referred-By token which gets passed through B 808 and C to D. In particular, B does not provide its own Referred-By 809 token to C. Also note that A is notified of the outcome of the 810 request it triggered at B (the REFER), not at C (the INVITE). 812 Refer-To: "> 814 This reference would result in the following flow: 816 A B C D 817 | F1 REFER | | | 818 |------------------>| | | 819 | 202 Accepted | | | 820 |<------------------| | | 821 | NOTIFY | | | 822 |<------------------| F2 REFER | | 823 | 200 OK |------------------>| | 824 |------------------>| 202 Accepted | | 825 | F3 NOTIFY |<------------------| | 826 |<------------------| NOTIFY | | 827 | 200 OK |<------------------| F4 INVITE | 828 |------------------>| 200 OK |------------------>| 829 | |------------------>| 200 OK | 830 | | NOTIFY |<------------------| 831 | |<------------------| ACK | 832 | | 200 OK |------------------>| 833 | |------------------>| | 834 | | | | 836 F1 REFER sip:B SIP/2.0 837 Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232 838 To: 839 From: ;tag=23490234 840 Call-ID: 2304098023@A.example 841 CSeq: 2342093 REFER 842 Max-Forwards: 70 843 Contact: 844 Refer-To: .example"> 845 Referred-By: ; 846 cid="23094202342.10123091233@A.example" 847 Content-Type: multipart/mixed; boundary=unique-boundary-1 848 Content-Length: (appropriate value) 850 --unique-boundary-1 851 Content-Type: multipart/signed; 852 protocol="application/pkcs7-signature"; 853 micalg=sha1; boundary=dragons39 854 Content-ID: <23094202342.10123091233@A.example> 855 Content-Length: (appropriate value) 857 --dragons39 858 Content-Type: message/sipfrag 859 Content-Disposition: aib; handling=optional 861 Date: Thu, 21 Feb 2002 13:02:03 GMT 862 Refer-To: "> 863 Referred-By: ; 864 cid="23094202342.10123091233@A.example" 866 --dragons39 867 Content-Type: application/pkcs7-signature; name=smime.p7s 868 Content-Transfer-Encoding: base64 869 Content-Disposition: attachment; filename=smime.p7s; 870 handling=required 872 (appropriate signature goes here) 874 --dragons39-- 875 --unique-boundary-1-- 877 F2 REFER sip:C.example SIP/2.0 878 Via: SIP/2.0/UDP B.example;branch=z9hG4bK00239842 879 To: 880 From: ;tag=2934u23 881 Call-ID: 203942834@B.example 882 CSeq: 8321039 REFER 883 Max-Forwards: 70 884 Contact: 885 Refer-To: 886 Referred-By: ; 887 cid="23094202342.10123091233@A.example" 888 Content-Type: multipart/mixed; boundary=unique-boundary-1 889 Content-Length: (appropriate value) 891 --unique-boundary-1 892 Content-Type: multipart/signed; 893 protocol="application/pkcs7-signature"; 894 micalg=sha1; boundary=dragons39 895 Content-ID: <23094202342.10123091233@A.example> 896 Content-Length: (appropriate value) 898 --dragons39 899 Content-Type: message/sipfrag 900 Content-Disposition: aib; handling=optional 902 Date: Thu, 21 Feb 2002 13:02:03 GMT 903 Refer-To: "> 904 Referred-By: ;cid="23094202342.1012309123@A.example" 906 --dragons39 907 Content-Type: application/pkcs7-signature; name=smime.p7s 908 Content-Transfer-Encoding: base64 909 Content-Disposition: attachment; filename=smime.p7s; 910 handling=required 912 (appropriate signature goes here) 914 --dragons39-- 915 --unique-boundary-1-- 917 F3 NOTIFY sip:A.example SIP/2.0 918 Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232 919 To: ;tag=23490234 920 From: ;tag=5923020 921 Call-ID: 2304098023@A.example 922 CSeq: 29420342 NOTIFY 923 Event: refer;id=2342093 924 Subscription-State: terminated 925 Max-Forwards: 70 926 Contact: 927 Content-Type: message/sipfrag 928 Content-Length: (appropriate value) 930 SIP/2.0 202 Accepted 932 F4 INVITE sip:D.example SIP/2.0 933 Via: SIP/2.0/UDP C.example;branch=z9hG4bK29348234 934 To: 935 From: ;tag=023942334 936 Call-ID: 23489020352@C.example 937 CSeq: 1230934 INVITE 938 Max-Forwards: 70 939 Contact: 940 Referred-By: ; 941 cid="23094202342.10123091233@A.example" 942 Content-Type: multipart/mixed; boundary=unique-boundary-1 943 Content-Length: (appropriate value) 945 --unique-boundary-1 946 Content-Type: application/sdp 947 Content-Length: (appropriate value) 949 v=0 950 o=C 2890844526 2890844526 IN IP4 C.example 951 s=Session SDP 952 c=IN IP4 C.example 953 t=0 0 954 m=audio 49172 RTP/AVP 0 955 a=rtpmap:0 PCMU/8000 957 --unique-boundary-1 958 Content-Type: multipart/signed; 959 protocol="application/pkcs7-signature"; 960 micalg=sha1; boundary=dragons39 961 Content-ID: <23094202342.10123091233@A.example> 962 Content-Length: (appropriate value) 964 --dragons39 965 Content-Type: message/sipfrag 966 Content-Disposition: aib; handling=optional 968 Date: Thu, 21 Feb 2002 13:02:03 GMT 969 Refer-To: "> 970 Referred-By: ; 971 cid="23094202342.1012309123@A.example" 973 --dragons39 974 Content-Type: application/pkcs7-signature; name=smime.p7s 975 Content-Transfer-Encoding: base64 976 Content-Disposition: attachment; filename=smime.p7s; 977 handling=required 979 (appropriate signature goes here) 981 --dragons39-- 982 --unique-boundary-1-- 984 8. IANA Considerations 986 (Note to RFC Editor: Please fill in all occurrences of XXXX in this 987 section with the RFC number of this specification). 989 This document defines a new SIP header field name with a compact form 990 (Referred-By and b respectively). It also defines an new SIP client 991 error response code (429). 993 The following changes should be made to http:///www.iana.org/ 994 assignments/sip-parameters 996 The following row should be added to the header field section 997 (replacing any existing row for Referred-By). 999 Header Name Compact Form Reference 1000 Referred-By b [RFCXXXX] 1002 The following row should be added to the response code section under 1003 the Request Failure 4xx heading 1005 429 Provide Referrer Identity [RFCXXXX] 1007 9. Contributors 1009 Rohan Mahy distilled RFC2822's msg-id into this document's definition 1010 of sip-clean-msg-id. 1012 Normative References 1014 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1015 Levels", BCP 14, RFC 2119, March 1997. 1017 [2] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1018 Method", RFC 3515, April 2003. 1020 [3] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 1021 draft-ietf-sip-authid-body-02 (work in progress), July 2003. 1023 [4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 1024 November 2002. 1026 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1027 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1028 Session Initiation Protocol", RFC 3261, June 2002. 1030 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1031 Extensions (MIME) Part One: Format of Internet Message Bodies", 1032 RFC 2045, November 1996. 1034 Informative References 1036 [7] Peterson, J., "Enhancements for Authenticated Identity 1037 Management in the Session Initiation Protocol (SIP)", 1038 draft-ietf-sip-identity-01 (work in progress), March 2003. 1040 [8] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1041 Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in 1042 progress), February 2003. 1044 [9] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 1046 Author's Address 1048 Robert J. Sparks 1049 dynamicsoft 1050 5100 Tennyson Parkway 1051 Suite 1200 1052 Plano, TX 75024 1054 EMail: rsparks@dynamicsoft.com 1056 Intellectual Property Statement 1058 The IETF takes no position regarding the validity or scope of any 1059 intellectual property or other rights that might be claimed to 1060 pertain to the implementation or use of the technology described in 1061 this document or the extent to which any license under such rights 1062 might or might not be available; neither does it represent that it 1063 has made any effort to identify any such rights. Information on the 1064 IETF's procedures with respect to rights in standards-track and 1065 standards-related documentation can be found in BCP-11. Copies of 1066 claims of rights made available for publication and any assurances of 1067 licenses to be made available, or the result of an attempt made to 1068 obtain a general license or permission for the use of such 1069 proprietary rights by implementors or users of this specification can 1070 be obtained from the IETF Secretariat. 1072 The IETF invites any interested party to bring to its attention any 1073 copyrights, patents or patent applications, or other proprietary 1074 rights which may cover technology that may be required to practice 1075 this standard. Please address the information to the IETF Executive 1076 Director. 1078 Full Copyright Statement 1080 Copyright (C) The Internet Society (2004). All Rights Reserved. 1082 This document and translations of it may be copied and furnished to 1083 others, and derivative works that comment on or otherwise explain it 1084 or assist in its implementation may be prepared, copied, published 1085 and distributed, in whole or in part, without restriction of any 1086 kind, provided that the above copyright notice and this paragraph are 1087 included on all such copies and derivative works. However, this 1088 document itself may not be modified in any way, such as by removing 1089 the copyright notice or references to the Internet Society or other 1090 Internet organizations, except as needed for the purpose of 1091 developing Internet standards in which case the procedures for 1092 copyrights defined in the Internet Standards process must be 1093 followed, or as required to translate it into languages other than 1094 English. 1096 The limited permissions granted above are perpetual and will not be 1097 revoked by the Internet Society or its successors or assignees. 1099 This document and the information contained herein is provided on an 1100 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1101 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1102 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1103 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1104 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1106 Acknowledgment 1108 Funding for the RFC Editor function is currently provided by the 1109 Internet Society.