idnits 2.17.1 draft-ietf-sip-referredby-01.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 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 180: '...or sips: scheme) MUST copy any Referre...' (19 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 (February 12, 2003) is 7741 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 974 == Unused Reference: '3' is defined on line 1024, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-00 == Outdated reference: A later version (-03) exists of draft-ietf-sip-authid-body-00 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-00 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 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: August 13, 2003 February 12, 2003 6 The SIP Referred-By Mechanism 7 draft-ietf-sip-referredby-01 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 August 13, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 The SIP REFER method [2] provides a mechanism where one party (the 39 referrer) gives a second party (the referree) an arbitrary URI to 40 reference. If that URI is a SIP URI, the referree 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 reference to the refer target using the 44 referree 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 Referree behavior . . . . . . . . . . . . . . . . . . . . . . 5 56 2.3 Refer Target behavior . . . . . . . . . . . . . . . . . . . . 5 57 3. The Referred-By Header Field . . . . . . . . . . . . . . . . . 6 58 4. The Referred-By Token . . . . . . . . . . . . . . . . . . . . 7 59 4.1 Refer target inspection of a Referred-By token . . . . . . . . 7 60 5. The 429 Provide Referrer Identity error response . . . . . . . 8 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 7.1 Basic REFER . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 7.2 Insecure REFER . . . . . . . . . . . . . . . . . . . . . . . . 13 65 7.3 Requiring Referrer Identity . . . . . . . . . . . . . . . . . 13 66 7.4 Nested REFER . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 68 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22 69 10. Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . 22 70 Normative References . . . . . . . . . . . . . . . . . . . . . 23 71 Informative References . . . . . . . . . . . . . . . . . . . . 23 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23 73 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24 75 1. Overview 77 The SIP REFER method [2] provides a mechanism where one party (the 78 referrer) provides a second party (the referree) with an arbitrary 79 URI to reference. If that URI is a SIP URI, the referree will send a 80 SIP request, often an INVITE, to that URI (the refer target). 81 Nothing provided in [2] distinguishes this referenced request from 82 any other request the referree might have sent to the refer target. 84 --------------------------------------------------------------------- 86 Referrer Referree 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 referree 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 referree, 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 referree. 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 Referree copies this header and 129 the token, if provided, into the triggered request (shown here as an 130 INVITE). 132 --------------------------------------------------------------------- 134 Referrer Referree 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 sipfrag indicating a final 168 response of 429 "Provide Referrer Identity" to the referenced request 169 if the refer target requires a valid Referred-By token to accept the 170 request. The can occur when either no token is provided or a 171 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 2.2 Referree behavior 179 A UA receiving a REFER request (a referree) to a SIP URI (using 180 either the sip: or sips: scheme) MUST copy any Referred-By header 181 field value and token into the referenced request without 182 modification. 184 A referree MAY reject a REFER request that does not contain a 185 Referred-By token with a 429 "Provide Referrer Identity" response. A 186 referree SHOULD NOT reject a request that contains a Referred-By 187 token encrypted to a key it does not possess. Note that per [5] the 188 referee should still be able to verify the signature of such an 189 encrypted token. 191 2.3 Refer Target behavior 193 A UA receiving a non-REFER SIP request MAY inspect the request for a 194 Referred-By header field and token. 196 If a Referred-By header field value is not present, this UA can not 197 distinguish this request from any other the UA acting as the referree 198 might have sent. Thus, the UA would apply exactly the admissions 199 policies and processing described in [1] to the request. 201 If a Referred-By header field value is present, the receiving UA can 202 consider itself a refer target and MAY apply additional admission 203 policies based on the contents of the Referred-By header field and 204 token. 206 The referee is in a position to modify the contents of the Referred- 207 By header field value, or falsely provide one even if no REFER 208 actually exists. If such behavior could affect admission policy 209 (including influencing the agent's user by rendering misleading 210 content), the refer target SHOULD require that a valid Referred-By 211 token be present. 213 The refer target MAY reject a request if no Referred-By token is 214 present or if the token is stale using the 429 "Provide Referrer 215 Identity" error response defined in Section 5. The 428 error 216 response from [4] is not appropriate for this purpose - it is needed 217 for the refer target to request an authentication token from the 218 referee. 220 If no Referred-By token is present, the refer target MAY proceed with 221 processing the request. If the agent provides any information from 222 the Referred-By header to its user as part of processing the request, 223 it MUST notify the user that the information is suspect. 225 The refer target MUST reject an otherwise well-formed request with an 226 invalid Referred-By token (see Section 4) with a 429 error response. 228 3. The Referred-By Header Field 230 Referred-By is a request header field as defined by [1]. It can 231 appear in any request. It carries a SIP URI representing the 232 identity of the referrer and, optionally, the Content-ID of a body 233 part (the Referred-By token) that provides a more secure statement of 234 that identity. 236 --------------------------------------------------------------------- 238 Referred-By = ("Referred-By" / "b") HCOLON referrer-uri 239 *( SEMI (referredby-id-param / generic-param) ) 241 referrer-uri = ( name-addr / addr-spec ) 243 referredby-id-param = "cid" EQUAL msg-id 245 msg-id = TO BE INCORPORATED from rfc2822 (at great pain) 247 Referred-By Syntax 249 --------------------------------------------------------------------- 251 The Referred-By header field MAY appear in any SIP request, but is 252 meaningless for ACK and CANCEL. Proxies do not need to be able to 253 read Referred-By header field values and MUST NOT remove or modify 254 them. 256 The following row should be interpreted as if it appeared in Table 3 257 of RFC 3261. 259 Header field where proxy ACK BYE CAN INV OPT REG 260 ___________________________________________________________________ 261 Referred-By R - o - o o o 263 4. The Referred-By Token 265 The Referred-By token is an Authenticated Identity Body as defined by 266 [5]. This body part MUST be identified with a MIME [6] Content-ID: 267 field. 269 In addition to the From, Date, and Call-ID header fields required by 270 [5], the sipfrag inside a Referred-By token MUST contain copies of 271 the Refer-To and Referred-By header fields from the REFER request. 272 As in [5] additional header fields and body parts MAY be included. 274 OPEN ISSUE: The Call-ID header from the referrer will not be 275 useful to the refer target. It can even be argued that including 276 it leaks information to the refer target that it should not get to 277 see. Should we require that this field be populated with a 278 minimal, meaningless constant value? 280 As described in [5], a Referred-By token MAY be encrypted as well as 281 signed. 283 4.1 Refer target inspection of a Referred-By token 285 (Editor's note: This section is new, replacing and modifying text 286 that was removed from sip-identity. Please review it carefully.) 288 A refer target MUST treat a Referred-By token with an invalid 289 signature as an invalid token. A target SHOULD treat a token with an 290 aged Date header field value as invalid. 292 A target SHOULD verify that the request it receives matches the 293 reference in the Refer-To header field in the token. Note that the 294 URI in that header field may not match the request URI in the 295 received request due to request retargetting between the referree and 296 the refer target. 298 The target SHOULD verify that the identity in the From header field 299 in the token exactly matches the SubjectAltName from the signing 300 certificate. 302 OPEN ISSUE: [5] suggests this check with a non-normative "should". 303 Can we expect a referrer to always have a certificate that matches 304 whatever From header field value it happened to be using in the 305 middle of a call? Is From even the right field to be looking at? 306 The referrer may need to provide a different identity to the refer 307 target than it provides to the referee. Should we be basing this 308 on the Referred-By header field instead? If no, then we should 309 remove Referred-By from the token. If yes, is there any value in 310 including real information in the From field, or should we 311 recommend using a minimal, meaningless constant value. 313 OPEN ISSUE: Can the target make any meaningful use of the To 314 header field in the token? This value could quite reasonably have 315 no relation to the identity that the referree presents to the 316 refer target. Is it appropriate to restrict the referree to reuse 317 the To value from the original dialog (helpdesk@example.com 318 perhaps) as the From in the referenced request? Or do we need a 319 way for the referrer to tell the referree "Use this identity for 320 me in the token you build"? As noted in Section 9, a similar 321 problem may exist in sip-identity and the solution may belong 322 there. 324 5. The 429 Provide Referrer Identity error response 326 The 429 client error response code is used by a refer target to 327 indicate that the referree must provide a valid Referred-By token. 328 As discussed in the behavior section, the referree will forward this 329 error response to the referrer in a NOTIFY as the result of the 330 REFER. The suggested text phrase for the 429 error response is 331 "Provide Referrer Identity". 333 6. Security Considerations 335 This mechanism defined in this specification relies on an 336 intermediary (the referree) to forward information from the referrer 337 to the refer target. This necessarily establishes the referree as an 338 eavesdropper of that information and positions him perfectly to 339 launch man-in-the-middle attacks using the mechanism. 341 A SIP proxy is similarly positioned. Protecting SIP messaging from 342 malicious proxy implementations is discussed in [1]. In contrast to 343 a proxy, the referree's agent is an endpoint. Proxies will 344 typically be managed and monitored by service providers. Malicious 345 behavior by a proxy is more likely to be noticed and result in 346 negative repercussions for the provider than malicious behavior by an 347 endpoint would be. The behavior of an endpoint can be entirely under 348 the control of a single user. Thus, it is more feasible for an 349 endpoint acting as referree to behave maliciously than it is for a 350 proxy being operated by a service provider. 352 This specification uses an S/MIME based mechanism to enable the refer 353 target to detect manipulation of the Referred-By information by the 354 referree. Use of this protection is optional! The community has 355 asserted that there are systems where trust in the validity of this 356 information is either not important or can be established through 357 other means. Any implementation choosing not to use this optional 358 mechanism needs to provide its own defense to the following risks: 360 o The Referred-By information is highly likely to influence request 361 admission policy. For instance, it may be displayed to the user 362 of the agent with a "This call was transferred to you by X. 363 Accept?" prompt. A malicious referree can unduly influence that 364 policy decision by providing falsified referred-by information. 365 This includes falsely claiming to have been referred in the first 366 place. (The S/MIME mechanism protects the information with a 367 signature, hampering the referree's ability to inject or modify 368 information without knowing the key used for that signature). 370 o A referree is by definition an eavesdropper of the referred-by 371 information. Parts of that information may be sensitive. (The S/ 372 MIME mechanism allows encryption). 374 o The referree may store any referred-by information it sees and 375 paste it into future unrelated requests. (The S/MIME mechanism 376 allows detection of stale assertions by covering a timestamp with 377 the signature and allows detection of use in unrelated requests by 378 covering the Refer-To header field with the signature). 380 The mechanisms in this specification do NOT prevent the referree from 381 deleting ALL referred-by information from the referenced request. A 382 refer target can not detect such deletion. This introduces no new 383 problems since removing all referred-by information from a referenced 384 request transforms it into an ordinary SIP request as described in 385 [1]. Thus the referree gains no new influence over processing logic 386 at the refer target by removing the referred-by information. 388 Refer targets can protect themselves from the possibility that a 389 malicious referree removed a token (leaving an unsecured identity in 390 the Referred-By header field) by using the 429 error response. 392 Applications using the mechanisms in this draft may be able to take 393 advantage of pre-existing relationships between the participants to 394 mitigate the risks of its use. In some transfer scenarios, A has the 395 choice of referring B to C or referring C to B. If A and B have a 396 pre-existing trust relationship leading A to have greater confidence 397 that B will not behave maliciously (B is A's administrative assistant 398 for example), referring B to C may make more sense. 400 This mechanism involves two SIP messages between three endpoints, the 401 REFER and the referenced request. The content of those messages 402 (including the referred-by information) is subject to the security 403 considerations and protection mechanisms documented in [1]. 405 Proxies between the participants may collect referred-by information 406 and reinsert it in future request or make them available to hostile 407 endpoints. The end-to-end confidentiality capabilities discussed in 408 [1] can help reduce risk of exposing sensitive referred-by 409 information to these proxies. The abuse possibilities in subsequent 410 requests by proxies (or endpoints that they may leak information to) 411 between the referree and the refer target are identical to abuse by 412 the referree and the considerations discussed for malicious referree 413 applies. The abuse possibilities in subsequent requests by proxies 414 (or endpoints that they may leak information to) between the referrer 415 and the referree are identical to those discussed for the 416 presentation of Authenticated Identity Bodies in [4]. 418 7. Examples 420 7.1 Basic REFER 422 This example shows the secured Referred-By mechanism applied to a 423 REFER to an SIP INVITE URI. 425 Details are shown only for those messages involved in exercising the 426 mechanism defined in this document. 428 Referrer Referree Refer Target 429 | F1 REFER | | 430 |-------------------------->| | 431 | 202 Accepted | | 432 |<--------------------------| | 433 | | F2 INVITE | 434 | |--------------------------->| 435 | | 200 OK | 436 | |<---------------------------| 437 | | ACK | 438 | NOTIFY |--------------------------->| 439 |<--------------------------| | 440 | 200 OK | | 441 |-------------------------->| | 442 | | | 444 F1 REFER sip:referree@referree.example SIP/2.0 445 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842 446 To: sip:referree@referree.example 447 From: sip:referror@referror.example;tag=39092342 448 Call-ID: 2203900ef0299349d9209f023a 449 CSeq: 1239930 REFER 450 Max-Forwards: 70 451 Contact: 452 Refer-To: sip:refertarget@target.example 453 Referred-By: sip:referror@referror.example 454 ;cid=%3C20398823.2UWQFN309shb3@referror.example%3E 455 Content-Type: multipart/mixed; boundary=unique-boundary-1 456 Content-Length: (appropriate value) 458 --unique-boundary-1 460 Content-Type: multipart/signed; 461 protocol="application/pkcs7-signature"; 462 micalg=sha1; boundary=dragons39 463 Content-ID: <20398823.2UWQFN309shb3@referror.example> 464 Content-Length: (appropriate value) 466 --dragons39 467 Content-Type: message/sipfrag 468 Content-Disposition: auth-id; handling=optional 470 From: sip:referror@referror.example 471 Date: Thu, 21 Feb 2002 13:02:03 GMT 472 Call-ID: 2203900ef0299349d9209f023a 473 Refer-To: sip:refertarget@target.example 474 Referred-By: sip:referror@referror.example 475 ;cid=%3C20398823.2UWQFN309shb3@referror.example%3E 477 --dragons39 478 Content-Type: application/pkcs7-signature; name=smime.p7s 479 Content-Transfer-Encoding: base64 480 Content-Disposition: attachment; filename=smime.p7s; 481 handling=required 483 (appropriate signature goes here) 485 --dragons39-- 487 --unique-boundary-1-- 489 F2 INVITE sip:refertarget@target.example SIP/2.0 490 Via: SIP/2.0/UDP referree.example;branch=z9hG4bKffe209934aac 491 To: sip:refertarget@target.example 492 From: sip:referree@referree.example;tag=2909034023 493 Call-ID: fe9023940-a3465@referree.example 494 CSeq: 889823409 INVITE 495 Max-Forwards: 70 496 Contact: 497 Referred-By: sip:referror@referror.example 498 ;cid=%3C20398823.2UWQFN309shb3@referror.example%3E 499 Content-Type: multipart/mixed; boundary=my-boundary-9 500 Content-Length: (appropriate value) 502 --my-boundary-9 504 Content-Type: application/sdp 505 Content-Length: (appropriate value) 507 v=0 508 o=referree 2890844526 2890844526 IN IP4 referree.example 509 s=Session SDP 510 c=IN IP4 referree.example 511 t=0 0 512 m=audio 49172 RTP/AVP 0 513 a=rtpmap:0 PCMU/8000 515 --my-boundary-9 517 Content-Type: multipart/signed; 518 protocol="application/pkcs7-signature"; 519 micalg=sha1; boundary=dragons39 520 Content-ID: <20398823.2UWQFN309shb3@referror.example> 521 Content-Length: (appropriate value) 523 --dragons39 524 Content-Type: message/sipfrag 525 Content-Disposition: auth-id; handling=optional 527 From: sip:referror@referror.example 528 Date: Thu, 21 Feb 2002 13:02:03 GMT 529 Call-ID: 2203900ef0299349d9209f023a 530 Refer-To: sip:refertarget@target.example 531 Referred-By: sip:referror@referror.example 532 ;cid=%3C20398823.2UWQFN309shb3@referror.example%3E 534 --dragons39 535 Content-Type: application/pkcs7-signature; name=smime.p7s 536 Content-Transfer-Encoding: base64 537 Content-Disposition: attachment; filename=smime.p7s; 538 handling=required 540 (appropriate signature goes here) 542 --dragons39-- 543 --my-boundary-9-- 545 7.2 Insecure REFER 547 The flow for this example is the same as that of Section 7.1. Here, 548 the referrer has opted to not include a Referred-By token, and the 549 refer target is willing to accept the referenced request without one. 551 F1 REFER sip:referree@referree.example SIP/2.0 552 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842 553 To: sip:referree@referree.example 554 From: sip:referror@referror.example;tag=39092342 555 Call-ID: 2203900ef0299349d9209f023a 556 CSeq: 1239930 REFER 557 Max-Forwards: 70 558 Contact: 559 Refer-To: sip:refertarget@target.example 560 Referred-By: sip:referror@referror.example 561 Content-Length: 0 563 F2 INVITE sip:refertarget@target.example SIP/2.0 564 Via: SIP/2.0/UDP referree.example;branch=z9hG4bKffe209934aac 565 To: sip:refertarget@target.example 566 From: sip:referree@referree.example;tag=2909034023 567 Call-ID: fe9023940-a3465@referree.example 568 CSeq: 889823409 INVITE 569 Max-Forwards: 70 570 Contact: 571 Referred-By: sip:referror@referror.example 572 Content-Type: application/sdp 573 Content-Length: (appropriate value) 575 v=0 576 o=referree 2890844526 2890844526 IN IP4 referree.example 577 s=Session SDP 578 c=IN IP4 referree.example 579 t=0 0 580 m=audio 49172 RTP/AVP 0 581 a=rtpmap:0 PCMU/8000 583 7.3 Requiring Referrer Identity 585 In contrast to the example in Section 7.2, the refer target requires 586 a Referred-By token to accept the referenced request. The referrer 587 choses to provide an encrypted token (note that the block surrounded 588 by asterisks represents encrypted content). F1 and F2 are identical 589 to the messages detailed in Section 7.2. 591 Referrer Referree Refer Target 592 | F1 REFER | | 593 |-------------------------->| | 594 | 202 Accepted | | 595 |<--------------------------| | 596 | | F2 INVITE | 597 | |--------------------------->| 598 | | F3 429 Provide Referrer Identity 599 | |<---------------------------| 600 | | ACK | 601 | F4 NOTIFY |--------------------------->| 602 |<--------------------------| | 603 | 200 OK | | 604 |-------------------------->| | 605 | F5 REFER | | 606 |-------------------------->| | 607 | 202 Accepted | | 608 |<--------------------------| | 609 | | F6 INVITE | 610 | |--------------------------->| 611 | | 200 OK | 612 | |<---------------------------| 613 | | ACK | 614 | NOTIFY |--------------------------->| 615 |<--------------------------| | 616 | 200 OK | | 617 |-------------------------->| | 618 | | | 620 F3 SIP/2.0 429 Provide Referrer Identity 621 Via: SIP/2.0/UDP referree.example;branch=z9hG4bKffe209934aac 622 To: sip:refertarget@target.example;tag=392093422302334 623 From: sip:referree@referree.example;tag=2909034023 624 Call-ID: fe9023940-a3465@referree.example 625 CSeq: 889823409 INVITE 626 Content-Length: 0 628 F4 NOTIFY sip:referror@referror.example SIP/2.0 629 Via: SIP/2.0/UDP referree.example;branch=z9hG4bK2934209da390 630 To: sip:referror@referror.example;tag=39092342 631 From: sip:referree@referree.example;tag=199949923 632 Call-ID: 2203900ef0299349d9209f023a 633 CSeq: 3920390 NOTIFY 634 Event: refer;id=1239930 635 Subscription-State: terminated 636 Content-Type: message/sipfrag 637 Content-Length: (appropriate value) 639 SIP/2.0 429 Provide Referrer Identity 641 F5 REFER sip:referree@referree.example SIP/2.0 642 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK98823423 643 To: sip:referree@referree.example 644 From: sip:referror@referror.example;tag=39092342 645 Call-ID: 2203900ef0299349d9209f023a 646 CSeq: 1239931 REFER 647 Max-Forwards: 70 648 Contact: 649 Refer-To: sip:refertarget@target.example 650 Referred-By: sip:referror@referror.example 651 ;cid=%3C20342EFXEI.390sdefn2@referror.example%3E 652 Content-Type: multipart/mixed; boundary=unique-boundary-1 653 Content-Length: (appropriate value) 655 --unique-boundary-1 657 Content-Type: multipart/signed; 658 protocol="application/pkcs7-signature"; 659 micalg=sha1; boundary=boundary42 660 Content-ID: <20342EFXEI.390sdefn2@referror.example> 661 Content-Length: (appropriate value) 663 --boundary42 665 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 666 name=smime.p7m 667 Content-Transfer-Encoding: base64 668 Content-Disposition: attachment; filename=smime.p7m 669 handling=required 670 Content-Length: (appropriate value) 672 *********************************************************** 673 * Content-Type: message/sipfrag * 674 * Content-Disposition: auth-id; handling=optional * 675 * * 676 * From: sip:referror@referror.example * 677 * Call-ID: 2203900ef0299349d9209f023a * 678 * Date: Thu, 21 Feb 2002 13:02:03 GMT * 679 * Refer-To: sip:refertarget@target.example * 680 * Referred-By: sip:referror@referror.example * 681 * ;cid=%3C20342EFXEI.390sdefn2@referror.example%3E * 682 *********************************************************** 683 --boundary42 685 Content-Type: application/pkcs7-signature; name=smime.p7s 686 Content-Transfer-Encoding: base64 687 Content-Disposition: attachment; filename=smime.p7s; 688 handling=required 690 (appropriate signature) 692 --boundary42-- 694 F6 INVITE sip:refertarget@target.example SIP/2.0 695 Via: SIP/2.0/UDP referree.example;branch=z9hG4bK3920390423 696 To: sip:refertarget@target.example 697 From: sip:referree@referree.example;tag=1342093482342 698 Call-ID: 23499234-9239842993@referree.example 699 CSeq: 19309423 INVITE 700 Max-Forwards: 70 701 Referred-By: sip:referror@referror.example 702 ;cid=%3C20342EFXEI.390sdefn2@referror.example%3E 703 Contact: 704 Content-Type: multipart/mixed; boundary=my-boundary-9 705 Content-Length: (appropriate value) 707 --my-boundary-9 709 Content-Type: application/sdp 710 Content-Length: (appropriate value) 712 v=0 713 o=referree 2890844526 2890844526 IN IP4 referree.example 714 s=Session SDP 715 c=IN IP4 referree.example 716 t=0 0 717 m=audio 49172 RTP/AVP 0 718 a=rtpmap:0 PCMU/8000 720 --my-boundary-9 722 Content-Type: multipart/signed; 723 protocol="application/pkcs7-signature"; 724 micalg=sha1; boundary=boundary42 725 Content-ID: <20342EFXEI.390sdefn2@referror.example> 726 Content-Length: (appropriate value) 728 --boundary42 730 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; 731 name=smime.p7m 732 Content-Transfer-Encoding: base64 733 Content-Disposition: attachment; filename=smime.p7m 734 handling=required 735 Content-Length: (appropriate value) 737 *********************************************************** 738 * Content-Type: message/sipfrag * 739 * Content-Disposition: auth-id; handling=optional * 740 * * 741 * From: sip:referror@referror.example * 742 * Call-ID: 2203900ef0299349d9209f023a * 743 * Date: Thu, 21 Feb 2002 13:02:03 GMT * 744 * Refer-To: sip:refertarget@target.example * 745 * Referred-By: sip:referror@referror.example * 746 * ;cid=%3C20342EFXEI.390sdefn2@referror.example%3E * 747 *********************************************************** 749 --boundary42 751 Content-Type: application/pkcs7-signature; name=smime.p7s 752 Content-Transfer-Encoding: base64 753 Content-Disposition: attachment; filename=smime.p7s; 754 handling=required 756 (appropriate signature) 758 --boundary42-- 759 --my-boundary-9-- 761 7.4 Nested REFER 763 The Refer-To URI may be a SIP URI indicating the REFER method. 764 Consider The following URI which A uses to refer B to send a REFER 765 request to C which refers C to send an INVITE to D. 767 Note that A provides a Referred-By token which gets passed through B 768 and C to D. In particular, B does not provide its own Referred-By 769 token to C. Also note that A is notified of the outcome of the 770 request it triggered at B (the REFER), not at C (the INVITE). 772 Refer-To: 774 This reference would result in the following flow: 776 A B C D 777 | F1 REFER | | | 778 |------------------>| | | 779 | 202 Accepted | | | 780 |<------------------| | | 781 | | F2 REFER | | 782 | |------------------>| | 783 | | 202 Accepted | | 784 | |<------------------| | 785 | F3 NOTIFY | | F4 INVITE | 786 |<------------------| |------------------>| 787 | 200 OK | | 200 OK | 788 |------------------>| |<------------------| 789 | | | ACK | 790 | | |------------------>| 791 | | NOTIFY | | 792 | |<------------------| | 793 | | 200 OK | | 794 | |------------------>| | 795 | | | | 797 F1 REFER sip:B SIP/2.0 798 Via: SIP/2.0/UDP A;branch=z9hG4bK3802394232 799 To: sip:B 800 From: sip:A;tag=23490234 801 Call-ID: 2304098023@A 802 CSeq: 2342093 REFER 803 Max-Forwards: 70 804 Contact: 805 Refer-To: 806 Referred-By: ;cid=%3C23094202342.10123091233@A%3E 807 Content-Type: multipart/mixed; boundary=unique-boundary-1 808 Content-Length: (appropriate value) 810 --unique-boundary-1 812 Content-Type: multipart/signed; 813 protocol="application/pkcs7-signature"; 814 micalg=sha1; boundary=dragons39 815 Content-ID: <23094202342.10123091233@A> 816 Content-Length: (appropriate value) 818 --dragons39 819 Content-Type: message/sipfrag 820 Content-Disposition: auth-id; handling=optional 822 From: sip:A 823 Call-ID: 2304098023@A 824 Date: Thu, 21 Feb 2002 13:02:03 GMT 825 Refer-To: 826 Referred-By: ;cid=%3C23094202342.101230912342A%3E 828 --dragons39 829 Content-Type: application/pkcs7-signature; name=smime.p7s 830 Content-Transfer-Encoding: base64 831 Content-Disposition: attachment; filename=smime.p7s; 832 handling=required 834 (appropriate signature goes here) 836 --dragons39-- 838 --unique-boundary-1-- 840 F2 REFER sip:C SIP/2.0 841 Via: SIP/2.0/UDP B;branch=z9hG4bK00239842 842 To: sip:C 843 From: sip:B;tag=2934u23 844 Call-ID: 203942834@B 845 CSeq: 8321039 REFER 846 Max-Forwards: 70 847 Contact: 848 Refer-To: 849 Referred-By: ;cid=%3C23094202342.10123091233@A%3E 850 Content-Type: multipart/mixed; boundary=unique-boundary-1 851 Content-Length: (appropriate value) 853 --unique-boundary-1 855 Content-Type: multipart/signed; 856 protocol="application/pkcs7-signature"; 857 micalg=sha1; boundary=dragons39 858 Content-ID: <23094202342.10123091233@A> 859 Content-Length: (appropriate value) 861 --dragons39 862 Content-Type: message/sipfrag 863 Content-Disposition: auth-id; handling=optional 865 From: sip:A 866 Call-ID: 2304098023@A 867 Date: Thu, 21 Feb 2002 13:02:03 GMT 868 Refer-To: 869 Referred-By: ;cid=%3C23094202342.101230912342A%3E 871 --dragons39 872 Content-Type: application/pkcs7-signature; name=smime.p7s 873 Content-Transfer-Encoding: base64 874 Content-Disposition: attachment; filename=smime.p7s; 875 handling=required 877 (appropriate signature goes here) 879 --dragons39-- 881 --unique-boundary-1-- 883 F3 NOTIFY sip:A SIP/2.0 884 Via: SIP/2.0/UDP A;branch=z9hG4bK3802394232 885 To: sip:A;tag=23490234 886 From: sip:B;tag=5923020 887 Call-ID: 2304098023@A 888 CSeq: 29420342 NOTIFY 889 Event: refer;id=2342093 890 Subscription-State: terminated 891 Max-Forwards: 70 892 Contact: 893 Content-Type: message/sipfrag 894 Content-Length: (appropriate value) 896 SIP/2.0 202 Accepted 898 F4 INVITE sip:D SIP/2.0 899 Via: SIP/2.0/UDP C;branch=z9hG4bK29348234 900 To: sip:D 901 From: sip:C;tag=023942334 902 Call-ID: 23489020352@C 903 CSeq: 1230934 INVITE 904 Max-Forwards: 70 905 Contact: 906 Referred-By: ;cid=%3C23094202342.10123091233@A%3E 907 Content-Type: multipart/mixed; boundary=unique-boundary-1 908 Content-Length: (appropriate value) 910 --unique-boundary-1 912 Content-Type: application/sdp 913 Content-Length: (appropriate value) 915 v=0 916 o=C 2890844526 2890844526 IN IP4 C 917 s=Session SDP 918 c=IN IP4 C 919 t=0 0 920 m=audio 49172 RTP/AVP 0 921 a=rtpmap:0 PCMU/8000 923 --unique-boundary-1 925 Content-Type: multipart/signed; 926 protocol="application/pkcs7-signature"; 927 micalg=sha1; boundary=dragons39 928 Content-ID: <23094202342.10123091233@A> 929 Content-Length: (appropriate value) 931 --dragons39 932 Content-Type: message/sipfrag 933 Content-Disposition: auth-id; handling=optional 935 From: sip:A 936 Call-ID: 2304098023@A 937 Date: Thu, 21 Feb 2002 13:02:03 GMT 938 Refer-To: 939 Referred-By: ;cid=%3C23094202342.101230912342A%3E 941 --dragons39 942 Content-Type: application/pkcs7-signature; name=smime.p7s 943 Content-Transfer-Encoding: base64 944 Content-Disposition: attachment; filename=smime.p7s; 945 handling=required 947 (appropriate signature goes here) 949 --dragons39-- 951 --unique-boundary-1-- 953 8. IANA Considerations 955 (Note to RFC Editor: Please fill in all occurrences of XXXX in this 956 section with the RFC number of this specification). 958 This document defines a new SIP header field name with a compact form 959 (Referred-By and b respectively). It also defines an new SIP client 960 error response code (429). 962 The following changes should be made to http:///www.iana.org/ 963 assignments/sip-parameters 965 The following row should be added to the header field section 966 (replacing any existing row for Referred-By). 968 Header Name Compact Form Reference 969 Referred-By b [RFCXXXX] 971 The following row should be added to the response code section under 972 the Request Failure 4xx heading 974 429 Provide Referrer Identity [RFCXXXX] 976 9. Open Issues 978 1. This mechanism proves to the target that the referrer sent a 979 REFER with this particular Refer-To and Referred-By header field 980 values. It DOES NOT prove to the target that the referrer sent 981 that REFER to this particular referree (which may enable an 982 intercept/cut-paste attack). Including the REFER start line (the 983 Request-URI in particular) is not sufficient to tighten this up - 984 location services may arbitrarily retarget the REFER and the 985 target will generally have no way to reconcile the REFER Request- 986 URI with the actual identity of the referree. Do we need to 987 tighten this? If so, I believe the solution needs to lie in the 988 identity service mechanism. The same attack applies to that 989 mechanism in general, resulting in theft of identity. 991 2. Is Call-ID in a token a security leak? Is it even useful? See 992 Section 4. 994 3. Should the identity expressed by the token reflect From or 995 Referred-By? See Section 4. 997 4. Is the To field in the token useful to the target? See Section 4 999 10. Changes from -00 1001 o Resolved open issue: A referree is not allowed to change the 1002 content-id for the body part containing a token while copying the 1003 header and body part into the referenced request. A copy of the 1004 Referred-By header is in the token. Allowing the referree to 1005 change the copy outside the token adds complexity to the 1006 acceptance logic at a refer target. 1008 o Updated to reflect the current identity drafts 1010 o Identified open issues with using the token on reciept 1012 o Added SIP to the draft title 1013 o Updated References 1015 Normative References 1017 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1018 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1019 Session Initiation Protocol", RFC 3261, June 2002. 1021 [2] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-07 1022 (work in progress), December 2002. 1024 [3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 1025 November 2002. 1027 [4] Peterson, J., "Enhancements for Authenticated Identity 1028 Management in the Session Initiation Protocol (SIP)", draft- 1029 ietf-sip-identity-00 (work in progress), October 2002. 1031 [5] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", 1032 draft-ietf-sip-authid-body-00 (work in progress), October 2002. 1034 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1035 Extensions (MIME) Part One: Format of Internet Message Bodies", 1036 RFC 2045, November 1996. 1038 Informative References 1040 [7] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1041 Control - Transfer", draft-ietf-sipping-cc-transfer-00 (work in 1042 progress), October 2002. 1044 Author's Address 1046 Robert J. Sparks 1047 dynamicsoft 1048 5100 Tennyson Parkway 1049 Suite 1200 1050 Plano, TX 75024 1052 EMail: rsparks@dynamicsoft.com 1054 Full Copyright Statement 1056 Copyright (C) The Internet Society (2003). All Rights Reserved. 1058 This document and translations of it may be copied and furnished to 1059 others, and derivative works that comment on or otherwise explain it 1060 or assist in its implementation may be prepared, copied, published 1061 and distributed, in whole or in part, without restriction of any 1062 kind, provided that the above copyright notice and this paragraph are 1063 included on all such copies and derivative works. However, this 1064 document itself may not be modified in any way, such as by removing 1065 the copyright notice or references to the Internet Society or other 1066 Internet organizations, except as needed for the purpose of 1067 developing Internet standards in which case the procedures for 1068 copyrights defined in the Internet Standards process must be 1069 followed, or as required to translate it into languages other than 1070 English. 1072 The limited permissions granted above are perpetual and will not be 1073 revoked by the Internet Society or its successors or assigns. 1075 This document and the information contained herein is provided on an 1076 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1077 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1078 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1079 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1080 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1082 Acknowledgement 1084 Funding for the RFC Editor function is currently provided by the 1085 Internet Society.