by the referee, and the considerations discussed for a 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 [7].
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 [5].
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
referenced 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
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: <sip:referrer.example>
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;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
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
Date: Thu, 21 Feb 2002 13:02:03 GMT
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;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: <sip:refertarget@target.example>
From: <sip:referee@referee.example>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Max-Forwards: 70
Contact: <sip:referee@referee.example>
Referred-By: <sip:referrer@referrer.example>
;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
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: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;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.
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: <sip:referrer.example>
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
Content-Length: 0
F2 INVITE sip:refertarget@target.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bKffe209934aac
To: <sip:refertarget@target.example>
From: <sip:referee@referee.example>;tag=2909034023
Call-ID: fe9023940-a3465@referee.example
CSeq: 889823409 INVITE
Max-Forwards: 70
Contact: <sip:referee@referee.example>
Referred-By: <sip:referrer@referrer.example>
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.
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: <sip:refertarget@target.example>;tag=392093422302334
From: <sip:referee@referee.example>;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: <sip:referrer@referrer.example>;tag=39092342
From: <sip:referee@referee.example>;tag=199949923
Call-ID: 2203900ef0299349d9209f023a
CSeq: 3920390 NOTIFY
Event: refer;id=1239930
Subscription-State: terminated
Content-Type: message/sipfrag
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: <sip:referee@referee.example>
From: <sip:referrer@referrer.example>;tag=39092342
Call-ID: 2203900ef0299349d9209f023a
CSeq: 1239931 REFER
Max-Forwards: 70
Contact: <sip:referrer.example>
Refer-To: <sip:refertarget@target.example>
Referred-By: <sip:referrer@referrer.example>
;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: <sip:refertarget@target.example> *
* Referred-By: <sip:referrer@referrer.example> *
* ;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--
F6 INVITE sip:refertarget@target.example SIP/2.0
Via: SIP/2.0/UDP referee.example;branch=z9hG4bK3920390423
To: <sip:refertarget@target.example>
From: <sip:referee@referee.example>;tag=1342093482342
Call-ID: 23499234-9239842993@referee.example
CSeq: 19309423 INVITE
Max-Forwards: 70
Referred-By: <sip:referrer@referrer.example>
;cid="20342EFXEI.390sdefn2@referrer.example"
Contact: <sip:referee@referee.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=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: <sip:refertarget@target.example> *
* Referred-By: <sip:referrer@referrer.example> *
* ;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: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
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 |
| | NOTIFY |<------------------|
| |<------------------| ACK |
| | 200 OK |------------------>|
| |------------------>| |
| | | |
F1 REFER sip:B SIP/2.0
Via: SIP/2.0/UDP A.example;branch=z9hG4bK3802394232
To: <sip:B.example>
From: <sip:A.example>;tag=23490234
Call-ID: 2304098023@A.example
CSeq: 2342093 REFER
Max-Forwards: 70
Contact: <sip:A.example>
Refer-To: <sip:C.example;method=REFER?Refer-To="<sip:D>.example">
Referred-By: <sip:A.example>;
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: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
Referred-By: <sip:A.example>;
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
Via: SIP/2.0/UDP B.example;branch=z9hG4bK00239842
To: <sip:C.example>
From: <sip:B.example>;tag=2934u23
Call-ID: 203942834@B.example
CSeq: 8321039 REFER
Max-Forwards: 70
Contact: <sip:B.example>
Refer-To: <sip:D.example>
Referred-By: <sip:A.example>;
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: <sip:C.example;method=REFER?Refer-To="<sip:D.example>">
Referred-By: <sip:A.example>;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: <sip:A.example>;tag=23490234