RFC 5767
User-Agent-Driven Privacy Mechanism for SIP
RFC 5767 💖 User-Agent-Driven Privacy Mechanism for SIP
okay bestie, this one is from the IETF (Internet Engineering Task Force) 🌸 It's RFC 5767, titled User-Agent-Driven Privacy Mechanism for SIP, published in April 2010. The authors are M. Munakata, S. Schubert, and T. Ohba, all from NTT ✨ It's categorised as Informational (so it's not a standards-track spec), and its ISSN is 2070-1721. The header doesn't list any RFCs it obsoletes or updates, so it just stands on its own 🎀
Abstract
okay so the whole point here is giving a User Agent (UA) a way to make an anonymous Session Initiation Protocol (SIP) message 🦋 It does this with Globally Routable User Agent URIs (GRUUs) and Traversal Using Relays around NAT (TURN), and the big glow-up is that you don't need the privacy service from RFC 3323 to do it 💅
Status of This Memo
this doc is not an Internet Standards Track spec, it's published just for info 🧚 It's a product of the IETF, it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🔥
for the current status, errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5767 ✨
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're in effect on the publication date. Read those carefully, because they describe your rights and restrictions for this doc. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Simplified BSD License 🫶
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Concept of Privacy ..............................................3
4. Treatment of Privacy-Sensitive Information ......................3
4.1. Obtaining a Functional Anonymous URI Using the GRUU
Mechanism ..................................................4
4.2. Obtaining a Functional Anonymous IP Address Using
the TURN Mechanism .........................................5
5. UA Behavior .....................................................6
5.1. Critical Privacy-Sensitive Information .....................6
5.1.1. Contact Header Field ................................6
5.1.2. From Header Field in Requests .......................7
5.1.3. Via Header Field in Requests ........................8
5.1.4. IP Addresses in SDP .................................8
5.2. Non-Critical Privacy-Sensitive Information .................8
5.2.1. Host Names in Other SIP Header Fields ...............8
5.2.2. Optional SIP Header Fields ..........................9
6. Security Considerations .........................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................101. Introduction ✨
okay so [RFC3323] defined a privacy mechanism for SIP [RFC3261], using the techniques that were around when it came out 🌸 It relies on a separate privacy service that strips privacy-sensitive info out of SIP messages from a UA before they get forwarded to the final destination. A lot of SIP extensions have shown up since then, and some of them let a UA hide its user's identity without needing a privacy service. That just wasn't possible when RFC 3323 was written, so it's giving growth 📈
this doc is not trying to obsolete RFC 3323. The goal is to level up the overall SIP privacy mechanism by letting a UA take control of its own privacy, instead of being totally dependent on some external privacy service 💜
the UA-driven privacy mechanism here won't get rid of the need for the RFC 3323 usage in [RFC3325]. That one tells a privacy service not to forward a P-Asserted-Identity header field outside the Trust Domain. To stop that forwarding, a UA needs to include the Privacy header field with the value 'id' (Privacy:id) in the request, even when the UA is using this spec 🙈
this doc sets up a guideline where a UA handles all its privacy functions on its own, using SIP extensions like Globally Routable User Agent URIs (GRUUs) [RFC5627] and Traversal Using Relays around NAT (TURN) [RFC5766] 🦋
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].
privacy-sensitive information: the info that identifies a user who sends the SIP message, plus any other info that can be used to guess the user's identity 🔥
3. Concept of Privacy 🌈
the concept of privacy here is all about concealing privacy-sensitive information 💅 Protecting network privacy, like topology hiding, is outside the scope of this doc.
privacy-sensitive info includes the display-name and the Uniform Resource Identifier (URI) in a From header field, since those can reveal the user's name and affiliation (like a company name). It also includes IP addresses or host names in a Contact header field, a Via header field, a Call-ID header field, or a Session Description Protocol (SDP) [RFC4566] body, anywhere they might reveal where a UA is located 👑
4. Treatment of Privacy-Sensitive Information 🧚
some fields of a SIP message might contain privacy-sensitive info but aren't essential for the message's purpose, so they can be left out with no side effects. Other fields are essential for the message's purpose, so they need anonymized values to avoid disclosing privacy-sensitive info. Out of the privacy-sensitive info listed in Section 3, the URIs, host names, and IP addresses in Contact, Via, and SDP are required to be functional (aka suitable for purpose) even when they've been anonymized 💖
with GRUU [RFC5627] and TURN [RFC5766], a UA can get URIs and IP addresses for media and signaling that are functional and anonymous, so they don't identify the UA or the user ✨
how to get a functional anonymous URI and IP address is covered in Section 4.1 and 4.2, respectively 🦋
host names need to be hidden because the user's identity can be guessed from them, but they aren't always treated as critical privacy-sensitive info 🌸
also, a UA needs to be careful not to put anything that identifies the user into optional SIP header fields like Subject and User-Agent 🙈
4.1. Obtaining a Functional Anonymous URI Using the GRUU Mechanism 🎀
a UA that wants a functional anonymous URI MUST support and utilize the GRUU mechanism, unless it can get a functional anonymous URI some other way that's outside the scope of this doc. By sending a REGISTER request that asks for GRUU, the UA can get an anonymous URI, and that URI can be used later in the Contact header field 💜
the full process for how a UA gets a GRUU is described in [RFC5627] 🔥
to use the GRUU mechanism for a functional anonymous URI, the UA MUST request GRUU in the REGISTER request. If a temp-gruu SIP URI parameter and value show up in the REGISTER response, the user agent MUST use the value of the temp-gruu as an anonymous URI representing the UA. That means the UA MUST use this URI as its local target, and the UA MUST place this URI in the Contact header field of subsequent requests and responses that need the local target to be sent 👑
if there's no temp-gruu SIP URI parameter in the 200 (OK) response to the REGISTER request, a UA SHOULD NOT proceed with its anonymization process, unless something equivalent to temp-gruu is provided through some administrative means 🙈
it is RECOMMENDED that the UA consult the user before sending a request without a functional anonymous URI when the user has asked for privacy 🫶
because of how GRUU works, the domain name is always revealed when GRUU is used 💀 If revealing the domain name in the Contact header field is a concern, a third-party GRUU server is a possible fix, but that's outside the scope of this doc. Check the Security Considerations section for details 🌈
4.2. Obtaining a Functional Anonymous IP Address Using the TURN Mechanism 🦋
a UA that hasn't been given a functional anonymous IP address through some administrative means MUST obtain a relayed address (aka the IP address of a relay) if it wants anonymity for use in SDP and in the Via header field. That IP address gets derived from a Session Traversal Utilities of NAT (STUN) relay server through the TURN mechanism, which lets a STUN server act as a relay 🧚
anonymous IP addresses are needed for two things 💅 The first is the Via header field of a SIP request. The UA gets an IP address from a STUN relay server, puts that address in the Via header field, and sends the SIP request to the STUN relay server. That way the UA's IP address won't be revealed beyond the relay server 🌸
the second is SDP, as the address for receiving media. The UA gets an IP address from a STUN relay server and puts it in SDP, so media gets received via the relay server. Media can also be sent via the relay server 🎀 That way, neither the SDP nor the media packets reveal the UA's IP address ✨
it's assumed that a UA gets configured, either manually or automatically, through things like the configuration framework [SIPPING-CONFIG], with the address of one or more STUN (Session Traversal Utilities for NAT) [RFC5766] relay servers so it can get an anonymous IP address 🫶
5. UA Behavior 💖
this section explains how a UA generates an anonymous SIP message 🔥
a UA that's fully compliant with this document MUST obscure or conceal all the critical UA-inserted privacy-sensitive info in SIP requests and responses, as shown in Section 5.1, whenever user privacy is requested. On top of that, the UA SHOULD conceal the non-critical privacy-sensitive info as shown in Section 5.2 🌈
also, when a UA uses a relay server to hide its identity, the UA MUST send requests to the relay server, so the request and response follow the same signaling path 👑
5.1. Critical Privacy-Sensitive Information 🧚
5.1.1. Contact Header Field 📇
okay so when the Contact header field shows up in a dialog-forming request or response, or in a mid-dialog one, it holds the local target 🎯. That's the URI used to reach the UA for mid-dialog requests, and maybe for out-of-dialog ones too, like a REFER request [RFC3515]. It can also have a display-name. Since Contact is how further requests get routed to the UA, the UA MUST include a functional URI even when it's anonymized 🫶 no skipping that, bestie.
When this header is in a dialog-forming or mid-dialog request or response, the UA MUST anonymize the Contact header field with an anonymous URI ("temp-gruu") from the GRUU mechanism, unless an equivalent functional anonymous URI is provided some other way ✨. For other requests and responses, except 3xx responses, REGISTER requests, and 200 (OK) responses to a REGISTER request, the UA MUST either omit the Contact header field or use an anonymous URI 🙈.
Check out Section 4.1 for how to get an anonymous URI through GRUU 💅.
The UA MUST omit the display-name in a Contact header field or set the display-name to "Anonymous" 🎀.
5.1.2. From Header Field in Requests 🎭
Without privacy considerations, the From header field has the identity of the user, like a display-name and URI 🪪.
RFCs 3261 and 3323 recommend setting "sip:anonymous@anonymous.invalid" as a SIP URI in a From header field when user privacy is requested. This is where things get messy 😭, because the SIP-Identity mechanism [RFC4474] needs an actual domain name in the From header field when it's applied to the message.
A UA generating an anonymous SIP message that supports this specification MUST anonymize the From header field in one of the two ways below 💖.
Option 1:
A UA anonymizes a From header field using an anonymous display-name and an anonymous URI, following the procedure in Section 4.1.1.3 of RFC 3323.
Here's what a Option 1 From header looks like:
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774Option 2:
A UA anonymizes a From header field using an anonymous display-name and an anonymous URI that has the user's valid domain name instead of "anonymous.invalid".
Here's what an Option 2 From header looks like:
From: "Anonymous" <sip:anonymous@example.com>;tag=1928301774A UA SHOULD go with option 1 to hide its domain name in the From header field 🕵️♀️. But heads up: SIP-Identity can't be used with a From header field under option 1, because SIP-Identity does its authentication based on the domain name 💀.
If a UA expects the SIP-Identity mechanism to be applied to the request, it is RECOMMENDED to go with option 2. Just know that the user's domain name will be revealed from the From header field under option 2 🥲.
If the user wants both anonymity and strong identity, the move is a third-party anonymization service that issues an Address of Record (AoR) for use in the From header field of a request, and that also provides a SIP-Identity Authentication Service 🧚. Third-party anonymization services are out of scope for this document.
5.1.3. Via Header Field in Requests 🛣️
Without privacy considerations, the bottommost Via header field a UA adds to a request has the IP address and port or hostname that are used to reach the UA for responses 📍.
A UA generating an anonymous SIP request that supports this specification MUST anonymize the IP address in the Via header field using an anonymous IP address obtained through the TURN mechanism, unless an equivalent functional anonymous IP address is provided some other way 🔒.
The UA SHOULD NOT include a host name in a Via header field 🙅♀️.
5.1.4. IP Addresses in SDP 🎶
A UA generating an anonymous SIP message that supports this specification MUST anonymize IP addresses in SDP, if any are present, using an anonymous IP address obtained through the TURN mechanism, unless an equivalent functional anonymous IP address is provided some other way 🫣.
Check out Section 4.2 for how to get an IP address through TURN 🌸.
5.2. Non-Critical Privacy-Sensitive Information 🌷
5.2.1. Host Names in Other SIP Header Fields 🏷️
A UA generating an anonymous SIP message that supports this specification SHOULD conceal host names in any SIP header fields, such as Call-ID and Warning header fields, if they're considered privacy-sensitive 🧐.
5.2.2. Optional SIP Header Fields 🎈
Other optional SIP header fields (such as Call-Info, In-Reply-To, Organization, Referred-By, Reply-To, Server, Subject, User-Agent, and Warning) can contain privacy-sensitive information 👀.
A UA generating an anonymous SIP message that supports this specification SHOULD NOT include any information that identifies the user in such optional header fields 🫶.
6. Security Considerations 🔐
This specification uses GRUU and TURN, and it inherits any security considerations described in those documents. Read them, no cap 🧠.
Furthermore, if the provider of the caller who wants to obscure their identity is a small number of people (for example a small enterprise, Small Office, Home Office (SOHO)), the domain name alone can reveal who the caller is 😱.
The same can be true when the provider is large, but the receiver of the call only knows a few people from the source of the call 🫠.
There are mainly two places in the message where the domain name is expected to be functional: the From header field and the Contact header field 🎯.
The domain name in the From header field can be obscured as described in Section 5.1.2. The Contact header field, though, needs to contain a valid domain name at all times in order to function properly 🥹.
Note: Generally, a device won't show the contact address to the receiver. But that does not mean you can't find the domain name in a message! In fact, as long as this specification is used to obscure identity, the message will always contain a valid domain name, because it inherits key characteristics of GRUU 🔍.
Note: For UAs that use a temporary GRUU, confidentiality does not extend to parties that are permitted to register to the same AoR, or that are permitted to obtain temporary GRUUs when subscribed to the'reg'event package [RFC3680] for the AoR. To limit this, it is suggested that the authorization policy for the'reg'event package permit only those subscribers authorized to register to the AoR to receive temporary GRUUs. With this policy, the confidentiality of the temporary GRUU will be the same whether or not the'reg'event package is used 💜.
If someone really wants to assure anonymization, it is suggested that they seek out and rely on a third-party anonymization service, which is outside the scope of this document 🦋.
A third-party anonymization service provides registrar and TURN service that have no affiliation with the caller's provider. That lets the caller completely withhold its identity, which is a whole main character move 👑.
7. References 📚
7.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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally
Routable User Agent URIs (GRUUs) in the Session
Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg,
"Traversal Using Relays around NAT (TURN): Relay
Extensions to Session Traversal Utilities for NAT
(STUN)", RFC 5766, April 2010.7.2. Informative References
[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.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP)
Refer Method", RFC 3515, April 2003.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP)
Event Package for Registrations", RFC 3680,
March 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[SIPPING-CONFIG] Channabasappa, S., "A Framework for Session
Initiation Protocol User Agent Profile Delivery",
Work in Progress, September 2009.Authors' Addresses 💌
Mayumi Munakata
NTT Corporation
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
URI: http://www.ntt.co.jp📦 where this page comes from
- ietf: rfc5767 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms