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

Versions: 00 01 02 03 04 05                                             
SIPPING                                                     J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: August 21, 2005                                    G. Camarillo
                                                                Ericsson
                                                               D. Willis
                                                           Cisco Systems
                                                       February 20, 2005


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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 21, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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



Rosenberg, et al.       Expires August 21, 2005                 [Page 1]


Internet-Draft             Consent Framework               February 2005


   invitations, instant messages, and other requests to be delivered
   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 spam and 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Reference Architecture . . . . . . . . . . . . . . . . . . . .  4
   5.  Structure of a Permission  . . . . . . . . . . . . . . . . . .  5
   6.  Single-Relay Scenario  . . . . . . . . . . . . . . . . . . . .  6
     6.1   Attempting Communication . . . . . . . . . . . . . . . . .  6
     6.2   Requesting a Permission  . . . . . . . . . . . . . . . . .  8
     6.3   Waiting for Permissions  . . . . . . . . . . . . . . . . .  9
     6.4   Granting a Permission  . . . . . . . . . . . . . . . . . .  9
     6.5   Retrying the Original Request  . . . . . . . . . . . . . . 10
     6.6   Permission Revocation  . . . . . . . . . . . . . . . . . . 10
   7.  Permission Servers . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Multiple-Relay Scenario  . . . . . . . . . . . . . . . . . . . 12
     8.1   Initial Steps  . . . . . . . . . . . . . . . . . . . . . . 12
     8.2   Waiting for Permissions  . . . . . . . . . . . . . . . . . 15
     8.3   Intermediate Relays  . . . . . . . . . . . . . . . . . . . 15
   9.  Installing Permissions in Advance  . . . . . . . . . . . . . . 16
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16
   11.   Security Considerations  . . . . . . . . . . . . . . . . . . 16
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 16
   12.1  Normative References . . . . . . . . . . . . . . . . . . . . 16
   12.2  Informative References . . . . . . . . . . . . . . . . . . . 16
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 18

















Rosenberg, et al.       Expires August 21, 2005                 [Page 2]


Internet-Draft             Consent Framework               February 2005


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
   [2]) 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 spam and DoS (Denial of
   Service) attacks.  These problems are described in more detail in a
   companion requirements document [5].

   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 proxy) that has performed 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

   A central concept in this framework is that of a relay.  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 21, 2005                 [Page 3]


Internet-Draft             Consent Framework               February 2005


                       +---------------+
                       |               |  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 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,
   'sip: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 'sip:user@example.com' to the UA 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.

4.  Reference Architecture

   The reference architecture is shown in Figure 2.  In this
   architecture, a UAC wishes to send a message to a request URI
   representing a resource in domain A (sip:resource@A).  This request
   may pass through a local outbound proxy (not shown), but eventually
   arrives at a server authoritative for domain A.  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 domain A.  This relay may be, for instance, a proxy server
   or a URI-list service [7].







Rosenberg, et al.       Expires August 21, 2005                 [Page 4]


Internet-Draft             Consent Framework               February 2005


                                   +-------+
                                   |       |
                                  >|  UAS  |
                 +-------+       / |       |
                 | Rules |      /  +-------+
                 |  DB   |     /
                 +-------+    /
                     |       /
                     V      /
   +-----+       +-------+ /       +-------+
   |     |       |       |/        |       |
   | UAC |------>| Relay |-------->| Proxy |
   |     |       |       |\        |       |
   +-----+       +-------+ \       +-------+
                            \
                             \       [...]
                              \
                               \
                                \  +-------+
                                 \ |       |
                                  >| B2BUA |
                                   |       |
                                   +-------+

                Figure 2: Relay performing a translation


5.  Structure of a Permission

   This framework centers on the idea that a relay will only perform a
   translation if a permission is in place authorizing that translation.
   As such, the notion of a permission is another key part of this
   framework.  A permission is an object, represented in XML, that
   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 21, 2005                 [Page 5]


Internet-Draft             Consent Framework               February 2005



   Operations Permitted: A set of specific methods or qualifiers for
      which the permission applies.  For example, the permission may
      only grant relaying for INVITE or MESSAGE, or for MESSAGE with
      specific MIME types.

   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.

   Permissions are installed on a resource by resource basis.  That is,
   for each target URI to which a request is sent, there is a set of
   permissions installed for that URI.  Each permission has the content
   described above.

   A natural format for representing permissions appears to be the
   common policy format [3].  This format is also used for presence
   permissions.

6.  Single-Relay Scenario

   This section describes the fundamental operations of this framework
   in a single-relay scenario.  The descriptions are illustrated with an
   example (see Figure 3).

6.1  Attempting Communication

   When a UA sends a request to a target resource (message 1 in Figure
   3), the request eventually arrives at a server that is authoritative
   for the domain in the request URI.  The server may require, as part
   of its processing logic, the relaying of the request to one or more
   next hops.  If such relaying is required, the server first
   authenticates the sender of the request.  Such authentication can be
   done using the SIP identity mechanism [4].  Once the sender is
   authenticated, the server checks its permission database for that
   target resource.  It looks for permissions containing senders whose
   URI matches the identity of the sender of the request.  Of those that
   are found, the server checks to see if the permitted translated URI
   matches the URIs to which the server wishes to relay the request.

   If at least one of the next hops to which the server wishes to relay
   have not been permitted, the server includes a Permission-Needed
   header field in the response to the request (message 2 in Figure 3).
   This Permission-Needed header field contains a list of URIs, each of
   which identify a translation for which permissions are needed.






Rosenberg, et al.       Expires August 21, 2005                 [Page 6]


Internet-Draft             Consent Framework               February 2005


      Note that each of the URIs identify a translation at the server
      (i.e., at the relay).  That is, the domain part of the URI will
      identify the server and the user part will be meaningful only to
      the server.


             A                         Relay                         B
             |(1) REQUEST school-friends@relay                       |
             |-------------------------->|                           |
             |(2) 470 Consent Needed     |                           |
             |Call-Info: 123@relay;      |                           |
             |purpose=wait-permission    |                           |
             |Permission-Needed: xyz@relay                           |
             |<--------------------------|                           |
             |(3) CONSENT school-friends@relay                       |
             |Permission-From: xyz@relay |                           |
             |-------------------------->|                           |
             |                           |(4) CONSENT B              |
             |                           |Permission-Requested: uri-req
             |                           |-------------------------->|
             |                           |(5) 202 Accepted           |
             |                           |<--------------------------|
             |(6) 202 Accepted           |                           |
             |<--------------------------|                           |
             |(7) SUBSCRIBE 123@relay    |                           |
             |-------------------------->|                           |
             |(8) 200 OK                 |                           |
             |<--------------------------|                           |
             |(9) NOTIFY (no permission) |                           |
             |<--------------------------|                           |
             |(10) 200 OK                |                           |
             |-------------------------->|                           |
             |                           |(11) HTTP uri-req          |
             |                           |Get Requested Permission   |
             |                           |<--------------------------|
             |                           |(12) 200 OK                |
             |                           |Permission Document        |
             |                           |URI to Upload: uri-up      |
             |                           |-------------------------->|
             |                           |(13) PUBLISH uri-up        |
             |                           |Permission Document        |
             |                           |<--------------------------|
             |                           |(14) 200 OK                |
             |                           |-------------------------->|
             |(15) NOTIFY (permission)   |                           |
             |<--------------------------|                           |
             |(16) 200 OK                |                           |
             |-------------------------->|                           |



Rosenberg, et al.       Expires August 21, 2005                 [Page 7]


Internet-Draft             Consent Framework               February 2005


             |(17) REQUEST school-friends@relay                      |
             |-------------------------->|                           |
             |                           |(18) REQUEST B             |
             |                           |Permission-Used: uri-perm  |
             |                           |-------------------------->|

                       Figure 3: Basic call flow

   The status code the server uses in its response depends on the
   service the translation is part of.  For example, a URI-list service
   which receives a request with a list of recipient URIs may already
   have permissions for some of them.  The URI-list service may choose
   to perform the translations which it has permissions for and return a
   200 (OK) response with a list of URIs in a Permission-Needed header
   field for the translations for which permissions have not yet been
   obtained.  Alternatively, the URI-list service may choose not to
   perform any translation and to return a 470 (Consent Needed) response
   with a list of URIs in a Permission-Needed header field for the
   translations for which permissions have not yet been obtained.

   The response from the server may carry a URI in a Call-Info header
   field (wait-permission purpose) where the client can SUBSCRIBE to
   using the wait-permission event package.  This event package models
   the state of the permission granted to the client for communicating
   with the target URIs.  When a permission is granted, the state
   changes, and the client receives a NOTIFY.  This NOTIFY contains the
   permission(s) that have been granted for the sender.

      OPEN ISSUE: in which response does the server include the
      call-info header? Proposal: it can include it in any response
      (i.e., responses to the original request and responses to the
      CONSENTs, but it should include always the same URI.

   Usage of an event package has the benefit that the client can come
   back at any time and do a query SUBSCRIBE to see if permissions were
   granted, or it can wait for them to be granted, and find out when.
   There is no requirement that the client use this event package to
   wait.  For some requests, it may not be important for the sender to
   find out when permission is granted (e.g., a presence subscription).

6.2  Requesting a Permission

   If a server returns a response with a Permission-Needed header field,
   the client knows that it needs to obtain some number of permissions.
   The response will include a list of URIs in a Permission-Needed
   header field for which permission must be obtained.  To obtain
   permission, the client generates as many CONSENT request as entries
   the Permission-Needed header field contained.



Rosenberg, et al.       Expires August 21, 2005                 [Page 8]


Internet-Draft             Consent Framework               February 2005


   Each CONSENT request (message 3 in Figure 3) is sent to the same URI
   as the original request and carries, in a Permission-From header
   field, one of the URIs received in the Permission-Needed header
   field.  The server will forward these CONSENT requests on to the
   destinations whose permissions have not been obtained yet.

      OPEN ISSUE: it was proposed having clients send CONSENTs to the
      URIs received in the Permission-Needed header field (i.e., using
      them in the Request-URI instead of in a Request-From header
      field).  This would require the server to store more state
      information and come up with a number of URIs in multiple-relay
      scenarios.

   When the CONSENT request arrives at the server, the relay adds a
   Permission-Requested header field which contains a URI (e.g., an HTTP
   URI) that the receiver can use to download a description of the
   permission being requested (e.g., an XML-based permission document).
   Then, the server forwards the request towards its destination
   (message 4 in Figure 3).

   If there are several relays between the sender and the final
   destination, those CONSENT requests may also fail if permissions have
   not yet been obtained, in which case the process recurses, as
   described in Section Section 8.  Eventually, the client will have
   sent a request to all of the relays at the leaves of the translation
   tree between the sender and the final destinations.

6.3  Waiting for Permissions

   A CONSENT request is responded with a 202 (Accepted) response
   (message 5 in Figure 3).  As stated earlier, if the client is
   interested in the status of the permissions, it can SUBSCRIBE
   (message 7 in Figure 3) to the the wait-permission event package
   using the URI received in the Call-Info header field (wait-permission
   purpose) of the response to the original request (responses to
   CONSENT requests may also carry a Call-Info header field with such a
   URI).

6.4  Granting a Permission

   On reception of a CONSENT request, the user fetches the permission
   being requested from the URI in the Permission-Requested header field
   (message 11 in Figure 3).  This permission document includes the URI
   that the user needs to use to upload the permissions that the user
   chooses to grant.  So, if the user wishes to grant a permission, it
   may use a SIP PUBLISH request (message 13 in Figure 3) to upload a
   permission document into that URI.  This PUBLISH request is
   authenticated using the SIP identity mechanism.



Rosenberg, et al.       Expires August 21, 2005                 [Page 9]


Internet-Draft             Consent Framework               February 2005


      OPEN ISSUE: XCAP could be useful for endpoints that support it.
      Do we want to allow XCAP to be used? If XCAP was allowed, how do
      we permorm authentication? Do endpoings using XCAP need to sign
      their permissions? Relaying on the routing architecture and SIPS
      to deliver a randomly-looking http URI to the proper endpoint does
      not seem to be secure enough.
      OPEN ISSUE: Using XCAP to grant permissions would require the
      definition of a new application usage.  We note that this usage
      appears to be a generalization of the presence rules usage
      currently defined [6].

   The owner of the target resource may choose to grant the permissions
   requested or a superset of them.  For example, a CONSENT request may
   request permission to perform a given translation on MESSAGE
   requests, and the target resource owner may grant permission to
   perform the translation on any request (not only on MESSAGE
   requests).

6.5  Retrying the Original Request

   The sender learns about permissions through the wait-permission event
   package.  Once it has obtained permissions for all of the resources
   that were identified in the Permission-Needed header field, the
   client can retry the original request (message 17 in Figure 3).

   When the server performs the translation, it adds a Permission-Used
   header field with a URI (e.g., an HTTP URI) where the permission
   document that authorizes the translation can be downloaded from.

6.6  Permission Revocation

   At any time, if a client wants to revoke any permission, it uses the
   same URI as before to upload a new permission document.  If a client
   loses this URI for some reason, it needs to wait until it receives a
   new request, which will contain a Permission-Used header field.

   The permission documents that can be downloaded from the URIs in the
   Permission-Used header field contain a URI where the client can
   upload a new permission document (e.g., a permission document that
   does not allow a particular translation any longer).

      OPEN ISSUE: is it OK to force clients to download the permission
      document in order to obtain the SIP URI to send their PUBLISH
      requests to or we want to already include such a URI in the
      Permission-Used header field.






Rosenberg, et al.       Expires August 21, 2005                [Page 10]


Internet-Draft             Consent Framework               February 2005


7.  Permission Servers

   We described in Section 6.4 how a user agent that receives a CONSENT
   request can use a PUBLISH request to grant certain permissions.
   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.  Permission servers are network elements that act as SIP UAs
   and handle CONSENT requests for a user.

   Permission servers inform users about new CONSENT requests using the
   "grant-permission" event package.  The user associated with the
   target URI SUBSCRIBEs (message 1 in Figure 4) 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, for which permissions do not yet exist.  When a
   new CONSENT request (message 3 in Figure 4) arrives for which
   permissions have not been granted, a NOTIFY (message 5 in Figure 4)
   is sent to the user.  This informs them that permission is needed for
   a particular sender.  The NOTIFY contains information on the
   operation which was requested.

      There is a strong similarity between the watcherinfo event package
      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.

   When a user is notified of a new pending CONSENT request, the user
   follows regular procedures to upload the permissions that were
   requested (messages 9 to 11 in Figure 4).
















Rosenberg, et al.       Expires August 21, 2005                [Page 11]


Internet-Draft             Consent Framework               February 2005


           Relay          B's Permission             B
                              Server
             |                   |(1) SUBSCRIBE      |
             |                   |grant-permission   |
             |                   |<------------------|
             |                   |(2) 200 OK         |
             |                   |------------------>|
             |(3) CONSENT B      |                   |
             |Permission-Requested: uri-req          |
             |------------------>|                   |
             |(4) 202 Accepted   |                   |
             |<------------------|                   |
             |                   |(5) NOTIFY         |
             |                   |Permission Requested: uri-req
             |                   |------------------>|
             |                   |(6) 200 OK         |
             |                   |<------------------|
             |(7) HTTP uri-req   |                   |
             |Get Requested Permission               |
             |<--------------------------------------|
             |(8) 200 OK         |                   |
             |Permission Document|                   |
             |URI to Upload: uri-up                  |
             |------------------>|                   |
             |(9) PUBLISH uri-up |                   |
             |Permission Document|                   |
             |<--------------------------------------|
             |(10) 200 OK        |                   |
             |-------------------------------------->|

                 Figure 4: Permission server operation


8.  Multiple-Relay Scenario

   One of the results of a translation (i.e., a recipient URI) at a
   relay can route to another relay.  In this case, there will be
   multiple relays between the UA generating a request and the
   destination UA or UAs.

8.1  Initial Steps

   The way UAs are informed that they need to request permissions for a
   translation and the way they request those permissions (i.e., using
   CONSENT requests) are identical to the single-relay case.

   In the example of Figure 5, Relay 1 handles the URI 'friends@relay1',
   which translates to a set of URIs.  Relay 1 already has permissions



Rosenberg, et al.       Expires August 21, 2005                [Page 12]


Internet-Draft             Consent Framework               February 2005


   to perform all the translations but one.  Relay 1 needs to obtain
   permission to perform the translation to 'school-friends@relay2'.

   Relay 1 returns a 470 (Consent Needed) response (message 2 in Figure
   5) with a Permission-Needed header field.  The UA generates a CONSENT
   request (message 2 in Figure 5) placing the URI received in that
   header field in a Request-From header field.

   The CONSENT request is forwarded by Relay 1 to Relay 2 (message 4 in
   Figure 5).  The URI 'school-friends@relay2' translates to a set of
   URIs.  Relay 1 already has permissions to perform all the
   translations but one.  Relay 1 needs to obtain permission to perform
   the translation to B.

   Relay 2 returns a 470 (Consent Needed) response (message 5 in Figure
   5) with a Permission-Needed header field.  On reception of this
   response, Relay 1 adds the URI identifying the first translation to
   this header field (message 6 in Figure 5).

   The UA inserts the two URIs received in the Permission-Needed header
   field into the Permission-From header field of a new CONSENT request
   (message 7 in Figure 5).  Relay 1 consumes the URI it added when it
   relays the CONSENT request to Relay 2 (message 8 in Figure 5).  Relay
   2 consumes the URI it added when it relays the CONSENT request to B
   (message 9 in Figure 5).


   A              Relay1            Relay2               B
   |(1) REQUEST friends@relay1         |                 |
   |---------------->|                 |                 |
   |(2) 470 Consent Needed             |                 |
   |Call-Info: 123@relay1;             |                 |
   |purpose=wait-permission            |                 |
   |Permission-Needed: xyz@relay1      |                 |
   |<----------------|                 |                 |
   |(3) CONSENT friends@relay1         |                 |
   |Permission-From: xyz@relay1        |                 |
   |---------------->|                 |                 |
   |                 |(4) CONSENT school-friends@relay2  |
   |                 |Permission-Requested: uri-req1     |
   |                 |---------------->|                 |
   |                 |(5) 470 Consent Needed             |
   |                 |Call-Info:456@relay2;              |
   |                 |purpose=wait-permission            |
   |                 |Permission-Needed: abc@relay2      |
   |                 |<----------------|                 |
   |(6) 470 Consent Needed             |                 |
   |Permission-Needed: xyz@relay1;abc@relay2             |



Rosenberg, et al.       Expires August 21, 2005                [Page 13]


Internet-Draft             Consent Framework               February 2005


   |<----------------|                 |                 |
   |(7) CONSENT friends@relay1         |                 |
   |Permission-From: xyz@relay1;abc@relay2               |
   |---------------->|                 |                 |
   |                 |(8) CONSENT school-friends@relay2  |
   |                 |Permission-Requested:uri-req1      |
   |                 |Permission-From: abc@relay2        |
   |                 |---------------->|                 |
   |                 |                 |(9) CONSENT B    |
   |                 |                 |Permission-Requested: uri-req2
   |                 |                 |---------------->|
   |                 |                 |(10) 202 Accepted|
   |                 |                 |<----------------|
   |                 |(11) 202 Accepted|                 |
   |                 |<----------------|                 |
   |(12) 202 Accepted|                 |                 |
   |<----------------|                 |                 |
   |(13) SUBSCRIBE 123@relay1          |                 |
   |---------------->|                 |                 |
   |(14) 200 OK      |                 |                 |
   |<----------------|                 |                 |
   |(15) NOTIFY (no permission)        |                 |
   |<----------------|                 |                 |
   |(16) 200 OK      |                 |                 |
   |---------------->|                 |                 |
   |                 |                 |(17) HTTP uri-req|
   |                 |                 |Get Requested Permission
   |                 |                 |<----------------|
   |                 |                 |(18) 200 OK      |
   |                 |                 |Permission Document
   |                 |                 |URI to Upload: uri-up2
   |                 |                 |---------------->|
   |                 |                 |(19) PUBLISH uri-up2
   |                 |                 |Permission Document
   |                 |                 |<----------------|
   |                 |                 |(20) 200 OK      |
   |                 |                 |---------------->|
   |                 |(21) HTTP uri-req1                 |
   |                 |Get Requested Permission           |
   |                 |<----------------|                 |
   |                 |(22) 200 OK      |                 |
   |                 |Permission Document                |
   |                 |URI to Upload: uri-up1             |
   |                 |---------------->|                 |
   |                 |(23) PUBLISH uri-up1               |
   |                 |Permission Document                |
   |                 |<----------------|                 |
   |                 |(24) 200 OK      |                 |



Rosenberg, et al.       Expires August 21, 2005                [Page 14]


Internet-Draft             Consent Framework               February 2005


   |                 |---------------->|                 |
   |(25) NOTIFY (permission)           |                 |
   |<----------------|                 |                 |
   |(26) 200 OK      |                 |                 |
   |---------------->|                 |                 |
   |(27) REQUEST friends@relay1        |                 |
   |---------------->|                 |                 |
   |                 |(28) REQUEST school-friends@relay2 |
   |                 |Permission-Used: uri-perm1         |
   |                 |---------------->|                 |
   |                 |                 |(29) REQUEST B   |
   |                 |                 |Permission-Used: uri-perm1
   |                 |                 |Permission-Used: uri-perm2
   |                 |                 |---------------->|

                   Figure 5: Multiple-relay scenario


8.2  Waiting for Permissions

   In order to be informed of the status of the permissions, A
   subscribes (message 13 in Figure 5) to the URI it received from Relay
   1 in a Call-Info header field (message 2 in Figure 5).

   Although Figure 5 does not show it, Relay 1 could subscribe to the
   status of the permissions at Relay 2 using the URI it received in a
   Call-Info header field (message 5 in Figure 5).

8.3  Intermediate Relays

   At this point, A needs to upload permissions to Relay 2 and Relay 2
   needs to upload permissions to Relay 1.  Therefore, Relay 2 acts as
   an intermediate relay between B and Relay 1.

   The policy followed by Relay 2 in Figure 5 is not to give permissions
   to Relay 1 to perform the translation from friends@relay1 to
   school-friends@relay2 until B gives Relay 2 permissions to perform
   the translation school-friends@relay2 to B.  However, this is not the
   only possible policy.  Relay 2 may choose to give permissions to
   Relay 1 before B gave Relay 2 permissions.  This would probably be
   the case if Relay 2 was a forking proxy trying to locate a user
   registered at several UAs, one of which had not given permissions to
   the forking proxy yet.

   Therefore, how a relay decides when to give certain permissions to
   other relays is based on the local policy of the relay, which will
   generally depend on the type of service provided by the relay.




Rosenberg, et al.       Expires August 21, 2005                [Page 15]


Internet-Draft             Consent Framework               February 2005


9.  Installing Permissions in Advance

   The previous sections described how a relay can request a target
   resource owner to authorize a communication attempt.  However, target
   resource owners may want to authorize a particular translation in
   advance.  That is, before any communication attempt is performed.

   To do so, the target resource owner sends a CONSENT request to the
   target URI of the translation.  This CONSENT request will trigger the
   mechanisms described in the previous sections.  The result is that
   the target resource owner(s) will obtain a URI to upload a permission
   document.

10.  IANA Considerations

   TBD.

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

12.  References

12.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]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D.
        Gurle, "Session Initiation Protocol (SIP) Extension for Instant
        Messaging", RFC 3428, December 2002.

12.2  Informative References

   [3]  Schulzrinne, H., "A Document Format for Expressing Privacy
        Preferences", draft-ietf-geopriv-common-policy-03 (work in
        progress), October 2004.



Rosenberg, et al.       Expires August 21, 2005                [Page 16]


Internet-Draft             Consent Framework               February 2005


   [4]  Peterson, J., "Enhancements for Authenticated Identity
        Management in the Session Initiation  Protocol (SIP)",
        draft-ietf-sip-identity-03 (work in progress), September 2004.

   [5]  Rosenberg, J., "Requirements for Consent-Based Communications in
        the Session Initiation  Protocol (SIP)",
        draft-ietf-sipping-consent-reqs-00 (work in progress), October
        2004.

   [6]  Rosenberg, J., "Presence Authorization Rules",
        draft-ietf-simple-presence-rules-01 (work in progress), October
        2004.

   [7]  Camarillo, G., "Requirements and Framework for Session
        Initiation Protocol (SIP)Uniform  Resource Identifier (URI)-List
        Services", draft-ietf-sipping-uri-services-01 (work in
        progress), October 2004.


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
   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 21, 2005                [Page 17]


Internet-Draft             Consent Framework               February 2005


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 (2005).  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 21, 2005                [Page 18]