RFC 5079

Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)

📅 published December 2007, from ietf

Part 1 of 2 🎀

RFC 5079: Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)

Okay bestie, the header info first 🧾: this is a Network Working Group doc, Request for Comments: 5079, written by J. Rosenberg at Cisco. It's filed as Standards Track and dated December 2007 📅. The title block doesn't list anything it obsoletes or updates, so there's nothing extra to chase there 🦋.

Status of This Memo ✨

This is an Internet standards track protocol spec for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💅.

Abstract 🌸

SIP lets users make anonymous calls, but the people receiving those calls are allowed to reject them just because they're anonymous 🙅. The issue is that SIP has no way for the caller to find out the call was rejected because it was anonymous 😭. That info is useful because it lets the call get retried without anonymity 🔁. This spec adds a brand new SIP response code to make that possible 💜.

Table of Contents 🧾

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.  Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 3
4.  UAC Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.  433 (Anonymity Disallowed) Definition . . . . . . . . . . . . . 4
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6

1. Introduction 🎀

SIP ([RFC3261]) lets users make anonymous calls. In RFC 3261, that's done by putting a From header field whose display name is "Anonymous" 🕵️. Later on, [RFC3323] went for greater levels of anonymity and introduced the Privacy header field. With it, a requesting User Agent (UA) can ask for different levels of anonymity: user level, header level, and session level 🧚. [RFC3325] then added the P-Asserted-Identity header field, which carries an asserted identity. RFC 3325 also defined the 'id' value for the Privacy header field, which asks the network to remove the P-Asserted-Identity header field 🔒.

Here's the tea ☕: users need to make anonymous calls, but the users receiving them still have the right to reject a call because it's anonymous. SIP doesn't have a response code that lets the User Agent Server (UAS), or a proxy acting for it, clearly say "rejected because anonymous" 🙃. The closest one is 403 (Forbidden), and that doesn't give a specific reason. You can put a reason phrase in a 403 that tells the human the call was rejected for being anonymous, but a robot can't really use that phrase, and callers who speak a different language won't get it either 🌍. A machine-readable indication would allow programmatic handling, like user interface prompts, or converting to equivalent error codes in the Public Switched Telephone Network (PSTN) when the client is a gateway 🔥.

To fix all that, this spec defines the 433 (Anonymity Disallowed) response code 👑.

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] 💅.

3. Server Behavior 🛡️

A server (usually acting on behalf of the called party, though it doesn't have to be) MAY generate a 433 (Anonymity Disallowed) response when it gets an anonymous request and refuses to fulfill it because the requestor is anonymous 🙅‍♀️. A request SHOULD be considered anonymous when the originator has explicitly withheld their identity 🫣. That happens in any one of these cases:

  • The From header field contains a URI within the anonymous.invalid domain.
  • The From header field contains a display name whose value is either 'Anonymous' or 'anonymous'. Heads up, display names make a poor choice for signalling anonymity, because they're meant for humans, not automata 🤖. So language variations and even misspellings can make an automaton miss the hint. Even with all that, this check is included here because RFC 3261 explicitly calls out the display name as a way to declare anonymity 💀.
  • The request contained a Privacy header field whose value indicates that the user wishes their identity withheld. Values meeting this criteria are 'id' [RFC3325] or user.
  • The From header field contains a URI that has an explicit indication that it is anonymous. One example of a mechanism that meets this criteria is [coexistence]. This criteria is true even if the request has a validated Identity header field [RFC4474], which can be used together with anonymized From header fields ✨.

Lack of a network-asserted identity (like the P-Asserted-Identity header field) on its own SHOULD NOT be considered an indication of anonymity 🙈. Even though a Privacy header field value of 'id' removes a network-asserted identity, there's no way to tell that apart from a domain that just doesn't support network-asserted identity. So a request without one is only considered anonymous when there's some other sign of it, like a From header field with a display name of 'Anonymous' 🧐.

Also, requests where the requestor's identity can't be determined or validated, but that isn't caused by an explicit action from the requestor, are not considered anonymous 🫶. For example, say a request has a non-anonymous From header field, along with the Identity and Identity-Info header fields [RFC4474], but the certificate couldn't be fetched from the reference in the Identity-Info header field. That is not considered an anonymous request, so the 433 response code SHOULD NOT be used 🚫.

4. UAC Behavior 💫

A User Agent Client (UAC) that gets a 433 (Anonymity Disallowed) MUST NOT retry the request without anonymity unless it gets confirmation from the user that this is desirable 🙋‍♀️. That confirmation could come through the user interface, or from user-defined policy. If the user has said it's desirable, the UAC MAY retry the request without requesting anonymity ✅. Important: if the UAC automatically retried without anonymity without the user saying so, the user's expectations wouldn't be met 😱. Then a user might think they completed a call anonymously when it actually isn't anonymous 🥲.

Getting a 433 for a mid-dialog request SHOULD NOT cause the dialog to terminate, and SHOULD NOT cause the specific usage of that dialog to terminate [RFC5057] 🦋.

A UAC that doesn't understand or care about the specific semantics of the 433 response will treat it as a 400 response 🤷‍♀️.

5. 433 (Anonymity Disallowed) Definition 👑

This response means the server refused to fulfill the request because the requestor was anonymous 🕶️. Its default reason phrase is "Anonymity Disallowed" 🎀.

9.2. Informative References 📚✨

Okay bestie, these are the "good to know" references. You don't have to read them to get the main spec, but they're the receipts 💅🔥

   [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.

   [coexistence]   Rosenberg, J., "Coexistence of P-Asserted-ID and SIP
                   Identity", Work in Progress, June 2006.

   [tispan-req]    Jesske, R., "Input Requirements for the Session
                   Initiation Protocol (SIP) in support for  the
                   European Telecommunications Standards Institute",
                   Work in Progress, July 2007.

   [hautakorpi]    Hautakorpi, J. and G. Camarillo, "Extending the
                   Session Initiation Protocol Reason Header with
                   Warning Codes", Work in Progress, October 2005.

   [RFC5057]       Sparks, R., "Multiple Dialog Usages in the Session
                   Initiation Protocol", RFC in 5057, November 2007.

   [sipping-spam]  Jennings, C. and J. Rosenberg, "The Session
                   Initiation Protocol (SIP) and Spam", Work
                   in Progress, August 2007.

Author's Address 🧚

Meet the author! 🎀 Jonathan Rosenberg, over at Cisco in Edison, NJ, US.

   Jonathan Rosenberg
   Cisco
   Edison, NJ
   US

   EMail: jdrosen@cisco.com
   URI:   http://www.jdrosen.net

Copyright (C) The IETF Trust (2007). Legally speaking, this one's ours to keep track of 🫶

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

The document and the info in it are given to you "AS IS," and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. No cap, that's a big legal disclaimer 💀

Intellectual Property 💎

The IETF doesn't take a position on whether any Intellectual Property Rights (or other rights) that someone might claim over the tech in this document are valid or in scope, or on whether a license for them is available. It also doesn't say it has independently checked for any such rights. If you want the procedures for rights in RFC documents, look in BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission for implementers or users of this specification to use proprietary rights can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF invites anyone interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to ietf-ipr@ietf.org 🦋 ✨

📦 where this page comes from