SIPPING J. Rosenberg Internet-Draft Cisco Systems Expires:August 29,December 14, 2006 G. Camarillo, Ed. Ericsson D. Willis Cisco SystemsFebruary 25,June 12, 2006 A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)draft-ietf-sipping-consent-framework-04.txtdraft-ietf-sipping-consent-framework-05.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 onAugust 29,December 14, 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 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, includingamplificationamplification, 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. . . . . . . .and Terminology . . . . . . . . . . . . . . . . . 3 3. Relays and Translations . . . . . . . . . . . . . . . . . . .34 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 ofFramework Operations . . . . . . . . . . . . . . . . . . . . . 8 5.1. Amplification Avoidance . . . . . . . . . . . . . . . . .109 5.2. Subscription to the Permission Status . . . . . . . . . .1110 5.3. Request for Permission . . . . . . . . . . . . . . . . . .1110 5.4. Permission Document Structure . . . . . . . . . . . . . . 11 5.5. Permission Requested Notification . . . . . . . . . . . . 12 5.6. PermissionUploadGrant . . . . . . . . . . . . . . . . . . . .12. 13 5.6.1. SIP Identity . . . . . . . . . . . . . . . . . . . . . 13 5.6.2. P-Asserted-Identity . . . . . . . . . . . . . . . . . 13 5.6.3. Return Routability . . . . . . . . . . . . . . . . . .1314 5.7. Permission Granted Notification . . . . . . . . . . . . . 14 5.8. Permission Revocation . . . . . . . . . . . . . . . . . .1415 5.9. Request-contained URI Lists . . . . . . . . . . . . . . .1516 5.10. Registrations . . . . . . . . . . . . . . . . . . . . . . 17 5.11. Relays Generating Traffic towards Recipients . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . .2021 8. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . .20 8.1.22 9.1. Normative References . . . . . . . . . . . . . . . . . . .20 8.2.22 9.2. Informative References . . . . . . . . . . . . . . . . . .2223 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .2324 Intellectual Property and Copyright Statements . . . . . . . . . .2425 1. Introduction The Session Initiation Protocol (SIP)[1][3] supports communications across many media types, including real-time audio, video, text, instantmessagingmessaging, and presence. This communication is established by the transmission of various SIP requests (such as INVITE and MESSAGE[4])[5]) from an initiator to therecipient,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 tothe recipientits recipients 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].[13]. This specification defines a basic framework for adding consent-based communication to SIP. 2. Definitions and Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. Recipient URI: Therequest-URIRequest-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. Any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or some hybrid, that receives a request, translates its Request-URI into one or more next-hop URIs (i.e., recipient URIs), and delivers the request to those URIs. Target URI: Therequest-URIRequest-URI of an incoming request that arrives toan entity (e.g.,aproxy)relay that will perform a translation operation. Translation operation: Operation by whichan entity (e.g.,aproxy)relay 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 arequest andrequest, translatesthe request URIits Request-URI into one or more next hopURIs to which it thenURIs, and deliversa request. Thethe requestURIto those URIs. The Request-URI of the incoming request is referred to as 'target URI' and the destinationURIURIs of the outgoing requestsisare referred to as 'recipient URIs', as shown in Figure 1. +---------------+ | | 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, therequest URIRequest-URI into one or more additional URIs.Or, more generally, itThat is, the relay 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.(OfOf course, if the spammer knows the address of the user agent, it will be able to deliver requests directly toit.)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].[14]. +-------+ | | >|UASUA | / | | / +-------+ / / +-----------------------+ / | | / +-----+ | Relay | / +-------+ | | | |/ | | |UACUA |------>| |-------->| 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 givingpermission tothe relay performing the translation permission 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 grantpermissions toa relay permissions to add them to the relay's translation logic. +-----------------------+ 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 frameworkneed toobtain 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 givenpermission tothe relay permission 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 isvalid.valid or until they are revoked. 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 serviceexists.exists or until the permissions are revoked. 4.2. Consenting Manipulations on a Relay's Transaction Logic This framework aims to ensure that any particularRelayrelay only performs translations towards destinations that have givenpermission totheRelayrelay permission to perform such a translation. Consequently, when the translation logic of a relay is manipulated (e.g., a new recipient URI is added), the relayneeds to obtainobtains permission from the new recipient in order to install the new translation logic. Relays ask recipients for permission usingCONSENT [10]MESSAGE [5] 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 aCONSENTMESSAGE request to 'bob@example.org' asking whether or not it is OK to perform the translation from 'friends@example.com' to'bob@example.org' (CONSENT requests carry'bob@example.org'. The MESSAGE request carries intheirits messagebodiesbody a permission document that describes the translation for which permissions are beingrequested).requested and a human readable part that also describes the translation. If the answer is positive, the new translation logic is installed at the relay. That is, the new recipient URI is added. The human-readable part is included so that user agents that do not understand permission documents can still process the request and display it in a sensible way to the user. Note that the mechanism to be used to manipulate the translation logic of a particular relay depends on the relay.One possible mechanismTwo existing mechanisms to manipulate translation logicisare XCAP[15]. Section 5.9 and Section 5.10 describe how to add recipients to a translation using request-contained URI lists[11] and REGISTERrequests respectively.transactions. In any case,manipulation mechanismsrelays implementing this frameworkneed toSHOULD 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.states specified in [10] (i.e., pending, waiting, error, denied, or granted). 4.3. Permission Servers When aCONSENTMESSAGE requestsent bywith arelaypermission document arrives to the recipient URI to which it wassent,sent by the relay, 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 receiveCONSENTMESSAGE 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 andoff-line.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 handleCONSENTMESSAGE requests for a user.Permission servers inform users about new CONSENTSo, a permission server stores incoming MESSAGE requestsusingwhen the'grant-permission' event package [12]. Figure 4 illustrates this point. Theuserassociated with the recipient URI for whichis unavailable and delivers them when therelay will ask foruser is available again. Conceptually, a permissionsubscribes [2] (1)server provides a store-and- forward message service. There are several mechanisms to implement store-and-forward message services (e.g., with an instant message to email gateway). Any of these mechanisms can be used between a user agent and its permission server as long as they agree on which mechanism to use. Therefore, this framework does not make any recommendation on the'grant-permission' event package at theinterface between user agents and their permissionserver. This event package modelsservers. Note that thestate ofsame store-and-forward message service can handle allpending CONSENTincoming MESSAGE requests for aparticular resource. When a new CONSENT request (3) arrives to the permission server, a NOTIFY (5) is sent to the user. This informs them that permissionuser while this isneeded foroff line, not only those MESSAGE requests with aparticular sender. The NOTIFY contains thepermission documentreceivedin their bodies. 4.4. Recipients Grant Permissions Relays include in theCONSENT request. Thispermissiondocument is a description of the translation for which permissions are being requested. There is a strong similarity betweendocuments they generate URIs that can be used by the'winfo' event template- package [19] andrecipient of the'grant-permission' event package. Indeed,document to grant or deny thegrant-permission package is effectively a superset of watcherinfo. Once in place, presentities could userelay thegrant-permissionevent package for presencedescribed inaddition to all other servicesthe document. Relays always include SIP URIs and may include HTTP [2] URIs forwhich 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 Recipientsthis purpose. Consequently, recipients provide relays with permissions using SIP PUBLISHrequests. Theserequestscontain a permission document that describes the translation for which permissions are being granted.or HTTP GET requests. 5.Overview ofFramework Operations This sectionprovides an overview ofspecifies this consent 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. FigureFigure 54 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 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).(1). User A uses XCAP[15][11] and the XML (Extensible Markup Language) format for representing resource lists[16] as extended by [14][12] 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).pending state, as specified in [10]. 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|(2) HTTP 202 (Accepted) | | |<---------------| | ||(7) REFER| |(3) MESSAGE B@example | | |Permission Document ||Refer-To: B@example.com?method=CONSENT| |--------------->| | ||(8) 200 OK ||(4) 202 Accepted| | | |<---------------| || |(9)|(5) SUBSCRIBE | | | |Event:list-statepending-additions | | |--------------->| | ||(10)|(6) 200 OK | | | |<---------------| | ||(11)|(7) NOTIFY | | | |<---------------| | ||(12)|(8) 200 OK | | | |--------------->| | | ||(13) CONSENT B@example| ||Permission-Upload: uri-up|User B goes | ||Permission Document| ||--------------->|on line | ||(14) 202 Accepted|(9) Request for | ||<---------------|| | stored messages ||(15) NOTIFY| |<---------------| | ||uri-up|(10) Delivery of| | | ||Permission Documentstored messages | | |--------------->| || |(16) 200 OK | | | |<---------------| | |(17)|(11) PUBLISH uri-up | | |Permission Document | | |<--------------------------------| ||(18)|(12) 200 OK | | | |-------------------------------->||(19)|(13) NOTIFY | | | |<---------------| | ||(20)|(14) 200 OK | | | |--------------->| | | Figure5:4: Prototypical call flow 5.1. Amplification Avoidance Once 'B@example.com' is in the'Permission Pending'pending state, the relay needs to ask user B for permission by sending aCONSENTMESSAGE 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 aCONSENTMESSAGE 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 sendingCONSENTMESSAGE requests towards those recipient URIs.ThisWhen XCAP is used, this requirement is met byhaving users generate REFER requests [5] towards the relay. Each REFER request triggers the sending ofnot allowing clients to add more than one URI per HTTP transaction. Therefore, relays implementing this framework MUST NOT allow clients to add more than one URI per HTTP transaction. If aCONSENT request byclient attempts to add more than one URI in a single HTTP transaction, therelay. So,XCAP server SHOULD return an HTTP 403 (Forbidden) response. The XCAP server SHOULD describe therelay sends user Areason for the refusal (i.e., only one URI(6) where user A needs to send a REFER request. User A generates suchcan be added at aREFER request (7) and sends it totime) in therelay. User A usesentity, as described in [2]. 5.2. Subscription to the'norefersub' extension [7], which supressesPermission Status Clients can use theimplicit subscription that is associated with REFER transactions. This is because user A is not interested inPending Additions SIP event package [10] to be informed about theresultstatus of theCONSENT transaction, but in whether or not user B will authorizeoperations they requested. That is, thetranslation by providingclient will be informed when an operation (e.g., therequested permission. The relay providesaddition of a URI(6) where user A can subscribetoobtain information on whetherthe translation logic of a relay) is authorized (and thus executed) ornot user B providesrejected. OPEN ISSUE: how do clients obtain therequested permission. User A subscribes to thatURIusingto subscribe to the'list-state' [14]Pending Additions eventpackage (9). 5.2. Subscriptionpackage, both when using XCAP and when using REGISTERs to manipulate thePermission Status After sendingtranslation? In our example, after receiving theREFER (7)response from the server (2), user A subscribes to the'list-state'Pending Additions event package at therelay.relay (5). This subscription keeps user A informed about the status of the permissions (e.g., granted or denied) the relay willrequest on receiving the REFER request (7).obtain. 5.3. Request for PermissionOnRelays MUST obtain permissions from potential recipients before adding them to their translation logics. Relays request permissions from potential recipients using MESSAGE requests. MESSAGE requests sent to request permissions MUST include a permission document and SHOULD include a human-readable part in their bodies. MESSAGE requests also carry a body part that contains the same information as the permission document but in a human-readable format so that user agents that do not understand permission documents can still process the request and display it in a sensible way to the user. Section 5.6 describes three methods a relay can use to authenticate recipients giving the relay permission to perform a particular translation. Relays that use the method consisting of a return routability test have to send their MESSAGE requests to a SIPS URI, as specified in Section 5.6. In our example, on receiving theREFERrequest(7),to add User B to the translation logic of the relay (1), the relay generates aCONSENTMESSAGE request(13)(3) towards 'B@example.com'. ThisCONSENTMESSAGE request carries a permission document, which describes the translation that needs to beauthorized,authorized and carries aURI whereset of URIs to be used by the recipient to grant or touploaddeny the relay permissionforto perform that translation. User B will authorize the translation byuploading the permission document received in the CONSENT request into this URI,using one of those URIs, as described in Section 5.6.WhenThe MESSAGE request also carry a body part that contains the same information as the permission documentis uploaded tobut in a human-readable format. When User B uses one of theURI provided byURIs in therelay (17),permission document to grant or deny permissions, the relay needs to make sure thatthe permission document receivedit wasgenerated by useractually User B the one using that URI, and notbyan attacker. The relay can use three methods to authenticate the permission document: SIPidentity,identity [7], P-Asserted-Identity[3],[4], 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.Signature: A digital signature overURIs to Grant Permission: URIs that recipients can use to grant therest ofrelay permission to perform thepermission, signed by an entitytranslation described in the document. At least one of these URIs MUST be a SIP or SIPS URI. HTTP and HTTPS URIs MAY also be used. URIs to Deny Permission: URIs that recipients canidentify itself asuse to deny therecipientrelay permission to perform the translation described in the document. At least one of these URIs MUST be a SIP or SIPS URI.The signature is not always present.HTTP and HTTPS URIs MAY also be used. Permission documents may contain wildcards. For example, a permission document mayauthorizerequest permission for 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.TheEntities implementing this framework MUST support the format for permission documentsisdefined in[11]. The[9]. In our example, the permission document in theCONSENTMESSAGE request(13)(3) 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 URI to Grant Permission: sips:grant-1awdch5Fasddfce34@example.com URI to Grant Permission: https://example.com/grant-1awdch5Fasddfce34 URI to Deny Permission: sips:deny-23rCsdfgvdT5sdfgye@example.com URI to Deny Permission: https://example.com/deny-23rCsdfgvdT5sdfgye 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 thatrelays MUST authenticate senders. 5.5. Permission Requested Notification On receiving theCONSENTMESSAGE request(13),(3), User B's permission serversends a NOTIFY request (15) to user B, who had previously subscribed to the grant-permission event package (1). This NOTIFY request contains,stores it because User B is off line at that point. When User B goes on line, User B fetches all the requests its permissiondocument, which describesserver has stored (9). 5.6. Permission Grant A client gives a relay permission to execute the translationthat needs to be authorized, anddescribed in aURI wherepermission document by sending a SIP PUBLISH or an HTTP GET request to one of the URIs touploadgrant permissions contained in the document. Similarly, a client denies a relay permissionfor that translation. Bothto execute the translation described in a permission documentand the URIby sending a SIP PUBLISH or an HTTP GET request touploadone of thepermission are copied fromURIs to deny permissions contained in theCONSENT request (13) intodocument. In our example, User B obtains theNOTIFY request (15). 5.6. Permission Upload On receivingpermission document (10) that was received earlier by its permission server in theNOTIFYMESSAGE request(15), user(3). User B authorizes the translation described in the permission document received byuploading this permission document to the relay. User B usessending a PUBLISH request(17) to upload the permission document(11) to the SIP URIreceivedto grant permissions contained in theNOTIFY request. When thepermissiondocument is uploaded to the URI provided by the relay (17), the relay needsdocument. Relays need tomake sureensure that thepermission documentSIP PUBLISH or the HTTP GET request received was generated byuser Bthe recipient of the translation and not by an attacker.The relayRelays can use three methods to authenticatethe permission document:those requests: SIP identity, P-Asserted-Identity[3],[4], or a return routability test. While return routability tests can be used to authenticate both SIP PUBLISH and HTTP GET requests, SIP identity and P-Asserted-Identity can only be used to authenticate SIP PUBLISH requests. 5.6.1. SIP Identity The SIP identity[8][7] mechanism can be used to authenticate the sender ofthea PUBLISHrequest uploading the permission document.request. The relaychecksMUST check that the originator of the PUBLISH request is the owner of the recipient URI in the permission document. Otherwise, thepermission document is discarded.PUBLISH request SHOULD be responded with a 401 (Unauthorized) response and MUST NOT be processed further. 5.6.2. P-Asserted-Identity The P-Asserted-Identity[3][4] mechanism can also be used to authenticate the sender ofthea PUBLISHrequest uploading the permission document.request. However, as discussed in RFC 3325[3],[4], 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 previouslyagreed-uponagreed- upon policies. The relaychecksMUST check that the originator of the PUBLISH request is the owner of the recipient URI in the permission document. Otherwise, thepermission document is discarded.PUBLISH request SHOULD be responded with a 401 (Unauthorized) response and MUST NOT be processed further. 5.6.3. Return Routability SIP identity provides a good authentication mechanism forthis type of scenario.incoming PUBLISH requests. 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.,(i.e., with a long and random-looking user part) and places it in theCONSENTpermission document in the MESSAGE request(13).(3). The recipient needs toupload the permission documentsend a SIP PUBLISH request or an HTTP GET request to that URI. Any incoming request sent to that URI SHOULD be considered authenticated by the relay. Note that the return routability method is the only one that allows the use of HTTP URIs in permission documents. The other methods require the use of SIP URIs. Relays using a return routability test to perform this authenticationneed toMUST send theCONSENTMESSAGE request with the permission document to a SIPS URI. This ensures that attackers do not get access to the (unguessable) URI. Thus, the only user able toupload the permission document touse the (unguessable) URI is the receiver of theCONSENTMESSAGE request. Similarly, permission documents sent by relays using a return routability test MUST only contain secure URIs (i.e., SIPS and HTTPS) to grant and deny permissions. The user part of these URIs MUST be cryptographically random with at least 32 bits of randomness. 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),(11), the relay sends a NOTIFY request(19)(13) to inform user A that the permission for the translation has been received and 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 thesameURIas before to upload, using a PUBLISH request, a newit received in the permission documentthat does not authorize the translation atto deny therelay any longer.permissions it previously granted. If a client loses this URI for some reason, it needs to wait until it receives a new requestproduct ofproduced by 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 aCONSENTMESSAGE request from the relay. Such aCONSENTMESSAGE request will containthea permission documentthat was uploaded to the relay at some point and thewith a URIwhereto revoke theuser can upload a newpermissiondocumentthatdoes not authorize the translation at the relay any longer.was previously granted. Figure65 shows an example of how a userrevokingthat lost the URI to revoke permissions at arelay.relay can obtain a new URI using the Trigger-Consent header field of an incoming request. The user rejects an incoming INVITE(5)(1) request, which contains a Trigger-Consent header field. Using the URI in the that header field, the user sends a REFER request(8)(4) to the relay. On receiving the REFER request(8),(4), the relay generates aCONSENTMESSAGE request(8)(6) towards the user. Finally, the user revokes the permissions by sending a PUBLISH request(14)(8) to the relay. RelayB's PermissionB@example.comServer ||(1)SUBSCRIBE | | |Event: grant-permission | |<---------------| | |(2) 200 OK | | |--------------->| | |(3) NOTIFY | | |--------------->| | |(4) 200 OK | | |<---------------| |(5)INVITE | ||Trigger-Consent:Trigger-Consent: <123@relay.example.com> | ?Refer-To=<B%40example.com>|-------------------------------->| |(6)|---------------------------->| |(2) 603 Decline || |<--------------------------------| |(7)|<----------------------------| |(3) ACK || |-------------------------------->| |(8)|---------------------------->| |(4) REFER 123@relay.example.com ||Refer-To:Refer-To: B@example.com ||<--------------------------------| |(9)|<----------------------------| |(5) 200 OK || |-------------------------------->| |(10) CONSENT|---------------------------->| |(6) MESSAGE B@example ||Permission-Upload: uri-up||Permission Document | |--------------->| | |(11) 202 Accepted | |<---------------| | | |(12) NOTIFY | | |uri-up | | |PermissionPermission Document ||--------------->| | |(13)|---------------------------->| |(7) 200 OK || |<---------------| |(14)|<----------------------------| |(8) PUBLISHuri-upuri-deny ||Permission Document Revoking Permissions |<--------------------------------| |(15)|<----------------------------| |(9) 200 OK || |-------------------------------->||---------------------------->| Figure6:5: 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 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.ThisRelays implementing this framework and providing this type ofURI-listURI- list services MUST 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 toA relay thatlist. Ifreceives a request-contained URI-list with a URI for which the relay has no permissions SHOULD return a 470 (Consent Needed) response. The relay SHOULD add a Permission-Missing header field with the URIs for which the relay has no permissions. The following is the augmented Backus-Naur Form (BNF) [6] syntax of the Permission-Missing header field. Some of its elements are defined in RFC 3261 [3]. Permission-Missing = "Permission-Missing" HCOLON per-miss-spec *( COMMA per-miss-spec ) per-miss-spec = ( name-addr / addr-spec ) *( SEMI generic-param ) The following is an example of a Permission-Missing header field: Permission-Missing:<sip:C@example.com> Figure 6 shows a relay that receives a request (1) that contains URIs for which the relay does not havepermission, thepermission. The relay rejects the request with a 470 (Consent Needed) response (2).Such aThat response contains aTrigger-ConsentPermission-Missing header field witha URI for each recipientthe URIs for which thereiswas nopermission, 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.permission. A@example.com RelayB@example.com|(1) INVITE | ||B@example.com | | |C@example.comB@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 |<------------------|| Permission-Missing: C@example.com |<----------------------| |(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 | | |------------------>| ||---------------------->| Figure7:6: 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 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]).[8]). 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 Figure8.7. User A performs a third-party registration (1) and receives a200 (OK)202 (Accepted) response(2) with a Trigger-Consent header field. This header field contains(2). Since theURI for which there is norelay does not have permissionin an escaped Refer-To header field. That is,from 'a@ws123.example.com' to perform translations towards that URI, theURIrelay places 'a@ws123.example.com' in theuser'pending' state. Once 'a@ws123.example.com' isattempting to register. A REFER request sent to the URIin theTrigger-Consent header field will trigger'Permission Pending' state, the registrar needs tosendask 'a@ws123.example.com' for permission by sending aCONSENTMESSAGE requestto(3). After receiving theURI being registered. Theresponse from the server (2), usersends a REFER request (7)A subscribes to theURI received in the Trigger-Consent header field. In order to know whether or notPending Additions event package at the registrarreceives the permission needed,(4). This subscription keeps the usersubscribes (3) toinformed about the'reg-event' event package [6], which can report consent-related information usingstatus of theextension defined in [13].permissions (e.g., granted or denied) the registrar will obtain. The rest of the process is similar to the one described in Section 5. 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>202 Accepted OK| |?Refer-To=<a%40ws123.example.com>|<------------------| ||(3) SUBSCRIBE |||Event: reg-event|(3) MESSAGE a@ws123.example | |Permission Document| | |------------------>| | |(4) 200 OK | | |<------------------|||(5)NOTIFYSUBSCRIBE | ||<------------------||Event: pending-additions | |------------------>| | |(6) 200 OK | ||------------------>||<------------------| | |(7)REFER 123@RegistrarNOTIFY ||Refer-To: a@ws123.example.com||------------------>||<------------------| | |(8) 200 OK | ||<------------------| | | |(9) CONSENT a@ws123.example | |Permission-Upload: uri-up | |Permission Document| ||------------------>| ||(10) 202 Accepted | | |<------------------|||(11)|(9) PUBLISHuri-up|uri-up ||Permission Document|| |<------------------| ||(12)|(10) 200 OK | | |------------------>||(13)|(11) NOTIFY | | |<------------------| ||(14)|(12) 200 OK | | |------------------>| | Figure8:7: Registration Permission documentsused to authorize registrationsgenerated by registrars are typically very general. For example, in one such documentmay authorize thea registrar may ask a recipient for permission to forward any request from any sender toa particular recipientthe recipient's 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 user A should only be accepted between 9:00 and 11:00) should use other mechanisms such as CPL[20].[15]. Note that, as indicated previously, user agents using the same connection to register and to receive traffic from the registrar, as described in[9][8] 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 routabilityneeds toMUST be used. 5.11. Relays Generating Traffic towards Recipients A relay executing a translation that involves sending a request to a URI from which permissions were obtained previously SHOULD add a Trigger-Consent header field to the request. The URI in the Trigger- Consent header field MUST have an escaped Refer-To header field identifying the recipient of the translation so that a REFER request sent to that URI will cause a MESSAGE request to be sent to the recipient. On receiving a REFER request addressed to the URI a relay placed in a Trigger-Consent header field, the relay SHOULD send a MESSAGE request to the URI in the Refer-To header field with a permission document. The following is the augmented Backus-Naur Form (BNF) [6] syntax of the Trigger-Consent header field. Some of its elements are defined in RFC 3261 [3]. Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec *( COMMA trigger-cons-spec ) trigger-cons-spec = ( name-addr / addr-spec ) *( SEMI generic-param ) The following is an example of a Trigger-Consent header field: Trigger-Consent:<sip:relay@example.com ?Refer-To=<sip:recipient%40example.net>> 6. IANA ConsiderationsThis document does not requireThe IANA is requested to add the following new response code to the Methods and Response Codes subregistry under the SIP Parameters registry. Response Code Number: 470 Default Reason Phrase: Consent Needed Reference: [RFCxxxx] Note to the RFC editor: substitute xxxx with the RFC number of this document. The IANA is requested totake any actions.add the following new SIP header field to the Header Fields subregistry under the SIP Parameters registry. Header Name: Trigger-Consent Compact Form: (none) Reference: [RFCxxxx] Note to the RFC editor: substitute xxxx with the RFC number of this document. The IANA is requested to add the following new SIP header field to the Header Fields subregistry under the SIP Parameters registry. Header Name: Permission-Missing Compact Form: (none) Reference: [RFCxxxx] Note to the RFC editor: substitute xxxx with the RFC number of this document. 7. Security ConsiderationsTBD. Editor's note: we have to avoid that attackers provide permissions for translationsSecurity has been discussed throughout the whole document. However, there are some issues thatapplydeserve special attention. The specifications of mechanisms toother users (e.g., allow everyonemanipulate translation logic at relays usually stress the importance of client authentication and authorization. Having relays authenticate and authorize clients manipulating their translation logic keeps unauthorized clients from adding recipients tosend traffica translation. However, this does not prevent authorized clients to add recipients to avictim) and that attackerstranslation without their consent. Additionally, some relays providepermissionsweb interfaces fora translation that applyany client tothem but routesadd new recipients toa victimthe translation (e.g.,3rd party registration that binds attacker@relaymany email mailing lists are operated in this way). In this situation, every client is considered authorized tovictim@somewhere). Formanipulate theformer we need authentication (e.g., SIP identity) and fortranslation logic at thelatter we relay onrelay. This makes therouting infrastructure to route CONSENTsuse of this framework even more important. Therefore, it is RECOMMENDED that relays performing translations implement this framework. As pointed out in Section 5.6.3, when return routability tests are used to authenticate recipients granting or denying permissions, thesame placeURIs used to grant or deny permissions need to be protected from attackers. SIPS URIs provide a good tool to meet this requirement, as described in [9]. The information provided by thetraffic willPending Additions event package can besentsensitive. For this reason, as described in [10], relays need toonce permissionsuse strong means for authentication and information confidentiality. SIPS URIs areobtained (i.e.,areturn routability test).good mechanism to meet this requirement. 8. Acknowledges Henning Schulzrinne, Jon Peterson, and Cullen Jennings provided useful ideas on this document. 9. References8.1.9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [3] 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][4] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.[4][5] 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",Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC3680, March 2004.4234, October 2005. [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][8] 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-00draft-ietf-sip-outbound-03 (work in progress),FebruaryMarch 2006.[12][9] Camarillo, G., "A Document Format forExpressingRequesting 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-00draft-camarillo-sipping-consent-format-01 (work in progress),FebruaryJune 2006.[14][10] Camarillo, G., "The Session Initiation Protocol (SIP)List StatePending Additions Event Package",draft-camarillo-sipping-list-state-00draft-camarillo-sipping-pending-additions-00 (work in progress),FebruaryJune 2006.[15][11] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)",draft-ietf-simple-xcap-08draft-ietf-simple-xcap-11 (work in progress),October 2005. [16]May 2006. [12] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", draft-ietf-simple-xcap-list-usage-05 (work in progress), February 2005.[17][13] 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][14] 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.9.2. Informative References[19] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004. [20][15] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, 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 (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 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.