[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
SIPPING                                                     J. Rosenberg
Internet-Draft                                               dynamicsoft
Expires: January 6, 2005                                    G. Camarillo
                                                                Ericsson
                                                               D. Willis
                                                             dynamicsoft
                                                            July 8, 2004


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

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I 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 January 6, 2005.

Copyright Notice

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

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
   from one party to another without requiring explicit consent of the
   recipient. Without such consent, it is possible for SIP to be used



Rosenberg, et al.       Expires January 6, 2005                 [Page 1]


Internet-Draft             Consent Framework                   July 2004


   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.   Relays . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Reference Architecture . . . . . . . . . . . . . . . . . . .   4
   4.   Structure of a Permission  . . . . . . . . . . . . . . . . .   4
   5.   Attempting Communication . . . . . . . . . . . . . . . . . .   5
   6.   Requesting a Permission  . . . . . . . . . . . . . . . . . .   6
   7.   Waiting for Permissions  . . . . . . . . . . . . . . . . . .   6
   8.   Granting a Permission  . . . . . . . . . . . . . . . . . . .   7
     8.1  Permission Servers . . . . . . . . . . . . . . . . . . . .   7
   9.   Retrying the Original Request  . . . . . . . . . . . . . . .   8
   10.  Permission Revocation  . . . . . . . . . . . . . . . . . . .   8
   11.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1   Basic Flow with No Permission Server . . . . . . . . . .   8
     11.2   Basic Flow with a Permission Server  . . . . . . . . . .   9
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  11
   12.1   Normative References . . . . . . . . . . . . . . . . . . .  11
   12.2   Informative References . . . . . . . . . . . . . . . . . .  11
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  11
        Intellectual Property and Copyright Statements . . . . . . .  13


























Rosenberg, et al.       Expires January 6, 2005                 [Page 2]


Internet-Draft             Consent Framework                   July 2004


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
   [draft-rosenberg-sipping-consent-reqs-00.txt].

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

2.  Relays

   A central concept in this framework is that of a relay. A relay is
   defined as any SIP server, be it a proxy, 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.
   So, 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. Since the translation
   operation can result in more than one URI, it is 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 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.




Rosenberg, et al.       Expires January 6, 2005                 [Page 3]


Internet-Draft             Consent Framework                   July 2004


3.  Reference Architecture

   The reference architecture is shown in Figure 1. 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
   request URI into one or more next hop URIs, which may or may not
   belong to domain A. This relay may be a proxy server of a URI-list
   service, for instance.


                                   +-------+
                                   |       |
                                  >| UAS 1 |
                 +-------+       / |       |
                 | Rules |      /  +-------+
                 |  DB   |     /
                 +-------+    /
                     |       /
                     V      /
   +-----+       +-------+ /       +-------+
   |     |       |       |/        |       |
   | UAC |------>| Relay |-------->| UAS 2 |
   |     |       |       |\        |       |
   +-----+       +-------+ \       +-------+
                            \
                             \       [...]
                              \
                               \
                                \  +-------+
                                 \ |       |
                                  >| UAS n |
                                   |       |
                                   +-------+

                                Figure 1


4.  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:




Rosenberg, et al.       Expires January 6, 2005                 [Page 4]


Internet-Draft             Consent Framework                   July 2004


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

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

   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.

   It is important to note that the permission itself does not depend
   on, or contain, the identity of a target URI (i.e., the input). As
   such, if a request is sent to sip:resource1@A and to sip:resource2@A,
   and for both targets, the same permission was installed, allowing
   requests from the sender to be relayed to sip:resource@B, that same
   permission would allow the translation to take place for both
   targets.

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

5.  Attempting Communication

   When a UA sends a request to a target resource, 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
   mechansim [5]. 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.



Rosenberg, et al.       Expires January 6, 2005                 [Page 5]


Internet-Draft             Consent Framework                   July 2004


   If at least one of the next hops to which the server wishes to relay
   have not been permitted, the server rejects the request with a 470
   (Consent Needed) response. The 470 response code indicates that the
   request couldn't be relayed because at least one permission was not
   present. The error response can contain a body, which contains a list
   of URIs for the translations for which permissions have not yet been
   obtained. This is effectively an instruction for the sender to go
   off, and obtain permissions from those URIs.

6.  Requesting a Permission

   If the attempt to communicate was rejected with a 470 (Consent
   Needed) response, the client knows that it must obtain some number of
   permissions in order for the communications to take place. The error
   response will include a list of URIs for which permission must be
   obtained. To obtain permission, the client sends a CONSENT request to
   each of the URIs it learned from the body of the error response.
   These URIs typically route to the relay, which will forward them on
   to the destinations whose permissions have not been obtained yet. The
   CONSENT request carries a Consent-Methods header field which
   indicates for which methods consent is being requested.

   When the CONSENT request arrives at the relay, the relay adds a
   Permission header field which contains a URI that the receiver can
   use to upload a permission (e.g., the receiver can use XCAP to upload
   an XML-based permission document). Then, the relay forwards the
   request towards its destination.

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

7.  Waiting for Permissions

   A CONSENT request is responded with a 202 (Accepted) response, which
   carries 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 URI. 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.

   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



Rosenberg, et al.       Expires January 6, 2005                 [Page 6]


Internet-Draft             Consent Framework                   July 2004


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

8.  Granting a Permission

   On reception of a CONSENT request, if the user wishes to grant a
   permission, XCAP is used, just as it is today in presence. The owner
   of the target resource would use contact the URI in the Permission
   header field of the CONSENT request and use XCAP to place the
   permission into a document containing the list of permissions for
   that target resource.

   The XCAP server needs to make sure that the entity uploading the
   permission document is the same as the destination of the CONSENT
   request. This is done by inserting a URI in the Permission header
   field of the CONSENT request which is long and random enough so that
   it cannot be guessed. In addition, the CONSENT request is delivered
   to the user using a SIPS URI. Then, the server inserting such a URI
   relies on the SIP routing infrastructure to deliver the CONSENT
   request to its proper destination.

      If the SIP routing infrastructure is compromised, it could route
      the CONSENT request to an attacker so that the attacker could
      authorize requests addressed to a victim. Nevertheless, if the SIP
      routing infrastructure gets compromised, many types of attacks
      much worse than this are possible. So, relaying on the SIP routing
      infrastructure seems like a sensible choice.

   Using XCAP to grant permissions will 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
   [PRES-RULES].

8.1  Permission Servers

   We have just described how a user agent that receives a CONSENT
   request can use XCAP 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.




Rosenberg, et al.       Expires January 6, 2005                 [Page 7]


Internet-Draft             Consent Framework                   July 2004


   Permission servers inform users about new CONSENT requests using the
   "grant-permission" event package. The user associated with the target
   URI SUBSCRIBEs 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 arrives for which
   permissions have not been granted, a NOTIFY 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.

9.  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 470 (Consent Needed) response, the client
   can retry the original request.

10.  Permission Revocation

   At any time, if a client wants to revoke any permission, it uses the
   XCAP URI that received in the CONSENT message or through the
   grant-permission event package. If a client lost this URI for some
   reason, it would need to wait until it received a new request and
   respond with a 470 (Consent Needed) response. The client would get
   the URI in a new CONSENT request.

   OPEN ISSUE: if we defined the Permission header field so that it can
   be present in any request, and not only in CONSENT requests, the
   relay could add this header field to every request directed to the
   user which used SIPS.

11.  Use Cases

   The following use cases exhibit how the framework works.

11.1  Basic Flow with No Permission Server



       A                         Relay                         B




Rosenberg, et al.       Expires January 6, 2005                 [Page 8]


Internet-Draft             Consent Framework                   July 2004


       | MESSAGE list@relay        |                           |
       |-------------------------->|                           |
       | 470                       |                           |
       | xyz@relay                 |                           |
       |<--------------------------|                           |
       |                           |                           |
       | CONSENT xyz@relay         | CONSENT B                 |
       | Consent-methods: MESSAGE  | Consent-methods: MESSAGE  |
       |-------------------------->| Permission: xcap-uri      |
       |                           |-------------------------->|
       | 202 Accepted              |                           |
       | Call-Info: 123@relay;     | 202 Accepted              |
       |  purpose: wait-permission |<--------------------------|
       |<--------------------------|                           |
       |                           |                           |
       | SUBSCRIBE 123@relay       |                           |
       |-------------------------->|                           |
       | 200 OK                    |                           |
       |<--------------------------|                           |
       |                           |                           |
       | NOTIFY (no permission)    |                           |
       |<--------------------------|                           |
       | 200 OK                    |                           |
       |-------------------------->|                           |
       |                           |                           |
       |                           | XCAP xcap-uri             |
       |                           |  Permission Grant         |
       |                           |<--------------------------|
       |                           | 200 OK                    |
       | NOTIFY (permission)       |-------------------------->|
       |<--------------------------|                           |
       | 200 OK                    |                           |
       |-------------------------->|                           |
       |                           |                           |
       | MESSAGE list@relay        |                           |
       |-------------------------->| MESSAGE B                 |
       |                           |-------------------------->|
       |                           |                           |

                                Figure 2

   Alternatively, the Call-Info header field could have been inserted by
   B directly. In this case, A would SUBSCRIBE to B, instead of
   subscribing to the Relay.

11.2  Basic Flow with a Permission Server





Rosenberg, et al.       Expires January 6, 2005                 [Page 9]


Internet-Draft             Consent Framework                   July 2004


   A                         Relay          B's Permission            B
                                                Server

   | MESSAGE list@relay        |                  |                   |
   |-------------------------->|                  |                   |
   | 470                       |                  |                   |
   | xyz@relay                 |                  |                   |
   |<--------------------------|                  |                   |
   |                           |                  |                   |
   | CONSENT xyz@relay         | CONSENT B        |                   |
   | Consent-methods: MESSAGE  | Consent-methods: MESSAGE             |
   |-------------------------->| Permission: xcap-uri                 |
   |                           |----------------->|                   |
   | 202 Accepted              |                  |                   |
   | Call-Info: 123@relay;     | 202 Accepted     |                   |
   |  purpose: wait-permission |<-----------------|                   |
   |<--------------------------|                  |                   |
   |                           |                  |                   |
   | SUBSCRIBE 123@relay       |                  |                   |
   |-------------------------->|                  |                   |
   | 200 OK                    |                  |                   |
   |<--------------------------|                  |                   |
   |                           |                  |                   |
   | NOTIFY (no permission)    |                  | [B goes on-line]  |
   |<--------------------------|                  |                   |
   | 200 OK                    |                  |                   |
   |-------------------------->|                  | SUBSCRIBE         |
   |                           |                  |  grant-permission |
   |                           |                  |<------------------|
   |                           |                  | 200 OK            |
   |                           |                  |------------------>|
   |                           |                  |                   |
   |                           |                  | NOTIFY            |
   |                           |                  |  xcap-uri         |
   |                           |                  |------------------>|
   |                           |                  | 200 OK            |
   |                           |                  |<------------------|
   |                           | XCAP xcap-uri    |                   |
   |                           |  Permission Grant|                   |
   |                           |<-------------------------------------|
   |                           | 200 OK           |                   |
   | NOTIFY (permission)       |--------------------------------------|
   |<--------------------------|                  |                   |
   | 200 OK                    |                  |                   |
   |-------------------------->|                  |                   |
   |                           |                  |                   |
   | MESSAGE list@relay        |                  |                   |
   |-------------------------->|                  |                   |



Rosenberg, et al.       Expires January 6, 2005                [Page 10]


Internet-Draft             Consent Framework                   July 2004


   |                           | MESSAGE B        |                   |
   |                           |------------------------------------->|
   |                           |                  |                   |


                                Figure 3


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]  Rosenberg, J., "A Presence Event Package for the Session
        Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
        in progress), January 2003.

   [4]  Schulzrinne, H., "Common Policy",
        draft-ietf-geopriv-common-policy-00 (work in progress), February
        2004.

   [5]  Peterson, J., "SIP Authenticated Identity Body (AIB) Format",
        draft-ietf-sip-authid-body-02 (work in progress), July 2003.


Authors' Addresses

   Jonathan Rosenberg
   dynamicsoft
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

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






Rosenberg, et al.       Expires January 6, 2005                [Page 11]


Internet-Draft             Consent Framework                   July 2004


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com


   Dean Willis
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75028
   USA

   EMail: dean.willis@softarmor.com


































Rosenberg, et al.       Expires January 6, 2005                [Page 12]


Internet-Draft             Consent Framework                   July 2004


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 IETF's procedures with respect to rights in IETF 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 (2004). 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 January 6, 2005                [Page 13]