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.
AbstractSIP 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.
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 18.104.22.168. SIP Identity ..............................17 22.214.171.124. P-Asserted-Identity .......................17 126.96.36.199. Return Routability ........................18 188.8.131.52. 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
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. 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.
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:email@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:firstname.lastname@example.org' 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
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:email@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.
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
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. RFC3428] requests. For example, the relay hosting the URI-list service at 'sip:firstname.lastname@example.org' 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 'email@example.com' as a new recipient URI, the relay sends a MESSAGE request to 'sip:firstname.lastname@example.org' asking whether or not it is OK to perform the translation from 'sip:email@example.com' to 'sip:firstname.lastname@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.
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).
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. RFC2616] URIs for this purpose. Consequently, recipients provide relays with permissions using SIP PUBLISH requests or HTTP GET requests. 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. Section 4 (i.e., relays, translations, and store-and-forward servers) play an essential role in this call flow.
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].
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
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. 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). 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.
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. RFC5362]. 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. 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.
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:email@example.com SIP/2.0 From: <sip:firstname.lastname@example.org>;tag=12345678 To: <sip:email@example.com> Content-Type: multipart/mixed;boundary="boundary1" --boundary1 Content-Type: text/plain If you consent to receive traffic sent to <sip:firstname.lastname@example.org>, 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:email@example.com"/> </recipient> <target> <cp:one id="sip:firstname.lastname@example.org"/> </target>
</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--
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:email@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.
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). 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. 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.
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.
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.
Relay B@example.com |(1) INVITE | | Trigger-Consent: sip:firstname.lastname@example.org | ;target-uri="sip:email@example.com" |---------------------------->| |(2) 603 Decline | |<----------------------------| |(3) ACK | |---------------------------->| |(4) PUBLISH sip:firstname.lastname@example.org |<----------------------------| |(5) 200 OK | |---------------------------->| |(6) MESSAGE sip:B@example | | Permission Document | |---------------------------->| |(7) 200 OK | |<----------------------------| |(8) PUBLISH uri-deny | |<----------------------------| |(9) 200 OK | |---------------------------->| Figure 5: Permission Revocation
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. 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
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. 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
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:email@example.com' to perform translations towards that recipient URI, the relay places 'sip:firstname.lastname@example.org' in the 'pending' state. Once 'sip:email@example.com' is in the 'Permission Pending' state, the registrar needs to ask 'sip:firstname.lastname@example.org' 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.
A@example.com Registrar email@example.com |(1) REGISTER | | | Contact: sip:firstname.lastname@example.org | |------------------>| | |(2) 202 Accepted OK| | |<------------------| | | |(3) MESSAGE sip:email@example.com | | 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.
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:firstname.lastname@example.org), which is the recipient URI of the translation. In this case, return routability MUST be used. 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:email@example.com ;target-uri="sip:firstname.lastname@example.org"
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 184.108.40.206, 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.
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. [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.
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI- List Services", RFC 5363, October 2008. [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.
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: email@example.com
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 firstname.lastname@example.org.