RFC 3325

Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks

📅 published December 2002, from ietf

RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks 🎀

okay so this is the RFC bestie needs to know about 💅 It came out in November 2002 from the Network Working Group, and it's marked Informational, which means it shares info for the Internet community but isn't an Internet standard. The authors are C. Jennings (Cisco Systems), J. Peterson (NeuStar, Inc.), and M. Watson (Nortel Networks). It doesn't obsolete or update any other RFC, so it's just vibing on its own 🦋

Status of This Memo 📋

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract ✨

okay so this doc describes private extensions to SIP that let a network of trusted SIP servers assert the identity of authenticated users, and also how existing privacy mechanisms can be applied to the identity problem 🔐 These extensions are only meant to be used inside an administrative domain that has previously agreed-upon policies for generating, transporting, and using that information. This document does not offer a general privacy or identity model that works between different trust domains, or across the Internet at large 🙈

Table of Contents 🗂️

1.   Applicability Statement  . . . . . . . . . . . . . . . . . .   2
2.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   3
3.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
4.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   5
5.   Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . .   5
6.   Hints for Multiple Identities  . . . . . . . . . . . . . . .   6
7.   Requesting Privacy . . . . . . . . . . . . . . . . . . . . .   6
8.   User Agent Server Behavior . . . . . . . . . . . . . . . . .   7
9.   Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1  The P-Asserted-Identity Header  . . . . . . . . . . . .   8
     9.2  The P-Preferred-Identity Header . . . . . . . . . . . .   8
     9.3  The "id" Privacy Type . . . . . . . . . . . . . . . . .   9
10.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1 Network Asserted Identity passed to trusted gateway . .   9
     10.2 Network Asserted Identity Withheld  . . . . . . . . . .  11
11.  Example of Spec(T) . . . . . . . . . . . . . . . . . . . . .  13
12.  Security Considerations  . . . . . . . . . . . . . . . . . .  14
13.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  14
     13.1 Registration of new SIP header fields . . . . . . . . .  14
     13.2 Registration of "id" privacy type for SIP Privacy header 15
14.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  15
     Normative References . . . . . . . . . . . . . . . . . . . .  15
     Informational References . . . . . . . . . . . . . . . . . .  16
     Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17
     Full Copyright Statement . . . . . . . . . . . . . . . . . .  18

1. Applicability Statement 🌸

okay so this document describes private extensions to SIP [1] that let a network of trusted SIP servers assert the identity of end users or end systems, and also show indications of end-user requested privacy 🫶 These extensions only work inside a 'Trust Domain' as defined in "Short term requirements for Network Asserted Identity" [5]. Nodes in that Trust Domain are explicitly trusted by their users and end-systems to publicly assert each party's identity, and to be responsible for hiding that identity outside the Trust Domain when privacy is requested. How the network figures out which identity to assert is outside the scope of this document (though it usually involves some form of authentication) 🔑

A key requirement of [5] is that the behavior of all nodes within a given Trust Domain 'T' is known to comply with a set of specs called 'Spec(T)'. Spec(T) MUST specify behavior for the following:

  1. The manner in which users are authenticated
  2. The mechanisms used to secure the communication among nodes within the Trust Domain
  3. The mechanisms used to secure the communication between UAs and nodes within the Trust Domain
  4. The manner used to determine which hosts are part of the Trust Domain
  5. The default privacy handling when no Privacy header field is present
  6. That nodes in the Trust Domain are compliant to SIP [1]
  7. That nodes in the Trust Domain are compliant to this document
  8. Privacy handling for identity as described in Section 7.

An example of a suitable Spec(T) is shown in Section 11 ✨

This document does not offer a general privacy or identity model suitable for inter-domain use or use in the Internet at large. Its assumptions about the trust relationship between the user and the network may not apply in many applications 🙃 For example, these extensions don't support a model where end users can assert their own identity using the extensions defined here. Also, since the asserted identities aren't cryptographically certified, they can be forged, replayed, and falsified in any architecture that doesn't meet the requirements of [5] 😬

The asserted identities also don't say who specifically is asserting them, so it has to be assumed that the Trust Domain is asserting the identity. That means the information is only meaningful when it's securely received from a node known to be a member of the Trust Domain 🧐

Even with those limitations, there are useful specialized deployments that meet the assumptions above and can live with the resulting restrictions, which is why this mechanism is being published as informational. An example deployment would be a closed network that emulates a traditional circuit switched telephone network 📞

2. Conventions 📝

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 BCP 14, RFC 2119 [3].

Throughout this document, requirements for or references to proxy servers or proxy behavior apply similarly to other intermediaries within a Trust Domain (ex: B2BUAs) 🤝

The terms Identity, Network Asserted Identity and Trust Domain in this document have the meanings defined in [5] 💜

3. Introduction 🧚

okay so various providers offering telephony over IP networks have picked SIP as their call establishment protocol 📱 Their environments need trusted network elements run by the service providers (like SIP proxy servers) to pass along the identity of the subscribers to that service, but they also need to hide this info from entities that aren't trusted when necessary. These networks usually assume some level of transitive trust among providers and the devices they operate 🤍

These networks also need to support certain traditional telephony services and meet basic regulatory and public safety requirements. Those include Calling Identity Delivery, Calling Identity Delivery Blocking, and the ability to trace the originator of a call 🕵️‍♀️ Baseline SIP can support each of these services on its own, but certain combos can't be supported without the extensions in this document. For example, a caller who wants privacy and therefore gives limited info in the SIP From header field won't be identifiable by the call recipients, unless they rely on some other way to find out who the caller is 😭 Masking identity info at the originating user agent also stops services like call trace from working in the Public Switched Telephone Network (PSTN), or from being performed at intermediaries that aren't privy to the authenticated identity of the user 🚫

This document tries to provide a network asserted identity service using a very limited, simple mechanism, based on the requirements in [5] 🎯 It's derived from an earlier attempt, [6], to solve several privacy and identity problems in Trust Domains. A more comprehensive mechanism, [7], which uses cryptography to address this problem, is being studied by the SIP working group 🔬

Providing privacy in a SIP network is way more complicated than in the PSTN 💀 In SIP networks, the session participants can usually exchange IP traffic directly without involving any SIP service provider, and the IP addresses used for those sessions may reveal private info themselves.

A general purpose privacy mechanism for SIP environments is discussed in [2]. This document applies that privacy mechanism to the problem of network asserted identity 🌈

4. Overview 🦋

The mechanism proposed in this document relies on a new header field called 'P-Asserted-Identity' that contains a URI (commonly a SIP URI) and an optional display-name, for example:

P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>

A proxy server that handles a message can, after authenticating the originating user in some way (for example, Digest authentication), insert such a P-Asserted-Identity header field into the message and forward it to other trusted proxies. A proxy that is about to forward a message to a proxy server or UA it does not trust MUST remove all the P-Asserted-Identity header field values if the user requested that this information be kept private. Users can request this type of privacy as described in Section 7 🙌

The formal syntax for the P-Asserted-Identity header is presented in Section 9 📜

5. Proxy Behavior ✨

okay so a proxy inside a Trust Domain can get a message from someone it trusts, or from someone it doesn't 🫣 if it gets a message from an untrusted node and wants to add a P-Asserted-Identity header field, it MUST authenticate the originator of the message 🔐 then it uses whatever identity came out of that authentication to insert a P-Asserted-Identity header field into the message. no shortcuts, bestie 💅

if the proxy gets a message (request or response) from a node it trusts, it can use whatever is in the P-Asserted-Identity header field, if there is one, like it authenticated the user itself 🫶

if there's no P-Asserted-Identity header field, a proxy MAY add one, with at most one SIP or SIPS URI and at most one tel URL 🎀 now here's the messy part. if the proxy got the message from an element it does NOT trust and there's already a P-Asserted-Identity header with a SIP or SIPS URI in it, the proxy MUST replace that SIP or SIPS URI with a single SIP or SIPS URI, or remove the header field 💀 same deal for tel: if the message came from an untrusted element and the header has a tel URI, the proxy MUST replace that tel URI with a single tel URI, or remove the header field. ngl the cleanup crew is working overtime here 🧹✨

when a proxy forwards a message to another node, it must first figure out whether it trusts that node or not 🧐 if it trusts the node, the proxy does not remove any P-Asserted-Identity header fields that it generated itself, or that it got from a trusted source 🌸 but if it does NOT trust the element, then the proxy MUST look at the Privacy header field (if there is one) to see whether the user asked for their asserted identity info to be kept private 🙈

6. Hints for Multiple Identities 🧚

so picture this: a proxy gets a message with a P-Preferred-Identity header field from an entity it doesn't trust 👀 the proxy MAY use that as a hint about which of several valid identities for the authenticated user should get asserted. it's a suggestion, not a command 💜 if the hint doesn't match any valid identity the proxy knows for that user, the proxy can add its own P-Asserted-Identity header, or it can reject the request (for example, with a 403 Forbidden) 🚫 and no matter what, the proxy MUST remove the user-provided P-Preferred-Identity header from any message it forwards. bye bye, hint 👋

a user agent only sends a P-Preferred-Identity header field to proxy servers in a Trust Domain 🛡️ user agents MUST NOT populate the P-Preferred-Identity header field in a message that is not sent directly to a proxy the user agent trusts. like, do not put that header on a message going to a random node 🙅‍♀️ if a user agent did send a message with a P-Preferred-Identity header field to a node outside a Trust Domain, the hinted identity might not get managed properly by the network, and that could seriously hurt privacy 😭

7. Requesting Privacy 🙈

okay, privacy time 🔒 parties who want the P-Asserted-Identity header fields removed before they go to an untrusted element can add the "id" privacy token defined in this document to the Privacy header field. the Privacy header field itself is defined in [6] ✨ if that token is there, proxies MUST remove all the P-Asserted-Identity header fields before forwarding messages to untrusted elements. and if the Privacy header field value is set to "none", the proxy MUST NOT remove the P-Asserted-Identity header fields 🫧

when a proxy forwards the request to an untrusted element and there's no Privacy header field at all, the proxy MAY include the P-Asserted-Identity header field, or it MAY remove it 🤷‍♀️ this is a policy thing for the Trust Domain, and it MUST be specified in Spec(T). it is RECOMMENDED that the P-Asserted-Identity header fields SHOULD NOT be removed unless local privacy policies prevent it, because removing them may cause services based on Asserted Identity to fail 🥺 so basically don't yeet them unless you really have to.

BUT (and this is a big but 🫣) unless all the users of the Trust Domain have access to proper privacy services, forwarding the P-Asserted-Identity may disclose information the user never asked to share and can't stop 😱 which is why it is STRONGLY RECOMMENDED that all users have access to privacy services as described in this document. this is non-negotiable, babe 💖

the formal spec for the "id" Privacy header priv-value lives in Section 9.3 🎀 and some general guidelines for when users need privacy are in [2] 🌈

and if a message has multiple P-Asserted-Identity header field values and privacy of that header field is requested, then ALL instances of the header field values MUST be removed before forwarding the request to an entity that is not trusted. every single one, no leftovers 🧹💅

8. User Agent Server Behavior 📱

typically, a user agent shows the value of a P-Asserted-Identity header field it receives to its user 👀 it may treat the identity from a Trust Domain as privileged, or as more trustworthy than the From header field of a request. however, any specific behavior is up to the implementations or services 🤓 this document also doesn't mandate any user agent handling for multiple P-Asserted-Identity header field values that happen to show up in a message (like a SIP URI next to a tel URL) 🙃

BUT if a User Agent Server gets a message from a previous element it does not trust, it MUST NOT use the P-Asserted-Identity header field in any way. no peeking, no using, nothing 🚫✋

if a UA is part of the Trust Domain it got a message from that has a P-Asserted-Identity header field, then it can use the value freely. but it MUST make sure it does NOT forward the info to any element outside the Trust Domain if the user asked for that asserted identity info to be kept private 🔒 and if a UA is NOT part of the Trust Domain it got the message from, it can assume this info doesn't need to be kept private 🌸

9. Formal Syntax 📐

the following syntax spec uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [4] 🧠

9.1 The P-Asserted-Identity Header 🪪

the P-Asserted-Identity header field is used between trusted SIP entities (usually intermediaries) to carry the identity of the user sending a SIP message, as it was verified by authentication ✨

PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value
                *(COMMA PAssertedID-value)
PAssertedID-value = name-addr / addr-spec

a P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. there can be one or two P-Asserted-Identity values. if there's one value, it MUST be a sip, sips, or tel URI. if there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI. it's worth noting that proxies can (and will) add and remove this header field 🫶

this document adds the following entry to Table 2 of [1] 📋

Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
------------         -----   -----   ---  ---  ---  ---  ---  ---
P-Asserted-Identity           adr     -    o    -    o    o    -


                                     SUB  NOT  REF  INF  UPD  PRA
                                     ---  ---  ---  ---  ---  ---
                                      o    o    o    -    -    -

9.2 The P-Preferred-Identity Header 💜

the P-Preferred-Identity header field is used from a user agent to a trusted proxy to carry the identity the user sending the SIP message wants used for the P-Asserted-Header field value that the trusted element will insert 🎀

PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value
                  *(COMMA PPreferredID-value)
PPreferredID-value = name-addr / addr-spec

a P-Preferred-Identity header field value MUST consist of exactly one name-addr or addr-spec. there can be one or two P-Preferred-Identity values. if there's one value, it MUST be a sip, sips, or tel URI. if there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI. it's worth noting that proxies can (and will) remove this header field 🧚

this document adds the following entry to Table 2 of [1] 📋

Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
------------         -----   -----   ---  ---  ---  ---  ---  ---
P-Preferred-Identity          adr     -    o    -    o    o    -


                                     SUB  NOT  REF  INF  UPD  PRA
                                     ---  ---  ---  ---  ---  ---
                                      o    o    o    -    -    -

9.3 The "id" Privacy Type 🔐

this spec adds a new privacy type ("priv-value") to the Privacy header, defined in [2] 🌈 the presence of this privacy type in a Privacy header field means the user would like the Network Asserted Identity kept private from SIP entities outside the Trust Domain they authenticated with 🫧 and if a user requests multiple types of privacy, they MUST include ALL of the requested privacy types in their Privacy header field value. no skipping, queen 👑

priv-value = "id"

Example:

Privacy: id

10. Examples 🍓

10.1. Network Asserted Identity passed to trusted gateway ✨

Okay bestie, so in this one proxy.cisco.com builds a P-Asserted-Identity header from an identity it figured out through SIP Digest authentication 🔐. It passes that along to a trusted proxy, which hands it on to a trusted gateway 🚪. Heads up: these are only partial SIP messages that show the headers relevant to the authenticated identity drama, so don't panic when stuff is missing 🙈.

* F1   useragent.cisco.com -> proxy.cisco.com

INVITE sip:+14085551212@cisco.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
Privacy: id
* F2   proxy.cisco.com -> useragent.cisco.com

SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
To: <sip:+14085551212@cisco.com>;tag=123456
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Proxy-Authenticate: .... realm="sip.cisco.com"
* F3   useragent.cisco.com -> proxy.cisco.com

INVITE sip:+14085551212@cisco.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Privacy: id
Proxy-Authorization: .... realm="sip.cisco.com" user="fluffy"
* F4   proxy.cisco.com -> proxy.pstn.net (trusted)

INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
P-Asserted-Identity: tel:+14085264000
Privacy: id
* F5   proxy.pstn.net -> gw.pstn.net (trusted)

INVITE sip:+14085551212@gw.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
Via: SIP/2.0/TCP proxy.pstn.net;branch=z9hG4bK-a1b2
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
P-Asserted-Identity: tel:+14085264000
Privacy: id

10.2. Network Asserted Identity Withheld 🙈

In this one, the User Agent sends an INVITE saying it'd prefer the identity sip:fluffy@cisco.com to the first proxy. That proxy authenticates the request with SIP Digest, creates a P-Asserted-Identity header field, and forwards it to a trusted proxy called outbound.cisco.com. The next proxy removes the P-Asserted-Identity header field and the request for Privacy before sending the request onward to the biloxi.com proxy server, which it does not trust. 🕵️‍♀️

* F1    useragent.cisco.com -> proxy.cisco.com

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
Privacy: id
P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
* F2    proxy.cisco.com -> useragent.cisco.com
SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111
To: <sip:bob@biloxi.com>;tag=123456
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Proxy-Authenticate: .... realm="cisco.com"
* F3    useragent.cisco.com -> proxy.cisco.com

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Privacy: id
P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
Proxy-Authorization: .... realm="cisco.com" user="fluffy"
* F4    proxy.cisco.com -> outbound.cisco.com (trusted)

INVITE sip:bob@biloxi SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@vovida.org>
Privacy: id
* F5   outbound.cisco.com -> proxy.biloxi.com (not trusted)

INVITE sip:bob@biloxi SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
Privacy: id
* F6   proxy.biloxi.com -> bobster.biloxi.com

INVITE sip:bob@bobster.biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
Via: SIP/2.0/TCP proxy.biloxi.com;branch=z9hG4bK-d456
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 67
Privacy: id

11. Example of Spec(T) 💅

Okay so the whole trust thing only works if one node knows, through configuration, that every node in a Trust Domain will behave in a predetermined way 🤝. That predetermined behavior has to be clearly defined, and every node in the Trust Domain has to be compliant. The set of specifications that all nodes in a Trust Domain T must comply with is called 'Spec(T)' 📜.

The rest of this section shows an example Spec(T). It is not normative in any way 🙃.

  1. Protocol requirements

The following specifications MUST be supported:

  1. RFC 3261
  2. RFC 3325
  1. Authentication requirements

Users MUST be authenticated using SIP Digest Authentication 🔑.

  1. Security requirements

Connections between nodes within the Trust Domain, and between UAs and nodes in the Trust Domain, MUST use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual authentication between nodes in the trust domain MUST be performed, and confidentiality MUST be negotiated 🔒.

  1. Scope of Trust Domain

The Trust Domain specified in this agreement consists of hosts that possess a valid certificate which is a) signed by examplerootca.org; b) whose subjectAltName ends with one of the following domain names: trusted.div1.carrier-a.net, trusted.div2.carrier-a.net, sip.carrier-b.com; and c) whose domain name corresponds to the hostname in the subjectAltName in the certificate 🎀.

  1. Implicit handling when no Privacy header is present

The elements in the trust domain must support the 'id' privacy service, so the absence of a Privacy header can be assumed to indicate that the user is not requesting any privacy. If no Privacy header field is present in a request, elements in this Trust Domain MUST act as if no privacy is requested 🧚.

12. Security Considerations 🚨

The mechanism in this document is only a partial answer to the problem of identity and privacy in SIP 🫣. For example, these mechanisms give end users no way to securely share identity information end-to-end without a trusted service provider. Identity information that the user designates as 'private' can be inspected by any intermediaries participating in the Trust Domain. This information is secured by transitive trust, which is only as reliable as the weakest link in the chain of trust 💀.

When a trusted entity sends a message to any destination with that party's identity in a P-Asserted-Identity header field, the entity MUST take precautions to protect the identity information from eavesdropping and interception, to protect the confidentiality and integrity of that identity information. Transport or network layer hop-by-hop security mechanisms, such as TLS or IPSec with appropriate cipher suites, can satisfy this requirement 🔐.

13. IANA Considerations 📝

13.1. Registration of new SIP header fields 🎀

This document defines two new private SIP header fields, "P-Asserted-Identity" and "P-Preferred-Identity". As recommended by the policy of the Transport Area, these headers have been registered by the IANA in the SIP header registry, using the RFC number of this document as its reference 📚.

Name of Header:          P-Asserted-Identity

Short form:              none

Registrant:              Cullen Jennings
                         fluffy@cisco.com

Normative description:
Section 9.1 of this document
Name of Header:          P-Preferred-Identity

Short form:              none

Registrant:              Cullen Jennings
                         fluffy@cisco.com

Normative description:
Section 9.2 of this document

13.2. Registration of "id" privacy type for SIP Privacy header 🦋

Name of privacy type:    id

Short Description:       Privacy requested for Third-Party Asserted
                         Identity

Registrant:              Cullen Jennings
                         fluffy@cisco.com

Normative description:
Section 9.3 of this document

14. Acknowledgements 🫶

Thanks to Bill Marshall and Flemming Andreason [6], Mark Watson [5], and Jon Peterson [7] for authoring the drafts that make up the bulk of this document 💜. Thanks also to many people for useful comments, including Jonathan Rosenberg, Rohan Mahy and Paul Kyzivat 🌸.

Normative References 📚

  • [1] 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.
  • [2] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
  • [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

Informational References 🔍

  • [5] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
  • [6] Andreasen, F., "SIP Extensions for Network-Asserted Caller Identity and Privacy within Trusted Networks", Work in Progress.
  • [7] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress.

okay bestie, the legal bit 🫶 The big copyright line is Copyright (C) The Internet Society (2002). All Rights Reserved. 💅 Anyone can copy and share this document, translations included. You can also write derivative works that comment on or explain it or help people implement it, and publish and distribute those however you like, in whole or in part, with zero restrictions 🦋 The catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work 🔒

The original document itself can't be modified in any way. That covers removing the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: if you're developing Internet standards, you follow the copyright procedures in the Internet Standards process, and if you're translating it into a language other than English 🌍

The permissions above are perpetual. The Internet Society and its successors or assigns won't revoke them 💜

The document and everything in it is provided "AS IS" 🫠 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that using the information won't infringe any rights, and any implied warranty of merchantability or fitness for a particular purpose. Not giving a warranty is a whole vibe, but it's the rule 💀

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society 🎀 The people who keep these documents organized and published get paid through that funding, so shoutout to them 👑

📦 where this page comes from