idnits 2.17.1 draft-ietf-sip-referredby-03.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 158: '...est (a referrer) MAY provide a Referre...' RFC 2119 keyword, line 159: '...est. A REFER request MUST NOT contain...' RFC 2119 keyword, line 162: '... A referrer MAY include a Referred-B...' RFC 2119 keyword, line 163: '...eferred-By token MUST contain a Referr...' RFC 2119 keyword, line 178: '... containing a 429, it MAY submit a new...' (29 more instances...) 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 (August 6, 2003) is 7567 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 1004 == 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. '8') (Obsoleted by RFC 5322) Summary: 3 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: February 4, 2004 August 6, 2003 6 The SIP Referred-By Mechanism 7 draft-ietf-sip-referredby-03 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 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on February 4, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 The SIP REFER method provides a mechanism where one party (the 39 referrer) gives a second party (the referee) an arbitrary URI to 40 reference. If that URI is a SIP URI, the referee will send a SIP 41 request, often an INVITE, to that URI (the refer target). This 42 document extends the REFER method allowing the referrer to provide 43 information about the REFER request to the refer target using the 44 referee as an intermediary. This information includes the identity 45 of the referrer and the URI to which the referrer referred. The 46 mechanism utilizes S/MIME to help protect this information from a 47 malicious intermediary. This protection is optional, but a recipient 48 may refuse to accept a request unless it is present. 50 Table of Contents 52 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 8 59 4.1 Refer target inspection of a Referred-By token . . . . . . . . 8 60 5. The 429 Provide Referrer Identity error response . . . . . . . 9 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 6.1 Identifying the referee in the Referred-by Token . . . . . . . 11 63 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 7.1 Basic REFER . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7.2 Insecure REFER . . . . . . . . . . . . . . . . . . . . . . . . 14 66 7.3 Requiring Referrer Identity . . . . . . . . . . . . . . . . . 15 67 7.4 Nested REFER . . . . . . . . . . . . . . . . . . . . . . . . . 19 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 69 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 70 Normative References . . . . . . . . . . . . . . . . . . . . . 23 71 Informative References . . . . . . . . . . . . . . . . . . . . 24 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24 73 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25 75 1. Overview 77 The SIP REFER method [1] 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 [1] distinguishes this referenced request from any other 82 request the referee might have sent to the refer target. 84 --------------------------------------------------------------------- 86 Referrer Referee Refer Target 87 | | | 88 | REFER | | 89 | Refer-To: target | | 90 |----------------->| INVITE target | 91 | |------------------->| 93 Classic REFER 95 --------------------------------------------------------------------- 97 There are applications of REFER, such as call transfer [7], where it 98 is desirable to provide the refer target with certain information 99 about the referrer and the REFER request itself. This information 100 may include, but is not limited to, the referrer's identity, the 101 referred to URI, and the time of the referral. The refer target can 102 use this information when deciding whether to admit the referenced 103 request. This draft defines one set of mechanisms to provide that 104 information. 106 All of the mechanisms in this draft involve placing information in 107 the REFER request that the referee copies into the referenced 108 request. This necessarily establishes the referee as an eavesdropper 109 and places the referee in a position to launch man-in-the-middle 110 attacks on that information. 112 At the simplest level, this draft defines a mechanism for carrying 113 the referrer's identity, expressed as a SIP URI in a new header: 114 Referred-By. The refer target can use that information, even if it 115 has not been protected from the referee, at the perils and with the 116 limitations documented here. The draft proceeds to define an S/MIME 117 based mechanism for expressing the identity of the referrer and 118 capturing other information about the REFER request, allowing the 119 refer target to detect tampering (and other undesirable behaviors) by 120 the referee. 122 2. The Referred-By Mechanism 124 The following figure summarizes how Referred-By information is 125 carried to the Refer Target. The Referrer provides a Referred-By 126 header with its SIP address-of-record, optionally associating an S/ 127 MIME protected token reflecting the identity of the referrer and 128 details of the REFER request. The Referee copies this header and the 129 token, if provided, into the triggered request (shown here as an 130 INVITE). 132 --------------------------------------------------------------------- 134 Referrer Referee Refer Target 135 | | | 136 | REFER | | 137 | Refer-To: target | | 138 | Referred-By: referrer;cid=X | | 139 | | | 140 | (one of the body parts is) | | 141 | Content-ID: X | | 142 | | | 143 |----------------------------->| | 144 | | INVITE target | 145 | | Referred-By: referrer;cid=X | 146 | | | 147 | | (one of the body parts is) | 148 | | Content-ID: X | 149 | | | 150 | |---------------------------->| 152 REFER with Referred-By 154 --------------------------------------------------------------------- 156 2.1 Referrer behavior 158 A UA sending a REFER request (a referrer) MAY provide a Referred-By 159 header field value in the request. A REFER request MUST NOT contain 160 more than one Referred-By header field value. 162 A referrer MAY include a Referred-By token in a REFER request. A 163 REFER request containing a Referred-By token MUST contain a Referred- 164 By header field value with a cid parameter value equal to the 165 Content-ID of the body part containing the token. 167 The referrer will receive a NOTIFY with a message/sipfrag [3] body 168 indicating a final response of 429 "Provide Referrer Identity" to the 169 referenced request if the refer target requires a valid Referred-By 170 token to accept the request. This can occur when either no token is 171 provided or a provided token is invalid. 173 The referrer will receive a 429 "Provide Referrer Identity" response 174 to the REFER if the referee requires a Referred-By token to be 175 present in order to accept the REFER. 177 If a referrer wishes to reattempt to refer a referee after receiving 178 a 429 response or a NOTIFY containing a 429, it MAY submit a new 179 REFER request containing a Referred-By token. 181 2.2 Referee behavior 183 A UA accepting a REFER request (a referee) to a SIP URI (using either 184 the sip: or sips: scheme) MUST copy any Referred-By header field 185 value and token into the referenced request without modification. 187 A referee MAY reject a REFER request that does not contain a 188 Referred-By token with a 429 "Provide Referrer Identity" response. A 189 referee SHOULD NOT reject a request that contains a Referred-By token 190 encrypted to a key it does not possess. Note that per [2] the 191 referee should still be able to verify the signature of such an 192 encrypted token. 194 A referee SHOULD present the same identity to the referrer and the 195 refer target. 197 2.3 Refer Target behavior 199 A UA receiving a non-REFER SIP request MAY inspect the request for a 200 Referred-By header field and token. 202 If a Referred-By header field value is not present, this UA can not 203 distinguish this request from any other the UA acting as the referee 204 might have sent. Thus, the UA would apply exactly the admissions 205 policies and processing described in [4] to the request. 207 If a Referred-By header field value is present, the receiving UA can 208 consider itself a refer target and MAY apply additional admission 209 policies based on the contents of the Referred-By header field and 210 token. 212 The referee is in a position to modify the contents of the Referred- 213 By header field value, or falsely provide one even if no REFER 214 actually exists. If such behavior could affect admission policy 215 (including influencing the agent's user by rendering misleading 216 content), the refer target SHOULD require that a valid Referred-By 217 token be present. 219 The refer target MAY reject a request if no Referred-By token is 220 present or if the token is stale using the 429 "Provide Referrer 221 Identity" error response defined in Section 5. The 428 error 222 response from [6] is not appropriate for this purpose - it is needed 223 for the refer target to request an authentication token from the 224 referee. 226 If no Referred-By token is present, the refer target MAY proceed with 227 processing the request. If the agent provides any information from 228 the Referred-By header to its user as part of processing the request, 229 it MUST notify the user that the information is suspect. 231 The refer target MUST reject an otherwise well-formed request with an 232 invalid Referred-By token (see Section 4) with a 429 error response. 234 3. The Referred-By Header Field 236 Referred-By is a request header field as defined by [4]. It can 237 appear in any request. It carries a SIP URI representing the 238 identity of the referrer and, optionally, the Content-ID of a body 239 part (the Referred-By token) that provides a more secure statement of 240 that identity. 242 --------------------------------------------------------------------- 244 Referred-By = ("Referred-By" / "b") HCOLON referrer-uri 245 *( SEMI (referredby-id-param / generic-param) ) 247 referrer-uri = ( name-addr / addr-spec ) 249 referredby-id-param = "cid" EQUAL sip-clean-msg-id 251 sip-clean-msg-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT 253 dot-atom = atom *( "." atom ) 255 atom = 1*( alphanum / "-" / "!" / "%" / "*" / 256 "_" / "+" / "'" / "`" / "~" ) 258 Referred-By Syntax 260 --------------------------------------------------------------------- 262 Since the Content-ID appears as a SIP header parameter value which 263 must conform to the expansion of gen-value defined in [4], this 264 grammar produces values in the intersection of the expansions of gen- 265 value and msg-id from [8]. The double-quotes surrounding the sip- 266 clean-msg-id MUST be replaced with left and right angle brackets to 267 derive the Content-ID used in the message's MIME body. For example, 269 Referred-By: sip:r@ref.example;cid="2UWQFN309shb3@ref.example" 270 indicates the token is in the body part containing 271 Content-ID: <2UWQFN309shb3@ref.example> 273 The Referred-By header field MAY appear in any SIP request, but is 274 meaningless for ACK and CANCEL. Proxies do not need to be able to 275 read Referred-By header field values and MUST NOT remove or modify 276 them. 278 The following row should be interpreted as if it appeared in Table 3 279 of RFC 3261. 281 Header field where proxy ACK BYE CAN INV OPT REG 282 ___________________________________________________________________ 283 Referred-By R - o - o o o 285 4. The Referred-By Token 287 The Referred-By token is an Authenticated Identity Body as defined by 288 [2]. This body part MUST be identified with a MIME [5] Content-ID: 289 field. 291 The sipfrag inside a Referred-By token MUST contain copies of the 292 Refer-To, Referred-By, and Date header fields from the REFER request. 294 The token SHOULD NOT contain the Call-ID header field from the REFER 295 request as that information is not useful to the refer target and may 296 even be an information leak. The token SHOULD NOT contain the From 297 header field from the REFER request since the identity being claimed 298 is represented in the Referred-By header field. 300 The token MAY contain the To header field from the REFER request, but 301 it SHOULD NOT be included unless the referrer has cryptographically 302 identified the referee. Some ways this authentication can be 303 achieved include inspecting the certificates used in a TLS 304 association between the referrer and the referee or encrypting the 305 Refer-To header in the REFER request using the S/MIME encryption 306 techniques detailed in [4]. Including the To header field 307 significantly strengthens the claim being asserted by the token, but 308 may have privacy implications as discussed in Section 6.1. 310 Additional header fields and body parts MAY be included in the token. 312 As described in [2], a Referred-By token MAY be encrypted as well as 313 signed. The subjectAltName of the certificate used for these 314 operations SHOULD exactly match the identity claimed in the referrer- 315 uri in the Referred-By header field in the token. 317 4.1 Refer target inspection of a Referred-By token 319 A refer target MUST treat a Referred-By token with an invalid 320 signature as an invalid token. A target SHOULD treat a token with an 321 aged Date header field value as invalid. 323 A target SHOULD verify that the request it receives matches the 324 reference in the Refer-To header field in the token. This 325 verification SHOULD include at least the request method and any 326 indicated end-to-end header field values. Note that the URI in the 327 Refer-To header field may not match the request URI in the received 328 request due to request retargetting between the referee and the refer 329 target. 331 The target SHOULD verify that the identity in the Referred-By header 332 field in the token exactly matches the SubjectAltName from the 333 signing certificate, reporting discrepancies to its user as described 334 in [2]. 336 If the token contains a To header field, the target SHOULD verify 337 that the identity it expresses matches the referrer. One way of 338 verifying this is to exactly match the identity in the token's To 339 header field with the subjectAltName of the certificate used by the 340 referee to sign the aib protecting the request itself. The 428 341 response defined in [6] can be used to request such an aib if one is 342 not already present. 344 5. The 429 Provide Referrer Identity error response 346 The 429 client error response code is used by a refer target to 347 indicate that the referee must provide a valid Referred-By token. As 348 discussed in the behavior section, the referee will forward this 349 error response to the referrer in a NOTIFY as the result of the 350 REFER. The suggested text phrase for the 429 error response is 351 "Provide Referrer Identity". 353 6. Security Considerations 355 This mechanism defined in this specification relies on an 356 intermediary (the referee) to forward information from the referrer 357 to the refer target. This necessarily establishes the referee as an 358 eavesdropper of that information and positions him perfectly to 359 launch man-in-the-middle attacks using the mechanism. 361 A SIP proxy is similarly positioned. Protecting SIP messaging from 362 malicious proxy implementations is discussed in [4]. In contrast to 363 a proxy, the referee's agent is an endpoint. Proxies will typically 364 be managed and monitored by service providers. Malicious behavior by 365 a proxy is more likely to be noticed and result in negative 366 repercussions for the provider than malicious behavior by an endpoint 367 would be. The behavior of an endpoint can be entirely under the 368 control of a single user. Thus, it is more feasible for an endpoint 369 acting as referee to behave maliciously than it is for a proxy being 370 operated by a service provider. 372 This specification uses an S/MIME based mechanism to enable the refer 373 target to detect manipulation of the Referred-By information by the 374 referee. Use of this protection is optional! The community has 375 asserted that there are systems where trust in the validity of this 376 information is either not important or can be established through 377 other means. Any implementation choosing not to use this optional 378 mechanism needs to provide its own defense to the following risks: 380 o The Referred-By information is highly likely to influence request 381 admission policy. For instance, it may be displayed to the user 382 of the agent with a "This call was transferred to you by X. 383 Accept?" prompt. A malicious referee can unduly influence that 384 policy decision by providing falsified referred-by information. 385 This includes falsely claiming to have been referred in the first 386 place. (The S/MIME mechanism protects the information with a 387 signature, hampering the referee's ability to inject or modify 388 information without knowing the key used for that signature). 390 o A referee is by definition an eavesdropper of the referred-by 391 information. Parts of that information may be sensitive. (The S/ 392 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 [4]. Thus the referee gains no new influence over processing logic 406 at 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 [4]. 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 [4] 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 [6]. 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 449 a 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 [4]. 455 Including the To header field from the REFER request in the Referred- 456 by token enables the "Only accept requests from Bob if he can prove 457 that Alice referred him to us". Alice is constrained to add this 458 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 467 appeared in the token Alice created. If Alice encrypted the token to 468 us, Carol will not even be aware of the information leak. To protect 469 herself when she wishes anonymity, Carol will have to reject any 470 REFER requests containing a Referred-By token she can not inspect. 472 7. Examples 473 7.1 Basic REFER 475 This example shows the secured Referred-By mechanism applied to a 476 REFER to an SIP INVITE URI. 478 Details are shown only for those messages involved in exercising the 479 mechanism defined in this document. 481 Referrer Referee Refer Target 482 | F1 REFER | | 483 |-------------------------->| | 484 | 202 Accepted | | 485 |<--------------------------| | 486 | NOTIFY | | 487 |<--------------------------| F2 INVITE | 488 | 200 OK |--------------------------->| 489 |-------------------------->| 200 OK | 490 | |<---------------------------| 491 | | ACK | 492 | NOTIFY |--------------------------->| 493 |<--------------------------| | 494 | 200 OK | | 495 |-------------------------->| | 496 | | | 498 F1 REFER sip:referee@referee.example SIP/2.0 499 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842 500 To: sip:referee@referee.example 501 From: sip:referrer@referrer.example;tag=39092342 502 Call-ID: 2203900ef0299349d9209f023a 503 CSeq: 1239930 REFER 504 Max-Forwards: 70 505 Contact: 506 Refer-To: 507 Referred-By: 508 ;cid="20398823.2UWQFN309shb3@referrer.example" 509 Content-Type: multipart/mixed; boundary=unique-boundary-1 510 Content-Length: (appropriate value) 512 --unique-boundary-1 513 Content-Type: multipart/signed; 514 protocol="application/pkcs7-signature"; 515 micalg=sha1; boundary=dragons39 516 Content-ID: <20398823.2UWQFN309shb3@referrer.example> 517 Content-Length: (appropriate value) 519 --dragons39 520 Content-Type: message/sipfrag 521 Content-Disposition: aib; handling=optional 523 Date: Thu, 21 Feb 2002 13:02:03 GMT 524 Refer-To: 525 Referred-By: 526 ;cid="20398823.2UWQFN309shb3@referrer.example" 528 --dragons39 529 Content-Type: application/pkcs7-signature; name=smime.p7s 530 Content-Transfer-Encoding: base64 531 Content-Disposition: attachment; filename=smime.p7s; 532 handling=required 534 (appropriate signature goes here) 536 --dragons39-- 537 --unique-boundary-1-- 539 F2 INVITE sip:refertarget@target.example SIP/2.0 540 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac 541 To: 542 From: ;tag=2909034023 543 Call-ID: fe9023940-a3465@referee.example 544 CSeq: 889823409 INVITE 545 Max-Forwards: 70 546 Contact: 547 Referred-By: 548 ;cid="20398823.2UWQFN309shb3@referrer.example" 549 Content-Type: multipart/mixed; boundary=my-boundary-9 550 Content-Length: (appropriate value) 552 --my-boundary-9 553 Content-Type: application/sdp 554 Content-Length: (appropriate value) 556 v=0 557 o=referee 2890844526 2890844526 IN IP4 referee.example 558 s=Session SDP 559 c=IN IP4 referee.example 560 t=0 0 561 m=audio 49172 RTP/AVP 0 562 a=rtpmap:0 PCMU/8000 564 --my-boundary-9 565 Content-Type: multipart/signed; 566 protocol="application/pkcs7-signature"; 567 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 774 Content-Transfer-Encoding: base64 775 Content-Disposition: attachment; filename=smime.p7m 776 handling=required 777 Content-Length: (appropriate value) 779 *********************************************************** 780 * Content-Type: message/sipfrag * 781 * Content-Disposition: aib; handling=optional * 782 * * 783 * Date: Thu, 21 Feb 2002 13:02:03 GMT * 784 * Refer-To: * 785 * Referred-By: * 786 * ;cid="20342EFXEI.390sdefn2@referrer.example" * 787 *********************************************************** 789 --boundary42 790 Content-Type: application/pkcs7-signature; name=smime.p7s 791 Content-Transfer-Encoding: base64 792 Content-Disposition: attachment; filename=smime.p7s; 793 handling=required 795 (appropriate signature) 797 --boundary42-- 798 --my-boundary-9-- 800 7.4 Nested REFER 802 The Refer-To URI may be a SIP URI indicating the REFER method. 803 Consider The following URI which A uses to refer B to send a REFER 804 request to C which refers C to send an INVITE to D. 806 Note that A provides a Referred-By token which gets passed through B 807 and C to D. In particular, B does not provide its own Referred-By 808 token to C. Also note that A is notified of the outcome of the 809 request it triggered at B (the REFER), not at C (the INVITE). 811 Refer-To: "> 813 This reference would result in the following flow: 815 A B C D 816 | F1 REFER | | | 817 |------------------>| | | 818 | 202 Accepted | | | 819 |<------------------| | | 820 | NOTIFY | | | 821 |<------------------| F2 REFER | | 822 | 200 OK |------------------>| | 823 |------------------>| 202 Accepted | | 824 | F3 NOTIFY |<------------------| | 825 |<------------------| NOTIFY | | 826 | 200 OK |<------------------| F4 INVITE | 827 |------------------>| 200 OK |------------------>| 828 | |------------------>| 200 OK | 829 | | NOTIFY |<------------------| 830 | |<------------------| ACK | 831 | | 200 OK |------------------>| 832 | |------------------>| | 833 | | | | 835 F1 REFER sip:B SIP/2.0 836 Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232 837 To: 838 From: ;tag=23490234 839 Call-ID: 2304098023@A.example 840 CSeq: 2342093 REFER 841 Max-Forwards: 70 842 Contact: 843 Refer-To: .example"> 844 Referred-By: ; 845 cid="23094202342.10123091233@A.example" 846 Content-Type: multipart/mixed; boundary=unique-boundary-1 847 Content-Length: (appropriate value) 849 --unique-boundary-1 850 Content-Type: multipart/signed; 851 protocol="application/pkcs7-signature"; 852 micalg=sha1; boundary=dragons39 853 Content-ID: <23094202342.10123091233@A.example> 854 Content-Length: (appropriate value) 856 --dragons39 857 Content-Type: message/sipfrag 858 Content-Disposition: aib; handling=optional 860 Date: Thu, 21 Feb 2002 13:02:03 GMT 861 Refer-To: "> 862 Referred-By: ; 863 cid="23094202342.10123091233@A.example" 865 --dragons39 866 Content-Type: application/pkcs7-signature; name=smime.p7s 867 Content-Transfer-Encoding: base64 868 Content-Disposition: attachment; filename=smime.p7s; 869 handling=required 871 (appropriate signature goes here) 873 --dragons39-- 874 --unique-boundary-1-- 876 F2 REFER sip:C.example SIP/2.0 877 Via: SIP/2.0/UDP B.example;branch=z9hG4bK00239842 878 To: 879 From: ;tag=2934u23 880 Call-ID: 203942834@B.example 881 CSeq: 8321039 REFER 882 Max-Forwards: 70 883 Contact: 884 Refer-To: 885 Referred-By: ; 886 cid="23094202342.10123091233@A.example" 887 Content-Type: multipart/mixed; boundary=unique-boundary-1 888 Content-Length: (appropriate value) 890 --unique-boundary-1 891 Content-Type: multipart/signed; 892 protocol="application/pkcs7-signature"; 893 micalg=sha1; boundary=dragons39 894 Content-ID: <23094202342.10123091233@A.example> 895 Content-Length: (appropriate value) 897 --dragons39 898 Content-Type: message/sipfrag 899 Content-Disposition: aib; handling=optional 901 Date: Thu, 21 Feb 2002 13:02:03 GMT 902 Refer-To: "> 903 Referred-By: ;cid="23094202342.1012309123@A.example" 905 --dragons39 906 Content-Type: application/pkcs7-signature; name=smime.p7s 907 Content-Transfer-Encoding: base64 908 Content-Disposition: attachment; filename=smime.p7s; 909 handling=required 911 (appropriate signature goes here) 913 --dragons39-- 914 --unique-boundary-1-- 916 F3 NOTIFY sip:A.example SIP/2.0 917 Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232 918 To: ;tag=23490234 919 From: ;tag=5923020 920 Call-ID: 2304098023@A.example 921 CSeq: 29420342 NOTIFY 922 Event: refer;id=2342093 923 Subscription-State: terminated 924 Max-Forwards: 70 925 Contact: 926 Content-Type: message/sipfrag 927 Content-Length: (appropriate value) 929 SIP/2.0 202 Accepted 931 F4 INVITE sip:D.example SIP/2.0 932 Via: SIP/2.0/UDP C.example;branch=z9hG4bK29348234 933 To: 934 From: ;tag=023942334 935 Call-ID: 23489020352@C.example 936 CSeq: 1230934 INVITE 937 Max-Forwards: 70 938 Contact: 939 Referred-By: ; 940 cid="23094202342.10123091233@A.example" 941 Content-Type: multipart/mixed; boundary=unique-boundary-1 942 Content-Length: (appropriate value) 944 --unique-boundary-1 945 Content-Type: application/sdp 946 Content-Length: (appropriate value) 948 v=0 949 o=C 2890844526 2890844526 IN IP4 C.example 950 s=Session SDP 951 c=IN IP4 C.example 952 t=0 0 953 m=audio 49172 RTP/AVP 0 954 a=rtpmap:0 PCMU/8000 956 --unique-boundary-1 957 Content-Type: multipart/signed; 958 protocol="application/pkcs7-signature"; 959 micalg=sha1; boundary=dragons39 960 Content-ID: <23094202342.10123091233@A.example> 961 Content-Length: (appropriate value) 963 --dragons39 964 Content-Type: message/sipfrag 965 Content-Disposition: aib; handling=optional 967 Date: Thu, 21 Feb 2002 13:02:03 GMT 968 Refer-To: "> 969 Referred-By: ; 970 cid="23094202342.1012309123@A.example" 972 --dragons39 973 Content-Type: application/pkcs7-signature; name=smime.p7s 974 Content-Transfer-Encoding: base64 975 Content-Disposition: attachment; filename=smime.p7s; 976 handling=required 978 (appropriate signature goes here) 980 --dragons39-- 981 --unique-boundary-1-- 983 8. IANA Considerations 985 (Note to RFC Editor: Please fill in all occurrences of XXXX in this 986 section with the RFC number of this specification). 988 This document defines a new SIP header field name with a compact form 989 (Referred-By and b respectively). It also defines an new SIP client 990 error response code (429). 992 The following changes should be made to http:///www.iana.org/ 993 assignments/sip-parameters 995 The following row should be added to the header field section 996 (replacing any existing row for Referred-By). 998 Header Name Compact Form Reference 999 Referred-By b [RFCXXXX] 1001 The following row should be added to the response code section under 1002 the Request Failure 4xx heading 1004 429 Provide Referrer Identity [RFCXXXX] 1006 9. Contributors 1008 Rohan Mahy distilled RFC2822's msg-id into this document's definition 1009 of sip-clean-msg-id. 1011 Normative References 1013 [1] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1014 Method", RFC 3515, April 2003. 1016 [2] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 1017 draft-ietf-sip-authid-body-02 (work in progress), July 2003. 1019 [3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 1020 November 2002. 1022 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1023 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1024 Session Initiation Protocol", RFC 3261, June 2002. 1026 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1027 Extensions (MIME) Part One: Format of Internet Message Bodies", 1028 RFC 2045, November 1996. 1030 Informative References 1032 [6] Peterson, J., "Enhancements for Authenticated Identity 1033 Management in the Session Initiation Protocol (SIP)", draft- 1034 ietf-sip-identity-01 (work in progress), March 2003. 1036 [7] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1037 Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in 1038 progress), February 2003. 1040 [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 1042 Author's Address 1044 Robert J. Sparks 1045 dynamicsoft 1046 5100 Tennyson Parkway 1047 Suite 1200 1048 Plano, TX 75024 1050 EMail: rsparks@dynamicsoft.com 1052 Full Copyright Statement 1054 Copyright (C) The Internet Society (2003). All Rights Reserved. 1056 This document and translations of it may be copied and furnished to 1057 others, and derivative works that comment on or otherwise explain it 1058 or assist in its implementation may be prepared, copied, published 1059 and distributed, in whole or in part, without restriction of any 1060 kind, provided that the above copyright notice and this paragraph are 1061 included on all such copies and derivative works. However, this 1062 document itself may not be modified in any way, such as by removing 1063 the copyright notice or references to the Internet Society or other 1064 Internet organizations, except as needed for the purpose of 1065 developing Internet standards in which case the procedures for 1066 copyrights defined in the Internet Standards process must be 1067 followed, or as required to translate it into languages other than 1068 English. 1070 The limited permissions granted above are perpetual and will not be 1071 revoked by the Internet Society or its successors or assigns. 1073 This document and the information contained herein is provided on an 1074 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1075 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1076 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1077 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1078 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1080 Acknowledgement 1082 Funding for the RFC Editor function is currently provided by the 1083 Internet Society.