Network Working Group R. Sparks Internet-Draft dynamicsoft Expires: February 4, 2004 August 6, 2003 The SIP Referred-By Mechanism draft-ietf-sip-referredby-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 4, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The SIP REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. Sparks Expires February 4, 2004 [Page 1] Internet-Draft The SIP Referred-By Mechanism August 2003 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Referred-By Mechanism . . . . . . . . . . . . . . . . . . 4 2.1 Referrer behavior . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Referee behavior . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Refer Target behavior . . . . . . . . . . . . . . . . . . . . 5 3. The Referred-By Header Field . . . . . . . . . . . . . . . . . 6 4. The Referred-By Token . . . . . . . . . . . . . . . . . . . . 8 4.1 Refer target inspection of a Referred-By token . . . . . . . . 8 5. The 429 Provide Referrer Identity error response . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6.1 Identifying the referee in the Referred-by Token . . . . . . . 11 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1 Basic REFER . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2 Insecure REFER . . . . . . . . . . . . . . . . . . . . . . . . 14 7.3 Requiring Referrer Identity . . . . . . . . . . . . . . . . . 15 7.4 Nested REFER . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 Normative References . . . . . . . . . . . . . . . . . . . . . 23 Informative References . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25 Sparks Expires February 4, 2004 [Page 2] Internet-Draft The SIP Referred-By Mechanism August 2003 1. Overview The SIP REFER method [1] provides a mechanism where one party (the referrer) provides a second party (the referee) with an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). Nothing provided in [1] distinguishes this referenced request from any other request the referee might have sent to the refer target. --------------------------------------------------------------------- Referrer Referee Refer Target | | | | REFER | | | Refer-To: target | | |----------------->| INVITE target | | |------------------->| Classic REFER --------------------------------------------------------------------- There are applications of REFER, such as call transfer [7], where it is desirable to provide the refer target with certain information about the referrer and the REFER request itself. This information may include, but is not limited to, the referrer's identity, the referred to URI, and the time of the referral. The refer target can use this information when deciding whether to admit the referenced request. This draft defines one set of mechanisms to provide that information. All of the mechanisms in this draft involve placing information in the REFER request that the referee copies into the referenced request. This necessarily establishes the referee as an eavesdropper and places the referee in a position to launch man-in-the-middle attacks on that information. At the simplest level, this draft defines a mechanism for carrying the referrer's identity, expressed as a SIP URI in a new header: Referred-By. The refer target can use that information, even if it has not been protected from the referee, at the perils and with the limitations documented here. The draft proceeds to define an S/MIME based mechanism for expressing the identity of the referrer and capturing other information about the REFER request, allowing the refer target to detect tampering (and other undesirable behaviors) by the referee. Sparks Expires February 4, 2004 [Page 3] Internet-Draft The SIP Referred-By Mechanism August 2003 2. The Referred-By Mechanism The following figure summarizes how Referred-By information is carried to the Refer Target. The Referrer provides a Referred-By header with its SIP address-of-record, optionally associating an S/ MIME protected token reflecting the identity of the referrer and details of the REFER request. The Referee copies this header and the token, if provided, into the triggered request (shown here as an INVITE). --------------------------------------------------------------------- Referrer Referee Refer Target | | | | REFER | | | Refer-To: target | | | Referred-By: referrer;cid=X | | | | | | (one of the body parts is) | | | Content-ID: X | | | | | |----------------------------->| | | | INVITE target | | | Referred-By: referrer;cid=X | | | | | | (one of the body parts is) | | | Content-ID: X | | | | | |---------------------------->| REFER with Referred-By --------------------------------------------------------------------- 2.1 Referrer behavior A UA sending a REFER request (a referrer) MAY provide a Referred-By header field value in the request. A REFER request MUST NOT contain more than one Referred-By header field value. A referrer MAY include a Referred-By token in a REFER request. A REFER request containing a Referred-By token MUST contain a Referred- By header field value with a cid parameter value equal to the Content-ID of the body part containing the token. The referrer will receive a NOTIFY with a message/sipfrag [3] body Sparks Expires February 4, 2004 [Page 4] Internet-Draft The SIP Referred-By Mechanism August 2003 indicating a final response of 429 "Provide Referrer Identity" to the referenced request if the refer target requires a valid Referred-By token to accept the request. This can occur when either no token is provided or a provided token is invalid. The referrer will receive a 429 "Provide Referrer Identity" response to the REFER if the referee requires a Referred-By token to be present in order to accept the REFER. If a referrer wishes to reattempt to refer a referee after receiving a 429 response or a NOTIFY containing a 429, it MAY submit a new REFER request containing a Referred-By token. 2.2 Referee behavior A UA accepting a REFER request (a referee) to a SIP URI (using either the sip: or sips: scheme) MUST copy any Referred-By header field value and token into the referenced request without modification. A referee MAY reject a REFER request that does not contain a Referred-By token with a 429 "Provide Referrer Identity" response. A referee SHOULD NOT reject a request that contains a Referred-By token encrypted to a key it does not possess. Note that per [2] the referee should still be able to verify the signature of such an encrypted token. A referee SHOULD present the same identity to the referrer and the refer target. 2.3 Refer Target behavior A UA receiving a non-REFER SIP request MAY inspect the request for a Referred-By header field and token. If a Referred-By header field value is not present, this UA can not distinguish this request from any other the UA acting as the referee might have sent. Thus, the UA would apply exactly the admissions policies and processing described in [4] to the request. If a Referred-By header field value is present, the receiving UA can consider itself a refer target and MAY apply additional admission policies based on the contents of the Referred-By header field and token. The referee is in a position to modify the contents of the Referred- By header field value, or falsely provide one even if no REFER actually exists. If such behavior could affect admission policy (including influencing the agent's user by rendering misleading Sparks Expires February 4, 2004 [Page 5] Internet-Draft The SIP Referred-By Mechanism August 2003 content), the refer target SHOULD require that a valid Referred-By token be present. The refer target MAY reject a request if no Referred-By token is present or if the token is stale using the 429 "Provide Referrer Identity" error response defined in Section 5. The 428 error response from [6] is not appropriate for this purpose - it is needed for the refer target to request an authentication token from the referee. If no Referred-By token is present, the refer target MAY proceed with processing the request. If the agent provides any information from the Referred-By header to its user as part of processing the request, it MUST notify the user that the information is suspect. The refer target MUST reject an otherwise well-formed request with an invalid Referred-By token (see Section 4) with a 429 error response. 3. The Referred-By Header Field Referred-By is a request header field as defined by [4]. It can appear in any request. It carries a SIP URI representing the identity of the referrer and, optionally, the Content-ID of a body part (the Referred-By token) that provides a more secure statement of that identity. Sparks Expires February 4, 2004 [Page 6] Internet-Draft The SIP Referred-By Mechanism August 2003 --------------------------------------------------------------------- Referred-By = ("Referred-By" / "b") HCOLON referrer-uri *( SEMI (referredby-id-param / generic-param) ) referrer-uri = ( name-addr / addr-spec ) referredby-id-param = "cid" EQUAL sip-clean-msg-id sip-clean-msg-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT dot-atom = atom *( "." atom ) atom = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "'" / "`" / "~" ) Referred-By Syntax --------------------------------------------------------------------- Since the Content-ID appears as a SIP header parameter value which must conform to the expansion of gen-value defined in [4], this grammar produces values in the intersection of the expansions of gen- value and msg-id from [8]. The double-quotes surrounding the sip- clean-msg-id MUST be replaced with left and right angle brackets to derive the Content-ID used in the message's MIME body. For example, Referred-By: sip:r@ref.example;cid="2UWQFN309shb3@ref.example" indicates the token is in the body part containing Content-ID: <2UWQFN309shb3@ref.example> The Referred-By header field MAY appear in any SIP request, but is meaningless for ACK and CANCEL. Proxies do not need to be able to read Referred-By header field values and MUST NOT remove or modify them. The following row should be interpreted as if it appeared in Table 3 of RFC 3261. Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________________ Referred-By R - o - o o o Sparks Expires February 4, 2004 [Page 7] Internet-Draft The SIP Referred-By Mechanism August 2003 4. The Referred-By Token The Referred-By token is an Authenticated Identity Body as defined by [2]. This body part MUST be identified with a MIME [5] Content-ID: field. The sipfrag inside a Referred-By token MUST contain copies of the Refer-To, Referred-By, and Date header fields from the REFER request. The token SHOULD NOT contain the Call-ID header field from the REFER request as that information is not useful to the refer target and may even be an information leak. The token SHOULD NOT contain the From header field from the REFER request since the identity being claimed is represented in the Referred-By header field. The token MAY contain the To header field from the REFER request, but it SHOULD NOT be included unless the referrer has cryptographically identified the referee. Some ways this authentication can be achieved include inspecting the certificates used in a TLS association between the referrer and the referee or encrypting the Refer-To header in the REFER request using the S/MIME encryption techniques detailed in [4]. Including the To header field significantly strengthens the claim being asserted by the token, but may have privacy implications as discussed in Section 6.1. Additional header fields and body parts MAY be included in the token. As described in [2], a Referred-By token MAY be encrypted as well as signed. The subjectAltName of the certificate used for these operations SHOULD exactly match the identity claimed in the referrer- uri in the Referred-By header field in the token. 4.1 Refer target inspection of a Referred-By token A refer target MUST treat a Referred-By token with an invalid signature as an invalid token. A target SHOULD treat a token with an aged Date header field value as invalid. A target SHOULD verify that the request it receives matches the reference in the Refer-To header field in the token. This verification SHOULD include at least the request method and any indicated end-to-end header field values. Note that the URI in the Refer-To header field may not match the request URI in the received request due to request retargetting between the referee and the refer target. The target SHOULD verify that the identity in the Referred-By header field in the token exactly matches the SubjectAltName from the Sparks Expires February 4, 2004 [Page 8] Internet-Draft The SIP Referred-By Mechanism August 2003 signing certificate, reporting discrepancies to its user as described in [2]. If the token contains a To header field, the target SHOULD verify that the identity it expresses matches the referrer. One way of verifying this is to exactly match the identity in the token's To header field with the subjectAltName of the certificate used by the referee to sign the aib protecting the request itself. The 428 response defined in [6] can be used to request such an aib if one is not already present. 5. The 429 Provide Referrer Identity error response The 429 client error response code is used by a refer target to indicate that the referee must provide a valid Referred-By token. As discussed in the behavior section, the referee will forward this error response to the referrer in a NOTIFY as the result of the REFER. The suggested text phrase for the 429 error response is "Provide Referrer Identity". 6. Security Considerations This mechanism defined in this specification relies on an intermediary (the referee) to forward information from the referrer to the refer target. This necessarily establishes the referee as an eavesdropper of that information and positions him perfectly to launch man-in-the-middle attacks using the mechanism. A SIP proxy is similarly positioned. Protecting SIP messaging from malicious proxy implementations is discussed in [4]. In contrast to a proxy, the referee's agent is an endpoint. Proxies will typically be managed and monitored by service providers. Malicious behavior by a proxy is more likely to be noticed and result in negative repercussions for the provider than malicious behavior by an endpoint would be. The behavior of an endpoint can be entirely under the control of a single user. Thus, it is more feasible for an endpoint acting as referee to behave maliciously than it is for a proxy being operated by a service provider. This specification uses an S/MIME based mechanism to enable the refer target to detect manipulation of the Referred-By information by the referee. Use of this protection is optional! The community has asserted that there are systems where trust in the validity of this information is either not important or can be established through other means. Any implementation choosing not to use this optional mechanism needs to provide its own defense to the following risks: o The Referred-By information is highly likely to influence request Sparks Expires February 4, 2004 [Page 9] Internet-Draft The SIP Referred-By Mechanism August 2003 admission policy. For instance, it may be displayed to the user of the agent with a "This call was transferred to you by X. Accept?" prompt. A malicious referee can unduly influence that policy decision by providing falsified referred-by information. This includes falsely claiming to have been referred in the first place. (The S/MIME mechanism protects the information with a signature, hampering the referee's ability to inject or modify information without knowing the key used for that signature). o A referee is by definition an eavesdropper of the referred-by information. Parts of that information may be sensitive. (The S/ MIME mechanism allows encryption). o The referee may store any referred-by information it sees and paste it into future unrelated requests. (The S/MIME mechanism allows detection of stale assertions by covering a timestamp with the signature and allows detection of use in unrelated requests by covering the Refer-To header field with the signature). The mechanisms in this specification do NOT prevent the referee from deleting ALL referred-by information from the referenced request. A refer target can not detect such deletion. This introduces no new problems since removing all referred-by information from a referenced request transforms it into an ordinary SIP request as described in [4]. Thus the referee gains no new influence over processing logic at the refer target by removing the referred-by information. Refer targets can protect themselves from the possibility that a malicious referee removed a token (leaving an unsecured identity in the Referred-By header field) by using the 429 error response. Applications using the mechanisms in this draft may be able to take advantage of pre-existing relationships between the participants to mitigate the risks of its use. In some transfer scenarios, A has the choice of referring B to C or referring C to B. If A and B have a pre-existing trust relationship leading A to have greater confidence that B will not behave maliciously (B is A's administrative assistant for example), referring B to C may make more sense. This mechanism involves two SIP requests between three endpoints, the REFER and the referenced request. The content of those messages (including the referred-by information) is subject to the security considerations and protection mechanisms documented in [4]. Proxies between the participants may collect referred-by information and reinsert it in future requests or make it available to hostile endpoints. The end-to-end confidentiality capabilities discussed in [4] can help reduce risk of exposing sensitive referred-by Sparks Expires February 4, 2004 [Page 10] Internet-Draft The SIP Referred-By Mechanism August 2003 information to these proxies. The abuse possibilities in subsequent requests by proxies (or endpoints that they may leak information to) between the referee and the refer target are identical to abuse by the referee and the considerations discussed for malicious referee applies. The abuse possibilities in subsequent requests by proxies (or endpoints that they may leak information to) between the referrer and the referee are similar to those discussed for the presentation of Authenticated Identity Bodies in [6]. 6.1 Identifying the referee in the Referred-by Token To a refer target, a Referred-By token minimally asserts "The identity expressed by this Referred-By header field asked at the time indicated in this Date header field that the request indicated by this Refer-To header field be sent". This assertion makes no claims at all about who is being asked to send the request. This is sufficient to enable policies such as "Accept any requests referred by Alice", but not "Only accept requests from Bob if he can prove that Alice referred him to us". Thus, there is an opportunity for a cut-and-paste attack. If Mallory sees Alice refer Carol to us using a minimal token, he can copy that token into his own request (as long as it matches what is indicated in the embedded Refer-To header), and it will appear to us that Alice referred Mallory to us. This risk is best mitigated by protecting the REFER Alice sends to Carol from eavesdropping, using TLS or the S/MIME mechanisms detailed in [4]. Including the To header field from the REFER request in the Referred- by token enables the "Only accept requests from Bob if he can prove that Alice referred him to us". Alice is constrained to add this header to the token only if she is sure she is sending the REFER request to Bob. We, in turn, ensure it was Bob that sent the referrenced request to us in addition to validating Alice's signature of the token. Mallory's earlier attack is not effective with this token. Including the To header field in the Referred-By token has privacy implications, however. Carol, above, might wish to contact us anonymously. That wish would be defeated if Carol's identity appeared in the token Alice created. If Alice encrypted the token to us, Carol will not even be aware of the information leak. To protect herself when she wishes anonymity, Carol will have to reject any REFER requests containing a Referred-By token she can not inspect. 7. Examples Sparks Expires February 4, 2004 [Page 11] Internet-Draft The SIP Referred-By Mechanism August 2003 7.1 Basic REFER This example shows the secured Referred-By mechanism applied to a REFER to an SIP INVITE URI. Details are shown only for those messages involved in exercising the mechanism defined in this document. Referrer Referee Refer Target | F1 REFER | | |-------------------------->| | | 202 Accepted | | |<--------------------------| | | NOTIFY | | |<--------------------------| F2 INVITE | | 200 OK |--------------------------->| |-------------------------->| 200 OK | | |<---------------------------| | | ACK | | NOTIFY |--------------------------->| |<--------------------------| | | 200 OK | | |-------------------------->| | | | | F1 REFER sip:referee@referee.example SIP/2.0 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842 To: sip:referee@referee.example From: sip:referrer@referrer.example;tag=39092342 Call-ID: 2203900ef0299349d9209f023a CSeq: 1239930 REFER Max-Forwards: 70 Contact: Refer-To: Referred-By: ;cid="20398823.2UWQFN309shb3@referrer.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (appropriate value) --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=dragons39 Content-ID: <20398823.2UWQFN309shb3@referrer.example> Content-Length: (appropriate value) --dragons39 Sparks Expires February 4, 2004 [Page 12] Internet-Draft The SIP Referred-By Mechanism August 2003 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: Referred-By: ;cid="20398823.2UWQFN309shb3@referrer.example" --dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (appropriate signature goes here) --dragons39-- --unique-boundary-1-- F2 INVITE sip:refertarget@target.example SIP/2.0 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac To: From: ;tag=2909034023 Call-ID: fe9023940-a3465@referee.example CSeq: 889823409 INVITE Max-Forwards: 70 Contact: Referred-By: ;cid="20398823.2UWQFN309shb3@referrer.example" Content-Type: multipart/mixed; boundary=my-boundary-9 Content-Length: (appropriate value) --my-boundary-9 Content-Type: application/sdp Content-Length: (appropriate value) v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --my-boundary-9 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=dragons39 Sparks Expires February 4, 2004 [Page 13] Internet-Draft The SIP Referred-By Mechanism August 2003 Content-ID: <20398823.2UWQFN309shb3@referrer.example> Content-Length: (appropriate value) --dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: Referred-By: ;cid="20398823.2UWQFN309shb3@referrer.example" --dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (appropriate signature goes here) --dragons39-- --my-boundary-9-- 7.2 Insecure REFER The flow for this example is the same as that of Section 7.1. Here, the referrer has opted to not include a Referred-By token, and the refer target is willing to accept the referenced request without one. Sparks Expires February 4, 2004 [Page 14] Internet-Draft The SIP Referred-By Mechanism August 2003 F1 REFER sip:referee@referee.example SIP/2.0 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK392039842 To: From: ;tag=39092342 Call-ID: 2203900ef0299349d9209f023a CSeq: 1239930 REFER Max-Forwards: 70 Contact: Refer-To: Referred-By: Content-Length: 0 F2 INVITE sip:refertarget@target.example SIP/2.0 Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac To: From: ;tag=2909034023 Call-ID: fe9023940-a3465@referee.example CSeq: 889823409 INVITE Max-Forwards: 70 Contact: Referred-By: Content-Type: application/sdp Content-Length: (appropriate value) v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 7.3 Requiring Referrer Identity In contrast to the example in Section 7.2, the refer target requires a Referred-By token to accept the referenced request. The referrer chooses to provide an encrypted token (note that the block surrounded by asterisks represents encrypted content). F1 and F2 are identical to the messages detailed in Section 7.2. Sparks Expires February 4, 2004 [Page 15] Internet-Draft The SIP Referred-By Mechanism August 2003 Referrer Referee Refer Target | F1 REFER | | |-------------------------->| | | 202 Accepted | | |<--------------------------| | | NOTIFY | | |<--------------------------| F2 INVITE | | 200 OK |--------------------------->| |-------------------------->| F3 429 Provide Referrer Identity | |<---------------------------| | | ACK | | F4 NOTIFY |--------------------------->| |<--------------------------| | | 200 OK | | |-------------------------->| | | F5 REFER | | |-------------------------->| | | 202 Accepted | | |<--------------------------| | | NOTIFY | | |<--------------------------| F6 INVITE | | 200 OK |--------------------------->| |-------------------------->| 200 OK | | |<---------------------------| | | ACK | | NOTIFY |--------------------------->| |<--------------------------| | | 200 OK | | |-------------------------->| | | | | F3 SIP/2.0 429 Provide Referrer Identity Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac To: ;tag=392093422302334 From: ;tag=2909034023 Call-ID: fe9023940-a3465@referee.example CSeq: 889823409 INVITE Content-Length: 0 F4 NOTIFY sip:referrer@referrer.example SIP/2.0 Via: SIP/2.0/UDP referee.example;branch=z9hG4bK2934209da390 To: ;tag=39092342 From: ;tag=199949923 Call-ID: 2203900ef0299349d9209f023a CSeq: 3920390 NOTIFY Event: refer;id=1239930 Subscription-State: terminated Content-Type: message/sipfrag Sparks Expires February 4, 2004 [Page 16] Internet-Draft The SIP Referred-By Mechanism August 2003 Content-Length: (appropriate value) SIP/2.0 429 Provide Referrer Identity F5 REFER sip:referee@referee.example SIP/2.0 Via: SIP/2.0/UDP referrer.example;branch=z9hG4bK98823423 To: From: ;tag=39092342 Call-ID: 2203900ef0299349d9209f023a CSeq: 1239931 REFER Max-Forwards: 70 Contact: Refer-To: Referred-By: ;cid="20342EFXEI.390sdefn2@referrer.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (appropriate value) --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 Content-ID: <20342EFXEI.390sdefn2@referrer.example> Content-Length: (appropriate value) --boundary42 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m handling=required Content-Length: (appropriate value) *********************************************************** * Content-Type: message/sipfrag * * Content-Disposition: aib; handling=optional * * * * Date: Thu, 21 Feb 2002 13:02:03 GMT * * Refer-To: * * Referred-By: * * ;cid="20342EFXEI.390sdefn2@referrer.example" * *********************************************************** --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required Sparks Expires February 4, 2004 [Page 17] Internet-Draft The SIP Referred-By Mechanism August 2003 (appropriate signature) --boundary42-- F6 INVITE sip:refertarget@target.example SIP/2.0 Via: SIP/2.0/UDP referee.example;branch=z9hG4bK3920390423 To: From: ;tag=1342093482342 Call-ID: 23499234-9239842993@referee.example CSeq: 19309423 INVITE Max-Forwards: 70 Referred-By: ;cid="20342EFXEI.390sdefn2@referrer.example" Contact: Content-Type: multipart/mixed; boundary=my-boundary-9 Content-Length: (appropriate value) --my-boundary-9 Content-Type: application/sdp Content-Length: (appropriate value) v=0 o=referee 2890844526 2890844526 IN IP4 referee.example s=Session SDP c=IN IP4 referee.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --my-boundary-9 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 Content-ID: <20342EFXEI.390sdefn2@referrer.example> Content-Length: (appropriate value) --boundary42 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m handling=required Content-Length: (appropriate value) *********************************************************** * Content-Type: message/sipfrag * * Content-Disposition: aib; handling=optional * * * Sparks Expires February 4, 2004 [Page 18] Internet-Draft The SIP Referred-By Mechanism August 2003 * Date: Thu, 21 Feb 2002 13:02:03 GMT * * Refer-To: * * Referred-By: * * ;cid="20342EFXEI.390sdefn2@referrer.example" * *********************************************************** --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (appropriate signature) --boundary42-- --my-boundary-9-- 7.4 Nested REFER The Refer-To URI may be a SIP URI indicating the REFER method. Consider The following URI which A uses to refer B to send a REFER request to C which refers C to send an INVITE to D. Note that A provides a Referred-By token which gets passed through B and C to D. In particular, B does not provide its own Referred-By token to C. Also note that A is notified of the outcome of the request it triggered at B (the REFER), not at C (the INVITE). Refer-To: "> This reference would result in the following flow: A B C D | F1 REFER | | | |------------------>| | | | 202 Accepted | | | |<------------------| | | | NOTIFY | | | |<------------------| F2 REFER | | | 200 OK |------------------>| | |------------------>| 202 Accepted | | | F3 NOTIFY |<------------------| | |<------------------| NOTIFY | | | 200 OK |<------------------| F4 INVITE | |------------------>| 200 OK |------------------>| | |------------------>| 200 OK | Sparks Expires February 4, 2004 [Page 19] Internet-Draft The SIP Referred-By Mechanism August 2003 | | NOTIFY |<------------------| | |<------------------| ACK | | | 200 OK |------------------>| | |------------------>| | | | | | F1 REFER sip:B SIP/2.0 Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232 To: From: ;tag=23490234 Call-ID: 2304098023@A.example CSeq: 2342093 REFER Max-Forwards: 70 Contact: Refer-To: .example"> Referred-By: ; cid="23094202342.10123091233@A.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (appropriate value) --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=dragons39 Content-ID: <23094202342.10123091233@A.example> Content-Length: (appropriate value) --dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: "> Referred-By: ; cid="23094202342.10123091233@A.example" --dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (appropriate signature goes here) --dragons39-- --unique-boundary-1-- F2 REFER sip:C.example SIP/2.0 Sparks Expires February 4, 2004 [Page 20] Internet-Draft The SIP Referred-By Mechanism August 2003 Via: SIP/2.0/UDP B.example;branch=z9hG4bK00239842 To: From: ;tag=2934u23 Call-ID: 203942834@B.example CSeq: 8321039 REFER Max-Forwards: 70 Contact: Refer-To: Referred-By: ; cid="23094202342.10123091233@A.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (appropriate value) --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=dragons39 Content-ID: <23094202342.10123091233@A.example> Content-Length: (appropriate value) --dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: "> Referred-By: ;cid="23094202342.1012309123@A.example" --dragons39 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (appropriate signature goes here) --dragons39-- --unique-boundary-1-- F3 NOTIFY sip:A.example SIP/2.0 Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232 To: ;tag=23490234 From: ;tag=5923020 Call-ID: 2304098023@A.example CSeq: 29420342 NOTIFY Event: refer;id=2342093 Subscription-State: terminated Max-Forwards: 70 Sparks Expires February 4, 2004 [Page 21] Internet-Draft The SIP Referred-By Mechanism August 2003 Contact: Content-Type: message/sipfrag Content-Length: (appropriate value) SIP/2.0 202 Accepted F4 INVITE sip:D.example SIP/2.0 Via: SIP/2.0/UDP C.example;branch=z9hG4bK29348234 To: From: ;tag=023942334 Call-ID: 23489020352@C.example CSeq: 1230934 INVITE Max-Forwards: 70 Contact: Referred-By: ; cid="23094202342.10123091233@A.example" Content-Type: multipart/mixed; boundary=unique-boundary-1 Content-Length: (appropriate value) --unique-boundary-1 Content-Type: application/sdp Content-Length: (appropriate value) v=0 o=C 2890844526 2890844526 IN IP4 C.example s=Session SDP c=IN IP4 C.example t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --unique-boundary-1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=dragons39 Content-ID: <23094202342.10123091233@A.example> Content-Length: (appropriate value) --dragons39 Content-Type: message/sipfrag Content-Disposition: aib; handling=optional Date: Thu, 21 Feb 2002 13:02:03 GMT Refer-To: "> Referred-By: ; cid="23094202342.1012309123@A.example" --dragons39 Sparks Expires February 4, 2004 [Page 22] Internet-Draft The SIP Referred-By Mechanism August 2003 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required (appropriate signature goes here) --dragons39-- --unique-boundary-1-- 8. IANA Considerations (Note to RFC Editor: Please fill in all occurrences of XXXX in this section with the RFC number of this specification). This document defines a new SIP header field name with a compact form (Referred-By and b respectively). It also defines an new SIP client error response code (429). The following changes should be made to http:///www.iana.org/ assignments/sip-parameters The following row should be added to the header field section (replacing any existing row for Referred-By). Header Name Compact Form Reference Referred-By b [RFCXXXX] The following row should be added to the response code section under the Request Failure 4xx heading 429 Provide Referrer Identity [RFCXXXX] 9. Contributors Rohan Mahy distilled RFC2822's msg-id into this document's definition of sip-clean-msg-id. Normative References [1] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [2] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", draft-ietf-sip-authid-body-02 (work in progress), July 2003. Sparks Expires February 4, 2004 [Page 23] Internet-Draft The SIP Referred-By Mechanism August 2003 [3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. Informative References [6] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft- ietf-sip-identity-01 (work in progress), March 2003. [7] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in progress), February 2003. [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001. Author's Address Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: rsparks@dynamicsoft.com Sparks Expires February 4, 2004 [Page 24] Internet-Draft The SIP Referred-By Mechanism August 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Sparks Expires February 4, 2004 [Page 25]