RFC 5360
A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)
RFC 5360: A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP) 💖
Okay bestie, let's get into RFC 5360 🎀. It's called A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP), it came out in October 2008, and it's on the Standards Track 👑. That means it's an official internet protocol spec, no cap.
The authors are J. Rosenberg from Cisco Systems, G. Camarillo (the editor, marked Ed.) from Ericsson, and D. Willis, who's listed as Unaffiliated 🫶. The title block doesn't list any obsoletes or updates, so it isn't marked as replacing or updating another RFC.
Status of This Memo 📜
This doc specifies an Internet standards track protocol for the Internet community, and it's literally asking everyone to chat about it and suggest improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈, so share it all you want.
Abstract 🦋
SIP handles a whole bunch of services: real-time audio, video, text, instant messaging, and presence ✨. In its current form, it lets session invitations, instant messages, and other requests get delivered from one party to another without needing the recipient's explicit consent 🙈. And that's a problem, because it means SIP can be abused for malicious stuff like amplification and DoS (Denial of Service) attacks 💀. This document lays out a framework for consent-based communications in SIP, so it's the fix-it arc 💜.
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 ....................................291. Introduction 🌸
Okay so SIP ([RFC3261]) handles real-time audio, video, text, instant messaging, and presence, all the good stuff 💅. Communication gets set up when someone sends SIP requests (like INVITE and MESSAGE [RFC3428]) from an initiator to the person they want to reach. Now, a recipient can reject a request and decline the session 🙅, but the thing is, a network of SIP proxy servers will deliver that request to the recipient without their explicit consent. Rude 😭.
Getting these requests without consent can cause a bunch of problems, including amplification and DoS (Denial of Service) attacks 💀. There's a whole companion requirements doc that goes deeper into this, [RFC4453] 📖.
This spec defines a basic framework for adding consent-based communication to SIP 🦋. Consent is the whole vibe ✨.
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] 🎀.
Here are the main terms you need to know:
- 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. Main character energy 👑.
- 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.
3. Relays and Translations 🔁
Relays are a key part of this framework 🔑. A relay is any SIP server (proxy, B2BUA, or some hybrid) that gets 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 called the 'target URI', and the destination URIs of the outgoing requests are called 'recipient URIs', as shown in Figure 1 💫.
+---------------+ recipient URI
| |---------------->
| |
target URI | Translation | [...]
-------------->| Operation |
| | recipient URI
| |---------------->
+---------------+Figure 1: Translation Operation
So translation is the essential thing a relay does 🧩. When a relay gets a request, it translates the Request-URI (the target URI) into one or more additional URIs (the recipient URIs). Through that translation, the relay can create outgoing requests to one or more recipient URIs, and that's where the consent problem comes from 😤.
The consent problem comes from two kinds of translations: translations based on local data, and translations that involve amplification 🫠.
Translations based on local policy or local data (like registrations) are how a request gets delivered straight to an endpoint, which otherwise wouldn't be possible. Like, if a spammer has a user's address, 'sip:user@example.com', they can't deliver a MESSAGE request to that user's UA (user agent) unless they can get the registration data that maps 'sip:user@example.com' to the user agent where that user is currently present 🕵️. So it's the use of that registration data, and more generally the translation logic, that needs to be authorized to stop unwanted communications 🚫. Of course, if the spammer knows the address of the user agent itself, they can send requests straight to it, so yeah, not foolproof 🙃.
Translation operations that produce more than one recipient URI are a source of amplification 📣. Servers that don't do translations, like outbound proxy servers, don't cause amplification. But servers that do translate (like inbound proxies that are authoritatively responsible for a SIP domain) can cause amplification if the user can be reached at multiple endpoints, since that means multiple recipient URIs 🌊.
Figure 2 shows a relay that does translations 🖼️. The user agent client in the figure sends a SIP request to a URI for a resource in the domain 'example.com' (sip:resource@example.com). That request can go through a local outbound proxy (not shown), but it eventually lands on a server that's authoritative for the domain 'example.com'. That server acts as a relay: it does a translation operation, turning the target URI into one or more recipient URIs, which can (but don't have to) belong to the domain 'example.com'. This relay could 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 lets potential recipients of a translation agree to be actual recipients, by giving the relay that's doing the translation permission to send them traffic. 🌈💖
4. Architecture ✨
okay so, Figure 3 is basically the cast list for this whole framework 💅 The manipulation of a relay's translation logic usually makes the relay send a permission request, and then the recipient gets to say yes or no to the relay's permissions for that translation. Section 4.1 covers permissions at a relay. Section 4.2 covers what a relay does when a client messes with its translation logic. Section 4.3 is about store-and-forward servers and what they do. Section 4.4 explains how potential recipients can give a relay permission to add them to its translation logic. And Section 4.5 is about which entities actually 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
okay the vibe here is that relays implementing this framework get and store permissions tied to their translation logic 🦋 Those permissions basically say whether a certain recipient has agreed to receive traffic at any given time. If a recipient never gave the relay permission to send them traffic, the relay just ignores them when it does a translation. ignored, no drama 💀
In theory, permissions stay valid for as long as the context they were granted in is still valid, or until somebody revokes them. For example, the permissions a URI-list SIP service gets for handing out MESSAGE requests to a bunch of recipients stay good as long as that URI-list SIP service exists, or until the permissions get revoked ✨
Also, if a recipient gets removed from a relay's translation logic, the relay SHOULD delete the permissions tied to that recipient 🧚 Like, if a contact URI's registration expires or gets terminated some other way, the registrar deletes the permissions for that contact address. clean up your room, bestie 🌸
It is also RECOMMENDED that relays ask recipients to refresh their permissions every so often 💜 And if a recipient doesn't refresh its permissions for a certain amount of time, the relay SHOULD delete the permissions for that recipient. periodt 👑
This framework doesn't give any guidance on the values for refresh intervals, because different applications can have totally different needs. For example, a relay dealing with recipients that don't implement this framework might pick longer intervals between refreshes. Those recipients have to refresh manually, since they don't implement the framework, and super short intervals could turn into way too much work for their users 😭
4.2. Consenting Manipulations on a Relay's Translation Logic
so the big goal here is making sure a relay only does translations toward destinations that gave it permission to do that translation 🔥 That means when somebody changes a relay's translation logic (like adding a new recipient URI), the relay has to get permission from that new recipient before it can install the new translation logic. And relays ask for that permission by sending MESSAGE [RFC3428] requests 💌
Here's an example. The relay hosting the URI-list service at sip:friends@example.com translates from that target URI to a set of recipient URIs. When a client (say, the admin 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 if it's cool to do the translation from sip:friends@example.com to sip:bob@example.org. The MESSAGE request carries a permission document in its message body that describes the translation being asked about, plus a human-readable part that describes it too. If Bob says yes, the new translation logic gets installed at the relay, and boom, the new recipient URI is added ✨
The human-readable part is there so user agents that don't understand permission documents can still handle the request and show it to the user in a sensible way 🙈
The mechanism you use to manipulate a particular relay's translation logic depends on the relay itself. Two existing mechanisms for this are XML Configuration Access Protocol (XCAP) [RFC4825] and REGISTER transactions 🦋
Section 5 uses a URI-list service whose translation logic gets manipulated with XCAP as its example translation, so this framework can be explained properly. Section 5.10 talks about how to apply this framework to registrations, which are a different type of translation 🎀
Either way, relays implementing this framework SHOULD have a way to show that a particular recipient URI is in one of the states specified in [RFC5362] (so, pending, waiting, error, denied, or granted) 🌈
4.3. Store-and-Forward Servers
picture this: a MESSAGE request with a permission document shows up at the recipient URI the relay sent it to. The receiving user can grant or deny the permission needed for the translation. BUT the user might not be around when the request arrives, or they might have set preferences to block all incoming requests for a while. That's where a store-and-forward server comes in as a stand-in for the user, buffering incoming MESSAGE requests and handing them over once the user is available again 🧚
There are a bunch of ways to build store-and-forward message services (an instant-message-to-email gateway, for example). Any of those can be used between a user agent and its store-and-forward server, as long as both sides agree on which one to use. So this framework doesn't make any rules 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're offline, not just the ones with a permission document in their bodies 🍓
Store-and-forward servers are genuinely useful and are expected to show up in most domains, but some domains won't have them from the outset. That's okay though, because user agents and relays in domains without store-and-forward servers can still use this consent framework 🫶
Now, if a relay asks an offline user agent for permissions and that user agent doesn't have an associated store-and-forward server, the relay gets back an error response saying its MESSAGE request couldn't be delivered 😭 The client that tried to add the offline user to the relay's translation logic gets notified about the error (for example, through the Pending Additions event package [RFC5362]). That client MAY try adding the same user again later, hopefully once the user is online. Clients can figure out whether a user is online by using a presence service, for instance ✨
4.4. Recipients Grant Permissions
the permission documents a relay generates include URIs the recipient can use to grant or deny the relay the permission described in the document 🔥 Relays always include SIP URIs and can also include HTTP [RFC2616] URIs for this. So recipients give relays their permissions using SIP PUBLISH requests or HTTP GET requests 💜
4.5. Entities Implementing This Framework
the whole point of this framework is to stop relays from running translations toward unwilling recipients 🙅♀️ So all relays MUST implement this framework, otherwise they could be used to pull off attacks (like amplification attacks) 💀
This framework was designed with backwards compatibility in mind, so legacy user agents (the ones that don't implement this framework) can still act as both clients and recipients with an acceptable level of functionality. Still, 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, so they get full functionality 🌸
The only requirement this framework puts on store-and-forward servers is that they can deliver encrypted and integrity-protected messages to their user agents, as discussed in Section 7. But honestly, that's not a requirement specific to this framework. It's a general requirement for store-and-forward servers in the first place 🧚
5. Framework Operations ✨
Okay bestie, this section walks through the whole framework with one example call flow 💖 All the stuff from Section 4 (relays, translations, and store-and-forward servers) is the main cast here 🎀
Figure 4 shows the full process of adding a recipient URI ('sip:B@example.com') to a relay's translation logic 🦋 User A tries to add 'sip:B@example.com' as a new recipient URI to the relay's translation logic (1). User A does this with XCAP [RFC4825] and the XML (Extensible Markup Language) format for representing resource lists [RFC4826] 💅 Since the relay doesn't have permission from 'sip:B@example.com' to do translations toward that URI, it puts '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
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' 🙈 But the relay also has to make sure it can't be used as an amplifier to launch amplification attacks 💀
Here's the scary version: the attacker adds a huge pile of recipient URIs to a relay's translation logic. The relay then sends a MESSAGE request to every single one of them. The bandwidth the relay burns would be way bigger than the bandwidth the attacker spent adding those URIs. Yikes 😭
This framework uses a credit-based authorization mechanism to stop that attack 👑 It makes users who add new recipient URIs to a translation generate an amount of bandwidth that is comparable to the bandwidth the relay will use when it sends MESSAGE requests toward those recipient URIs. When XCAP is used, this is handled by not letting clients add more than one URI per HTTP transaction. When a REGISTER transaction is used, it's handled by not letting clients 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 tries 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 tries 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 find out what happened to the operations they asked for 👀 Otherwise, users can be sitting there waiting for something to succeed when it has actually already failed. Like, if the target of the consent request was unreachable and had no store-and-forward server, the client needs to know to retry later 😭 The Pending Additions SIP event package [RFC5362] is how clients get that info 💜
Clients can use the Pending Additions SIP event package to stay updated on the operations they requested. The client gets told when an operation (for example, adding a recipient URI to a relay's translation logic) is authorized (and therefore 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 getting the response from the relay (2), user A subscribes to the Pending Additions event package at the relay (5). That subscription keeps user A posted on the permissions (for example, granted or denied) the relay will get 🫶
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 asks potential recipients for permission before adding them to its translation logic, and it does that with MESSAGE requests 📩 In our example, when the relay gets the request to add user B to its translation logic (1), it generates a MESSAGE request (3) toward 'sip:B@example.com'. This MESSAGE request carries a permission document. That document describes the translation that needs to be authorized, and it includes a set of URIs the recipient can use to grant or deny the relay permission to do that translation 🦋 Since user B is offline, the MESSAGE request gets buffered by user B's store-and-forward server 🌈 Later, when user B goes online, they authorize the translation by using one of those URIs, as described in Section 5.6. The MESSAGE request also has a body part with the same info as the permission document, just 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 it was really user B using that URI and not some 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 those permissions using MESSAGE requests.
Section 5.6 describes the methods a relay can use to authenticate the recipients who give it permission to do a particular translation. These methods are SIP identity [RFC4474], P-Asserted-Identity [RFC3325], a return routability test, or SIP digest 🧚 Relays that use the 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 has the same info as the permission document (just in a human-readable format), including the URIs to grant and deny permissions. User agents that don't understand permission documents can still process the request and show it to the user in a sensible way, the same way they'd show any other instant message 📱 So even if the user agent doesn't implement this framework, the (human) user can manually click the right URI to grant or deny permissions 🍓 Here's an example of a MESSAGE request with a human-readable part and a permission document, which follows the format specified in [RFC5361], in its body. Not all header fields are shown, just to keep things simple 🌸
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>
</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 ✨
okay so a permission document is basically the written-down version of a permission 📜 (it's usually XML, bestie). Each one carries a few key pieces of info:
- Identity of the Sender: a URI for the sender who's getting the permission 💌
- Identity of the Original Recipient: a URI that goes into the translation as the input. It's also called the target URI 🎯
- Identity of the Final Recipient: a URI for the result of the translation. The permission lets the sender send requests to the target URI, and lets a relay that gets those requests forward them to this URI. It's also called the recipient URI 🦋
- URIs to Grant Permission: URIs that recipients can use to give the relay permission to do the translation in the document. Relays MUST support SIP and SIPS URIs in permission documents and MAY support HTTP and HTTPS URIs 🔐
- URIs to Deny Permission: URIs that recipients can use to say "nope" to the relay doing that translation. Relays MUST support SIP and SIPS URIs in permission documents and MAY support HTTP and HTTPS URIs 🙅♀️
Permission documents can have wildcards 🃏 For example, one could ask for permission for any relay to forward requests from one particular sender to one particular recipient. That one would work for any target URI, so the original recipient field matches any URI. BUT the recipient URI MUST NOT be wildcarded, no exceptions 🚫
Entities implementing this framework MUST support the permission document format defined in [RFC5361], and they MAY support other formats too 💅
Now let's look at our example! The permission document in the MESSAGE request (3) that the relay sends has these 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
The Sender field is gonna have a wildcard a lot of the time 🌸 BUT some scenarios, like the request-contained URI lists in Section 5.9, need permission documents that are locked to one specific sender. When the sender's identity actually matters, relays MUST authenticate senders. No shortcuts, periodt 🔥
5.5. Permission Requested Notification 🔔
So when the MESSAGE request (3) arrives, user B is offline, which means user B's store-and-forward server stores it 📦 Later, when user B comes online, they fetch all the requests their store-and-forward server has been holding (9). Main character comeback energy 👑
5.6. Permission Grant 🎀
A recipient gives a relay permission to run the translation in a permission document by sending a SIP PUBLISH or an HTTP GET request to one of the grant URIs in that document. Same idea in reverse: to deny permission, they send a SIP PUBLISH or HTTP GET to one of the deny URIs. Either way, the requests have an empty body 🫶
In our example, user B grabs the permission document (10) that their store-and-forward server got earlier in the MESSAGE request (3). Then user B approves the translation by sending a PUBLISH request (11) to the SIP URI to grant permissions in that document 💖
5.6.1. Relay's Behavior 🧠
Relays MUST make sure the SIP PUBLISH or HTTP GET they received was actually generated by the recipient of the translation and not by some sneaky attacker 🕵️♀️ Relays can use four methods to check this: SIP identity, P-Asserted-Identity [RFC3325], a return routability test, or SIP digest. Return routability tests work for both SIP PUBLISH and HTTP GET requests. SIP identity, P-Asserted-Identity, and SIP digest only work for SIP PUBLISH requests. And SIP digest only works for recipients who share a secret with the relay (like recipients 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 whoever sent the PUBLISH is the owner of the recipient URI in the permission document. If not, the PUBLISH SHOULD get a 401 (Unauthorized) response, and it MUST NOT be processed any further 🚫
5.6.1.2. P-Asserted-Identity 🏷️
P-Asserted-Identity [RFC3325] can also authenticate the sender of a PUBLISH request. BUT (and this is a big but) [RFC3325] makes it clear this mechanism is only meant for networks of trusted SIP servers. So it only really makes sense inside an administrative domain with policies that everyone agreed on ahead of time 🤝
The relay MUST check that whoever sent the PUBLISH is the owner of the recipient URI in the permission document. If not, the PUBLISH SHOULD get a 401 (Unauthorized) response, and it MUST NOT be processed any further 🙅♀️
5.6.1.3. Return Routability 🔁
Okay so SIP identity is a great way to authenticate incoming PUBLISH requests 💅 BUT it isn't widely available on the public Internet yet, sadly 😭 That's why we need a mechanism that works right now.
Return routability tests don't give you the same level of security as SIP identity, but they're a better-than-nothing option in setups where SIP identity isn't around (like the current Internet) 🌈 Here's how it goes: the relay generates an unguessable URI (a cryptographically random user part) and puts it in the permission document inside the MESSAGE request (3). The recipient then sends a SIP PUBLISH or an HTTP GET to that URI. Any incoming request sent to that URI SHOULD be considered authenticated by the relay ✨
Note that return routability is the only method that lets permission documents use HTTP URIs. The other methods all require SIP URIs.
Relays using return routability to authenticate MUST send the MESSAGE request with the permission document to a SIPS URI. This keeps attackers from getting their hands on the (unguessable) URI 🛡️ So the only one who can use that URI is the person who got the MESSAGE request. In the same spirit, permission documents from relays using return routability MUST only contain secure URIs (that's SIPS and HTTPS) for granting and denying permissions. And part of those URIs (like the user part of a SIPS URI) MUST be cryptographically random, with at least 32 bits of randomness 🎲
Relays can also graduate from return routability to SIP identity 🎓 They just require SIP identity for incoming PUBLISH requests, so anything without SIP identity gets rejected. Glow-up complete 🦋
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 whoever sent the PUBLISH is the owner of the recipient URI in the permission document. If not, the PUBLISH SHOULD get a 401 (Unauthorized) response, and it MUST NOT be processed any further 💀
5.7. Permission Granted Notification 🎉
When the PUBLISH request (11) arrives, the relay sends a NOTIFY request (13) to user A. That tells user A the permission for the translation has been received and the relay's translation logic has been updated 🥳 Specifically, sip:B@example.com has been added as a recipient URI. We're getting somewhere, besties!
5.8. Permission Revocation 🚪
Anytime a recipient wants to take back a permission, they use the URI they got in the permission document to deny the permissions they granted before 🙅♀️ But what if they lose that URI? Then they have to wait until a new request from the translation shows up. That request will have a Trigger-Consent header field with a URI in it. The Trigger-Consent header field will have a target-uri header field parameter that names the target URI of the translation 🔍 The recipient then sends a PUBLISH request with an empty body to the URI in Trigger-Consent, and that gets them a MESSAGE request from the relay. That MESSAGE request has a permission document with a URI they can use to revoke the permission 🪄
Figure 5 shows how a user who lost their revoke URI can get a new one from the Trigger-Consent header field of an incoming request. The user rejects an incoming INVITE (1) that has a Trigger-Consent header field. Then, using the URI from that header, the user sends a PUBLISH request (4) to the relay. When the relay gets that PUBLISH request (4), it generates a MESSAGE request (6) for 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: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 RevocationThe original text here carries on from Section 5.8, so I'll start right where that leaves off.
Okay so bestie, this next bit is where the relay gets extra picky 💅✨. Up till now, a user just adds recipient URIs to the translation logic, but the relay doesn't actually translate toward them until permission shows up. Lowkey iconic, right? 🦋
5.9. Request-Contained URI Lists
Okay so in the stuff we've covered so far, a user adds recipient URIs to the relay's translation logic. Super straightforward 🎀. BUT the relay doesn't do any translating toward those URIs until permissions are in. No cap, that's the whole vibe.
URI-list services that use request-contained URI lists are a special case 🌸, because the picking of recipient URIs happens at the exact same moment as the communication attempt. Like, a user drops a bunch of recipient URIs right into a request and sends it to a relay, and then the relay sends a similar request to every single one of them. Main character energy, literally 👑.
Relays that use this consent framework and offer request-contained URI-list services act a little differently than the relays we've talked about. This kind of relay also keeps a list of recipient URIs that have granted permission 🧚. Clients can also edit this list with a manipulation mechanism (e.g., XCAP) 💜. BUT this list is NOT a record of the recipient URIs for every translation the relay does 💀. It's literally just all the recipient URIs that have granted permission, which means it's the set of URIs that will get accepted if a request carrying a URI list shows up at the relay ✨. This set is a superset of the recipient URIs for any single translation the relay performs, so it's bigger than any one of them 🫶.
5.9.1. Relay's Behavior
So when a request-contained URI list comes in, the relay checks whether it has permissions for every URI in that list 🔍. If it does, it performs the translation 🥳. If it's missing permissions for one or more URIs, then the relay MUST NOT perform the translation, and it SHOULD send back an error response 😭.
A relay that gets a request-contained URI list with a URI it has no permissions for SHOULD return a 470 (Consent Needed) response 🙈. The relay SHOULD also add a Permission-Missing header field listing the URIs it has no permissions for 🍓.
Figure 6 shows a relay getting a request (1) that has URIs it doesn't have permission for (the INVITE carries the recipient URIs in its message body) 👀. The relay rejects it with a 470 (Consent Needed) response (2) 🚫. That response includes a Permission-Missing header field with the URIs it had no permission for 💅.
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 Body5.9.2. Definition of the 470 Response Code
A 470 (Consent Needed) response means the request that triggered it had a URI list with at least one URI the relay had no permissions for 🥺. A user agent server that generates a 470 (Consent Needed) response SHOULD include a Permission-Missing header field in it 🎀. That header field carries the URI or URIs the relay had no permissions for ✨.
If a user agent client gets a 470 (Consent Needed) response without a Permission-Missing header field, it NEEDS to use an alternative mechanism (e.g., XCAP) to figure out which URI or URIs had no permissions 🔎. Bestie, that's a bit of detective work 🕵️♀️.
A client that gets a 470 (Consent Needed) response uses a manipulation mechanism (e.g., XCAP) to add those URIs to the relay's list of URIs 🧚♀️. After that, the relay gets permissions for those URIs as usual 💖.
5.9.3. Definition of the Permission-Missing Header Field
Permission-Missing header fields carry URIs that a relay did not have permissions for 🌈. Here's 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 )Here's an example of a Permission-Missing header field 🦋:
Permission-Missing: sip:C@example.com5.10. Registrations
Okay so even though this framework was specified using a URI-list service as the example, it applies to any type of translation, not only URI-list services 🌸. Registrations are their own type of translation and they deserve a proper talk 🗣️.
Registrations are a special type of translation 🎀. The user registering has a trust relationship with the registrar in their home domain 🏠. That is NOT the case when a user gives any type of permissions to a relay in a different domain 🙅♀️.
Traditionally, REGISTER transactions did two jobs at once: setting up a translation and authorizing that translation 🥴. For example, when a user registers their current contact URI, they're giving the registrar permission to forward traffic sent to the user's AoR (Address of Record) to that registered contact URI 💌. This works fine when the entity registering is the same one that receives traffic later on (e.g., the entity gets traffic over the same connection used for the registration, as described in [OUTBOUND]) ✨. BUT this setup creates some sketchy potential attacks related to third-party registrations 😱.
An attacker can bind, through a registration, their own AoR to a victim's contact URI 😈. Now the victim gets unsolicited traffic that was originally addressed to the attacker 🚨.
Figure 7 shows how authorizing a registration works 🧩. User A does a third-party registration (1) and gets a 202 (Accepted) response (2) ✅.
Since the relay doesn't have permission from 'sip:a@ws123.example.com' to perform translations toward that recipient URI, the relay puts '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 getting the response from the relay (2), user A subscribes to the Pending Additions event package at the registrar (5) 🔔. This subscription keeps the user in the loop about the permission status (e.g., granted or denied) that the registrar will obtain 👀. The rest of the process is similar to what's described in Section 5 🎀.
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: RegistrationPermission documents generated by registrars are usually super general 🌍. For example, in one of these documents a registrar can ask a recipient for permission to forward any request from any sender to the recipient's URI 📬. This is the level of granularity this framework aims to provide for registrations 🎯. Users who want to set up how incoming requests are handled with finer detail (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 mentioned earlier, user agents that use 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 that's being registered by a third party might be unable to use the SIP Identity, P-Asserted-Identity, or SIP digest mechanisms to prove to the registrar that it owns 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 that generate traffic toward recipients need to make sure those recipients can revoke the permissions they gave at any time ⏰. The Trigger-Consent helps with this 🫶.
5.11.1. Relay's Behavior
A relay that executes a translation involving sending a request to a URI it got permissions from before 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 that identifies the target URI of the translation 🎯.
When a relay gets a PUBLISH request addressed to the URI it previously placed in a Trigger-Consent header field, the relay SHOULD send a MESSAGE request to the matching recipient URI with a permission document 📨. So the relay needs to be able to match up the URI it put in the Trigger-Consent header field with the recipient URI of the translation 🧩.
5.11.2. Definition of the Trigger-Consent Header Field
Here's 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 ) RDQUOTThe target-uri header field parameter MUST contain a URI 🔗.
Here's an example of a Trigger-Consent header field 🎀:
Trigger-Consent: sip:123@relay.example.com
;target-uri="sip:friends@relay.example.com"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 🎀
okay so IANA added a brand new SIP header field called Trigger-Consent to the Header Fields subregistry under the SIP Parameters registry 🦋 it's giving official ✨
Header Name: Trigger-Consent
Compact Form: (none)
Reference: [RFC5360]6.3. Registration of the Permission-Missing Header Field 💅
same energy here! IANA also added Permission-Missing to that same Header Fields subregistry under the SIP Parameters registry 🌸 no compact form, and the reference is [RFC5360] 🫶
Header Name: Permission-Missing
Compact Form: (none)
Reference: [RFC5360]6.4. Registration of the target-uri Header Field Parameter 🧚
IANA registered the target-uri parameter for the Trigger-Consent header field 💜 it lives in the Header Field Parameters and Parameter Values subregistry inside the SIP Parameters registry. no predefined values for this one, and the reference is [RFC5360] 🍓
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Trigger-Consent target-uri No [RFC5360]7. Security Considerations 🔥😭
okay this section is SERIOUS bestie, so grab a snack 🍓 security has been talked about the whole way through the document ✨ BUT there are a few things that deserve their own spotlight, so here we go 👑
relays usually have several security mechanisms for client authentication and authorization 🔐 clients are normally authenticated before they can touch a relay's translation logic. on top of that, clients are typically authenticated too, and sometimes they have to do SPAM prevention tasks [RFC5039] when they send traffic to a relay 🙈 it's important that relays actually implement these kinds of mechanisms. BUT they're out of scope for this framework. and even with all of those in place, relays still need this framework, because those mechanisms don't stop authorized clients from adding recipients to a translation without their consent 💀 so, lowkey non-negotiable: relays performing translations MUST implement this framework. 🔥
Note that, as mentioned before, user agents that use the same connection to register and to receive traffic from the registrar, as described in [OUTBOUND], don't need to use this framework. so a registrar that doesn't accept third-party registrations wouldn't need to implement it either 🦋
okay now the return routability stuff 🧐 as Section 5.6.1.3 pointed out, when return routability tests are used to authenticate recipients who grant or deny permissions, the URIs used for granting or denying need to be protected from attackers 🛡️ SIPS URIs are a great tool for this, as described in [RFC5361] ✨ but when store-and-forward servers are involved, the interface between a user agent and its store-and-forward server often isn't based on SIP 😬 so SIPS can't be used to secure those URIs in that case. the bottom line: implementations of store-and-forward servers MUST provide a mechanism for delivering encrypted and integrity-protected messages to their user agents. no cap, that's a must 🫶
the information in the Pending Additions event package can be seriously sensitive 🥺 so as described in [RFC5362], relays need strong means for authentication and information confidentiality. SIPS URIs are a good way to meet this one too 🌈
permission documents can reveal sensitive info, and attackers might try to change them so clients end up granting or denying permissions that aren't the ones they thought they were handling 👀 so it's RECOMMENDED that relays use strong means for information integrity protection and confidentiality when sending permission documents to clients 💖
the mechanism used to convey info to clients SHOULD ensure the integrity and confidentiality of the information 🎀 to get that, an end-to-end SIP encryption mechanism such as S/MIME, as described in [RFC3261], SHOULD be used ✨
and if strong end-to-end security (like the above) isn't available, it's 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 gave really useful ideas on this document 💜 and Ben Campbell, AC Mahendran, Keith Drage, and Mary Barnes did a thorough review of it 🌸 huge thanks to all of them, they're literal legends 👑
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.
[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.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.comFull 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 on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available 🤷♀️ it also doesn't say it has made any independent effort to identify any such rights. info on how rights work for RFC documents is in BCP 78 and BCP 79 ✨
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use such proprietary rights can be found in 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, patent applications, or other proprietary rights that may cover technology required to implement this standard. send that info to ietf-ipr@ietf.org 💌 and that's the whole tea, periodt 🍵💅
📦 where this page comes from
- ietf: rfc5360 2008-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms