RFC 5379
Guidelines for Using the Privacy Mechanism for SIP
RFC 5379: Guidelines for Using the Privacy Mechanism for SIP ✨
okay bestie, let's start with the title block 🎀 This is RFC 5379, called "Guidelines for Using the Privacy Mechanism for SIP." It's an Independent Submission and its Category is Informational. The ISSN is 2070-1721 and the date is February 2010. The authors are M. Munakata, S. Schubert, and T. Ohba, all from NTT. It doesn't list anything it obsoletes or updates, so it's a standalone doc 💅
Abstract
okay so this is an informational doc with guidelines for the privacy mechanism in the Session Initiation Protocol (SIP) 📞 That mechanism is specified in RFC 3323, and then RFCs 3325 and 4244 extended it. The whole point is to clarify what the target SIP headers and parameters are, plus the Session Description Protocol (SDP) parameters, for each of the privacy header values (priv-values) 🦋
Status of This Memo
this one is not an Internet Standards Track spec, it's just published for info purposes 🌸
it's a contribution to the RFC Series that's independent of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about how useful it is for implementation or deployment 🫶 Docs the RFC Editor approves for publication aren't a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for that.
info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc5379 ✨
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions for this document 🙈
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Semantics of Existing priv-values ...............................4
4. Target for Each priv-value ......................................5
4.1. Target SIP Headers for Each priv-value .....................5
4.2. Target SDP Parameters for Each priv-value ..................6
4.3. Treatment of priv-value Not Supported by the
Privacy Service ............................................7
5. Recommended Treatment of User-Privacy-Sensitive Information .....7
5.1. Target SIP Headers .........................................7
5.1.1. Call-ID .............................................7
5.1.2. Call-Info ...........................................8
5.1.3. Contact .............................................8
5.1.4. From ................................................9
5.1.5. History-Info .......................................10
5.1.6. In-Reply-To ........................................10
5.1.7. Organization .......................................11
5.1.8. P-Asserted-Identity ................................11
5.1.9. Record-Route .......................................12
5.1.10. Referred-By .......................................13
5.1.11. Reply-To ..........................................14
5.1.12. Server ............................................14
5.1.13. Subject ...........................................15
5.1.14. User-Agent ........................................15
5.1.15. Via ...............................................15
5.1.16. Warning ...........................................16
5.2. Target SDP Parameters .....................................16
5.2.1. c/m Lines ..........................................16
5.2.2. o Line .............................................17
5.2.3. i/u/e/p Lines ......................................17
5.3. Considerations for Non-Target SIP Headers/Parameters ......17
5.3.1. Identity/Identity-Info .............................17
5.3.2. Path ...............................................18
5.3.3. Replaces Header/Parameter ..........................18
5.3.4. Route ..............................................21
5.3.5. Service-Route ......................................21
5.3.6. Target-Dialog ......................................21
6. Security Considerations ........................................21
7. Acknowledgements ...............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................221. Introduction ✨
okay so this doc clarifies the privacy mechanism for SIP [RFC3261], which is defined in [RFC3323]. [RFC3325] and [RFC4244] later extended it. It's a guideline about how the privacy mechanism actually operates in practice, and it does not change the existing mechanism 🧚
so in RFC 3323, the semantics of the basic set of priv-values ("header", "session", "user", "none", and "critical") are defined. The gap is that the target information to be obscured per priv-value isn't explicitly specified, and that's the messy part 😭 Because of that, an entity setting a Privacy header and an entity processing one could read the same priv-value differently. That can hurt interoperability, bestie.
there are also two extra priv-values, "id" and "history," defined in RFCs 3325 and 4244 respectively 💅
RFC 4244 defines the priv-value "history" to request privacy for History-Info headers. The target for "history" is specified as only the History-Info headers. The RFC also clearly says History-Info headers are a target when "header"- and "session"-level privacy are requested too 👑
RFC 3325, on the other hand, defines the P-Asserted-Identity header and the priv-value "id," which requests privacy for only the P-Asserted-Identity header. What it doesn't say is how the other priv-values might affect privacy handling for P-Asserted-Identity 🙈 Since that's unspecified, some implementations have had trouble achieving the privacy they meant to, because they read things differently.
so this doc tries to clarify which SIP headers and SDP parameters get obscured for each priv-value 🎀 The goal is to clear up the interoperability issues people already hit from the lack of explicit text.
2. 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 [RFC2119].
Note: this doc is informational, so it does not specify any new normative behaviors for the privacy mechanism. All the RFC 2119 language in here is derived from the normative text in existing RFCs, like RFC 3323. 🌈
here are the key terms, bestie 💜
priv-value: values registered with IANA to be used in the Privacy header. The registered priv-values are "header", "session", "user", "none", and "critical" defined in [RFC3323]; "id" defined in [RFC3325]; and "history" defined in [RFC4244].
privacy service: a network entity that runs privacy functions before forwarding messages to the next hop. It's sometimes abbreviated to PS in this doc 🧚
user-level privacy: privacy for user-inserted information that the user agent itself can anonymize 🌸
3. Semantics of Existing priv-values 💖
this section gives the semantics of each priv-value defined in RFCs 3323, 3325, and 4244. The descriptions are taken straight from the IANA registration, so they're the official vibes ✨
Privacy Type Description Reference
------------- ---------------------------------- ----------
user Request that privacy services [RFC3323]
provide a user-level privacy function
header Request that privacy services modify [RFC3323]
headers that cannot be set arbitrarily
by the user (Contact/Via).
session Request that privacy services provide [RFC3323]
privacy for session media
none Privacy services must not perform any [RFC3323]
privacy function
critical Privacy service must perform the [RFC3323]
specified services or fail the request
id Privacy requested for Third-Party [RFC3325]
Asserted Identity
history Privacy requested for [RFC4244]
History-Info header(s)4. Target for Each priv-value 🍓
okay so this section has tables showing the recommended treatment of SIP headers and SDP parameters for each priv-value 📊 Any SIP headers or SDP parameters not shown in the tables are regarded as non-targets of those priv-values. Some non-target SIP headers and SDP parameters may still carry privacy-sensitive info that needs privacy treatment no matter what privacy level was requested. Section 5.3 gets into that more 🙈
how the SIP headers and SDP parameters listed here actually get obscured may depend on the implementation and network policy. This doc doesn't block the different variations that might exist under local policy, but it does try to give recommendations for how a privacy service treats SIP headers and SDP parameters 🫶
Scope note: the scope of these tables is SIP headers and related parameters specified in RFCs. 🎀
and that's where we are for now, bestie 🦋 more of this doc is still coming up!
4.1. Target SIP Headers for Each priv-value 💅
okay so Table 1 is basically your cheat sheet 🎀 It shows the recommended treatment for each SIP header for each priv-value. The deep dives are in Section 5, bestie.
The "where" column tells you which kinds of messages need the treatment to keep things private 🦋 The values are:
R: the header needs the treatment when it shows up in a request.r: the header needs the treatment when it shows up in a response.
The next five columns are the recommended treatments for each priv-value:
delete: the header is recommended to be deleted at a privacy service.not add: the header is recommended not to be added at a privacy service.anonymize: the header is recommended to be anonymized at a privacy service. How to anonymize it depends on the header, and the details are in Section 5.anonymize*: the asterisk means the involvement of a privacy service and the treatment of the header depend on the circumstance. The details are in Section 5 too 🌸
Target headers where user header session id history
--------------------------------------------------------------------
Call-ID (Note) R anonymize - - - -
Call-Info Rr delete not add - - -
Contact R - anonymize - - -
From R anonymize - - - -
History-Info Rr - delete delete - delete
In-Reply-To R delete - - - -
Organization Rr delete not add - - -
P-Asserted-Identity Rr - delete - delete -
Record-Route Rr - anonymize - - -
Referred-By R anonymize* - - - -
Reply-To Rr delete - - - -
Server r delete not add - - -
Subject R delete - - - -
User-Agent R delete - - - -
Via R - anonymize - - -
Warning r anonymize - - - -
Table 1: Recommended PS behavior for each SIP headerNote: any time a privacy service modifies a Call-ID, it MUST retain the former and modified values, as indicated in Section 5.3 in RFC 3323. It MUST then restore the former value in a Call-ID header and in other corresponding headers and parameters (such as In-Reply-To, Replaces, and Target-Dialog) in any messages that are sent using the modified Call-ID to the originating user agent. It should also modify a Call-ID header and other corresponding headers/parameters (such as Target-Dialog and "replaces" parameter) in any further relevant messages that are sent by the originating user agent. Refer to Section 5.1.1 (Call-ID) for the detailed behavior 🫶
Identity/Identity-Info, Path, Replaces, Route, Service-Route, and Target-Dialog headers are not targets of these priv-values. They should not be anonymized or modified by a privacy service based on a priv-value in a Privacy header. Refer to Section 5.3 for details ✨
4.2. Target SDP Parameters for Each priv-value 🎧
the recommended PS behaviors for each SDP parameter are honestly simple, no drama 💖 The c, m, o, i, u, e, and p lines in SIP request/response are recommended to be anonymized when user privacy is requested with Privacy:session.
4.3. Treatment of priv-value Not Supported by the Privacy Service 🚫
as RFC 3323 spells out, if the priv-value of "critical" is present in the Privacy header of a request, and the privacy service can't perform all of the levels of privacy listed in that header, it MUST fail the request with a 500 (Server Error) response code, as indicated in Section 5 in RFC 3323. no exceptions, periodt 💅
since protecting privacy is a big deal, the privacy service should also fail the request with a 500 response code when it's incapable of performing all of the levels of privacy in the Privacy header, even if "critical" isn't there 😭
5. Recommended Treatment of User-Privacy-Sensitive Information 🌈
okay this is the main event 👑 The following SIP headers and related parameters may concern privacy. This section describes what kind of user-privacy-sensitive information may be in each SIP header/parameter, and how to keep that info private at a user agent or a privacy service when it really is privacy-sensitive.
5.1. Target SIP Headers 🎀
this section covers the privacy considerations and recommended treatment for each SIP header that might reveal user-privacy-sensitive info. It goes into how each header affects privacy, what the user agent and privacy service should do with the value, and any extra notes you need to actually pull it off 🧚
5.1.1. Call-ID 🆔
this field frequently contains an IP address or hostname of a UAC (User Agent Client) appended to the Call-ID value, which is exactly the kind of thing we want to hide 🙈
a user agent doing a user-level privacy function on its own SHOULD swap that IP address or hostname for a suitably long random value (the value used as the 'tag' for the From header of the request might even be reused), as indicated in Section 4.1 in RFC 3323 🦋
a privacy service MAY anonymize the Call-ID header when the request contains Privacy:user, by substituting for the IP address or hostname in the Call-ID a suitably long random value (such as a From tag value) so that it is sufficiently unique, as indicated in Section 5.3 in RFC 3323 ✨
Call-ID is essential to dialog matching, so any time a privacy service modifies this field, it MUST retain the former value and restore it in a Call-ID header in any messages that are sent to/by the originating user agent inside the dialog, as indicated in Section 5.3 in RFC 3323. A privacy service should be prepared to receive a request outside the dialog containing the value of the Call-ID set by the PS in other SIP headers (e.g., In-Reply-To/Replaces/Target-Dialog), at least while the dialog state is active for the dialog whose Call-ID was modified by that PS. When such a request is received, the Call-ID value contained in the relevant headers indicated above should be replaced by the retained value 💜
Note: this is possible only if the privacy service maintains the state and retains all the information it modified to provide privacy. Some PSs are known to encrypt information prior to obfuscation in the Via header, etc. In this case, the PS cannot correlate the modified Call-ID value with the original Call-ID. Further challenges come up when the PS needs to stay on a signaling path to make sure it receives all the messages aimed at the caller it's protecting, especially when the request is out-of-dialog 😬
refer to the corresponding sections, 5.1.6 (In-Reply-To), 5.3.3 (Replaces Header/Parameter), and 5.3.6 (Target-Dialog), for detailed discussion 📚
5.1.2. Call-Info ℹ️
this field contains additional information about the user, so it can leak stuff 👀
a user agent doing a user-level privacy function on its own SHOULD NOT add a Call-Info header, as indicated in Section 4.1 in RFC 3323 🙅♀️
a privacy service MUST delete a Call-Info header if one exists when user privacy is requested with Privacy:user, as indicated in Section 5.3 in RFC 3323. A privacy service SHOULD NOT add a Call-Info header when user privacy is requested with Privacy:header, as indicated in Section 5.1 in RFC 3323 💅
5.1.3. Contact 📇
this field contains a URI used to reach the user agent for mid-dialog requests and possibly out-of-dialog requests, such as REFER [RFC3315]. Since the Contact header is essential for routing further requests to the user agent, it must include a functional URI even when it is anonymized. so it's a balancing act, bestie 🎯
a user agent MUST NOT anonymize a Contact header, unless it can obtain an IP address or contact address that is functional yet has a characteristic of anonymity, as indicated in Section 4.1.1.3 in RFC 3323 🔐
since RFC 3323 was published, there have been proposals that let UAs obtain an IP address or contact address with a characteristic of anonymity 🌸
the mechanisms being discussed at the time of this writing are Globally Routable User Agent URIs (GRUU) [SIPGRUU], which provides a functional Contact address with a short life span, making it ideal for privacy sensitive calls, and Traversal Using Relays around NAT (TURN) [TURN], through which an IP address of a relay can be obtained for use in a Contact header 🦋
a privacy service SHOULD anonymize a Contact header by replacing the existing Contact header field value with the URI that dereferences to the privacy service when user privacy is requested with Privacy:header, as indicated in Section 5.1 in RFC 3323. This is generally done by replacing the IP address or hostname with that of the privacy service 💖
5.1.4. From 🎭
this field contains the identity of the user, such as display-name and URI. Main character identity, literally 👑
a user agent doing a user-level privacy function on its own SHOULD anonymize a From header using an anonymous display-name and an anonymous URI, as indicated in Section 4.1 in RFC 3323 🫥
a privacy service should anonymize a From header when user privacy is requested with Privacy:user 🧚
Note: this does not stop a privacy service from anonymizing the From header based on local policy 📝
the anonymous display-name and anonymous URI mentioned in this section use the display-name "Anonymous", a URI with "anonymous" in the user portion of the From header, and the hostname value "anonymous.invalid", as indicated in Section 4.1.1.3 in RFC 3323 🕵️♀️
the recommended form of the From header for anonymity is:
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774The tag value varies from dialog to dialog, but the rest of this header form is recommended as shown 🎀
5.1.5. History-Info 🗺️
History-Info [RFC4244] header URIs to which the request was forwarded or retargeted can reveal general routing information, so it's giving "where have you been" energy 🧭
a user agent doing a user-level privacy function on its own SHOULD NOT add a History-Info header, as indicated in Section 3.3 in RFC 4244 🙅♀️
a privacy service SHOULD delete the History-Info headers when user privacy is requested with Privacy:header, Privacy:session, or Privacy:history, as indicated in Section 3.3 in RFC 4244 🗑️
the privacy could also be expressed for a specific History-Info entry by inserting privacy=history in the History-Info header. In such a case, a privacy service SHOULD delete the History-Info entry, as indicated in Section 4.3.3.1.1 in RFC 4244 🌟
refer to [RFC4244] for the detailed behavior for dealing with History-Info headers 🫶
5.1.6. In-Reply-To 💌
okay so the In-Reply-To header carries the Call-ID of the dialog being replied to 🦋 which means the replying user can be spotted from that Call-ID ✨
Alice > INV(Call-ID:C1) > Bob
Bob > INV(In-Reply-To:C1) > Alicengl this is the sneaky part 🙈 unless the In-Reply-To header gets deleted, Alice might notice the replier is Bob, because her UA knows that the Call-ID relates to Bob 💀
A user agent doing a user-level privacy function on its own should not add an In-Reply-To header, as implied in Section 4.1 in RFC 3323 💅
A privacy service MUST delete the In-Reply-To header when user privacy is requested with Privacy:user, as indicated in Section 5.3 in RFC 3323 🔥
Since an In-Reply-To header holds the Call-ID of the dialog it's replying to, it needs extra care, as described in Section 5.1.1 (Call-ID), no matter the priv-value or whether there's a Privacy header 🫶 Once a privacy service changes a Call-ID in the request, it should restore the former value in an In-Reply-To header (if one is present in the INVITE request replying to the original request), as long as the privacy service keeps track of the dialog state 🧚
Example:
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Bob > INV(In-Reply-To:C2, Privacy:none) > PS >
INV(In-Reply-To:C1) > AliceNote: This is possible only if the privacy service maintains the state and retains all the information that it modified to provide privacy even after the dialog has been terminated, which is unlikely. Call-back is difficult to achieve when a privacy service is involved in forming the dialog to be referenced. 😭
5.1.7. Organization 🏢
this field has extra info about the user 🌸
A user agent doing a user-level privacy function on its own should not add an Organization header, as implied in Section 4.1 in RFC 3323 ✨
A privacy service MUST delete the Organization header if one exists when user privacy is requested with Privacy:user, as indicated in Section 5.3 in RFC 3323 💖 A privacy service SHOULD NOT add an Organization header when user privacy is requested with Privacy: header, as indicated in Section 5.1 in RFC 3323 🙅♀️
5.1.8. P-Asserted-Identity 🪪
this header holds a network-verified and network-asserted identity of the user sending a SIP message 👑
A privacy service MUST delete the P-Asserted-Identity headers when user privacy is requested with Privacy:id, as indicated in Section 7 in RFC 3325 🔥 and it should delete the P-Asserted-Identity headers when user privacy is requested with Privacy:header before it forwards the message to an entity that is not trusted 🦋
It is recommended for a privacy service to remove the P-Asserted-Identity header if user privacy is requested with Privacy:id or Privacy:header, even when forwarding to a trusted entity, unless it can be confident that the message will not be routed to an untrusted entity without going through another privacy service 🧚
5.1.9. Record-Route 🗺️
this field may reveal info about the user's administrative domain 👀
To hide Record-Route headers while keeping routability to the sender, privacy services can do something called "stripping" ✨ Stripping means removing all the Record-Route headers that were added to the request before it arrived at the privacy service, and then adding a single Record-Route header representing itself 💅 In this case, the privacy service needs to keep the removed headers and restore them in a response 🫶
Or, privacy services can remove the Record-Route headers and encrypt them into a single Record-Route header field 🔐 In this case, the privacy service needs to decrypt the header and restore the former values in a response 💜
A privacy service SHOULD strip or encrypt any Record-Route headers that have been added to a message before it reaches the privacy service when user privacy is requested with Privacy:header, as indicated in Section 5.1 in RFC 3323 🌈
As with a Call-ID, if a privacy service modifies the Record-Route headers, it MUST be able to restore Route headers with retained values, as indicated in Section 5.1 in RFC 3323 🎀 Some examples where restoring the Route headers is necessary and unnecessary are below 👇
When a UAC (Alice) requires privacy for a request, a privacy service does not have to restore the Route headers in the subsequent request (see Example 1) 🌸
On the other hand, when a UAS (User Agent Server) (Bob) requires privacy for a response, a privacy service has to restore the Route headers in the subsequent request (see Example 2) 😤
Example 1:
Restoration of Route header is UNNECESSARY when UAC requires privacy
Alice > INV(Privacy:header) > P1 >
INV(Record-Route:P1, Privacy:header) > PS >
INV(Record-Route:PS) > P2 >
INV(Record-Route:P2,PS) > Bob
Bob > 200(Record-Route:P2,PS) > P2 > PS >
200(Record-Route:P2,PS,P1) > P1 > Alice
Alice > re-INV(Route:P2,PS,P1, Privacy:header) > P1 >
re-INV(Route:P2,PS, Privacy:header) > PS >
re-INV(Route:P2) > P2 > re-INV > Bob Alice P1 PS P2 Bob
| | | | |
| INV Priv |INV Priv RR:P1 | INV RR:PS | INV RR:P2,PS |
|---------------->|---------------->|---------------->|-------------->|
| | | | |
| 200 RR:P2,PS,P1 | 200 RR:P2,PS,P1 | 200 RR:P2,PS | 200 RR:P2,PS |
|<----------------|<----------------|<----------------|<--------------|
| | | | |
| INV R:P2,PS,P1 | INV R:P2,PS | INV R:P2 | INV |
|---------------->|---------------->|---------------->|-------------->|
| | | | |Figure 1: Example when restoration of Route header is UNNECESSARY 🎀
Example 2:
Restoration of Route header is NECESSARY when UAS requires privacy
Alice > INV > P1 > INV(Record-Route:P1) > P2 >
INV(Record-Route:P2,P1) > Bob
Bob > 200(Record-Route:P2,P1, Privacy:header) > P2 > PS' >
200(Record-Route:PS',P1) > P1 > Alice
Alice > re-INV(Route:PS',P1) > P1 > re-INV(Route:PS') > PS' >
re-INV(Route:P2) > P2 > Bob Alice P1 PS' P2 Bob
| | | | |
| INV |INV RR:P1 | | INV RR:P2,P1 |
|-------------->|---------------------------------->|---------------->|
| | | | |
| 200 RR:PS',P1 | 200 RR:PS',P1 |200 Priv RR:P2,P1|200 Priv RR:P2,P1|
|<--------------|<----------------|<----------------|<----------------|
| | | | |
| INV R:PS',P1 | INV R:PS' | INV R:P2 | INV |
|-------------->|---------------->|---------------->|---------------->|
| | | (Restored) | |Figure 2: Example when restoration of Route header is NECESSARY 🧩
Note: In Figures 1 and 2, Priv means Privacy:header, RR means Record-Route header, and R means Route header. 📝
5.1.10. Referred-By 🙋♀️
The Referred-By [RFC3892] header carries a SIP URI representing the identity of the referrer 🫣
The Referred-By header is an anonymization target when the REFER request with the Referred-By header is sent by the user (referrer) whose privacy is requested to be processed in the privacy service 🎭
A user agent that constructs REFER requests and does a user-level privacy function on its own should anonymize a Referred-By header by using an anonymous URI 🕶️
A privacy service should anonymize a Referred-By header in a REFER request by using an anonymous URI when user privacy is requested with Privacy:user 💜
On the other hand, the Referred-By header is not an anonymization target when it appears in a request other than REFER (e.g., INVITE), because the URI in the Referred-By header does not represent the sender of the request 🙅♀️
Example 1:
Referrer requests no privacy and referee requests privacy
Alice > REF(Referred-By:Alice) > Bob
Bob > INV(Referred-By:Alice, Privacy:user) > PS >
INV(Referred-By:Alice) > CarolExample 2:
Referrer requests privacy and referee requests privacy
Alice > REF(Referred-By:Alice, Privacy:user) > PS >
REF(Referred-By:X) > Bob
Bob > INV(Referred-By:X, Privacy:user) > PS >
INV(Referred-By:X) > Carol5.1.11. Reply-To 📮
this field has a URI that can be used to reach the user on later call-backs 📞
A user agent doing a user-level privacy function on its own should not add a Reply-To header to the message, as implied in Section 4.1 in RFC 3323 🌷
A privacy service MUST delete a Reply-To header when user privacy is requested with Privacy:user, as indicated in Section 5.3 in RFC 3323 🔥
5.1.12. Server 🖥️
this field has info about the software the UAS used to handle the request 🤖
A user agent doing a user-level privacy function on its own should not add a Server header in the response, as implied in Section 4.1 in RFC 3323 ✨
A privacy service must delete a Server header in a response when user privacy is requested with Privacy:user 🧹 A privacy service SHOULD NOT add a Server header in a response when user privacy is requested with Privacy:header, as indicated in Section 5.1 in RFC 3323 🙅♀️
5.1.13. Subject 🎀
this field is free-form text about the subject of the call 💬 It may include text describing something about the user 👀
A user agent doing a user-level privacy function on its own should not include any information identifying the caller in a Subject header 🤐
A privacy service MUST delete a Subject header when user privacy is requested with Privacy:user, as indicated in Section 5.3 in RFC 3323 🔥
5.1.14. User-Agent 🪄
this field has the UAC's info 🧾
A user agent doing a user-level privacy function on its own should not add a User-Agent header, as implied in Section 4.1 in RFC 3323 ✨
A privacy service MUST delete a User-Agent header when user privacy is requested with Privacy:user, as indicated in Section 5.3 in RFC 3323 💅
5.1.15. Via 🛤️
The bottommost Via header added by a user agent has the IP address and port or hostname used to reach the user agent for responses 📍 Via headers added by proxies may reveal info about the user's administrative domain 🏰
A user agent MUST NOT anonymize a Via header, as indicated in Section 4.1.1.3 in RFC 3323, unless it can obtain an IP address that is functional yet has a characteristic of anonymity 🙈 This may be possible by getting an IP address specifically for this purpose, either from the service provider or through features such as TURN 🦋
A privacy service SHOULD strip or encrypt any Via headers that were added prior to reaching the privacy service when user privacy is requested with Privacy:header, as indicated in Section 5.1 in RFC 3323 🌈 Refer to Section 5.1.9 (Record-Route) for details of stripping and encryption 🔐
A privacy service MUST restore the original values of Via headers when handling a response, in order to route the response to the originator, as indicated in Section 5.1 in RFC 3323 🧚
No Via stripping is required when handling responses ✨
5.1.16. Warning 🎀
okay so the Warning header is allowed to carry the hostname of the UAS 🫶
if a user agent is doing a user-level privacy thing on its own, it should not put the hostname that represents its identity in a Warning header 🙈
a privacy service should anonymize a Warning header by deleting the hostname part (if it's showing a UAS's identity) whenever user privacy is requested with Privacy:user ✨
5.2. Target SDP Parameters 🦋
this section is all about the privacy stuff for each SDP [RFC4566] parameter that might reveal info about the user 👀
when privacy functions for user-inserted information get requested at a privacy service, user agents MUST NOT encrypt SDP bodies in messages, as described in Section 4.2 in RFC 3323 🔒 that one's a big deal, bestie
5.2.1. c/m Lines 🌸
the c and m lines carry the IP address and port for receiving media, so they're kind of a big deal 💅
a user agent must not anonymize the IP address and port in the c and m lines, unless it can get an IP address that actually works but also has that anonymity vibe from Section 4.1.1.3 in RFC 3323 🧚 this might be doable by getting an IP address just for this purpose, either from the service provider or through stuff like TURN
a privacy service must anonymize the IP address and port in c and m lines using a working anonymous IP address and port when user privacy is requested with Privacy:session ✨ this is usually done by swapping the IP address and port in the SDP for the ones from a relay server 🫧
5.2.2. o Line 🍓
the username and IP address in this parameter can reveal stuff about the user, so it's giving main character attention 👑
a user agent may anonymize the username in an o line by setting the username to -, and it may anonymize the IP address in the o line by replacing it with a value that's sufficiently unique 💜
a privacy service must anonymize the username and IP address in the o line by setting the username to - and replacing the IP address with a value that's sufficiently unique when user privacy is requested with Privacy:session 🌈
5.2.3. i/u/e/p Lines 🧚
these lines might contain info about the user 🙈
a user agent doing a session-level privacy function on its own should not include the user's information in the i, u, e, and p lines 💅
a privacy service should modify the i, u, e, and p lines to delete the user's identity information when user privacy is requested with Privacy:session ✨
5.3. Considerations for Non-Target SIP Headers/Parameters 💖
5.3.1. Identity/Identity-Info 🔐
the Identity [RFC4474] header carries a signature that's used for validating the identity 🪪 the Identity-Info header holds a reference to the certificate of whoever signed the Identity headers 📜 and an Identity-Info header can reveal stuff about the administrative domain of the user 👀
the signature in an Identity header gives integrity protection over the From, To, Call-ID, Cseq, Date, and Contact headers, plus the message body 🛡️ that protection gets broken if a privacy service changes these headers and/or the message body to protect the user's privacy 💔
once those integrity-protected headers (like From and Call-ID) get changed, the Identity/Identity-Info header fields aren't valid anymore 😭 so a privacy service handling a request with Privacy:user, Privacy:header, or Privacy:session can knock out the integrity protection from an upstream authentication service that already added Identity/Identity-Info header fields 💀 if you need to keep the integrity protection, avoid using a privacy service like that 🫶 otherwise, if the privacy service breaks the integrity protection, it should remove the Identity/Identity-Info header fields 🧹
an authentication service that sits downstream of the privacy service may add Identity/Identity-Info header fields if the domain name in the From header field URI hasn't been anonymized (for example, sip:anonymous@example.com) ✨ that's what lets the service authenticate the UAC 🔑 this authenticated-but-anonymous From header basically says "this is a known user in my domain that I've authenticated, but I'm keeping their identity private," as described in Section 12 in RFC 4474 🤫
the desired setup has a privacy service located before or co-located with the identity service, so integrity and privacy can both be provided seamlessly 🌸💖
5.3.2. Path 🛤️
this field might contain info about the administrative domain and/or the visited domain of the user agent 👀 but the Path header isn't the target of any priv-values
since the Path header [RFC3327] only shows up in REGISTER requests/responses and is essential for a call to reach the registered UA in the visited domain, there's no point in hiding or withholding it... it's actually harmful 😬
the only reason privacy might be worth considering is if the visited domain wants to keep its topology hidden from the user's home domain 🕵️♀️ but then the domain hiding its topology needs to make sure it still gives enough info so the home domain can route the call to the visited domain and actually reach the UA 🧭
anonymization of network-privacy-sensitive information is out of scope, so we're not going there 🚫
5.3.3. Replaces Header/Parameter 🔁
the Replaces [RFC3891] header and the "replaces" parameter hold identifiers for a dialog that's going to be replaced, made up of the Call-ID, local tag, and remote tag 🪪
the sender of an INVITE with a Replaces header usually isn't the originating user agent or terminating user agent of the target dialog 🙅♀️ so the Call-ID inside the Replaces header is unlikely to be generated by the sender, which means this header is outside the anonymization target for each priv-value 💅
the "replaces" parameter, which shows up in a Refer-To header in a REFER request, isn't the target of any particular priv-values either 🤷♀️ as Section 5.1.1 (Call-ID) explains, no matter the priv-value or whether there's a Privacy header, once a privacy service changes a Call-ID in the request, it should keep an eye on headers that might contain Call-ID and restore the part of the value representing the changed Call-ID back to the original Call-ID value in a Replaces header it receives 🔄
the big challenge is that a privacy service has to be on the signaling path to the originator for every dialog 😵💫 that's generally not possible, so REFER requests end up not working all the time 💔 this is a trade-off you expect when privacy is imposed, so it's kind of part of the deal 🤝
the privacy requirements from Section 5.1.1 will make the Replaces header and "replaces" parameter contain values that fail dialog establishment in some situations 💀 this loss of functionality is allowed and/or intended, as shown above (so it's not the privacy service's job to make sure these features always work) 🙅♀️
how the Replaces header/parameter works when anonymized depends on the circumstances it's used in 🧩 REFER might work or might not work depending on these three criteria:
- Who generated the Call-ID.
- Where the privacy service is on the signaling path.
- Who initiates the
REFERwith the "replaces" parameter.
here are a few examples that show when the Replaces header/parameter works or fails 🎬
Example 1:
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS >
REF(Refer-To:Bob?Replaces=C2) > Carol
Carol > INV(Replaces:C2) > Bob (SUCCEED)Example 2:
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1) > Carol
Carol > INV(Replaces:C1) > Bob (FAIL)Note: Example 2 would succeed if the same PS (the one that modifies the Call-ID in the INVITE from Alice) is also added for REFER and changes the value in the "replaces" parameter from C1 to C2, even if there's no Privacy header in the REFER. 🙌
Example 3:
Alice > INV(Call-ID:C1) > INV(Call-ID:C1) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:user) > PS >
REF(Refer-To:Bob?Replaces=C1) > Carol
Carol > INV(Replaces:C1, Privacy:user) > PS' >
INV(Replaces:C1) > Bob (SUCCEED)Example 4:
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Bob > REF(Refer-To:Alice?Replaces=C2) > Carol
Carol > INV(Replaces:C2) > PS > INV(Replaces:C1) > Alice (SUCCEED)Note: Example 4 succeeds because the same PS (the one that modifies the Call-ID in the INVITE from Alice) checks the incoming requests and changes the value in a Replaces header in the INVITE from Carol back to the former value of Call-ID (C1). ✨
Example 5:
Alice > INV(Call-ID:C1, Privacy:user) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1) > Music-Server
Music-Server > INV(Replaces:C1) > Bob (FAIL)Note: Example 5 would succeed if the same PS (the one that modifies the Call-ID in the INVITE from Alice) is added for the INVITE from the Music-Server and changes the value in a Replaces header from C1 to C2. 🎶
as the examples above show, in some scenarios the information carried in the Replaces header/parameter makes the REFER fail 😭 this won't happen if the Call-ID isn't modified at a privacy service 🫶
5.3.4. Route 🗺️
this field might contain info about the administrative domain of the user agent, but the Route header isn't the target of any priv-values 💅
Route headers only appear in SIP requests, to force routing through the listed set of proxies 🚏 if a privacy service anonymizes the Route header, the routing stops working 🙃 also, there's no risk in revealing the info in the Route headers to further network entities (including the terminating user agent), because a proxy removes the value from the Route header when it replaces the value in the Request-URI, as defined in RFC 3261 🧼
a privacy service that modifies Record-Route headers might need to restore the values in Route headers as necessary 🔧 as Section 5.1 in RFC 3323 says, if a privacy service modifies the Record-Route headers, it MUST be able to restore Route headers with retained values 🔑 check out Section 5.1.9 (Record-Route) for more detail and examples 📖
5.3.5. Service-Route 🧭
Service-Route headers [RFC3608] only appear in 200 OK responses to REGISTER requests, and they contain info about the registrar 🗂️ the whole point of the privacy mechanism in RFC 3323 is to protect the user's privacy, so the case where a registrar sets a Privacy header isn't considered here 🙅♀️ so the Service-Route header isn't the target of any priv-values 🌸
5.3.6. Target-Dialog 🎯
the Target-Dialog [RFC4538] header runs into exactly the same issues as the Replaces header 🥹 check out Section 5.3.3 (Replaces Header/Parameter) for why it isn't a target for any particular priv-values, and how a privacy service still needs to evaluate and modify the value it contains, even when no privacy is requested 🫧
6. Security Considerations 🔒
okay bestie, the big plot twist here is that this guideline doc adds zero new security considerations 💅 Everything security-related is already covered in [RFC3323], [RFC3325], and [RFC4244], so go read those if you want the full tea 🍵
7. Acknowledgements 🫶
The authors want to thank John Elwell, Jon Peterson, Jonathan Rosenberg, Mary Barnes, Paul Kyzivat, and Roland Jesske for their reviews and comments. Iconic behavior, honestly 👑✨
8. References 📚
8.1. Normative References
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🎀[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. 🦋[RFC3323]Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. 🔐[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. 🌸[RFC4244]Barnes, M., Ed., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. 💜
8.2. Informative References
[TURN]Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work in Progress, July 2008. 🧚[SIPGRUU]Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009. 🌈[RFC3315]Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 🍓[RFC3327]Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. 🫧[RFC3608]Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003. ⭐[RFC3891]Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 💅[RFC3892]Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004. 🎀[RFC4474]Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. 🔥[RFC4538]Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006. 🦋[RFC4566]Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 🌸
Authors' Addresses 💌
these are the people behind it, and they're all at NTT Corporation:
Mayumi Munakata
NTT Corporation
Phone: +81 422 36 7502
EMail: munakata.mayumi@lab.ntt.co.jp
Shida Schubert
NTT Corporation
EMail: shida@ntt-at.com
Takumi Ohba
NTT Corporation
9-11, Midori-cho 3-Chome
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 7748
EMail: ohba.takumi@lab.ntt.co.jp📦 where this page comes from
- ietf: rfc5379 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms