Request for Comments: 3892 Xten
Category: Standards Track September 2004
The Session Initiation Protocol (SIP) Referred-By Mechanism
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The Session Initiation Protocol (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.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . 3
2. The Referred-By Mechanism . . . . . . . . . . . . . . . . . . 3
2.1. Referrer Behavior . . . . . . . . . . . . . . . . . . . 4
2.2. Referee Behavior . . . . . . . . . . . . . . . . . . . . 4
2.3. Refer Target Behavior . . . . . . . . . . . . . . . . . 5
3. The Referred-By Header Field . . . . . . . . . . . . . . . . . 6
4. The Referred-By Token . . . . . . . . . . . . . . . . . . . . 7
4.1. Refer Target Inspection of a Referred-By Token . . . . . 8
5. The 429 Provide Referrer Identity Error Response . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Identifying the Referee in the Referred-by Token . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Basic REFER . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Insecure REFER . . . . . . . . . . . . . . . . . . . . . 14
7.3. Requiring Referrer Identity . . . . . . . . . . . . . . 14
7.4. Nested REFER . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
11. Author’s Address . . . . . . . . . . . . . . . . . . . . . . . 24
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
1. Overview
The SIP REFER method [2] 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 [2] 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 |
| |------------------->|
There are applications of REFER, such as call transfer [8], where it
is desirable to provide the refer target with particular 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 document defines one set of mechanisms to provide that
information.
All of the mechanisms in this document 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 document 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 document 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.
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [1].
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
the 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 | |
| <Referred-By Token> | |
|----------------------------->| |
| | INVITE target |
| | Referred-By: referrer;cid=X |
| | |
| | (one of the body parts is) |
| | Content-ID: X |
| | <Referred-By token> |
| |---------------------------->|
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 [4] body
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 re-attempt 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 simply because it cannot
decrypt the token. (One scenario where such rejection would be
appropriate is when the referee is attempting to remain anonymous
(see Section 6.1).) Note that per [3], 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 cannot
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 [5] 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
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 [7] 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 [5]. 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.
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 / "-" / "!" / "%" / "*" /
"_" / "+" / "’" / "`" / "~" )
Since the Content-ID appears as a SIP header parameter value which
must conform to the expansion of the gen-value defined in [5], this
grammar produces values in the intersection of the expansions of
gen-value and msg-id from [9]. 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>
If the referrer-uri contains a comma, question mark, or semicolon,
(for example, if it contains URI parameters) the URI MUST be enclosed
in angle brackets (< and >). Any URI parameters are contained within
these brackets. If the URI is not enclosed in angle brackets, any
semicolon-delimited parameters are header-parameters, not URI
parameters.
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
4. The Referred-By Token
The Referred-By token is an Authenticated Identity Body as defined by
[3]. This body part MUST be identified with a MIME [6] 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 [5].
When inspecting the certificates used to establish TLS associations,
the identity asserted in the token’s To header field URI is compared
to the subjectAltNames from the referee’s certificate. The sip and
sips URI schemes MUST be treated as equivalent for this comparison.
If the URI is an exact match, confidence in the authentication is
high and the To header field MAY be added to the token. If the
certificate subjects contain only a hostname matching the hostname
portion of the URI, an application level warning SHOULD be issued to
the referrer agent’s user seeking that user’s consent before
including the To header field in the token.
Including the To header field in the token 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 [3], 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 re-targeting 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
signing certificate, reporting discrepancies to its user as described
in [3].
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 [7] 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
The 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 [5]. 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
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
[5]. 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 of a
malicious referee removing a token (leaving an unsecured identity in
the Referred-By header field) by using the 429 error response.
Applications using the mechanisms in this document 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 [5].
Proxies between the participants may collect referred-by information
and re-insert it in future requests or make it available to hostile
endpoints. The end-to-end confidentiality capabilities discussed in
[5] can help reduce the risk of exposing sensitive referred-by
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 the abuse