RFC 9410

Handling of Identity Header Errors for Secure Telephone Identity Revisited (STIR)

📅 published July 2023, from ietf

RFC 9410: Handling of Identity Header Errors for Secure Telephone Identity Revisited (STIR) 📞✨

Okay bestie, this is RFC 9410 💖 It's a Standards Track doc, so it's the real deal and not just a suggestion 👑 It came out in July 2023 🦋 and the author is C. Wendt from Somos Inc. 🌸 The ISSN is 2070-1721 if you ever need it. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🫶

Abstract ✨

Okay so this doc extends the error-handling rules for mapping verification failure reasons to 4xx codes in STIR (Secure Telephone Identity Revisited) and in Authenticated Identity Management in SIP (Session Initiation Protocol) 📞 🎀 The big glow-up is that it lets you use the Reason header field to pass along an error tied to an Identity header field, but only when local policy says the call should keep going even though verification failed 💅 It also says how to map a failure reason to one specific Identity header field when a call has multiple Identity header fields, some with errors and some without 🦋 It spells out how those situations get handled too ✨

Status of This Memo 📋

This is an Internet Standards Track document 👑

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶 If you want more on Internet Standards, check Section 2 of RFC 7841 💖

For info on the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9410 🌈

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, bestie, because they explain what you can and can't do with this doc 🙈 Any Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License says 💜

Table of Contents 🗂️

1.  Introduction
2.  Terminology
3.  Reason Header Field Protocol "STIR"
4.  Use of Provisional Response to Signal Errors without
        Terminating the Call
5.  Handling of a Verification Error When There Are Multiple
        Identity Header Fields
6.  Handling Multiple Verification Errors
7.  Removal of the Reason Header Field by Authentication Service
8.  IANA Considerations
9.  Security Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgements
Author's Address

1. Introduction 🌸

Okay so the STIR framework from [RFC7340] is an authentication framework 🔐 It lets you vouch for a telephone number or a URI-based identity using digital signatures and a certificate-based setup, which are covered in [RFC8225] and [RFC8226] respectively 🦋 [RFC8224] explains how STIR works inside SIP [RFC3261] 💖 It defines two roles: a) the authentication service, which makes a PASSporT [RFC8225] and delivers it in an Identity header field, and b) the verification service, which checks that PASSporT and the originating identity inside it ✨

This doc is all about errors when validating PASSporTs and Identity header fields, and how those errors get communicated in special cases 🎀 It also has a fix for the mess that can happen when there are multiple Identity header fields and a bunch of possible verification errors 💅 Another thing it tackles: the current 4xx error response just terminates the call whenever a verification error shows up 😭 In some deployments, though, policy says calls should keep going even with a verification error. Like, if it's an accidental or operational slip-up and not someone faking an identity, the preferred move might be to keep the call going despite the unverified identity 🫶 Even then, the authentication service still needs to hear about the error so someone can fix it 👀 This spec talks about using the Reason header field in later provisional (1xx) responses to send the error back to the authentication service, or to other SIP path network equipment that handles errors 🧚

For calls with multiple Identity header fields where some verify and some don't (meaning they have errors), this doc defines a way to add an identifier to the header 🔥 That way the authentication service can tell exactly which Identity header field an error is about ✨

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💜

3. Reason Header Field Protocol "STIR" 🎀

This doc defines a brand-new Reason header field [RFC3326] protocol called "STIR" for STIR apps that use SIP as defined in [RFC8224] 💖 Using "STIR" as the Reason header field protocol with the error defined in [RFC8224] causes codes to allow multiple Reason header fields, as detailed in [RFC3326] and updated in [RFC9366] 🦋 Any provisional SIP response message or final response message MAY contain one or more Reason header fields with a STIR-related cause code from [RFC8224] or future specs, with one exception: a 100 (Trying) doesn't get to do this 🙈 We'll get into multiple Reason header fields later in the doc 🫶

4. Use of Provisional Response to Signal Errors without Terminating the Call 🌈

So here's the deal: if local policy says a call should keep going no matter what verification errors happen, including the 4xx errors described in Section 6.2.2 of [RFC8224], the verification service MUST NOT send the 4xx as a response 🚫 Instead, it should put the error response code and reason phrase in a Reason header field in the next provisional or final response it sends to the authentication service 💅

Example Reason header field:

Reason: STIR ;cause=436 ;text="Bad Identity Info"

8. IANA Considerations 💅

okay so IANA registered a new protocol value 🦋 in the "Reason Protocols" registry, under <http://www.iana.org/assignments/sip-parameters>. It comes with its own protocol cause too, and you can see the whole thing in Table 1 below ✨

+================+=================+===========+
| Protocol Value | Protocol Cause  | Reference |
+================+=================+===========+
| STIR           | STIR Error code | [RFC8224] |
+----------------+-----------------+-----------+

                     Table 1

they also registered a brand new header field parameter name 🎀 in the "Header Field Parameters and Parameter Values" registry, under <https://www.iana.org/assignments/sip-parameters>. Table 2 has the details, and yes it's giving very organized 🌸

+==============+================+===================+===========+
| Header Field | Parameter Name | Predefined Values | Reference |
+==============+================+===================+===========+
| Reason       | ppi            | No                | RFC 9410  |
+--------------+----------------+-------------------+-----------+

                      Table 2

9. Security Considerations 💀🫶

bestie, this section is SERIOUS 😭 so read it carefully.

okay so this spec is talking about using a PASSporT 🔐 as an identifier when there are multiple identity header field errors showing up in the Reason header field response. For some call scenarios (like diversion-based call flows 📞), the person who signed the PASSporT(s) might not be the first-hop initiator of the call. In those cases, there could be security or privacy concerns 👀 because PASSporT information gets passed upstream, past the authentication service that originally signed it, inside that error Reason header field.

so the spec says the authentication service MUST remove the Reason header field with the PASSporT in it 🚫. Why? To protect security (imagine a still-fresh PASSporT getting used for replay attacks 😱) and privacy of anything that could travel back toward the call initiator past the authentication service response. It's giving "protect your secrets" energy 🔥

also, while this spec lets you use either the full or the compact form of the PASSporT as the error identifier, using the compact form is RECOMMENDED 🌈. The reason is to avoid accidentally exposing call information that's inside the full form. Protect that call info, periodt 💜

10. References ⭐

10.1. Normative References

okay these are the ones you NEED to read 🧚

10.2. Informative References

and this one is just for extra context 🌷

Acknowledgements 🫶

the author wants to thank David Hancock for helping identify these error scenarios 🙌 and also Jon Peterson, Roman Shpount, Robert Sparks, Christer Holmberg, and others in the STIR Working Group for their helpful feedback and discussion. the whole group is iconic 👑

Author's Address 🦋

Chris Wendt Somos Inc. Email: chris-ietf@chriswendt.net

📦 where this page comes from