summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5360.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5360.txt')
-rw-r--r--doc/rfc/rfc5360.txt1739
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc5360.txt b/doc/rfc/rfc5360.txt
new file mode 100644
index 0000000..f22fbc8
--- /dev/null
+++ b/doc/rfc/rfc5360.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group J. Rosenberg
+Request for Comments: 5360 Cisco Systems
+Category: Standards Track G. Camarillo, Ed.
+ Ericsson
+ D. Willis
+ Unaffiliated
+ October 2008
+
+
+ A Framework for Consent-Based Communications
+ in the Session Initiation Protocol (SIP)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ SIP supports communications for several services, 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, including
+ amplification and DoS (Denial of Service) attacks. This document
+ identifies a framework for consent-based communications in SIP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 1]
+
+RFC 5360 Consent Framework October 2008
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Definitions and Terminology .....................................3
+ 3. Relays and Translations .........................................4
+ 4. Architecture ....................................................6
+ 4.1. Permissions at a Relay .....................................6
+ 4.2. Consenting Manipulations on a Relay's Translation Logic ....7
+ 4.3. Store-and-Forward Servers ..................................8
+ 4.4. Recipients Grant Permissions ...............................9
+ 4.5. Entities Implementing This Framework .......................9
+ 5. Framework Operations ............................................9
+ 5.1. Amplification Avoidance ...................................11
+ 5.1.1. Relay's Behavior ...................................12
+ 5.2. Subscription to the Permission Status .....................12
+ 5.2.1. Relay's Behavior ...................................13
+ 5.3. Request for Permission ....................................13
+ 5.3.1. Relay's Behavior ...................................13
+ 5.4. Permission Document Structure .............................15
+ 5.5. Permission Requested Notification .........................16
+ 5.6. Permission Grant ..........................................17
+ 5.6.1. Relay's Behavior ...................................17
+ 5.6.1.1. SIP Identity ..............................17
+ 5.6.1.2. P-Asserted-Identity .......................17
+ 5.6.1.3. Return Routability ........................18
+ 5.6.1.4. SIP Digest ................................19
+ 5.7. Permission Granted Notification ...........................19
+ 5.8. Permission Revocation .....................................19
+ 5.9. Request-Contained URI Lists ...............................20
+ 5.9.1. Relay's Behavior ...................................21
+ 5.9.2. Definition of the 470 Response Code ................21
+ 5.9.3. Definition of the Permission-Missing Header Field ..22
+ 5.10. Registrations ............................................22
+ 5.11. Relays Generating Traffic towards Recipients .............25
+ 5.11.1. Relay's Behavior ..................................25
+ 5.11.2. Definition of the Trigger-Consent Header Field ....25
+ 6. IANA Considerations ............................................26
+ 6.1. Registration of the 470 Response Code .....................26
+ 6.2. Registration of the Trigger-Consent Header Field ..........26
+ 6.3. Registration of the Permission-Missing Header Field .......26
+ 6.4. Registration of the target-uri Header Field Parameter .....26
+ 7. Security Considerations ........................................27
+ 8. Acknowledgments ................................................28
+ 9. References .....................................................28
+ 9.1. Normative References ......................................28
+ 9.2. Informative References ....................................29
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 2]
+
+RFC 5360 Consent Framework October 2008
+
+
+1. Introduction
+
+ The Session Initiation Protocol (SIP) [RFC3261] supports
+ communications for several services, 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 [RFC3428]) 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
+ network of SIP proxy servers will deliver a SIP request to its
+ recipients without their explicit consent.
+
+ Receipt of these requests without explicit consent can cause a number
+ of problems. These include amplification and DoS (Denial of Service)
+ attacks. These problems are described in more detail in a companion
+ requirements document [RFC4453].
+
+ This specification defines a basic framework for adding consent-based
+ communication to SIP.
+
+2. Definitions and Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ Recipient URI: The Request-URI of an outgoing request sent by an
+ entity (e.g., a user agent or a proxy). The sending of such
+ request can have been the result of a translation operation.
+
+ Relay: 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: The Request-URI of an incoming request that arrives to a
+ relay that will perform a translation operation.
+
+ Translation logic: The logic that defines a translation operation at
+ a relay. This logic includes the translation's target and
+ recipient URIs.
+
+ Translation operation: Operation by which a relay translates the
+ Request-URI of an incoming request (i.e., the target URI) into one
+ or more URIs (i.e., recipient URIs) that are used as the Request-
+ URIs of one or more outgoing requests.
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 3]
+
+RFC 5360 Consent Framework October 2008
+
+
+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, that receives a request, translates its Request-URI into one
+ or more next-hop URIs, and delivers the request to those URIs. The
+ Request-URI of the incoming request is referred to as 'target URI'
+ and the destination URIs of the outgoing requests are 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 the Request-URI (target URI)
+ into one or more additional URIs (recipient URIs). Through this
+ translation operation, the relay can create outgoing requests to one
+ or more additional recipient URIs, thus creating the consent problem.
+
+ The consent problem is created by two types of translations:
+ translations based on local data and translations that involve
+ amplifications.
+
+ Translation operations based on local policy or local data (such as
+ registrations) are 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 user agent on which that
+ user is present. Thus, it is the usage of this registration data,
+ and more generally, the translation logic, that is expected to be
+ authorized in order to prevent undesired communications. Of course,
+ if the spammer knows the address of the user agent, it will be able
+ to deliver requests directly to it.
+
+ Translation operations that result in more than one recipient URI are
+ a source of amplification. Servers that do not perform translations,
+ such as outbound proxy servers, do not cause amplification. On the
+ other hand, servers that perform translations (e.g., inbound proxies
+
+
+
+Rosenberg, et al. Standards Track [Page 4]
+
+RFC 5360 Consent Framework October 2008
+
+
+ authoritatively responsible for a SIP domain) may cause amplification
+ if the user can be reached at multiple endpoints (thereby resulting
+ in multiple recipient URIs).
+
+ Figure 2 shows a relay that performs translations. The user agent
+ client in the figure sends a SIP request to a URI representing a
+ resource in the domain 'example.com' (sip:resource@example.com).
+ This request can 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 can (but need not) belong to the domain
+ 'example.com'. This relay can be, for instance, a proxy server or a
+ URI-list service [RFC5363].
+
+ +-------+
+ | |
+ >| UA |
+ / | |
+ / +-------+
+ /
+ /
+ +-----------------------+ /
+ | | /
+ +-----+ | Relay | / +-------+
+ | | | |/ | |
+ | UA |------>| |-------->| Proxy |
+ | | |+---------------------+|\ | |
+ +-----+ || Translation || \ +-------+
+ || Logic || \
+ |+---------------------+| \ [...]
+ +-----------------------+ \
+ \
+ \ +-------+
+ \ | |
+ >| B2BUA |
+ | |
+ +-------+
+
+ Figure 2: Relay Performing a Translation
+
+ This framework allows potential recipients of a translation to agree
+ to be actual recipients by giving the relay performing the
+ translation permission to send them traffic.
+
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 5]
+
+RFC 5360 Consent Framework October 2008
+
+
+4. Architecture
+
+ Figure 3 shows the architectural elements of this framework. The
+ manipulation of a relay's translation logic typically causes the
+ relay to send a permission request, which in turn causes the
+ recipient to grant or deny the relay permissions for the translation.
+ 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 discusses store-and-forward
+ servers and their functionality. Section 4.4 describes how potential
+ recipients can grant a relay permissions to add them to the relay's
+ translation logic. Section 4.5 discusses which entities need to
+ implement this framework.
+
+ +-----------------------+ Permission +-------------+
+ | | Request | |
+ +--------+ | Relay |----------->| Store & Fwd |
+ | | | | | Server |
+ | Client | | | | |
+ | | |+-------+ +-----------+| +-------------+
+ +--------+ ||Transl.| |Permissions|| |
+ | ||Logic | | || Permission |
+ | |+-------+ +-----------+| Request |
+ | +-----------------------+ V
+ | ^ ^ +-------------+
+ | Manipulation | | Permission Grant | |
+ +---------------+ +-------------------| Recipient |
+ | |
+ +-------------+
+
+ Figure 3: Reference Architecture
+
+4.1. Permissions at a Relay
+
+ Relays implementing this framework obtain and store permissions
+ associated to their translation logic. These permissions indicate
+ whether or not a particular recipient has agreed to receive traffic
+ at any given time. Recipients that have not given the relay
+ permission to send them traffic are simply ignored by the relay when
+ performing a translation.
+
+ In principle, permissions are valid as long as the context where they
+ were granted is 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 service exists or until the permissions are revoked.
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 6]
+
+RFC 5360 Consent Framework October 2008
+
+
+ Additionally, if a recipient is removed from a relay's translation
+ logic, the relay SHOULD delete the permissions related to that
+ recipient. For example, if the registration of a contact URI expires
+ or is otherwise terminated, the registrar deletes the permissions
+ related to that contact address.
+
+ It is also RECOMMENDED that relays request recipients to refresh
+ their permissions periodically. If a recipient fails to refresh its
+ permissions for a given period of time, the relay SHOULD delete the
+ permissions related to that recipient.
+
+ This framework does not provide any guidance for the values of the
+ refreshment intervals because different applications can have
+ different requirements to set those values. For example, a relay
+ dealing with recipients that do not implement this framework may
+ choose to use longer intervals between refreshes. The refresh
+ process in such recipients has to be performed manually by their
+ users (since the recipients do not implement this framework), and
+ having too short refresh intervals may become too heavy a burden
+ for those users.
+
+4.2. Consenting Manipulations on a Relay's Translation Logic
+
+ This framework aims to ensure that any particular relay only performs
+ translations towards destinations that have given the relay
+ 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 relay obtains permission from the new recipient in
+ order to install the new translation logic. Relays ask recipients
+ for permission using MESSAGE [RFC3428] requests.
+
+ For example, the relay hosting the URI-list service at
+ 'sip:friends@example.com' performs a translation from that target URI
+ to a set of recipient URIs. When a client (e.g., the administrator
+ of that URI-list service) adds 'bob@example.org' as a new recipient
+ URI, the relay sends a MESSAGE request to 'sip:bob@example.org'
+ asking whether or not it is OK to perform the translation from
+ 'sip:friends@example.com' to 'sip:bob@example.org'. The MESSAGE
+ request carries in its message body a permission document that
+ describes the translation for which permissions are being 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.
+
+
+
+
+Rosenberg, et al. Standards Track [Page 7]
+
+RFC 5360 Consent Framework October 2008
+
+
+ The mechanism to be used to manipulate the translation logic of a
+ particular relay depends on the relay. Two existing mechanisms to
+ manipulate translation logic are XML Configuration Access Protocol
+ (XCAP) [RFC4825] and REGISTER transactions.
+
+ Section 5 uses a URI-list service whose translation logic is
+ manipulated with XCAP as an example of a translation, in order to
+ specify this framework. Section 5.10 discusses how to apply this
+ framework to registrations, which are a different type of
+ translation.
+
+ In any case, relays implementing this framework SHOULD have a means
+ to indicate that a particular recipient URI is in the states
+ specified in [RFC5362] (i.e., pending, waiting, error, denied, or
+ granted).
+
+4.3. Store-and-Forward Servers
+
+ When a MESSAGE request with a permission document arrives to the
+ recipient URI to which it was sent by the relay, the receiving user
+ can grant or deny the permission needed to perform the translation.
+ However, the receiving user may not be available when the MESSAGE
+ request arrives, or it may have expressed preferences to block all
+ incoming requests for a certain time period. In such cases, a
+ store-and-forward server can act as a substitute for the user and
+ buffer the incoming MESSAGE requests, which are subsequently
+ delivered to the user when he or she is available again.
+
+ 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 store-and-
+ forward server as long as they agree on which mechanism to use.
+ Therefore, this framework does not make any provision for the
+ interface between user agents and their store-and-forward servers.
+
+ Note that the same store-and-forward message service can handle
+ all incoming MESSAGE requests for a user while they are offline,
+ not only those MESSAGE requests with a permission document in
+ their bodies.
+
+ Even though store-and-forward servers perform a useful function and
+ they are expected to be deployed in most domains, some domains will
+ not deploy them from the outset. However, user agents and relays in
+ domains without store-and-forward servers can still use this consent
+ framework.
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 8]
+
+RFC 5360 Consent Framework October 2008
+
+
+ When a relay requests permissions from an offline user agent that
+ does not have an associated store-and-forward server, the relay will
+ obtain an error response indicating that its MESSAGE request could
+ not be delivered. The client that attempted to add the offline user
+ to the relay's translation logic will be notified about the error
+ (e.g., using the Pending Additions event package [RFC5362]). This
+ client MAY attempt to add the same user at a later point, hopefully
+ when the user is online. Clients can discover whether or not a user
+ is online by using a presence service, for instance.
+
+4.4. Recipients Grant Permissions
+
+ Permission documents generated by a relay include URIs that can be
+ used by the recipient of the document to grant or deny the relay the
+ permission described in the document. Relays always include SIP URIs
+ and can include HTTP [RFC2616] URIs for this purpose. Consequently,
+ recipients provide relays with permissions using SIP PUBLISH requests
+ or HTTP GET requests.
+
+4.5. Entities Implementing This Framework
+
+ The goal of this framework is to keep relays from executing
+ translations towards unwilling recipients. Therefore, all relays
+ MUST implement this framework in order to avoid being used to perform
+ attacks (e.g., amplification attacks).
+
+ This framework has been designed with backwards compatibility in mind
+ so that legacy user agents (i.e., user agents that do not implement
+ this framework) can act both as clients and recipients with an
+ acceptable level of functionality. However, it is RECOMMENDED that
+ user agents implement this framework, which includes supporting the
+ Pending Additions event package specified in [RFC5362], the format
+ for permission documents specified in [RFC5361], and the header
+ fields and response code specified in this document, in order to
+ achieve full functionality.
+
+ The only requirement that this framework places on store-and-forward
+ servers is that they need to be able to deliver encrypted and
+ integrity-protected messages to their user agents, as discussed in
+ Section 7. However, this is not a requirement specific to this
+ framework but a general requirement for store-and-forward servers.
+
+5. Framework Operations
+
+ This section specifies this consent framework using an example of the
+ prototypical call flow. The elements described in Section 4 (i.e.,
+ relays, translations, and store-and-forward servers) play an
+ essential role in this call flow.
+
+
+
+Rosenberg, et al. Standards Track [Page 9]
+
+RFC 5360 Consent Framework October 2008
+
+
+ Figure 4 shows the complete process to add a recipient URI
+ ('sip:B@example.com') to the translation logic of a relay. User A
+ attempts to add 'sip:B@example.com' as a new recipient URI to the
+ translation logic of the relay (1). User A uses XCAP [RFC4825] and
+ the XML (Extensible Markup Language) format for representing resource
+ lists [RFC4826] to perform this addition. Since the relay does not
+ have permission from 'sip:B@example.com' to perform translations
+ towards that URI, the relay places 'sip:B@example.com' in the pending
+ state, as specified in [RFC5362].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 10]
+
+RFC 5360 Consent Framework October 2008
+
+
+ A@example.com Relay B's Store & Fwd B@example.com
+ Server
+
+ |(1) Add Recipient | |
+ | sip:B@example.com | |
+ |--------------->| | |
+ |(2) HTTP 202 (Accepted) | |
+ |<---------------| | |
+ | |(3) MESSAGE sip:B@example |
+ | | Permission Document |
+ | |--------------->| |
+ | |(4) 202 Accepted| |
+ | |<---------------| |
+ |(5) SUBSCRIBE | | |
+ | Event: pending-additions | |
+ |--------------->| | |
+ |(6) 200 OK | | |
+ |<---------------| | |
+ |(7) NOTIFY | | |
+ |<---------------| | |
+ |(8) 200 OK | | |
+ |--------------->| | |
+ | | | |User B goes
+ | | | | online
+ | | |(9) Request for |
+ | | | stored messages
+ | | |<---------------|
+ | | |(10) Delivery of|
+ | | | stored messages
+ | | |--------------->|
+ | |(11) PUBLISH uri-up |
+ | |<--------------------------------|
+ | |(12) 200 OK | |
+ | |-------------------------------->|
+ |(13) NOTIFY | | |
+ |<---------------| | |
+ |(14) 200 OK | | |
+ |--------------->| | |
+
+ Figure 4: Prototypical Call Flow
+
+5.1. Amplification Avoidance
+
+ Once 'sip:B@example.com' is in the pending state, the relay needs to
+ ask user B for permission by sending a MESSAGE request to
+ 'sip:B@example.com'. However, the relay needs to ensure that it is
+ not used as an amplifier to launch amplification attacks.
+
+
+
+
+Rosenberg, et al. Standards Track [Page 11]
+
+RFC 5360 Consent Framework October 2008
+
+
+ In such an attack, the attacker would add a large number of recipient
+ URIs to the translation logic of a relay. The relay would then send
+ a MESSAGE request to each of those recipient URIs. The bandwidth
+ generated by the relay would be much higher than the bandwidth used
+ by the attacker to add those recipient URIs to the translation logic
+ of the relay.
+
+ This framework uses a credit-based authorization mechanism to avoid
+ the attack just described. It requires users adding new recipient
+ URIs to a translation to generate an amount of bandwidth that is
+ comparable to the bandwidth the relay will generate when sending
+ MESSAGE requests towards those recipient URIs. When XCAP is used,
+ this requirement is met by not allowing clients to add more than one
+ URI per HTTP transaction. When a REGISTER transaction is used, this
+ requirement is met by not allowing clients to register more than one
+ contact per REGISTER transaction.
+
+5.1.1. Relay's Behavior
+
+ Relays implementing this framework MUST NOT allow clients to add more
+ than one recipient URI per transaction. If a client using XCAP
+ attempts to add more than one recipient URI in a single HTTP
+ transaction, the XCAP server SHOULD return an HTTP 409 (Conflict)
+ response. The XCAP server SHOULD describe the reason for the refusal
+ in an XML body using the <constraint-failure> element, as described
+ in [RFC4825]. If a client attempts to register more than one contact
+ in a single REGISTER transaction, the registrar SHOULD return a SIP
+ 403 response and explain the reason for the refusal in its reason
+ phrase (e.g., maximum one contact per registration).
+
+5.2. Subscription to the Permission Status
+
+ Clients need a way to be informed about the status of the operations
+ they requested. Otherwise, users can be waiting for an operation to
+ succeed when it has actually already failed. In particular, if the
+ target of the request for consent was not reachable and did not have
+ an associated store-and-forward server, the client needs to know to
+ retry the request later. The Pending Additions SIP event package
+ [RFC5362] is a way to provide clients with that information.
+
+ Clients can use the Pending Additions SIP event package to be
+ informed about the status of the operations they requested. That is,
+ the client will be informed when an operation (e.g., the addition of
+ a recipient URI to a relay's translation logic) is authorized (and
+ thus executed) or rejected. Clients use the target URI of the SIP
+ translation being manipulated to subscribe to the 'pending-additions'
+ event package.
+
+
+
+
+Rosenberg, et al. Standards Track [Page 12]
+
+RFC 5360 Consent Framework October 2008
+
+
+ In our example, after receiving the response from the relay (2), user
+ A subscribes to the Pending Additions event package at the relay (5).
+ This subscription keeps user A informed about the status of the
+ permissions (e.g., granted or denied) the relay will obtain.
+
+5.2.1. Relay's Behavior
+
+ Relays SHOULD support the Pending Additions SIP event package
+ specified in [RFC5362].
+
+5.3. Request for Permission
+
+ A relay requests permissions from potential recipients to add them to
+ its translation logic using MESSAGE requests. In our example, on
+ receiving the request to add user B to the translation logic of the
+ relay (1), the relay generates a MESSAGE request (3) towards
+ 'sip:B@example.com'. This MESSAGE request carries a permission
+ document, which describes the translation that needs to be authorized
+ and carries a set of URIs to be used by the recipient to grant or to
+ deny the relay permission to perform that translation. Since user B
+ is offline, the MESSAGE request will be buffered by user B's store-
+ and-forward server. User B will later go online and authorize the
+ translation by using one of those URIs, as described in Section 5.6.
+ The MESSAGE request also carries a body part that contains the same
+ information as the permission document but in a human-readable
+ format.
+
+ When user B uses one of the URIs in the permission document to grant
+ or deny permissions, the relay needs to make sure that it was
+ actually user B using that URI, and not an attacker. The relay can
+ use any of the methods described in Section 5.6 to authenticate the
+ permission document.
+
+5.3.1. Relay's Behavior
+
+ Relays that implement this framework MUST obtain permissions from
+ potential recipients before adding them to their translation logic.
+ Relays request permissions from potential recipients using MESSAGE
+ requests.
+
+ Section 5.6 describes the methods a relay can use to authenticate
+ those recipients giving the relay permission to perform a particular
+ translation. These methods are SIP identity [RFC4474],
+ P-Asserted-Identity [RFC3325], a return routability test, or SIP
+ digest. 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.
+
+
+
+
+Rosenberg, et al. Standards Track [Page 13]
+
+RFC 5360 Consent Framework October 2008
+
+
+ MESSAGE requests sent to request permissions MUST include a
+ permission document and SHOULD include a human-readable part in their
+ bodies. The human-readable part contains the same information as the
+ permission document (but in a human-readable format), including the
+ URIs to grant and deny permissions. User agents that do not
+ understand permission documents can still process the request and
+ display it in a sensible way to the user, as they would display any
+ other instant message. This way, even if the user agent does not
+ implement this framework, the (human) user will be able to manually
+ click on the correct URI in order to grant or deny permissions. The
+ following is an example of a MESSAGE request that carries a human-
+ readable part and a permission document, which follows the format
+ specified in [RFC5361], in its body. Not all header fields are shown
+ for simplicity reasons.
+
+ MESSAGE sip:bob@example.org SIP/2.0
+ From: <sip:alices-friends@example.com>;tag=12345678
+ To: <sip:bob@example.org>
+ Content-Type: multipart/mixed;boundary="boundary1"
+
+ --boundary1
+ Content-Type: text/plain
+
+ If you consent to receive traffic sent to
+ <sip:alices-friends@example.com>, please use one of the following
+ URIs: <sips:grant-1awdch5Fasddfce34@example.com> or
+ <https://example.com/grant-1awdch5Fasddfce34>. Otherwise, use one of
+ the following URIs: <sips:deny-23rCsdfgvdT5sdfgye@example.com> or
+ <https://example.com/deny-23rCsdfgvdT5sdfgye>.
+ --boundary1
+ Content-Type: application/auth-policy+xml
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <cp:ruleset
+ xmlns="urn:ietf:params:xml:ns:consent-rules"
+ xmlns:cp="urn:ietf:params:xml:ns:common-policy"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ <cp:rule id="f1">
+ <cp:conditions>
+ <cp:identity>
+ <cp:many/>
+ </cp:identity>
+ <recipient>
+ <cp:one id="sip:bob@example.org"/>
+ </recipient>
+ <target>
+ <cp:one id="sip:alices-friends@example.com"/>
+ </target>
+
+
+
+Rosenberg, et al. Standards Track [Page 14]
+
+RFC 5360 Consent Framework October 2008
+
+
+ </cp:conditions>
+ <cp:actions>
+ <trans-handling
+ perm-uri="sips:grant-1awdch5Fasddfce34@example.com">
+ grant</trans-handling>
+ <trans-handling
+ perm-uri="https://example.com/grant-1awdch5Fasddfce34">
+ grant</trans-handling>
+ <trans-handling
+ perm-uri="sips:deny-23rCsdfgvdT5sdfgye@example.com">
+ deny</trans-handling>
+ <trans-handling
+ perm-uri="https://example.com/deny-23rCsdfgvdT5sdfgye">
+ deny</trans-handling>
+ </cp:actions>
+ <cp:transformations/>
+ </cp:rule>
+ </cp:ruleset>
+ --boundary1--
+
+5.4. Permission Document Structure
+
+ A permission document is the representation (e.g., encoded in XML) 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.
+
+ URIs to Grant Permission: URIs that recipients can use to grant the
+ relay permission to perform the translation described in the
+ document. Relays MUST support the use of SIP and SIPS URIs in
+ permission documents and MAY support the use of HTTP and HTTPS
+ URIs.
+
+
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 15]
+
+RFC 5360 Consent Framework October 2008
+
+
+ URIs to Deny Permission: URIs that recipients can use to deny the
+ relay permission to perform the translation described in the
+ document. Relays MUST support the use of SIP and SIPS URIs in
+ permission documents and MAY support the use of HTTP and HTTPS
+ URIs.
+
+ Permission documents can contain wildcards. For example, a
+ permission document can request 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. However, the recipient URI MUST NOT be wildcarded.
+
+ Entities implementing this framework MUST support the format for
+ permission documents defined in [RFC5361] and MAY support other
+ formats.
+
+ In our example, the permission document in the MESSAGE request (3)
+ sent by the relay contains the following values:
+
+ Identity of the Sender: Any sender
+
+ Identity of the Original Recipient: sip:friends@example.com
+
+ Identity of the Final Recipient: sip: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, can require permission documents that
+ apply to a specific sender. In cases where the identity of the
+ sender matters, relays MUST authenticate senders.
+
+5.5. Permission Requested Notification
+
+ On receiving the MESSAGE request (3), user B's store-and-forward
+ server stores it because user B is offline at that point. When user
+ B goes online, user B fetches all the requests its store-and-forward
+ server has stored (9).
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 16]
+
+RFC 5360 Consent Framework October 2008
+
+
+5.6. Permission Grant
+
+ A recipient gives a relay permission to execute the translation
+ described in a permission document by sending a SIP PUBLISH or an
+ HTTP GET request to one of the URIs to grant permissions contained in
+ the document. Similarly, a recipient denies a relay permission to
+ execute the translation described in a permission document by sending
+ a SIP PUBLISH or an HTTP GET request to one of the URIs to deny
+ permissions contained in the document. Requests to grant or deny
+ permissions contain an empty body.
+
+ In our example, user B obtains the permission document (10) that was
+ received earlier by its store-and-forward server in the MESSAGE
+ request (3). User B authorizes the translation described in the
+ permission document received by sending a PUBLISH request (11) to the
+ SIP URI to grant permissions contained in the permission document.
+
+5.6.1. Relay's Behavior
+
+ Relays MUST ensure that the SIP PUBLISH or the HTTP GET request
+ received was generated by the recipient of the translation and not by
+ an attacker. Relays can use four methods to authenticate those
+ requests: SIP identity, P-Asserted-Identity [RFC3325], a return
+ routability test, or SIP digest. While return routability tests can
+ be used to authenticate both SIP PUBLISH and HTTP GET requests, SIP
+ identity, P-Asserted-Identity, and SIP digest can only be used to
+ authenticate SIP PUBLISH requests. SIP digest can only be used to
+ authenticate recipients that share a secret with the relay (e.g.,
+ recipients that are in the same domain as the relay).
+
+5.6.1.1. SIP Identity
+
+ The SIP identity [RFC4474] mechanism can be used to authenticate the
+ sender of a PUBLISH request. The relay MUST check that the
+ originator of the PUBLISH request is the owner of the recipient URI
+ in the permission document. Otherwise, the PUBLISH request SHOULD be
+ responded with a 401 (Unauthorized) response and MUST NOT be
+ processed further.
+
+5.6.1.2. P-Asserted-Identity
+
+ The P-Asserted-Identity [RFC3325] mechanism can also be used to
+ authenticate the sender of a PUBLISH request. However, as discussed
+ in [RFC3325], this mechanism is intended to be used only within
+ networks of trusted SIP servers. That is, the use of this mechanism
+ is only applicable inside an administrative domain with previously
+ agreed-upon policies.
+
+
+
+
+Rosenberg, et al. Standards Track [Page 17]
+
+RFC 5360 Consent Framework October 2008
+
+
+ The relay MUST check that the originator of the PUBLISH request is
+ the owner of the recipient URI in the permission document.
+ Otherwise, the PUBLISH request SHOULD be responded with a 401
+ (Unauthorized) response and MUST NOT be processed further.
+
+5.6.1.3. Return Routability
+
+ SIP identity provides a good authentication mechanism for 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 better-than-nothing security level
+ in architectures where the SIP identity mechanism is not available
+ (e.g., the current Internet). The relay generates an unguessable URI
+ (i.e., with a cryptographically random user part) and places it in
+ the permission document in the MESSAGE request (3). The recipient
+ needs to send 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 authentication
+ MUST send the MESSAGE 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 to use the (unguessable)
+ URI is the receiver of the MESSAGE 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. A part of these URIs (e.g., the user part of a SIPS
+ URI) 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.
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 18]
+
+RFC 5360 Consent Framework October 2008
+
+
+5.6.1.4. SIP Digest
+
+ The SIP digest mechanism can be used to authenticate the sender of a
+ PUBLISH request as long as that sender shares a secret with the
+ relay. The relay MUST check that the originator of the PUBLISH
+ request is the owner of the recipient URI in the permission document.
+ Otherwise, the PUBLISH request SHOULD be responded with a 401
+ (Unauthorized) response and MUST NOT be processed further.
+
+5.7. Permission Granted Notification
+
+ On receiving the PUBLISH request (11), the relay sends a NOTIFY
+ request (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, 'sip:B@example.com' has been added as a
+ recipient URI.
+
+5.8. Permission Revocation
+
+ At any time, if a recipient wants to revoke any permission, it uses
+ the URI it received in the permission document to deny the
+ permissions it previously granted. If a recipient loses this URI for
+ some reason, it needs to wait until it receives a new request
+ produced by the translation. Such a request will contain a Trigger-
+ Consent header field with a URI. That Trigger-Consent header field
+ will have a target-uri header field parameter identifying the target
+ URI of the translation. The recipient needs to send a PUBLISH
+ request with an empty body to the URI in the Trigger-Consent header
+ field in order to receive a MESSAGE request from the relay. Such a
+ MESSAGE request will contain a permission document with a URI to
+ revoke the permission that was previously granted.
+
+ Figure 5 shows an example of how a user that lost the URI to revoke
+ permissions at a relay can obtain a new URI using the Trigger-Consent
+ header field of an incoming request. The user rejects an incoming
+ INVITE (1) request, which contains a Trigger-Consent header field.
+ Using the URI in that header field, the user sends a PUBLISH request
+ (4) to the relay. On receiving the PUBLISH request (4), the relay
+ generates a MESSAGE request (6) towards the user. Finally, the user
+ revokes the permissions by sending a PUBLISH request (8) to the
+ relay.
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 19]
+
+RFC 5360 Consent Framework October 2008
+
+
+ Relay B@example.com
+ |(1) INVITE |
+ | Trigger-Consent: sip:123@relay.example.com
+ | ;target-uri="sip:friends@relay.example.com"
+ |---------------------------->|
+ |(2) 603 Decline |
+ |<----------------------------|
+ |(3) ACK |
+ |---------------------------->|
+ |(4) PUBLISH sip:123@relay.example.com
+ |<----------------------------|
+ |(5) 200 OK |
+ |---------------------------->|
+ |(6) MESSAGE sip:B@example |
+ | Permission Document |
+ |---------------------------->|
+ |(7) 200 OK |
+ |<----------------------------|
+ |(8) PUBLISH uri-deny |
+ |<----------------------------|
+ |(9) 200 OK |
+ |---------------------------->|
+
+ Figure 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 recipient 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.
+
+ Relays implementing this consent framework and providing request-
+ contained URI-list services behave in a slightly different way than
+ the relays described so far. This type of relay also maintains a
+ list of recipient URIs for which permissions have been received.
+ Clients also manipulate this list using a manipulation mechanism
+ (e.g., XCAP). Nevertheless, this list does not represent the
+ recipient URIs of every translation performed by the relay. This
+ list just represents all the recipient URIs for which permissions
+ have been received -- that is, the set of URIs that will be accepted
+
+
+
+
+Rosenberg, et al. Standards Track [Page 20]
+
+RFC 5360 Consent Framework October 2008
+
+
+ if a request containing a URI-list arrives to the relay. This set of
+ URIs is a superset of the recipient URIs of any particular
+ translation the relay performs.
+
+5.9.1. Relay's Behavior
+
+ On receiving a request-contained URI list, the relay checks whether
+ or not it has permissions for all the URIs contained in the incoming
+ URI list. If it does, the relay performs the translation. If it
+ lacks permissions for one or more URIs, the relay MUST NOT perform
+ the translation and SHOULD return an error response.
+
+ A relay that receives 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.
+
+ Figure 6 shows a relay that receives a request (1) that contains URIs
+ for which the relay does not have permission (the INVITE carries the
+ recipient URIs in its message body). The relay rejects the request
+ with a 470 (Consent Needed) response (2). That response contains a
+ Permission-Missing header field with the URIs for which there was no
+ permission.
+
+ A@example.com Relay
+
+ |(1) INVITE |
+ | sip:B@example.com |
+ | sip:C@example.com |
+ |---------------------->|
+ |(2) 470 Consent Needed |
+ | Permission-Missing: sip:C@example.com
+ |<----------------------|
+ |(3) ACK |
+ |---------------------->|
+
+ Figure 6: INVITE with a URI List in Its Body
+
+5.9.2. Definition of the 470 Response Code
+
+ A 470 (Consent Needed) response indicates that the request that
+ triggered the response contained a URI list with at least one URI for
+ which the relay had no permissions. A user agent server generating a
+ 470 (Consent Needed) response SHOULD include a Permission-Missing
+ header field in it. This header field carries the URI or URIs for
+ which the relay had no permissions.
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 21]
+
+RFC 5360 Consent Framework October 2008
+
+
+ A user agent client receiving a 470 (Consent Needed) response without
+ a Permission-Missing header field needs to use an alternative
+ mechanism (e.g., XCAP) to discover for which URI or URIs there were
+ no permissions.
+
+ A client receiving a 470 (Consent Needed) response uses a
+ manipulation mechanism (e.g., XCAP) to add those URIs to the relay's
+ list of URIs. The relay will obtain permissions for those URIs as
+ usual.
+
+5.9.3. Definition of the Permission-Missing Header Field
+
+ Permission-Missing header fields carry URIs for which a relay did not
+ have permissions. The following is the augmented Backus-Naur Form
+ (BNF) [RFC5234] syntax of the Permission-Missing header field. Some
+ of its elements are defined in [RFC3261].
+
+ 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
+
+5.10. Registrations
+
+ Even though the example used to specify this framework has been a
+ URI-list service, this framework applies to any type of translation
+ (i.e., not only to URI-list services). Registrations are a different
+ type of translations that deserve discussion.
+
+ 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 Record) 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
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 22]
+
+RFC 5360 Consent Framework October 2008
+
+
+ receives traffic over the same connection used for the registration
+ as described in [OUTBOUND]). However, this schema creates some
+ potential attacks that relate to third-party registrations.
+
+ An attacker binds, via a registration, his or her AoR with the
+ contact URI of a victim. Now the victim will receive unsolicited
+ traffic that was originally addressed to the attacker.
+
+ The process of authorizing a registration is shown in Figure 7. User
+ A performs a third-party registration (1) and receives a 202
+ (Accepted) response (2).
+
+ Since the relay does not have permission from
+ 'sip:a@ws123.example.com' to perform translations towards that
+ recipient URI, the relay places 'sip:a@ws123.example.com' in the
+ 'pending' state. Once 'sip:a@ws123.example.com' is in the
+ 'Permission Pending' state, the registrar needs to ask
+ 'sip:a@ws123.example.com' for permission by sending a MESSAGE request
+ (3).
+
+ After receiving the response from the relay (2), user A subscribes to
+ the Pending Additions event package at the registrar (5). This
+ subscription keeps the user informed about the status of the
+ permissions (e.g., granted or denied) the registrar will obtain. The
+ rest of the process is similar to the one described in Section 5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 23]
+
+RFC 5360 Consent Framework October 2008
+
+
+ A@example.com Registrar a@ws123.example.com
+
+ |(1) REGISTER | |
+ | Contact: sip:a@ws123.example.com |
+ |------------------>| |
+ |(2) 202 Accepted OK| |
+ |<------------------| |
+ | |(3) MESSAGE sip:a@ws123.example
+ | | Permission Document
+ | |------------------>|
+ | |(4) 200 OK |
+ | |<------------------|
+ |(5) SUBSCRIBE | |
+ | Event: pending-additions |
+ |------------------>| |
+ |(6) 200 OK | |
+ |<------------------| |
+ |(7) NOTIFY | |
+ |<------------------| |
+ |(8) 200 OK | |
+ |------------------>| |
+ | |(9) PUBLISH uri-up |
+ | |<------------------|
+ | |(10) 200 OK |
+ | |------------------>|
+ |(11) NOTIFY | |
+ |<------------------| |
+ |(12) 200 OK | |
+ |------------------>| |
+
+ Figure 7: Registration
+
+ Permission documents generated by registrars are typically very
+ general. For example, in one such document a registrar can ask a
+ recipient for permission to forward any request from any sender to
+ the 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 are only accepted between 9:00 and 11:00)
+ will have to use other mechanisms such as Call Processing Language
+ (CPL) [RFC3880].
+
+ Note that, as indicated previously, user agents using the same
+ connection to register and to receive traffic from the registrar,
+ as described in [OUTBOUND], do not need to use the mechanism
+ described in this section.
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 24]
+
+RFC 5360 Consent Framework October 2008
+
+
+ A user agent being registered by a third party can be unable to use
+ the SIP Identity, P-Asserted-Identity, or SIP digest mechanisms to
+ prove to the registrar that the user agent is the owner of the URI
+ being registered (e.g., sip:user@192.0.2.1), which is the recipient
+ URI of the translation. In this case, return routability MUST be
+ used.
+
+5.11. Relays Generating Traffic towards Recipients
+
+ Relays generating traffic towards recipients need to make sure that
+ those recipients can revoke the permissions they gave at any time.
+ The Trigger-Consent helps achieve this.
+
+5.11.1. Relay's Behavior
+
+ 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 a target-uri header field
+ parameter identifying the target URI of the translation.
+
+ On receiving a PUBLISH request addressed to the URI that a relay
+ previously placed in a Trigger-Consent header field, the relay SHOULD
+ send a MESSAGE request to the corresponding recipient URI with a
+ permission document. Therefore, the relay needs to be able to
+ correlate the URI it places in the Trigger-Consent header field with
+ the recipient URI of the translation.
+
+5.11.2. Definition of the Trigger-Consent Header Field
+
+ The following is the augmented Backus-Naur Form (BNF) [RFC5234]
+ syntax of the Trigger-Consent header field. Some of its elements are
+ defined in [RFC3261].
+
+ Trigger-Consent = "Trigger-Consent" HCOLON trigger-cons-spec
+ *( COMMA trigger-cons-spec )
+ trigger-cons-spec = ( SIP-URI / SIPS-URI )
+ *( SEMI trigger-param )
+ trigger-param = target-uri / generic-param
+ target-uri = "target-uri" EQUAL
+ LDQUOT *( qdtext / quoted-pair ) RDQUOT
+
+ The target-uri header field parameter MUST contain a URI.
+
+ The following is an example of a Trigger-Consent header field:
+
+ Trigger-Consent: sip:123@relay.example.com
+ ;target-uri="sip:friends@relay.example.com"
+
+
+
+Rosenberg, et al. Standards Track [Page 25]
+
+RFC 5360 Consent Framework October 2008
+
+
+6. IANA Considerations
+
+ Per the following sections, IANA has registered a SIP response code,
+ two SIP header fields, and a SIP header field parameter.
+
+6.1. Registration of the 470 Response Code
+
+ IANA has added 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: [RFC5360]
+
+6.2. Registration of the Trigger-Consent Header Field
+
+ IANA has added the following new SIP header field to the Header
+ Fields subregistry under the SIP Parameters registry.
+
+ Header Name: Trigger-Consent
+ Compact Form: (none)
+ Reference: [RFC5360]
+
+6.3. Registration of the Permission-Missing Header Field
+
+ IANA has added the following new SIP header field to the Header
+ Fields subregistry under the SIP Parameters registry.
+
+ Header Name: Permission-Missing
+ Compact Form: (none)
+ Reference: [RFC5360]
+
+6.4. Registration of the target-uri Header Field Parameter
+
+ IANA has registered the 'target-uri' Trigger-Consent header field
+ parameter under the Header Field Parameters and Parameter Values
+ subregistry within the SIP Parameters registry:
+
+ Predefined
+ Header Field Parameter Name Values Reference
+ ---------------------------- --------------- --------- ---------
+ Trigger-Consent target-uri No [RFC5360]
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 26]
+
+RFC 5360 Consent Framework October 2008
+
+
+7. Security Considerations
+
+ Security has been discussed throughout the whole document. However,
+ there are some issues that deserve special attention.
+
+ Relays generally implement several security mechanisms that relate to
+ client authentication and authorization. Clients are typically
+ authenticated before they can manipulate a relay's translation logic.
+ Additionally, clients are typically also authenticated and sometimes
+ need to perform SPAM prevention tasks [RFC5039] when they send
+ traffic to a relay. It is important that relays implement these
+ types of security mechanisms. However, they fall out of the scope of
+ this framework. Even with these mechanisms in place, there is still
+ a need for relays to implement this framework because the use of
+ these mechanisms does not prevent authorized clients to add
+ recipients to a translation without their consent. Consequently,
+ relays performing translations MUST implement this framework.
+
+ Note that, as indicated previously, user agents using the same
+ connection to register and to receive traffic from the registrar,
+ as described in [OUTBOUND], do not need to use this framework.
+ Therefore, a registrar that did not accept third-party
+ registrations would not need to implement this framework.
+
+ As pointed out in Section 5.6.1.3, when return routability tests are
+ used to authenticate recipients granting or denying permissions, the
+ URIs 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 [RFC5361]. When store-and-forward servers are used,
+ the interface between a user agent and its store-and-forward server
+ is frequently not based on SIP. In such a case, SIPS cannot be used
+ to secure those URIs. Implementations of store-and-forward servers
+ MUST provide a mechanism for delivering encrypted and integrity-
+ protected messages to their user agents.
+
+ The information provided by the Pending Additions event package can
+ be sensitive. For this reason, as described in [RFC5362], relays
+ need to use strong means for authentication and information
+ confidentiality. SIPS URIs are a good mechanism to meet this
+ requirement.
+
+ Permission documents can reveal sensitive information. Attackers may
+ attempt to modify them in order to have clients grant or deny
+ permissions different from the ones they think they are granting or
+ denying. For this reason, it is RECOMMENDED that relays use strong
+ means for information integrity protection and confidentiality when
+ sending permission documents to clients.
+
+
+
+
+Rosenberg, et al. Standards Track [Page 27]
+
+RFC 5360 Consent Framework October 2008
+
+
+ The mechanism used for conveying information to clients SHOULD ensure
+ the integrity and confidentially of the information. In order to
+ achieve these, an end-to-end SIP encryption mechanism, such as
+ S/MIME, as described in [RFC3261], SHOULD be used.
+
+ If strong end-to-end security means (such as above) are not
+ available, it is RECOMMENDED that hop-by-hop security based on TLS
+ and SIPS URIs, as described in [RFC3261], is used.
+
+8. Acknowledgments
+
+ Henning Schulzrinne, Jon Peterson, and Cullen Jennings provided
+ useful ideas on this document. Ben Campbell, AC Mahendran, Keith
+ Drage, and Mary Barnes performed a thorough review of this document.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2616] 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.
+
+ [RFC3261] 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.
+
+ [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H.,
+ Huitema, C., and D. Gurle, "Session Initiation Protocol
+ (SIP) Extension for Instant Messaging", RFC 3428, December
+ 2002.
+
+ [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", STD 68, RFC 5234, January
+ 2008.
+
+ [RFC5361] Camarillo, G., "A Document Format for Requesting Consent",
+ RFC 5361, October 2008.
+
+ [RFC5362] Camarillo, G., "The Session Initiation Protocol (SIP)
+ Pending Additions Event Package", RFC 5362, October 2008.
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 28]
+
+RFC 5360 Consent Framework October 2008
+
+
+ [RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security
+ Considerations for Session Initiation Protocol (SIP) URI-
+ List Services", RFC 5363, October 2008.
+
+9.2. Informative References
+
+ [RFC3325] 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.
+
+ [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
+ Language (CPL): A Language for User Control of Internet
+ Telephony Services", RFC 3880, October 2004.
+
+ [RFC4453] Rosenberg, J., Camarillo, G., Ed., and D. Willis,
+ "Requirements for Consent-Based Communications in the
+ Session Initiation Protocol (SIP)", RFC 4453, April 2006.
+
+ [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
+ Authenticated Identity Management in the Session
+ Initiation Protocol (SIP)", RFC 4474, August 2006.
+
+ [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
+ Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
+
+ [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
+ for Representing Resource Lists", RFC 4826, May 2007.
+
+ [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
+ Protocol (SIP) and Spam", RFC 5039, January 2008.
+
+ [OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated
+ Connections in the Session Initiation Protocol (SIP)",
+ Work in Progress, June 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 29]
+
+RFC 5360 Consent Framework October 2008
+
+
+Authors' Addresses
+
+ Jonathan Rosenberg
+ Cisco
+ Iselin, NJ 08830
+ USA
+
+ 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
+ Unaffiliated
+ 3100 Independence Pkwy #311-164
+ Plano, TX 75075
+ USA
+
+ EMail: dean.willis@softarmor.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 30]
+
+RFC 5360 Consent Framework October 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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.
+
+ 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, THE IETF TRUST 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.
+
+Intellectual Property
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al. Standards Track [Page 31]
+