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