[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 3892

Network Working Group                                          R. Sparks
Internet-Draft                                               dynamicsoft
Expires: November 20, 2002                                  May 22, 2002


                       The Referred-By Mechanism
                      draft-ietf-sip-referredby-00

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 November 20, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   The SIP REFER method [2] provides a mechanism where one party (the
   referror) provides a second party (the referree) with an arbitrary
   URI to reference.  If that URI is a SIP URI, the referree will send a
   SIP request, often an INVITE, to that URI (the refer target).  This
   document extends the REFER method allowing the referror to provide
   information about the reference to the refer target using the
   referree as an intermediary.  This information includes the identity
   of the referror and the URI to which the referror 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 November 20, 2002               [Page 1]

Internet-Draft          The Referred-By Mechanism               May 2002


Table of Contents

   1.    Overview . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    The Referred-By Mechanism  . . . . . . . . . . . . . . . . .  4
   2.1   Referror behavior  . . . . . . . . . . . . . . . . . . . . .  4
   2.2   Referree behavior  . . . . . . . . . . . . . . . . . . . . .  5
   2.2.1 OPEN ISSUE - changing Content-ID . . . . . . . . . . . . . .  5
   2.3   Refer Target behavior  . . . . . . . . . . . . . . . . . . .  5
   3.    The Referred-By Header Field . . . . . . . . . . . . . . . .  6
   3.1   OPEN ISSUE - remove the support table  . . . . . . . . . . .  6
   4.    The Referred-By Token  . . . . . . . . . . . . . . . . . . .  7
   5.    The 429 Provide Referror Identity error response . . . . . .  7
   6.    Security Considerations  . . . . . . . . . . . . . . . . . .  7
   7.    Using an Authentication Service  . . . . . . . . . . . . . .  9
   8.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.1   Basic REFER  . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.2   Insecure REFER . . . . . . . . . . . . . . . . . . . . . . . 12
   8.3   Requiring Referror Identity  . . . . . . . . . . . . . . . . 13
   8.4   Nested REFER . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 20
   10.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . 21
         References . . . . . . . . . . . . . . . . . . . . . . . . . 21
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 22
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 23



























Sparks                  Expires November 20, 2002               [Page 2]

Internet-Draft          The Referred-By Mechanism               May 2002


1. Overview

   The SIP REFER method [2] provides a mechanism where one party (the
   referror) provides a second party (the referree) with an arbitrary
   URI to reference.  If that URI is a SIP URI, the referree 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 referree might have sent to the refer target.

   ---------------------------------------------------------------------


      Referror           Referree            Refer Target
         |                  |                    |
         | REFER            |                    |
         | Refer-To: target |                    |
         |----------------->| INVITE target      |
         |                  |------------------->|

                             Classic REFER

   ---------------------------------------------------------------------

   There are applications of REFER, such as call transfer [4], where it
   is desirable to provide the refer target with certain information
   about the referror and the REFER request itself.  This information
   may include, but is not limited to, the referror'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 referree 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 referror'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 referree, 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 referror and
   capturing other information about the REFER request, allowing the
   refer target to detect tampering (and other undesirable behaviors) by
   the referree.  Finally, the draft discusses how an authentication
   service as defined in [5] may be used to generate that S/MIME



Sparks                  Expires November 20, 2002               [Page 3]

Internet-Draft          The Referred-By Mechanism               May 2002


   content.

2. The Referred-By Mechanism

   The following figure summarizes how Referred-By information is
   carried to the Refer Target.  The Referror provides a Referred-By
   header with its SIP identity, optionally associating an S/MIME
   protected token reflecting the identity of the referror and details
   of the REFER request.  The Referree copies this header and the token,
   if provided, into the triggered request (shown here as an INVITE).

   ---------------------------------------------------------------------


    Referror                       Referree                   Refer Target
       |                              |                             |
       | REFER                        |                             |
       | Refer-To: target             |                             |
       | Referred-By: referror;cid=X  |                             |
       |                              |                             |
       | (one of the body parts is)   |                             |
       | Content-ID: X                |                             |
       | <Referred-By Token>          |                             |
       |----------------------------->|                             |
       |                              | INVITE target               |
       |                              | Referred-By: referror;cid=X |
       |                              |                             |
       |                              | (one of the body parts is)  |
       |                              | Content-ID: X               |
       |                              | <Referred-By token>         |
       |                              |---------------------------->|

                         REFER with Referred-By

   ---------------------------------------------------------------------


2.1 Referror behavior

   A UA sending a REFER request (a referror) 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 referror 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.




Sparks                  Expires November 20, 2002               [Page 4]

Internet-Draft          The Referred-By Mechanism               May 2002


   The referror will receive a NOTIFY with a sipfrag indicating a final
   response of 429 "Provide Referror Identity" to the referrenced
   request if the refer target requires a valid Referred-By token to
   accept the request.  The can occur when either no token is provided
   or a provided token is invalid.

   The referror will recieve a 429 "Provide Referror Identity" response
   to the REFER if the referee requires a Referred-By token to be
   present in order to accept the REFER.

2.2 Referree behavior

   A UA receiving a REFER request (a referree) to a SIP URI (using
   either the sip: or sips: scheme) MUST copy any Referred-By header
   field value and token into the referrenced request without
   modification.  [5]


2.2.1 OPEN ISSUE - changing Content-ID

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 referree
   might have sent.  Thus, the UA would apply exactly the admissions
   policies and processing described in [1] 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 referror 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 Referror
   Identity" error response defined in Section 5.  The 428 error
   response from [5] is not appropriate for this purpose - it is needed
   for the refer target to request an authentication token from the
   referee.



Sparks                  Expires November 20, 2002               [Page 5]

Internet-Draft          The Referred-By Mechanism               May 2002


   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 requst,
   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 [1].  It can
   appear in any request.  It carries a SIP URI representing the
   identity of the referror 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 msg-id

        msg-id = TO BE INCORPORATED from rfc2822 (at great pain)



                           Referred-By Syntax

   ---------------------------------------------------------------------

   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.

3.1 OPEN ISSUE - remove the support table

   Is this form of table still useful? It is inherently obsolete.  I
   propose removing it leaving only the text above paragraph.

   The following row should be interpreted as if it appeared in Table 3
   of RFC 3261.



Sparks                  Expires November 20, 2002               [Page 6]

Internet-Draft          The Referred-By Mechanism               May 2002


       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
   [5].  This body part MUST be identified with a MIME [6] Content-ID:
   field.

   In addition to the From, Date, and Call-ID header fields required by
   [5], the sipfrag inside a Referred-By token MUST contain copies of
   the Refer-To and Referred-By header fields from the REFER request.
   As in [5] additional header fields and body parts MAY be included.

   As described in [5], a Referred-By token MAY be encrypted as well as
   signed.

   A Referred-By token is judged suspect or valid using the criteria in
   [5] with the addition that the mandatory headers enumerated in this
   document MUST be included in the validity test.

5. The 429 Provide Referror Identity error response

6. Security Considerations

   This mechanism defined in this specification relies on an
   intermediary (the referree) to forward information from the referror
   to the refer target.  This necessarily establishes the referree 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 [1].  In contrast to
   a proxy,  the referree'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 referree 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
   referree.  Use of this protection is optional! The community has
   asserted that there are systems where trust in the validity of this



Sparks                  Expires November 20, 2002               [Page 7]

Internet-Draft          The Referred-By Mechanism               May 2002


   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 referree 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 referree's ability to inject or modify
      information without knowing the key used for that signature).

   o  A referree 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 referree 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 referree from
   deleting ALL referred-by information from the referrenced request.  A
   refer target can not detect such deletion.  This is not a problem
   since removing all referred-by information from a referrenced request
   transforms it into an ordinary SIP request as described in [1].  Thus
   the referree gains no new influence over processing logic at the
   refer target by removing the referred-by information.

   Applications using the mechanims 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 messages between three endpoints, the
   REFER and the referrenced request.  The content of those messages
   (including the referred-by information) is subject to the security
   considerations and protection mechanisms documented in [1].

   This mechanism uses an Authenticated Identity Body as defined in [5].
   The security considerations and protection mechanisms described in
   that document apply.



Sparks                  Expires November 20, 2002               [Page 8]

Internet-Draft          The Referred-By Mechanism               May 2002


   Proxies between the participants may collect referred-by information
   and reinsert it in future request or make them available to hostile
   endpoints.  The end-to-end confidentiality capabilities discussed in
   [1] can help reduce 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 referree and the refer target are identical to abuse by
   the referree and the considerations discussed for malicious referree
   applies.  The abuse possibilities in subsequent requests by proxies
   (or endpoints that they may leak information to) between the referror
   and the referree are identical to those discussed for the
   presentation of Authenticated Identity Bodies in [5].

7. Using an Authentication Service

   This section will discuss considerations for using an Authentication
   Service to create a Referred-By token beyond those documented in [5]

8. Examples

8.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.


     Referror                    Referree                   Refer Target
        | F1 REFER                  |                            |
        |-------------------------->|                            |
        | 202 Accepted              |                            |
        |<--------------------------|                            |
        |                           | F2 INVITE                  |
        |                           |--------------------------->|
        |                           | 200 OK                     |
        |                           |<---------------------------|
        |                           | ACK                        |
        | NOTIFY                    |--------------------------->|
        |<--------------------------|                            |
        | 200 OK                    |                            |
        |-------------------------->|                            |
        |                           |                            |

    F1 REFER sip:referree@referree.example SIP/2.0
       Via: SIP/2.0/UDP referror.example;branch=z9hG4bK392039842
       To: sip:referree@referree.example



Sparks                  Expires November 20, 2002               [Page 9]

Internet-Draft          The Referred-By Mechanism               May 2002


       From: sip:referror@referror.example;tag=39092342
       Call-ID: 2203900ef0299349d9209f023a
       CSeq: 1239930 REFER
       Max-Forwards: 70
       Contact: <sip:referror.example>
       Refer-To: sip:refertarget@target.example
       Referred-By: sip:referror@referror.example
          ;cid=%3C20398823.2UWQFN309shb3@referror.example%3E
       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@referror.example>
       Content-Length: (appropriate value)

       --dragons39
       Content-Type: message/sipfrag
       Content-Disposition: auth-id; handling=optional

       From: sip:referror@referror.example
       Date: Thu, 21 Feb 2002 13:02:03 GMT
       Call-ID: 2203900ef0299349d9209f023a
       Refer-To: sip:refertarget@target.example
       Referred-By: sip:referror@referror.example
          ;cid=%3C20398823.2UWQFN309shb3@referror.example%3E

       --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 referree.example;branch=z9hG4bKffe209934aac
       To: sip:refertarget@target.example
       From: sip:referree@referree.example;tag=2909034023
       Call-ID: fe9023940-a3465@referree.example
       CSeq: 889823409 INVITE



Sparks                  Expires November 20, 2002              [Page 10]

Internet-Draft          The Referred-By Mechanism               May 2002


       Max-Forwards: 70
       Contact: <sip:referree@referee.example>
       Referred-By: sip:referror@referror.example
          ;cid=%3C20398823.2UWQFN309shb3@referror.example%3E
       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=referree 2890844526 2890844526 IN IP4 referree.example
       s=Session SDP
       c=IN IP4 referree.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@referror.example>
       Content-Length: (appropriate value)

       --dragons39
       Content-Type: message/sipfrag
       Content-Disposition: auth-id; handling=optional

       From: sip:referror@referror.example
       Date: Thu, 21 Feb 2002 13:02:03 GMT
       Call-ID: 2203900ef0299349d9209f023a
       Refer-To: sip:refertarget@target.example
       Referred-By: sip:referror@referror.example
          ;cid=%3C20398823.2UWQFN309shb3@referror.example%3E

       --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--



Sparks                  Expires November 20, 2002              [Page 11]

Internet-Draft          The Referred-By Mechanism               May 2002


       --my-boundary-9--


8.2 Insecure REFER

   The flow for this example is the same as that of Section 8.1.  Here,
   the referror has opted to not include a Referred-By token, and the
   refer target is willing to accept the referrenced request without
   one.



    F1 REFER sip:referree@referree.example SIP/2.0
       Via: SIP/2.0/UDP referror.example;branch=z9hG4bK392039842
       To: sip:referree@referree.example
       From: sip:referror@referror.example;tag=39092342
       Call-ID: 2203900ef0299349d9209f023a
       CSeq: 1239930 REFER
       Max-Forwards: 70
       Contact: <sip:referror.example>
       Refer-To: sip:refertarget@target.example
       Referred-By: sip:referror@referror.example
       Content-Length: 0

    F2 INVITE sip:refertarget@target.example SIP/2.0
       Via: SIP/2.0/UDP referree.example;branch=z9hG4bKffe209934aac
       To: sip:refertarget@target.example
       From: sip:referree@referree.example;tag=2909034023
       Call-ID: fe9023940-a3465@referree.example
       CSeq: 889823409 INVITE
       Max-Forwards: 70
       Contact: <sip:referree@referee.example>
       Referred-By: sip:referror@referror.example
       Content-Type: application/sdp
       Content-Length: (appropriate value)

       v=0
       o=referree 2890844526 2890844526 IN IP4 referree.example
       s=Session SDP
       c=IN IP4 referree.example
       t=0 0
       m=audio 49172 RTP/AVP 0
       a=rtpmap:0 PCMU/8000








Sparks                  Expires November 20, 2002              [Page 12]

Internet-Draft          The Referred-By Mechanism               May 2002


8.3 Requiring Referror Identity

   In contrast to the example in Section 8.2, the refer target requires
   a Referred-By token to accept the referrenced request.  The referror
   choses 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 8.2.


     Referror                    Referree                   Refer Target
        | F1 REFER                  |                            |
        |-------------------------->|                            |
        | 202 Accepted              |                            |
        |<--------------------------|                            |
        |                           | F2 INVITE                  |
        |                           |--------------------------->|
        |                           | F3 429 Provide Referror Identity
        |                           |<---------------------------|
        |                           | ACK                        |
        | F4 NOTIFY                 |--------------------------->|
        |<--------------------------|                            |
        | 200 OK                    |                            |
        |-------------------------->|                            |
        | F5 REFER                  |                            |
        |-------------------------->|                            |
        | 202 Accepted              |                            |
        |<--------------------------|                            |
        |                           | F6 INVITE                  |
        |                           |--------------------------->|
        |                           | 200 OK                     |
        |                           |<---------------------------|
        |                           | ACK                        |
        | NOTIFY                    |--------------------------->|
        |<--------------------------|                            |
        | 200 OK                    |                            |
        |-------------------------->|                            |
        |                           |                            |

    F3 SIP/2.0 429 Provide Referror Identity
       Via: SIP/2.0/UDP referree.example;branch=z9hG4bKffe209934aac
       To: sip:refertarget@target.example;tag=392093422302334
       From: sip:referree@referree.example;tag=2909034023
       Call-ID: fe9023940-a3465@referree.example
       CSeq: 889823409 INVITE
       Content-Length: 0

    F4 NOTIFY sip:referror@referror.example SIP/2.0
       Via: SIP/2.0/UDP referree.example;branch=z9hG4bK2934209da390



Sparks                  Expires November 20, 2002              [Page 13]

Internet-Draft          The Referred-By Mechanism               May 2002


       To: sip:referror@referror.example;tag=39092342
       From: sip:referree@referree.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 Referror Identity

    F5 REFER sip:referree@referree.example SIP/2.0
       Via: SIP/2.0/UDP referror.example;branch=z9hG4bK98823423
       To: sip:referree@referree.example
       From: sip:referror@referror.example;tag=39092342
       Call-ID: 2203900ef0299349d9209f023a
       CSeq: 1239931 REFER
       Max-Forwards: 70
       Contact: <sip:referror.example>
       Refer-To: sip:refertarget@target.example
       Referred-By: sip:referror@referror.example
          ;cid=%3C20342EFXEI.390sdefn2@referror.example%3E
       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@referror.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: auth-id; handling=optional         *
       *                                                         *
       * From: sip:referror@referror.example                     *
       * Call-ID: 2203900ef0299349d9209f023a                     *



Sparks                  Expires November 20, 2002              [Page 14]

Internet-Draft          The Referred-By Mechanism               May 2002


       * Date: Thu, 21 Feb 2002 13:02:03 GMT                     *
       * Refer-To: sip:refertarget@target.example                *
       * Referred-By: sip:referror@referror.example              *
       *    ;cid=%3C20342EFXEI.390sdefn2@referror.example%3E     *
       ***********************************************************

       --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 referree.example;branch=z9hG4bK3920390423
       To: sip:refertarget@target.example
       From: sip:referree@referree.example;tag=1342093482342
       Call-ID: 23499234-9239842993@referree.example
       CSeq: 19309423 INVITE
       Max-Forwards: 70
       Referred-By: sip:referror@referror.example
          ;cid=%3C20342EFXEI.390sdefn2@referror.example%3E
       Contact: <sip:referree@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=referree 2890844526 2890844526 IN IP4 referree.example
       s=Session SDP
       c=IN IP4 referree.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



Sparks                  Expires November 20, 2002              [Page 15]

Internet-Draft          The Referred-By Mechanism               May 2002


       Content-ID: <20342EFXEI.390sdefn2@referror.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: auth-id; handling=optional         *
       *                                                         *
       * From: sip:referror@referror.example                     *
       * Call-ID: 2203900ef0299349d9209f023a                     *
       * Date: Thu, 21 Feb 2002 13:02:03 GMT                     *
       * Refer-To: sip:refertarget@target.example                *
       * Referred-By: sip:referror@referror.example              *
       *    ;cid=%3C20342EFXEI.390sdefn2@referror.example%3E     *
       ***********************************************************

       --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--


8.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).




Sparks                  Expires November 20, 2002              [Page 16]

Internet-Draft          The Referred-By Mechanism               May 2002


    Refer-To: <sip:C;method=REFER?Refer-To=%3Csip:D%3E>

    This reference would result in the following flow:


     A                   B                   C                   D
     | F1 REFER          |                   |                   |
     |------------------>|                   |                   |
     | 202 Accepted      |                   |                   |
     |<------------------|                   |                   |
     |                   | F2 REFER          |                   |
     |                   |------------------>|                   |
     |                   | 202 Accepted      |                   |
     |                   |<------------------|                   |
     | F3 NOTIFY         |                   | F4 INVITE         |
     |<------------------|                   |------------------>|
     | 200 OK            |                   | 200 OK            |
     |------------------>|                   |<------------------|
     |                   |                   | ACK               |
     |                   |                   |------------------>|
     |                   | NOTIFY            |                   |
     |                   |<------------------|                   |
     |                   | 200 OK            |                   |
     |                   |------------------>|                   |
     |                   |                   |                   |

    F1 REFER sip:B SIP/2.0
       Via: SIP/2.0/UDP A;branch=z9hG4bK3802394232
       To: sip:B
       From: sip:A;tag=23490234
       Call-ID: 2304098023@A
       CSeq: 2342093 REFER
       Max-Forwards: 70
       Contact: <sip:A>
       Refer-To: <sip:C;method=REFER?Refer-To=%3Csip:D%3E>
       Referred-By: <sip:A>;cid=%3C23094202342.10123091233@A%3E
       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>
       Content-Length: (appropriate value)

       --dragons39



Sparks                  Expires November 20, 2002              [Page 17]

Internet-Draft          The Referred-By Mechanism               May 2002


       Content-Type: message/sipfrag
       Content-Disposition: auth-id; handling=optional

       From: sip:A
       Call-ID: 2304098023@A
       Date: Thu, 21 Feb 2002 13:02:03 GMT
       Refer-To: <sip:C;method=REFER?Refer-To=%3Csip:D%3E>
       Referred-By: <sip:A>;cid=%3C23094202342.101230912342A%3E

       --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 SIP/2.0
       Via: SIP/2.0/UDP B;branch=z9hG4bK00239842
       To: sip:C
       From: sip:B;tag=2934u23
       Call-ID: 203942834@B
       CSeq: 8321039 REFER
       Max-Forwards: 70
       Contact: <sip:B>
       Refer-To: <sip:D>
       Referred-By: <sip:A>;cid=%3C23094202342.10123091233@A%3E
       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>
       Content-Length: (appropriate value)

       --dragons39
       Content-Type: message/sipfrag
       Content-Disposition: auth-id; handling=optional

       From: sip:A
       Call-ID: 2304098023@A



Sparks                  Expires November 20, 2002              [Page 18]

Internet-Draft          The Referred-By Mechanism               May 2002


       Date: Thu, 21 Feb 2002 13:02:03 GMT
       Refer-To: <sip:C;method=REFER?Refer-To=%3Csip:D%3E>
       Referred-By: <sip:A>;cid=%3C23094202342.101230912342A%3E

       --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 SIP/2.0
       Via: SIP/2.0/UDP A;branch=z9hG4bK3802394232
       To: sip:A;tag=23490234
       From: sip:B;tag=5923020
       Call-ID: 2304098023@A
       CSeq: 29420342 NOTIFY
       Event: refer;id=2342093
       Subscription-State: terminated
       Max-Forwards: 70
       Contact: <sip:B>
       Content-Type: message/sipfrag
       Content-Length: (appropriate value)

       SIP/2.0 202 Accepted

    F4 INVITE sip:D SIP/2.0
       Via: SIP/2.0/UDP C;branch=z9hG4bK29348234
       To: sip:D
       From: sip:C;tag=023942334
       Call-ID: 23489020352@C
       CSeq: 1230934 INVITE
       Max-Forwards: 70
       Contact: <sip:C>
       Referred-By: <sip:A>;cid=%3C23094202342.10123091233@A%3E
       Content-Type: multipart/mixed; boundary=unique-boundary-1
       Content-Length: (appropriate value)

       --unique-boundary-1

       Content-Type: application/sdp
       Content-Length: (appropriate value)




Sparks                  Expires November 20, 2002              [Page 19]

Internet-Draft          The Referred-By Mechanism               May 2002


       v=0
       o=C 2890844526 2890844526 IN IP4 C
       s=Session SDP
       c=IN IP4 C
       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>
       Content-Length: (appropriate value)

       --dragons39
       Content-Type: message/sipfrag
       Content-Disposition: auth-id; handling=optional

       From: sip:A
       Call-ID: 2304098023@A
       Date: Thu, 21 Feb 2002 13:02:03 GMT
       Refer-To: <sip:C;method=REFER?Refer-To=%3Csip:D%3E>
       Referred-By: <sip:A>;cid=%3C23094202342.101230912342A%3E

       --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--



9. IANA Considerations

   (Note to RFC Editor: Please fill in all occurances 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).



Sparks                  Expires November 20, 2002              [Page 20]

Internet-Draft          The Referred-By Mechanism               May 2002


   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 Referror Identity                     [RFCXXXX]


10. Open Issues

   1.  Should referrees be allowed to change the content-id of a
       Referred-By token as they copy it into the referrenced request?
       See Section 2.2.1.

   2.  Can we remove the inherently incomplete header support table in
       favor of short descriptive text.  See Section 3.1.

   3.  This mechanism proves to the target that the referror sent a
       REFER with this particular Refer-To and Referred-By header field
       values.  It DOES NOT prove to the target that the referror sent
       that REFER to this particular referree (which may enable an
       intercept/cut-paste attack).  Including the REFER start line (the
       Request-URI in particular) is not sufficient to tightne this up -
       location services may arbitrarily retarget the REFER and the
       target will generally have no way to reconcile the REFER Request-
       URI with the actual identity of the referree.  Do we need to
       tighten this? If so, I beleive the solution needs to lie in the
       peterson-identity mechanism.  The same attack applies to that
       mechanism in general, resulting in theft of identity.

References

   [1]  PlaceHolder, A., "Placeholder", RFC 3261, placeholder 2002.

   [2]  PlaceHolder, A., "Placeholder", draft-ietf-sip-refer (work in
        progress), placeholder 2002.

   [3]  PlaceHolder, A., "Placeholder", draft-sparks-sip-mimetypes (work
        in progress), placeholder 2002.

   [4]  PlaceHolder, A., "Placeholder", draft-ietf-sipping-cc-transfer-



Sparks                  Expires November 20, 2002              [Page 21]

Internet-Draft          The Referred-By Mechanism               May 2002


        00 (work in progress), placeholder 2002.

   [5]  PlaceHolder, A., "Placeholder", draft-peterson-sip-identity-00
        (work in progress), placeholder 2002.

   [6]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.


Author's Address

   Robert J. Sparks
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024

   EMail: rsparks@dynamicsoft.com
































Sparks                  Expires November 20, 2002              [Page 22]

Internet-Draft          The Referred-By Mechanism               May 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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 November 20, 2002              [Page 23]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/