idnits 2.17.1 draft-ietf-sip-referredby-02.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 159: '...est (a referrer) MAY provide a Referre...' RFC 2119 keyword, line 160: '...est. A REFER request MUST NOT contain...' RFC 2119 keyword, line 163: '... A referrer MAY include a Referred-B...' RFC 2119 keyword, line 164: '...eferred-By token MUST contain a Referr...' RFC 2119 keyword, line 179: '... containing a 429, it MAY submit a new...' (28 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 (June 18, 2003) is 7618 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 1002 == Outdated reference: A later version (-03) exists of draft-ietf-sip-authid-body-00 == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-00 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-00 -- 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: December 17, 2003 June 18, 2003 6 The SIP Referred-By Mechanism 7 draft-ietf-sip-referredby-02 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 December 17, 2003. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 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. Changes from -01 . . . . . . . . . . . . . . . . . . . . . . . 23 70 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 71 Normative References . . . . . . . . . . . . . . . . . . . . . 24 72 Informative References . . . . . . . . . . . . . . . . . . . . 24 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25 74 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26 76 1. Overview 78 The SIP REFER method [1] provides a mechanism where one party (the 79 referrer) provides a second party (the referee) with an arbitrary URI 80 to reference. If that URI is a SIP URI, the referee will send a SIP 81 request, often an INVITE, to that URI (the refer target). Nothing 82 provided in [1] distinguishes this referenced request from any other 83 request the referee might have sent to the refer target. 85 --------------------------------------------------------------------- 87 Referrer Referee Refer Target 88 | | | 89 | REFER | | 90 | Refer-To: target | | 91 |----------------->| INVITE target | 92 | |------------------->| 94 Classic REFER 96 --------------------------------------------------------------------- 98 There are applications of REFER, such as call transfer [7], where it 99 is desirable to provide the refer target with certain information 100 about the referrer and the REFER request itself. This information 101 may include, but is not limited to, the referrer's identity, the 102 referred to URI, and the time of the referral. The refer target can 103 use this information when deciding whether to admit the referenced 104 request. This draft defines one set of mechanisms to provide that 105 information. 107 All of the mechanisms in this draft involve placing information in 108 the REFER request that the referee copies into the referenced 109 request. This necessarily establishes the referee as an eavesdropper 110 and places the referee in a position to launch man-in-the-middle 111 attacks on that information. 113 At the simplest level, this draft defines a mechanism for carrying 114 the referrer's identity, expressed as a SIP URI in a new header: 115 Referred-By. The refer target can use that information, even if it 116 has not been protected from the referee, at the perils and with the 117 limitations documented here. The draft proceeds to define an S/MIME 118 based mechanism for expressing the identity of the referrer and 119 capturing other information about the REFER request, allowing the 120 refer target to detect tampering (and other undesirable behaviors) by 121 the referee. 123 2. The Referred-By Mechanism 125 The following figure summarizes how Referred-By information is 126 carried to the Refer Target. The Referrer provides a Referred-By 127 header with its SIP address-of-record, optionally associating an S/ 128 MIME protected token reflecting the identity of the referrer and 129 details of the REFER request. The Referee copies this header and the 130 token, if provided, into the triggered request (shown here as an 131 INVITE). 133 --------------------------------------------------------------------- 135 Referrer Referee Refer Target 136 | | | 137 | REFER | | 138 | Refer-To: target | | 139 | Referred-By: referrer;cid=X | | 140 | | | 141 | (one of the body parts is) | | 142 | Content-ID: X | | 143 | | | 144 |----------------------------->| | 145 | | INVITE target | 146 | | Referred-By: referrer;cid=X | 147 | | | 148 | | (one of the body parts is) | 149 | | Content-ID: X | 150 | | | 151 | |---------------------------->| 153 REFER with Referred-By 155 --------------------------------------------------------------------- 157 2.1 Referrer behavior 159 A UA sending a REFER request (a referrer) MAY provide a Referred-By 160 header field value in the request. A REFER request MUST NOT contain 161 more than one Referred-By header field value. 163 A referrer MAY include a Referred-By token in a REFER request. A 164 REFER request containing a Referred-By token MUST contain a Referred- 165 By header field value with a cid parameter value equal to the 166 Content-ID of the body part containing the token. 168 The referrer will receive a NOTIFY with a message/sipfrag [3] body 169 indicating a final response of 429 "Provide Referrer Identity" to the 170 referenced request if the refer target requires a valid Referred-By 171 token to accept the request. This can occur when either no token is 172 provided or a provided token is invalid. 174 The referrer will receive a 429 "Provide Referrer Identity" response 175 to the REFER if the referee requires a Referred-By token to be 176 present in order to accept the REFER. 178 If a referrer wishes to reattempt to refer a referee after receiving 179 a 429 response or a NOTIFY containing a 429, it MAY submit a new 180 REFER request containing a Referred-By token. 182 2.2 Referee behavior 184 A UA accepting a REFER request (a referee) to a SIP URI (using either 185 the sip: or sips: scheme) MUST copy any Referred-By header field 186 value and token into the referenced request without modification. 188 A referee MAY reject a REFER request that does not contain a 189 Referred-By token with a 429 "Provide Referrer Identity" response. A 190 referee SHOULD NOT reject a request that contains a Referred-By token 191 encrypted to a key it does not possess. Note that per [2] the 192 referee should still be able to verify the signature of such an 193 encrypted token. 195 A referee SHOULD present the same identity to the referrer and the 196 refer target. 198 2.3 Refer Target behavior 200 A UA receiving a non-REFER SIP request MAY inspect the request for a 201 Referred-By header field and token. 203 If a Referred-By header field value is not present, this UA can not 204 distinguish this request from any other the UA acting as the referee 205 might have sent. Thus, the UA would apply exactly the admissions 206 policies and processing described in [4] to the request. 208 If a Referred-By header field value is present, the receiving UA can 209 consider itself a refer target and MAY apply additional admission 210 policies based on the contents of the Referred-By header field and 211 token. 213 The referee is in a position to modify the contents of the Referred- 214 By header field value, or falsely provide one even if no REFER 215 actually exists. If such behavior could affect admission policy 216 (including influencing the agent's user by rendering misleading 217 content), the refer target SHOULD require that a valid Referred-By 218 token be present. 220 The refer target MAY reject a request if no Referred-By token is 221 present or if the token is stale using the 429 "Provide Referrer 222 Identity" error response defined in Section 5. The 428 error 223 response from [6] is not appropriate for this purpose - it is needed 224 for the refer target to request an authentication token from the 225 referee. 227 If no Referred-By token is present, the refer target MAY proceed with 228 processing the request. If the agent provides any information from 229 the Referred-By header to its user as part of processing the request, 230 it MUST notify the user that the information is suspect. 232 The refer target MUST reject an otherwise well-formed request with an 233 invalid Referred-By token (see Section 4) with a 429 error response. 235 3. The Referred-By Header Field 237 Referred-By is a request header field as defined by [4]. It can 238 appear in any request. It carries a SIP URI representing the 239 identity of the referrer and, optionally, the Content-ID of a body 240 part (the Referred-By token) that provides a more secure statement of 241 that identity. 243 --------------------------------------------------------------------- 245 Referred-By = ("Referred-By" / "b") HCOLON referrer-uri 246 *( SEMI (referredby-id-param / generic-param) ) 248 referrer-uri = ( name-addr / addr-spec ) 250 referredby-id-param = "cid" EQUAL sip-clean-msg-id 252 sip-clean-msg-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT 254 dot-atom = atom *( "." atom ) 256 atom = 1*( alphanum / "-" / "!" / "%" / "*" / 257 "_" / "+" / "'" / "`" / "~" ) 259 Referred-By Syntax 261 --------------------------------------------------------------------- 263 Since the Content-ID appears as a SIP header parameter value which 264 must conform to the expansion of gen-value defined in [4], this 265 grammar produces values in the intersection of the expansions of gen- 266 value and msg-id from [8]. The double-quotes surrounding the sip- 267 clean-msg-id MUST be replaced with left and right angle brackets to 268 derive the Content-ID used in the message's MIME body. For example, 270 Referred-By: sip:r@ref.example;cid="2UWQFN309shb3@ref.example" 271 indicates the token is in the body part containing 272 Content-ID: <2UWQFN309shb3@ref.example> 274 The Referred-By header field MAY appear in any SIP request, but is 275 meaningless for ACK and CANCEL. Proxies do not need to be able to 276 read Referred-By header field values and MUST NOT remove or modify 277 them. 279 The following row should be interpreted as if it appeared in Table 3 280 of RFC 3261. 282 Header field where proxy ACK BYE CAN INV OPT REG 283 ___________________________________________________________________ 284 Referred-By R - o - o o o 286 4. The Referred-By Token 288 The Referred-By token is an Authenticated Identity Body as defined by 289 [2]. This body part MUST be identified with a MIME [5] Content-ID: 290 field. 292 The sipfrag inside a Referred-By token MUST contain copies of the 293 Refer-To, Referred-By, and Date header fields from the REFER request. 295 The token SHOULD NOT contain the Call-ID header field from the REFER 296 request as that information is not useful to the refer target and may 297 even be an information leak. The token SHOULD NOT contain the From 298 header field from the REFER request since the identity being claimed 299 is represented in the Referred-By header field. 301 The token MAY contain the To header field from the REFER request, but 302 it SHOULD NOT be included unless the referrer has cryptographically 303 identified the referee. Some ways this authentication can be 304 achieved include inspecting the certificates used in a TLS 305 association between the referrer and the referee or encrypting the 306 Refer-To header in the REFER request using the S/MIME encryption 307 techniques detailed in [4]. Including the To header field 308 significantly strengthens the claim being asserted by the token, but 309 may have privacy implications as discussed in Section 6.1. 311 Additional header fields and body parts MAY be included in the token. 313 As described in [2], a Referred-By token MAY be encrypted as well as 314 signed. The subjectAltName of the certificate used for these 315 operations SHOULD exactly match the identity claimed in the referrer- 316 uri in the Referred-By header field in the token. 318 4.1 Refer target inspection of a Referred-By token 320 A refer target MUST treat a Referred-By token with an invalid 321 signature as an invalid token. A target SHOULD treat a token with an 322 aged Date header field value as invalid. 324 A target SHOULD verify that the request it receives matches the 325 reference in the Refer-To header field in the token. Note that the 326 URI in that header field may not match the request URI in the 327 received request due to request retargetting between the referee and 328 the refer target. 330 The target SHOULD verify that the identity in the Referred-By header 331 field in the token exactly matches the SubjectAltName from the 332 signing certificate, reporting discrepancies to its user as described 333 in [2]. 335 If the token contains a To header field, the target SHOULD verify 336 that the identity it expresses matches the referrer. One way of 337 verifying this is to exactly match the identity in the token's To 338 header field with the subjectAltName of the certificate used by the 339 referee to sign the aib protecting the request itself. The 428 340 response defined in [6] can be used to request such an aib if one is 341 not already present. 343 5. The 429 Provide Referrer Identity error response 345 The 429 client error response code is used by a refer target to 346 indicate that the referee must provide a valid Referred-By token. As 347 discussed in the behavior section, the referee will forward this 348 error response to the referrer in a NOTIFY as the result of the 349 REFER. The suggested text phrase for the 429 error response is 350 "Provide Referrer Identity". 352 6. Security Considerations 354 This mechanism defined in this specification relies on an 355 intermediary (the referee) to forward information from the referrer 356 to the refer target. This necessarily establishes the referee as an 357 eavesdropper of that information and positions him perfectly to 358 launch man-in-the-middle attacks using the mechanism. 360 A SIP proxy is similarly positioned. Protecting SIP messaging from 361 malicious proxy implementations is discussed in [4]. In contrast to 362 a proxy, the referee's agent is an endpoint. Proxies will typically 363 be managed and monitored by service providers. Malicious behavior by 364 a proxy is more likely to be noticed and result in negative 365 repercussions for the provider than malicious behavior by an endpoint 366 would be. The behavior of an endpoint can be entirely under the 367 control of a single user. Thus, it is more feasible for an endpoint 368 acting as referee to behave maliciously than it is for a proxy being 369 operated by a service provider. 371 This specification uses an S/MIME based mechanism to enable the refer 372 target to detect manipulation of the Referred-By information by the 373 referee. Use of this protection is optional! The community has 374 asserted that there are systems where trust in the validity of this 375 information is either not important or can be established through 376 other means. Any implementation choosing not to use this optional 377 mechanism needs to provide its own defense to the following risks: 379 o The Referred-By information is highly likely to influence request 380 admission policy. For instance, it may be displayed to the user 381 of the agent with a "This call was transferred to you by X. 382 Accept?" prompt. A malicious referee can unduly influence that 383 policy decision by providing falsified referred-by information. 384 This includes falsely claiming to have been referred in the first 385 place. (The S/MIME mechanism protects the information with a 386 signature, hampering the referee's ability to inject or modify 387 information without knowing the key used for that signature). 389 o A referee is by definition an eavesdropper of the referred-by 390 information. Parts of that information may be sensitive. (The S/ 391 MIME mechanism allows encryption). 393 o The referee may store any referred-by information it sees and 394 paste it into future unrelated requests. (The S/MIME mechanism 395 allows detection of stale assertions by covering a timestamp with 396 the signature and allows detection of use in unrelated requests by 397 covering the Refer-To header field with the signature). 399 The mechanisms in this specification do NOT prevent the referee from 400 deleting ALL referred-by information from the referenced request. A 401 refer target can not detect such deletion. This introduces no new 402 problems since removing all referred-by information from a referenced 403 request transforms it into an ordinary SIP request as described in 404 [4]. Thus the referee gains no new influence over processing logic 405 at the refer target by removing the referred-by information. 407 Refer targets can protect themselves from the possibility that a 408 malicious referee removed a token (leaving an unsecured identity in 409 the Referred-By header field) by using the 429 error response. 411 Applications using the mechanisms in this draft may be able to take 412 advantage of pre-existing relationships between the participants to 413 mitigate the risks of its use. In some transfer scenarios, A has the 414 choice of referring B to C or referring C to B. If A and B have a 415 pre-existing trust relationship leading A to have greater confidence 416 that B will not behave maliciously (B is A's administrative assistant 417 for example), referring B to C may make more sense. 419 This mechanism involves two SIP requests between three endpoints, the 420 REFER and the referenced request. The content of those messages 421 (including the referred-by information) is subject to the security 422 considerations and protection mechanisms documented in [4]. 424 Proxies between the participants may collect referred-by information 425 and reinsert it in future requests or make it available to hostile 426 endpoints. The end-to-end confidentiality capabilities discussed in 427 [4] can help reduce risk of exposing sensitive referred-by 428 information to these proxies. The abuse possibilities in subsequent 429 requests by proxies (or endpoints that they may leak information to) 430 between the referee and the refer target are identical to abuse by 431 the referee and the considerations discussed for malicious referee 432 applies. The abuse possibilities in subsequent requests by proxies 433 (or endpoints that they may leak information to) between the referrer 434 and the referee are similar to those discussed for the presentation 435 of Authenticated Identity Bodies in [6]. 437 6.1 Identifying the referee in the Referred-by Token 439 To a refer target, a Referred-By token minimally asserts "The 440 identity expressed by this Referred-By header field asked at the time 441 indicated in this Date header field that the request indicated by 442 this Refer-To header field be sent". This assertion makes no claims 443 at all about who is being asked to send the request. This is 444 sufficient to enable policies such as "Accept any requests referred 445 by Alice", but not "Only accept requests from Bob if he can prove 446 that Alice referred him to us". Thus, there is an opportunity for a 447 cut-and-paste attack. If Mallory sees Alice refer Carol to us using 448 a minimal token, he can copy that token into his own request (as long 449 as it matches what is indicated in the embedded Refer-To header), and 450 it will appear to us that Alice referred Mallory to us. This risk is 451 best mitigated by protecting the REFER Alice sends to Carol from 452 eavesdropping, using TLS or the S/MIME mechanisms detailed in [4]. 454 Including the To header field from the REFER request in the Referred- 455 by token enables the "Only accept requests from Bob if he can prove 456 that Alice referred him to us". Alice is constrained to add this 457 header to the token only if she is sure she is sending the REFER 458 request to Bob. We, in turn, ensure it was Bob that sent the 459 referrenced request to us in addition to validating Alice's signature 460 of the token. Mallory's earlier attack is not effective with this 461 token. 463 Including the To header field in the Referred-By token has privacy 464 implications, however. Carol, above, might wish to contact us 465 anonymously. That wish would be defeated if Carol's identity 466 appeared in the token Alice created. If Alice encrypted the token to 467 us, Carol will not even be aware of the information leak. To protect 468 herself when she wishes anonymity, Carol will have to reject any 469 REFER requests containing a Referred-By token she can not inspect. 471 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 568 Content-ID: <20398823.2UWQFN309shb3@referrer.example> 569 Content-Length: (appropriate value) 571 --dragons39 572 Content-Type: message/sipfrag 573 Content-Disposition: aib; handling=optional 574 Date: Thu, 21 Feb 2002 13:02:03 GMT 575 Refer-To: 576 Referred-By: 577 ;cid="20398823.2UWQFN309shb3@referrer.example" 579 --dragons39 580 Content-Type: application/pkcs7-signature; name=smime.p7s 581 Content-Transfer-Encoding: base64 582 Content-Disposition: attachment; filename=smime.p7s; 583 handling=required 585 (appropriate signature goes here) 587 --dragons39-- 588 --my-boundary-9-- 590 7.2 Insecure REFER 592 The flow for this example is the same as that of Section 7.1. Here, 593 the referrer has opted to not include a Referred-By token, and the 594 refer target is willing to accept the referenced request without one. 596 F1 REFER sip:referee@referee.example SIP/2.0 597 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842 598 To: 599 From: ;tag=39092342 600 Call-ID: 2203900ef0299349d9209f023a 601 CSeq: 1239930 REFER 602 Max-Forwards: 70 603 Contact: 604 Refer-To: 605 Referred-By: 606 Content-Length: 0 608 F2 INVITE sip:refertarget@target.example SIP/2.0 609 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac 610 To: 611 From: ;tag=2909034023 612 Call-ID: fe9023940-a3465@referee.example 613 CSeq: 889823409 INVITE 614 Max-Forwards: 70 615 Contact: 616 Referred-By: 617 Content-Type: application/sdp 618 Content-Length: (appropriate value) 620 v=0 621 o=referee 2890844526 2890844526 IN IP4 referee.example 622 s=Session SDP 623 c=IN IP4 referee.example 624 t=0 0 625 m=audio 49172 RTP/AVP 0 626 a=rtpmap:0 PCMU/8000 628 7.3 Requiring Referrer Identity 630 In contrast to the example in Section 7.2, the refer target requires 631 a Referred-By token to accept the referenced request. The referrer 632 chooses to provide an encrypted token (note that the block surrounded 633 by asterisks represents encrypted content). F1 and F2 are identical 634 to the messages detailed in Section 7.2. 636 Referrer Referee Refer Target 637 | F1 REFER | | 638 |-------------------------->| | 639 | 202 Accepted | | 640 |<--------------------------| | 641 | NOTIFY | | 642 |<--------------------------| F2 INVITE | 643 | 200 OK |--------------------------->| 644 |-------------------------->| F3 429 Provide Referrer Identity 645 | |<---------------------------| 646 | | ACK | 647 | F4 NOTIFY |--------------------------->| 648 |<--------------------------| | 649 | 200 OK | | 650 |-------------------------->| | 651 | F5 REFER | | 652 |-------------------------->| | 653 | 202 Accepted | | 654 |<--------------------------| | 655 | NOTIFY | | 656 |<--------------------------| F6 INVITE | 657 | 200 OK |--------------------------->| 658 |-------------------------->| 200 OK | 659 | |<---------------------------| 660 | | ACK | 661 | NOTIFY |--------------------------->| 662 |<--------------------------| | 663 | 200 OK | | 664 |-------------------------->| | 665 | | | 667 F3 SIP/2.0 429 Provide Referrer Identity 668 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac 669 To: ;tag=392093422302334 670 From: ;tag=2909034023 671 Call-ID: fe9023940-a3465@referee.example 672 CSeq: 889823409 INVITE 673 Content-Length: 0 675 F4 NOTIFY sip:referrer@referrer.example SIP/2.0 676 Via: SIP/2.0/UDP referee.example;branch=z9hG4bK2934209da390 677 To: ;tag=39092342 678 From: ;tag=199949923 679 Call-ID: 2203900ef0299349d9209f023a 680 CSeq: 3920390 NOTIFY 681 Event: refer;id=1239930 682 Subscription-State: terminated 683 Content-Type: message/sipfrag 684 Content-Length: (appropriate value) 686 SIP/2.0 429 Provide Referrer Identity 688 F5 REFER sip:referee@referee.example SIP/2.0 689 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK98823423 690 To: 691 From: ;tag=39092342 692 Call-ID: 2203900ef0299349d9209f023a 693 CSeq: 1239931 REFER 694 Max-Forwards: 70 695 Contact: 696 Refer-To: 697 Referred-By: 698 ;cid="20342EFXEI.390sdefn2@referrer.example" 699 Content-Type: multipart/mixed; boundary=unique-boundary-1 700 Content-Length: (appropriate value) 702 --unique-boundary-1 703 Content-Type: multipart/signed; 704 protocol="application/pkcs7-signature"; 705 micalg=sha1; boundary=boundary42 706 Content-ID: <20342EFXEI.390sdefn2@referrer.example> 707 Content-Length: (appropriate value) 709 --boundary42 710 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 711 name=smime.p7m 712 Content-Transfer-Encoding: base64 713 Content-Disposition: attachment; filename=smime.p7m 714 handling=required 715 Content-Length: (appropriate value) 717 *********************************************************** 718 * Content-Type: message/sipfrag * 719 * Content-Disposition: aib; handling=optional * 720 * * 721 * Date: Thu, 21 Feb 2002 13:02:03 GMT * 722 * Refer-To: * 723 * Referred-By: * 724 * ;cid="20342EFXEI.390sdefn2@referrer.example" * 725 *********************************************************** 727 --boundary42 728 Content-Type: application/pkcs7-signature; name=smime.p7s 729 Content-Transfer-Encoding: base64 730 Content-Disposition: attachment; filename=smime.p7s; 731 handling=required 733 (appropriate signature) 735 --boundary42-- 737 F6 INVITE sip:refertarget@target.example SIP/2.0 738 Via: SIP/2.0/UDP referee.example;branch=z9hG4bK3920390423 739 To: 740 From: ;tag=1342093482342 741 Call-ID: 23499234-9239842993@referee.example 742 CSeq: 19309423 INVITE 743 Max-Forwards: 70 744 Referred-By: 745 ;cid="20342EFXEI.390sdefn2@referrer.example" 746 Contact: 747 Content-Type: multipart/mixed; boundary=my-boundary-9 748 Content-Length: (appropriate value) 750 --my-boundary-9 751 Content-Type: application/sdp 752 Content-Length: (appropriate value) 754 v=0 755 o=referee 2890844526 2890844526 IN IP4 referee.example 756 s=Session SDP 757 c=IN IP4 referee.example 758 t=0 0 759 m=audio 49172 RTP/AVP 0 760 a=rtpmap:0 PCMU/8000 762 --my-boundary-9 763 Content-Type: multipart/signed; 764 protocol="application/pkcs7-signature"; 765 micalg=sha1; boundary=boundary42 766 Content-ID: <20342EFXEI.390sdefn2@referrer.example> 767 Content-Length: (appropriate value) 769 --boundary42 770 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 771 name=smime.p7m 772 Content-Transfer-Encoding: base64 773 Content-Disposition: attachment; filename=smime.p7m 774 handling=required 775 Content-Length: (appropriate value) 777 *********************************************************** 778 * Content-Type: message/sipfrag * 779 * Content-Disposition: aib; handling=optional * 780 * * 781 * Date: Thu, 21 Feb 2002 13:02:03 GMT * 782 * Refer-To: * 783 * Referred-By: * 784 * ;cid="20342EFXEI.390sdefn2@referrer.example" * 785 *********************************************************** 787 --boundary42 788 Content-Type: application/pkcs7-signature; name=smime.p7s 789 Content-Transfer-Encoding: base64 790 Content-Disposition: attachment; filename=smime.p7s; 791 handling=required 793 (appropriate signature) 795 --boundary42-- 796 --my-boundary-9-- 798 7.4 Nested REFER 800 The Refer-To URI may be a SIP URI indicating the REFER method. 801 Consider The following URI which A uses to refer B to send a REFER 802 request to C which refers C to send an INVITE to D. 804 Note that A provides a Referred-By token which gets passed through B 805 and C to D. In particular, B does not provide its own Referred-By 806 token to C. Also note that A is notified of the outcome of the 807 request it triggered at B (the REFER), not at C (the INVITE). 809 Refer-To: "> 811 This reference would result in the following flow: 813 A B C D 814 | F1 REFER | | | 815 |------------------>| | | 816 | 202 Accepted | | | 817 |<------------------| | | 818 | NOTIFY | | | 819 |<------------------| F2 REFER | | 820 | 200 OK |------------------>| | 821 |------------------>| 202 Accepted | | 822 | F3 NOTIFY |<------------------| | 823 |<------------------| NOTIFY | | 824 | 200 OK |<------------------| F4 INVITE | 825 |------------------>| 200 OK |------------------>| 826 | |------------------>| 200 OK | 827 | | NOTIFY |<------------------| 828 | |<------------------| ACK | 829 | | 200 OK |------------------>| 830 | |------------------>| | 831 | | | | 833 F1 REFER sip:B SIP/2.0 834 Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232 835 To: 836 From: ;tag=23490234 837 Call-ID: 2304098023@A.example 838 CSeq: 2342093 REFER 839 Max-Forwards: 70 840 Contact: 841 Refer-To: .example"> 842 Referred-By: ; 843 cid="23094202342.10123091233@A.example" 844 Content-Type: multipart/mixed; boundary=unique-boundary-1 845 Content-Length: (appropriate value) 847 --unique-boundary-1 848 Content-Type: multipart/signed; 849 protocol="application/pkcs7-signature"; 850 micalg=sha1; boundary=dragons39 851 Content-ID: <23094202342.10123091233@A.example> 852 Content-Length: (appropriate value) 854 --dragons39 855 Content-Type: message/sipfrag 856 Content-Disposition: aib; handling=optional 858 Date: Thu, 21 Feb 2002 13:02:03 GMT 859 Refer-To: "> 860 Referred-By: ; 861 cid="23094202342.10123091233@A.example" 863 --dragons39 864 Content-Type: application/pkcs7-signature; name=smime.p7s 865 Content-Transfer-Encoding: base64 866 Content-Disposition: attachment; filename=smime.p7s; 867 handling=required 869 (appropriate signature goes here) 871 --dragons39-- 872 --unique-boundary-1-- 874 F2 REFER sip:C.example SIP/2.0 875 Via: SIP/2.0/UDP B.example;branch=z9hG4bK00239842 876 To: 877 From: ;tag=2934u23 878 Call-ID: 203942834@B.example 879 CSeq: 8321039 REFER 880 Max-Forwards: 70 881 Contact: 882 Refer-To: 883 Referred-By: ; 884 cid="23094202342.10123091233@A.example" 885 Content-Type: multipart/mixed; boundary=unique-boundary-1 886 Content-Length: (appropriate value) 888 --unique-boundary-1 889 Content-Type: multipart/signed; 890 protocol="application/pkcs7-signature"; 891 micalg=sha1; boundary=dragons39 892 Content-ID: <23094202342.10123091233@A.example> 893 Content-Length: (appropriate value) 895 --dragons39 896 Content-Type: message/sipfrag 897 Content-Disposition: aib; handling=optional 899 Date: Thu, 21 Feb 2002 13:02:03 GMT 900 Refer-To: "> 901 Referred-By: ;cid="23094202342.1012309123@A.example" 903 --dragons39 904 Content-Type: application/pkcs7-signature; name=smime.p7s 905 Content-Transfer-Encoding: base64 906 Content-Disposition: attachment; filename=smime.p7s; 907 handling=required 909 (appropriate signature goes here) 911 --dragons39-- 912 --unique-boundary-1-- 914 F3 NOTIFY sip:A.example SIP/2.0 915 Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232 916 To: ;tag=23490234 917 From: ;tag=5923020 918 Call-ID: 2304098023@A.example 919 CSeq: 29420342 NOTIFY 920 Event: refer;id=2342093 921 Subscription-State: terminated 922 Max-Forwards: 70 923 Contact: 924 Content-Type: message/sipfrag 925 Content-Length: (appropriate value) 927 SIP/2.0 202 Accepted 929 F4 INVITE sip:D.example SIP/2.0 930 Via: SIP/2.0/UDP C.example;branch=z9hG4bK29348234 931 To: 932 From: ;tag=023942334 933 Call-ID: 23489020352@C.example 934 CSeq: 1230934 INVITE 935 Max-Forwards: 70 936 Contact: 937 Referred-By: ; 938 cid="23094202342.10123091233@A.example" 939 Content-Type: multipart/mixed; boundary=unique-boundary-1 940 Content-Length: (appropriate value) 942 --unique-boundary-1 943 Content-Type: application/sdp 944 Content-Length: (appropriate value) 946 v=0 947 o=C 2890844526 2890844526 IN IP4 C.example 948 s=Session SDP 949 c=IN IP4 C.example 950 t=0 0 951 m=audio 49172 RTP/AVP 0 952 a=rtpmap:0 PCMU/8000 954 --unique-boundary-1 955 Content-Type: multipart/signed; 956 protocol="application/pkcs7-signature"; 957 micalg=sha1; boundary=dragons39 958 Content-ID: <23094202342.10123091233@A.example> 959 Content-Length: (appropriate value) 961 --dragons39 962 Content-Type: message/sipfrag 963 Content-Disposition: aib; handling=optional 965 Date: Thu, 21 Feb 2002 13:02:03 GMT 966 Refer-To: "> 967 Referred-By: ; 968 cid="23094202342.1012309123@A.example" 970 --dragons39 971 Content-Type: application/pkcs7-signature; name=smime.p7s 972 Content-Transfer-Encoding: base64 973 Content-Disposition: attachment; filename=smime.p7s; 974 handling=required 976 (appropriate signature goes here) 978 --dragons39-- 979 --unique-boundary-1-- 981 8. IANA Considerations 983 (Note to RFC Editor: Please fill in all occurrences of XXXX in this 984 section with the RFC number of this specification). 986 This document defines a new SIP header field name with a compact form 987 (Referred-By and b respectively). It also defines an new SIP client 988 error response code (429). 990 The following changes should be made to http:///www.iana.org/ 991 assignments/sip-parameters 993 The following row should be added to the header field section 994 (replacing any existing row for Referred-By). 996 Header Name Compact Form Reference 997 Referred-By b [RFCXXXX] 999 The following row should be added to the response code section under 1000 the Request Failure 4xx heading 1002 429 Provide Referrer Identity [RFCXXXX] 1004 9. Changes from -01 1006 o Resolved open issue: Call-ID is no longer included in the token. 1008 o Resolved open issue: Removed From from the token, and required 1009 subjAltName to align with the Referred-By header field value 1011 o Resolved open issue: Added requirements and discussion for 1012 including To in the token to identify who the referrer believes 1013 the referee to be. 1015 o Finished the definition of the msg-id token (now sip-clean-msg-id) 1016 in the grammar. 1018 o Moved sip-identity to the Informative References section 1020 o Updated references 1022 10. Contributors 1024 Rohan Mahy distilled RFC2822's msg-id into this document's definition 1025 of sip-clean-msg-id. 1027 Normative References 1029 [1] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1030 Method", RFC 3515, April 2003. 1032 [2] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 1033 draft-ietf-sip-authid-body-00 (work in progress), October 2002. 1035 [3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 1036 November 2002. 1038 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1039 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1040 Session Initiation Protocol", RFC 3261, June 2002. 1042 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1043 Extensions (MIME) Part One: Format of Internet Message Bodies", 1044 RFC 2045, November 1996. 1046 Informative References 1048 [6] Peterson, J., "Enhancements for Authenticated Identity 1049 Management in the Session Initiation Protocol (SIP)", draft- 1050 ietf-sip-identity-00 (work in progress), October 2002. 1052 [7] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1053 Control - Transfer", draft-ietf-sipping-cc-transfer-00 (work in 1054 progress), October 2002. 1056 [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 1058 Author's Address 1060 Robert J. Sparks 1061 dynamicsoft 1062 5100 Tennyson Parkway 1063 Suite 1200 1064 Plano, TX 75024 1066 EMail: rsparks@dynamicsoft.com 1068 Full Copyright Statement 1070 Copyright (C) The Internet Society (2003). All Rights Reserved. 1072 This document and translations of it may be copied and furnished to 1073 others, and derivative works that comment on or otherwise explain it 1074 or assist in its implementation may be prepared, copied, published 1075 and distributed, in whole or in part, without restriction of any 1076 kind, provided that the above copyright notice and this paragraph are 1077 included on all such copies and derivative works. However, this 1078 document itself may not be modified in any way, such as by removing 1079 the copyright notice or references to the Internet Society or other 1080 Internet organizations, except as needed for the purpose of 1081 developing Internet standards in which case the procedures for 1082 copyrights defined in the Internet Standards process must be 1083 followed, or as required to translate it into languages other than 1084 English. 1086 The limited permissions granted above are perpetual and will not be 1087 revoked by the Internet Society or its successors or assigns. 1089 This document and the information contained herein is provided on an 1090 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1091 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1092 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1093 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1094 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1096 Acknowledgement 1098 Funding for the RFC Editor function is currently provided by the 1099 Internet Society.