[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
SIPPING                                                     J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: August 29, 2006                               G. Camarillo, Ed.
                                                                Ericsson
                                                               D. Willis
                                                           Cisco Systems
                                                       February 25, 2006


 A Framework for Consent-Based Communications in the Session Initiation
                             Protocol (SIP)
              draft-ietf-sipping-consent-framework-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 August 29, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Session Initiation Protocol (SIP) supports communications across
   many media types, including real-time audio, video, text, instant
   messaging, and presence.  In its current form, it allows session
   invitations, instant messages, and other requests to be delivered



Rosenberg, et al.        Expires August 29, 2006                [Page 1]


Internet-Draft              Consent Framework              February 2006


   from one party to another without requiring explicit consent of the
   recipient.  Without such consent, it is possible for SIP to be used
   for malicious purposes, including amplification and DoS (Denial of
   Service) attacks.  This document identifies a framework for consent-
   based communications in SIP.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Relays and Translations  . . . . . . . . . . . . . . . . . . .  3
   4.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Permissions at a Relay . . . . . . . . . . . . . . . . . .  6
     4.2.  Consenting Manipulations on a Relay's Transaction Logic  .  6
     4.3.  Permission Servers . . . . . . . . . . . . . . . . . . . .  7
     4.4.  Recipients Grant Permissions . . . . . . . . . . . . . . .  8
   5.  Overview of Operations . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Amplification Avoidance  . . . . . . . . . . . . . . . . . 10
     5.2.  Subscription to the Permission Status  . . . . . . . . . . 11
     5.3.  Request for Permission . . . . . . . . . . . . . . . . . . 11
     5.4.  Permission Document Structure  . . . . . . . . . . . . . . 11
     5.5.  Permission Requested Notification  . . . . . . . . . . . . 12
     5.6.  Permission Upload  . . . . . . . . . . . . . . . . . . . . 12
       5.6.1.  SIP Identity . . . . . . . . . . . . . . . . . . . . . 13
       5.6.2.  P-Asserted-Identity  . . . . . . . . . . . . . . . . . 13
       5.6.3.  Return Routability . . . . . . . . . . . . . . . . . . 13
     5.7.  Permission Granted Notification  . . . . . . . . . . . . . 14
     5.8.  Permission Revocation  . . . . . . . . . . . . . . . . . . 14
     5.9.  Request-contained URI Lists  . . . . . . . . . . . . . . . 15
     5.10. Registrations  . . . . . . . . . . . . . . . . . . . . . . 17
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 24













Rosenberg, et al.        Expires August 29, 2006                [Page 2]


Internet-Draft              Consent Framework              February 2006


1.  Introduction

   The Session Initiation Protocol (SIP) [1] supports communications
   across many media types, including real-time audio, video, text,
   instant messaging and presence.  This communication is established by
   the transmission of various SIP requests (such as INVITE and MESSAGE
   [4]) from an initiator to the recipient, with whom communication is
   desired.  Although a recipient of such a SIP request can reject the
   request, and therefore decline the session, a SIP network will
   deliver a SIP request to the recipient without their explicit
   consent.

   Receipt of these requests without explicit consent can cause a number
   of problems in SIP networks.  These include amplification and DoS
   (Denial of Service) attacks.  These problems are described in more
   detail in a companion requirements document [17].

   This specification defines a basic framework for adding consent-based
   communication to SIP.


2.  Definitions

   Recipient URI: The request-URI of an outgoing request sent by an
      entity (e.g., a user agent or a proxy).  The sending of such
      request may have been the result of a translation operation.

   Target URI: The request-URI of an incoming request that arrives to an
      entity (e.g., a proxy) that will perform a translation operation.

   Translation operation: Operation by which an entity (e.g., a proxy)
      translates the request URI of an incoming request (i.e., the
      target URI) into one or more URIs (i.e., recipient URIs) which are
      used as the request URIs of one or more outgoing requests.


3.  Relays and Translations

   Relays play a key role in this framework.  A relay is defined as any
   SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some
   hybrid, which receives a request and translates the request URI into
   one or more next hop URIs to which it then delivers a request.  The
   request URI of the incoming request is referred to as 'target URI'
   and the destination URI of the outgoing requests is referred to as
   'recipient URIs', as shown in Figure 1.






Rosenberg, et al.        Expires August 29, 2006                [Page 3]


Internet-Draft              Consent Framework              February 2006


                       +---------------+
                       |               |  recipient URI
                       |               |---------------->
           target URI  |  Translation  |
        -------------->|   Operation   |  recipient URI
                       |               |---------------->
                       |               |
                       +---------------+

   Figure 1: Translation operation

   Thus, an essential aspect of a relay is that of translation.  When a
   relay receives a request, it translates, following its translation
   logic, the request URI into one or more additional URIs.  Or, more
   generally, it can create outgoing requests to one or more additional
   URIs.  The translation operation is what creates the consent problem.

   Additionally, since the translation operation can result in more than
   one URI, it is also the source of amplification.  Servers that do not
   perform translations, such as outbound proxy servers, do not cause
   amplification.

   Since the translation operation is based on local policy or local
   data (such as registrations), it is the vehicle by which a request is
   delivered directly to an endpoint, when it would not otherwise be
   possible to.  In other words, if a spammer has the address of a user,
   'user@example.com', it cannot deliver a MESSAGE request to the UA
   (User Agent) of that user without having access to the registration
   data that maps 'user@example.com' to the user agent on which that
   user is present.  Thus, it is the usage of this registration data,
   and more generally, the translation logic, which must be authorized
   in order to prevent undesired communications.  (Of course, if the
   spammer knows the address of the user agent, it will be able to
   deliver requests directly to it.)

   Figure 2 shows a relay that performs translations.  The user agent
   client (UAC) in the figure sends a SIP request to a URI representing
   a resource in the domain 'example.com' (resource@example.com).  This
   request may pass through a local outbound proxy (not shown), but
   eventually arrives at a server authoritative for the domain
   'example.com'.  This server, which acts as a relay, performs a
   translation operation, translating the target URI into one or more
   recipient URIs, which may or may not belong to the domain
   'example.com'.  This relay may be, for instance, a proxy server or a
   URI-list service [18].






Rosenberg, et al.        Expires August 29, 2006                [Page 4]


Internet-Draft              Consent Framework              February 2006


                                                    +-------+
                                                    |       |
                                                   >|  UAS  |
                                                  / |       |
                                                 /  +-------+
                                                /
                                               /
                  +-----------------------+   /
                  |                       |  /
    +-----+       |         Relay         | /       +-------+
    |     |       |                       |/        |       |
    | UAC |------>|                       |-------->| Proxy |
    |     |       |+---------------------+|\        |       |
    +-----+       ||     Translation     || \       +-------+
                  ||        Logic        ||  \
                  |+---------------------+|   \       [...]
                  +-----------------------+    \
                                                \
                                                 \  +-------+
                                                  \ |       |
                                                   >| B2BUA |
                                                    |       |
                                                    +-------+

   Figure 2: Relay performing a translation

   This framework allows potential recipients of a translation to agree
   to be actual recipients by giving permission to the relay performing
   the translation to send them traffic.


4.  Architecture

   Figure 3 shows the architectural elements of this framework.
   Section 4.1 describes the role of permissions at a relay.
   Section 4.2 discusses the actions taken by a relay when its
   translation logic is manipulated by a client.  Section 4.3 introduces
   permission servers and their functionality.  Section 4.4 describes
   how potential recipients can grant permissions to a relay to add them
   to the relay's translation logic.











Rosenberg, et al.        Expires August 29, 2006                [Page 5]


Internet-Draft              Consent Framework              February 2006


                  +-----------------------+ Permission +------------+
                  |                       |  Request   |            |
   +--------+     |         Relay         |----------->| Permission |
   |        |     |                       |            |   Server   |
   | Client |     |                       |            |            |
   |        |     |+-------+ +-----------+|            +------------+
   +--------+     ||Transl.| |Permissions||                   |
       |          ||Logic  | |           ||        Permission |
       |          |+-------+ +-----------+|         Request   |
       |          +-----------------------+                   V
       |               ^           ^                   +------------+
       | Manipulation  |           |  Permission Grant |            |
       +---------------+           +-------------------| Recipient  |
                                                       |            |
                                                       +------------+

   Figure 3: Reference Architecture

4.1.  Permissions at a Relay

   Relays implementing this framework need to obtain and store
   permissions associated to their translation logics.  These
   permissions indicate if a particular recipient has agreed to receive
   traffic or not at any given time.  Recipients that have not given
   permission to the relay to send them traffic are simply ignored by
   the relay when performing a translation.

   Permissions are valid as long as the context where they were granted
   is valid.  For example, the permissions obtained by a URI-list SIP
   service that distributes MESSAGE requests to a set of recipients will
   be valid as long as the URI-list SIP service exists.

4.2.  Consenting Manipulations on a Relay's Transaction Logic

   This framework aims to ensure that any particular Relay only performs
   translations towards destinations that have given permission to the
   Relay to perform such a translation.  Consequently, when the
   translation logic of a relay is manipulated (e.g., a new recipient
   URI is added), the relay needs to obtain permission from the new
   recipient in order to install the new translation logic.  Relays ask
   recipients for permission using CONSENT [10] requests.

   For example, the relay hosting the URI-list service at
   'friends@example.com' performs a translation from that URI to a set
   of recipient URIs.  When a client (e.g., the administrator of that
   URI-list service) adds 'bob@example.org' as a new recipient URI, the
   relay sends a CONSENT request to 'bob@example.org' asking whether or
   not it is OK to perform the translation from 'friends@example.com' to



Rosenberg, et al.        Expires August 29, 2006                [Page 6]


Internet-Draft              Consent Framework              February 2006


   'bob@example.org' (CONSENT requests carry in their message bodies a
   permission document that describes the translation for which
   permissions are being requested).  If the answer is positive, the new
   translation logic is installed at the relay.  That is, the new
   recipient URI is added.

   Note that the mechanism to be used to manipulate the translation
   logic of a particular relay depends on the relay.  One possible
   mechanism to manipulate translation logic is XCAP [15].  Section 5.9
   and Section 5.10 describe how to add recipients to a translation
   using request-contained URI lists and REGISTER requests respectively.

   In any case, manipulation mechanisms implementing this framework need
   to have a means to indicate that a particular recipient URI is in the
   'Permission Pending' state and to provide the URI where the REFER
   request needs to be sent to.

4.3.  Permission Servers

   When a CONSENT request sent by a relay arrives to the recipient URI
   to which it was sent, the receiving user can grant or deny the
   permission needed to perform the translation.  Nevertheless, users
   are not on-line all the time and, so, sometimes are not able to
   receive CONSENT requests.

   This issue is also found in presence, where a user's status is
   reported by a presence server instead of by the user's user agents,
   which can go on and off-line.  Similarly, we define permission
   servers, which are a key element of this framework.  Permission
   servers are network elements that act as SIP user agents and handle
   CONSENT requests for a user.

   Permission servers inform users about new CONSENT requests using the
   'grant-permission' event package [12].  Figure 4 illustrates this
   point.

   The user associated with the recipient URI for which the relay will
   ask for permission subscribes [2] (1) to the 'grant-permission' event
   package at the permission server.  This event package models the
   state of all pending CONSENT requests for a particular resource.
   When a new CONSENT request (3) arrives to the permission server, a
   NOTIFY (5) is sent to the user.  This informs them that permission is
   needed for a particular sender.  The NOTIFY contains the permission
   document received in the CONSENT request.  This permission document
   is a description of the translation for which permissions are being
   requested.





Rosenberg, et al.        Expires August 29, 2006                [Page 7]


Internet-Draft              Consent Framework              February 2006


      There is a strong similarity between the 'winfo' event template-
      package [19] and the 'grant-permission' event package.  Indeed,
      the grant-permission package is effectively a superset of
      watcherinfo.  Once in place, presentities could use the grant-
      permission event package for presence in addition to all other
      services for which opt-in is being provided.


           Relay          B's Permission             B
                              Server
             |                   |(1) SUBSCRIBE      |
             |                   |Event: grant-permission
             |                   |<------------------|
             |                   |(2) 200 OK         |
             |                   |------------------>|
             |                   |(3) NOTIFY         |
             |                   |------------------>|
             |                   |(4) 200 OK         |
             |                   |<------------------|
             |(5) CONSENT B@example                  |
             |------------------>|                   |
             |(6) 202 Accepted   |                   |
             |<------------------|                   |
             |                   |(7) NOTIFY         |
             |                   |------------------>|
             |                   |(8) 200 OK         |
             |                   |<------------------|

   Figure 4: Permission server operation

4.4.  Recipients Grant Permissions

   Recipients provide relays with permissions using SIP PUBLISH
   requests.  These requests contain a permission document that
   describes the translation for which permissions are being granted.


5.  Overview of Operations

   This section provides an overview of this framework using an example
   of the prototypical call flow.  The elements described in Section 4
   (i.e., relays, translations, and permission servers) play an
   essential role in this call flow.

   Figure Figure 5 shows the complete process to add a recipient URI
   ('B@example.com') to the translation logic of a relay.  The call flow
   starts with user B subscribing to the permission server using the
   'grant-permission' event package [12].  User B will be informed about



Rosenberg, et al.        Expires August 29, 2006                [Page 8]


Internet-Draft              Consent Framework              February 2006


   the arrival of CONSENT [10] requests addressed to 'B@example.com'.

   User A attempts to add 'B@example.com' as a new recipient URI to the
   translation logic of the relay (5).  User A uses XCAP [15] and the
   XML (Extensible Markup Language) format for representing resource
   lists [16] as extended by [14] to perform this addition.  Since the
   relay does not have permission from 'B@example.com' to perform
   translations towards that URI, the relay places 'B@example.com' in
   the 'Pending' state [14] and informs user A (6).


       A@example.com        Relay       B's Permission    B@example.com
                                            Server
             |                |                |(1) SUBSCRIBE   |
             |                |                |Event: grant-permission
             |                |                |<---------------|
             |                |                |(2) 200 OK      |
             |                |                |--------------->|
             |                |                |(3) NOTIFY      |
             |                |                |--------------->|
             |                |                |(4) 200 OK      |
             |                |                |<---------------|
             |(5) Add Recipient B@example.com  |                |
             |--------------->|                |                |
             |(6) Permission Pending           |                |
             |<---------------|                |                |
             |(7) REFER       |                |                |
             |Refer-To: B@example.com?method=CONSENT            |
             |--------------->|                |                |
             |(8) 200 OK      |                |                |
             |<---------------|                |                |
             |(9) SUBSCRIBE   |                |                |
             |Event: list-state           |                |
             |--------------->|                |                |
             |(10) 200 OK     |                |                |
             |<---------------|                |                |
             |(11) NOTIFY     |                |                |
             |<---------------|                |                |
             |(12) 200 OK     |                |                |
             |--------------->|                |                |
             |                |(13) CONSENT B@example           |
             |                |Permission-Upload: uri-up        |
             |                |Permission Document              |
             |                |--------------->|                |
             |                |(14) 202 Accepted                |
             |                |<---------------|                |
             |                |                |(15) NOTIFY     |
             |                |                |uri-up          |



Rosenberg, et al.        Expires August 29, 2006                [Page 9]


Internet-Draft              Consent Framework              February 2006


             |                |                |Permission Document
             |                |                |--------------->|
             |                |                |(16) 200 OK     |
             |                |                |<---------------|
             |                |(17) PUBLISH uri-up              |
             |                |Permission Document              |
             |                |<--------------------------------|
             |                |(18) 200 OK     |                |
             |                |-------------------------------->|
             |(19) NOTIFY     |                |                |
             |<---------------|                |                |
             |(20) 200 OK     |                |                |
             |--------------->|                |                |

   Figure 5: Prototypical call flow

5.1.  Amplification Avoidance

   Once 'B@example.com' is in the 'Permission Pending' state, the relay
   needs to ask user B for permission by sending a CONSENT request to
   'B@example.com'.  However, the relay needs to ensure that it is not
   used as an amplifier to launch amplification attacks.

   In such an attack, the attacker would add a large number of recipient
   URIs to the translation logic of a relay.  The relay would then send
   a CONSENT request to each of those URIs.  The bandwidth generated by
   the relay would be much higher than the bandwidth used by the
   attacker to add those URIs to the translation logic of the relay.

   This framework uses a credit-based authorization mechanism to avoid
   the attack just described.  It requires users adding new recipient
   URIs to a translation to generate an amount of bandwidth that is
   comparable to the bandwidth the relay will generate when sending
   CONSENT requests towards those recipient URIs.  This requirement is
   met by having users generate REFER requests [5] towards the relay.
   Each REFER request triggers the sending of a CONSENT request by the
   relay.

   So, the relay sends user A the URI (6) where user A needs to send a
   REFER request.  User A generates such a REFER request (7) and sends
   it to the relay.  User A uses the 'norefersub' extension [7], which
   supresses the implicit subscription that is associated with REFER
   transactions.  This is because user A is not interested in the result
   of the CONSENT transaction, but in whether or not user B will
   authorize the translation by providing the requested permission.

   The relay provides a URI (6) where user A can subscribe to obtain
   information on whether or not user B provides the requested



Rosenberg, et al.        Expires August 29, 2006               [Page 10]


Internet-Draft              Consent Framework              February 2006


   permission.  User A subscribes to that URI using the 'list-state'
   [14] event package (9).

5.2.  Subscription to the Permission Status

   After sending the REFER (7) user A subscribes to the 'list-state'
   event package at the relay.  This subscription keeps user A informed
   about the status of the permissions (e.g., granted or denied) the
   relay will request on receiving the REFER request (7).

5.3.  Request for Permission

   On receiving the REFER request (7), the relay generates a CONSENT
   request (13) towards 'B@example.com'.  This CONSENT request carries a
   permission document, which describes the translation that needs to be
   authorized, and a URI where to upload the permission for that
   translation.  User B will authorize the translation by uploading the
   permission document received in the CONSENT request into this URI, as
   described in Section 5.6.

   When the permission document is uploaded to the URI provided by the
   relay (17), the relay needs to make sure that the permission document
   received was generated by user B and not by an attacker.  The relay
   can use three methods to authenticate the permission document: SIP
   identity, P-Asserted-Identity [3], or a return routability test.
   These methods are described in Section 5.6.  Relays using a return
   routability test to perform this authentication need to send the
   CONSENT request to a SIPS URI.

5.4.  Permission Document Structure

   A permission document is the XML representation of a permission.  A
   permission document contains several pieces of data:

   Identity of the Sender: A URI representing the identity of the sender
      for whom permissions are granted.

   Identity of the Original Recipient: A URI representing the identity
      of the original recipient, which is used as the input for the
      translation operation.  This is also called the target URI.

   Identity of the Final Recipient: A URI representing the result of the
      translation.  The permission grants ability for the sender to send
      requests to the target URI, and for a relay receiving those
      requests to forward them to this URI.  This is also called the
      recipient URI.





Rosenberg, et al.        Expires August 29, 2006               [Page 11]


Internet-Draft              Consent Framework              February 2006



   Signature: A digital signature over the rest of the permission,
      signed by an entity that can identify itself as the recipient URI.
      The signature is not always present.

   Permission documents may contain wildcards.  For example, a
   permission document may authorize any relay to forward requests
   coming from a particular sender to a particular recipient.  Such a
   permission document would apply to any target URI.  That is, the
   field containing the identity of the original recipient would match
   any URI.

   The format for permission documents is defined in [11].

   The permission document in the CONSENT request (13) sent by the relay
   contains the following values:

   Identity of the Sender: Any.

   Identity of the Original Recipient: friends@example.com

   Identity of the Final Recipient: B@example.com

   It is expected that the Sender field often contains a wildcard.
   However, scenarios involving request-contained URI lists, such as the
   one described in Section 5.9, may require permission documents that
   apply to a specific sender.  Of course, in cases where the identity
   of the sender matters, it is essential that relays authenticate
   senders.

5.5.  Permission Requested Notification

   On receiving the CONSENT request (13), B's permission server sends a
   NOTIFY request (15) to user B, who had previously subscribed to the
   grant-permission event package (1).  This NOTIFY request contains,
   the permission document, which describes the translation that needs
   to be authorized, and a URI where to upload the permission for that
   translation.  Both the permission document and the URI to upload the
   permission are copied from the CONSENT request (13) into the NOTIFY
   request (15).

5.6.  Permission Upload

   On receiving the NOTIFY request (15), user B authorizes the
   translation described in the permission document received by
   uploading this permission document to the relay.  User B uses a
   PUBLISH request (17) to upload the permission document to the URI
   received in the NOTIFY request.



Rosenberg, et al.        Expires August 29, 2006               [Page 12]


Internet-Draft              Consent Framework              February 2006


   When the permission document is uploaded to the URI provided by the
   relay (17), the relay needs to make sure that the permission document
   received was generated by user B and not by an attacker.  The relay
   can use three methods to authenticate the permission document: SIP
   identity, P-Asserted-Identity [3], or a return routability test.

5.6.1.  SIP Identity

   The SIP identity [8] mechanism can be used to authenticate the sender
   of the PUBLISH request uploading the permission document.  The relay
   checks that the originator of the PUBLISH request is the owner of the
   recipient URI in the permission document.  Otherwise, the permission
   document is discarded.

5.6.2.  P-Asserted-Identity

   The P-Asserted-Identity [3] mechanism can be used to authenticate the
   sender of the PUBLISH request uploading the permission document.
   However, as discussed in RFC 3325 [3], this mechanism should only be
   used within networks of trusted SIP servers.  That is, the use of
   this mechanism is only applicable inside an administrative domain
   with previously agreed-upon policies.

   The relay checks that the originator of the PUBLISH request is the
   owner of the recipient URI in the permission document.  Otherwise,
   the permission document is discarded.

5.6.3.  Return Routability

   SIP identity provides a good authentication mechanism for this type
   of scenario.  Nevertheless, SIP identity is not widely available on
   the public Internet yet.  That is why an authentication mechanism
   that can already be used at this point is needed.

   Return routability tests do not provide the same level of security as
   SIP identity, but they provide a good-enough security level in
   architectures where the SIP identity mechanism is not available
   (e.g., the current Internet).  The relay generates an unguessable URI
   (e.g., with a long and random-looking user part) and places it in the
   CONSENT request (13).  The recipient needs to upload the permission
   document to that URI.

   Relays using a return routability test to perform this authentication
   need to send the CONSENT request to a SIPS URI.  This ensures that
   attackers do not get access to the (unguessable) URI.  Thus, the only
   user able to upload the permission document to the (unguessable) URI
   is the receiver of the CONSENT request.




Rosenberg, et al.        Expires August 29, 2006               [Page 13]


Internet-Draft              Consent Framework              February 2006


   Relays can transition from return routability tests to SIP identity
   by simply requiring the use of SIP identity for incoming PUBLISH
   requests.  That is, such a relay would reject PUBLISH requests that
   did not use SIP identity.

5.7.  Permission Granted Notification

   On receiving the PUBLISH request (17), the relay sends a NOTIFY
   request (19) to inform user A that the permission for the translation
   has been received that the translation logic at the relay has been
   updated.  That is, 'B@example.com' has been added as a recipient URI.

5.8.  Permission Revocation

   At any time, if a client wants to revoke any permission, it uses the
   same URI as before to upload, using a PUBLISH request, a new
   permission document that does not authorize the translation at the
   relay any longer.  If a client loses this URI for some reason, it
   needs to wait until it receives a new request product of the
   translation.  Such a request will contain a Trigger-Consent header
   field with a URI.  That URI will have an escaped Refer-To header
   field identifying the client (i.e., the recipient of the
   translation).  The client needs to send a REFER request to the URI in
   the Trigger-Consent header field in order to receive a CONSENT
   request from the relay.  Such a CONSENT request will contain the
   permission document that was uploaded to the relay at some point and
   the URI where the user can upload a new permission document that does
   not authorize the translation at the relay any longer.

   Figure 6 shows an example of a user revoking permissions at a relay.
   The user rejects an incoming INVITE (5) request, which contains a
   Trigger-Consent header field.  Using the URI in the that header
   field, the user sends a REFER request (8) to the relay.  On receiving
   the REFER request (8), the relay generates a CONSENT request (8)
   towards the user.  Finally, the user revokes the permissions by
   sending a PUBLISH request (14) to the relay.















Rosenberg, et al.        Expires August 29, 2006               [Page 14]


Internet-Draft              Consent Framework              February 2006


           Relay       B's Permission    B@example.com
                           Server
             |                |(1) SUBSCRIBE   |
             |                |Event: grant-permission
             |                |<---------------|
             |                |(2) 200 OK      |
             |                |--------------->|
             |                |(3) NOTIFY      |
             |                |--------------->|
             |                |(4) 200 OK      |
             |                |<---------------|
             |(5) INVITE      |                |
             |Trigger-Consent: <123@relay.example.com>
             |             ?Refer-To=<B%40example.com>
             |-------------------------------->|
             |(6) 603 Decline |                |
             |<--------------------------------|
             |(7) ACK         |                |
             |-------------------------------->|
             |(8) REFER 123@relay.example.com  |
             |Refer-To: B@example.com          |
             |<--------------------------------|
             |(9) 200 OK      |                |
             |-------------------------------->|
             |(10) CONSENT B@example           |
             |Permission-Upload: uri-up        |
             |Permission Document              |
             |--------------->|                |
             |(11) 202 Accepted                |
             |<---------------|                |
             |                |(12) NOTIFY     |
             |                |uri-up          |
             |                |Permission Document
             |                |--------------->|
             |                |(13) 200 OK     |
             |                |<---------------|
             |(14) PUBLISH uri-up              |
             |Permission Document Revoking Permissions
             |<--------------------------------|
             |(15) 200 OK     |                |
             |-------------------------------->|

   Figure 6: Permission Revocation

5.9.  Request-contained URI Lists

   In the scenarios described so far, a user adds recipient URIs to the
   translation logic of a relay.  However, the relay does not perform



Rosenberg, et al.        Expires August 29, 2006               [Page 15]


Internet-Draft              Consent Framework              February 2006


   translations towards those URIs until permissions are obtained.

   URI-list services using request-contained URI lists are a special
   case because the selection of recipient URIs is performed at the same
   time as the communication attempt.  A user places a set of recipient
   URIs in a request and sends it to a relay so that the relay sends a
   similar request to all those recipient URIs.

   This type of URI-list services maintain a list of recipient URIs from
   which permission have been received.  This list is manipulated in the
   same way as described in Section 5 and represents the set of URIs
   that will be accepted if a request containing a URI-list arrives to
   the relay.  Additionally, Figure 7 shows another way to add entries
   to that list.

   If the relay receives a request (1) that contains URIs for which the
   relay does not have permission, the relay rejects the request with a
   470 (Consent Needed) response (2).  Such a response contains a
   Trigger-Consent header field with a URI for each recipient for which
   there is no permission, as shown in Figure 7.  Each URI entry in the
   Trigger-Consent header field contains an escaped Refer-To header
   field with the URI of the recipient.  The user needs to send REFER
   requests to the URIs in the Trigger-Consent header field.
   Additionally, the response also contains a Call-Info header field
   with a URI where the user can subscribe in order to be informed on
   whether or not the relay receives permission from user B. The value
   of the purpose parameter for this entry is 'list-state'.

   OPEN ISSUE: do we need to provide that URI in a Call-Info header
   field (or in a new header field) or can we assume that the sender has
   a relationship with the relay and will know that URI already?

   The rest of the process is similar to the one described in Section 5.
   Note, however, that for simplicity, Figure 7 does not show the split
   between user B's permission server and user agent.
















Rosenberg, et al.        Expires August 29, 2006               [Page 16]


Internet-Draft              Consent Framework              February 2006


       A@example.com           Relay           B@example.com
             |(1) INVITE         |                   |
             |B@example.com      |                   |
             |C@example.com      |                   |
             |------------------>|                   |
             |(2) 470 Consent Needed                 |
             |Trigger-Consent: <123@relay.example.com>
             |             ?Refer-To=<B%40example.com>
             |Call-Info: 456@Relay;purpose=list-state
             |<------------------|                   |
             |(3) ACK            |                   |
             |------------------>|                   |
             |(4) SUBSCRIBE 456@Relay                |
             |Event: list-state                 |
             |------------------>|                   |
             |(5) 200 OK         |                   |
             |<------------------|                   |
             |(6) NOTIFY         |                   |
             |<------------------|                   |
             |(7) 200 OK         |                   |
             |------------------>|                   |
             |(8) REFER 123@Relay|                   |
             |Refer-To: B@example.com                |
             |------------------>|                   |
             |(9) 200 OK         |                   |
             |<------------------|                   |
             |                   |(10) CONSENT B@example
             |                   |Permission-Upload: uri-up-relay
             |                   |Permission Document|
             |                   |------------------>|
             |                   |(11) 202 Accepted  |
             |                   |<------------------|
             |                   |(12) PUBLISH uri-up-relay
             |                   |Permission Document|
             |                   |<------------------|
             |                   |(13) 200 OK        |
             |                   |------------------>|
             |(14) NOTIFY        |                   |
             |<------------------|                   |
             |(15) 200 OK        |                   |
             |------------------>|                   |

   Figure 7: INVITE with a URI list in its body

5.10.  Registrations

   Registrations are a special type of translations.  The user
   registering has a trust relationship with the registrar in its home



Rosenberg, et al.        Expires August 29, 2006               [Page 17]


Internet-Draft              Consent Framework              February 2006


   domain.  This is not the case when a user gives any type of
   permissions to a relay in a different domain.

   Traditionally, REGISTER transactions have performed two operations at
   the same time: setting up a translation and authorizing the use of
   that translation.  For example, a user registering its current
   contact URI is giving permission to the registrar to forward traffic
   sent to the user's AoR (Address of Records) to the registered contact
   URI.  This works fine when the entity registering is the same as the
   one that will be receiving traffic at a later point (e.g., the entity
   receives traffic over the same connection used for the registration
   as described in [9]).  However, this schema creates some potential
   attacks which relate to third-party registrations.

   An attacker binds, via a registration, his or her AoR with the
   contact URI of a victim.  Now, the victim will receive unsolicited
   traffic that was originally addressed to the attacker.

   The process of authorizing a registration is shown in Figure 8.  User
   A performs a third-party registration (1) and receives a 200 (OK)
   response (2) with a Trigger-Consent header field.  This header field
   contains the URI for which there is no permission in an escaped
   Refer-To header field.  That is, the URI the user is attempting to
   register.  A REFER request sent to the URI in the Trigger-Consent
   header field will trigger the registrar to send a CONSENT request to
   the URI being registered.

   The user sends a REFER request (7) to the URI received in the
   Trigger-Consent header field.  In order to know whether or not the
   registrar receives the permission needed, the user subscribes (3) to
   the 'reg-event' event package [6], which can report consent-related
   information using the extension defined in [13].  The rest of the
   process is similar to the one described in Section 5.


















Rosenberg, et al.        Expires August 29, 2006               [Page 18]


Internet-Draft              Consent Framework              February 2006


       A@example.com         Registrar      a@ws123.example.com
             |(1) REGISTER       |                   |
             |Contact: a@ws123.example.com           |
             |Supported: consent-reg                 |
             |------------------>|                   |
             |(2) 200 OK         |                   |
             |Required: consent-reg                  |
             |Trigger-Consent: <123@relay.example.com>
             |       ?Refer-To=<a%40ws123.example.com>
             |<------------------|                   |
             |(3) SUBSCRIBE      |                   |
             |Event: reg-event   |                   |
             |------------------>|                   |
             |(4) 200 OK         |                   |
             |<------------------|                   |
             |(5) NOTIFY         |                   |
             |<------------------|                   |
             |(6) 200 OK         |                   |
             |------------------>|                   |
             |(7) REFER 123@Registrar                |
             |Refer-To: a@ws123.example.com          |
             |------------------>|                   |
             |(8) 200 OK         |                   |
             |<------------------|                   |
             |                   |(9) CONSENT a@ws123.example
             |                   |Permission-Upload: uri-up
             |                   |Permission Document|
             |                   |------------------>|
             |                   |(10) 202 Accepted  |
             |                   |<------------------|
             |                   |(11) PUBLISH uri-up|
             |                   |Permission Document|
             |                   |<------------------|
             |                   |(12) 200 OK        |
             |                   |------------------>|
             |(13) NOTIFY        |                   |
             |<------------------|                   |
             |(14) 200 OK        |                   |
             |------------------>|                   |

   Figure 8: Registration

   Permission documents used to authorize registrations are very
   general.  For example, one such document may authorize the registrar
   to forward any request from any sender to a particular recipient URI.
   This is the type of granularity that this framework intends to
   provide for registrations.  Users who want to define how incoming
   requests are treated with a finer granularity (e.g., requests from



Rosenberg, et al.        Expires August 29, 2006               [Page 19]


Internet-Draft              Consent Framework              February 2006


   user A should only be accepted between 9:00 and 11:00) should use
   other mechanisms such as CPL [20].

   Note that, as indicated previously, user agents using the same
   connection to register and to receive traffic from the registrar, as
   described in [9] do not need to use the mechanism described in this
   section.

   A user agent being registered by a third party may not be able to use
   the SIP Identity or P-Asserted-Identity mechanisms to prove to the
   registrar that the user agent is the owner of the URI being
   registered (e.g., sip:user@192.0.2.1), which is the recipient URI of
   the translation.  In this case, return routability needs to be used.


6.  IANA Considerations

   This document does not require the IANA to take any actions.


7.  Security Considerations

   TBD.

   Editor's note: we have to avoid that attackers provide permissions
   for translations that apply to other users (e.g., allow everyone to
   send traffic to a victim) and that attackers provide permissions for
   a translation that apply to them but routes to a victim (e.g., 3rd
   party registration that binds attacker@relay to victim@somewhere).
   For the former we need authentication (e.g., SIP identity) and for
   the latter we relay on the routing infrastructure to route CONSENTs
   to the same place the traffic will be sent to once permissions are
   obtained (i.e., a return routability test).


8.  References

8.1.  Normative References

   [1]   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.

   [2]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [3]   Jennings, C., Peterson, J., and M. Watson, "Private Extensions
         to the Session Initiation Protocol (SIP) for Asserted Identity



Rosenberg, et al.        Expires August 29, 2006               [Page 20]


Internet-Draft              Consent Framework              February 2006


         within Trusted Networks", RFC 3325, November 2002.

   [4]   Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
         D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

   [5]   Sparks, R., "The Session Initiation Protocol (SIP) Refer
         Method", RFC 3515, April 2003.

   [6]   Rosenberg, J., "A Session Initiation Protocol (SIP) Event
         Package for Registrations", RFC 3680, March 2004.

   [7]   Levin, O., "Suppression of Session Initiation Protocol REFER
         Method Implicit  Subscription",
         draft-ietf-sip-refer-with-norefersub-04 (work in progress),
         January 2006.

   [8]   Peterson, J. and C. Jennings, "Enhancements for Authenticated
         Identity Management in the Session Initiation  Protocol (SIP)",
         draft-ietf-sip-identity-06 (work in progress), October 2005.

   [9]   Jennings, C. and R. Mahy, "Managing Client Initiated
         Connections in the Session Initiation Protocol  (SIP)",
         draft-ietf-sip-outbound-01 (work in progress), October 2005.

   [10]  Camarillo, G., "A Document Format for Expressing Consent",
         draft-camarillo-sip-consent-method-00 (work in progress),
         February 2006.

   [11]  Camarillo, G., "A Document Format for Expressing Consent",
         draft-camarillo-sipping-consent-format-00 (work in progress),
         February 2006.

   [12]  Camarillo, G., "A Document Format for Expressing Consent",
         draft-camarillo-sipping-grant-permission-00 (work in progress),
         February 2006.

   [13]  Camarillo, G., "Session Initiation Protocol (SIP) Registration
         Event Package Extension for Consent-Based Communications",
         draft-camarillo-sipping-consent-reg-event-00 (work in
         progress), February 2006.

   [14]  Camarillo, G., "The Session Initiation Protocol (SIP) List
         State Event Package", draft-camarillo-sipping-list-state-00
         (work in progress), February 2006.

   [15]  Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)",



Rosenberg, et al.        Expires August 29, 2006               [Page 21]


Internet-Draft              Consent Framework              February 2006


         draft-ietf-simple-xcap-08 (work in progress), October 2005.

   [16]  Rosenberg, J., "Extensible Markup Language (XML) Formats for
         Representing Resource Lists",
         draft-ietf-simple-xcap-list-usage-05 (work in progress),
         February 2005.

   [17]  Rosenberg, J., "Requirements for Consent-Based Communications
         in the Session Initiation  Protocol (SIP)",
         draft-ietf-sipping-consent-reqs-04 (work in progress),
         January 2006.

   [18]  Camarillo, G. and A. Roach, "Framework and Security
         Considerations for Session Initiation Protocol (SIP)  Uniform
         Resource Identifier (URI)-List Services",
         draft-ietf-sipping-uri-services-05 (work in progress),
         January 2006.

8.2.  Informative References

   [19]  Rosenberg, J., "A Watcher Information Event Template-Package
         for the Session Initiation Protocol (SIP)", RFC 3857,
         August 2004.

   [20]  Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
         Language (CPL): A Language for User Control of Internet
         Telephony Services", RFC 3880, October 2004.
























Rosenberg, et al.        Expires August 29, 2006               [Page 22]


Internet-Draft              Consent Framework              February 2006


Authors' Addresses

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net


   Gonzalo Camarillo (editor)
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com


   Dean Willis
   Cisco Systems
   2200 E. Pres. George Bush Turnpike
   Richardson, TX  75082
   USA

   Email: dean.willis@softarmor.com






















Rosenberg, et al.        Expires August 29, 2006               [Page 23]


Internet-Draft              Consent Framework              February 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Rosenberg, et al.        Expires August 29, 2006               [Page 24]