RFC 9475

Messaging Use Cases and Extensions for Secure Telephone Identity Revisited (STIR)

📅 published December 2023, from ietf

RFC 9475: Messaging Use Cases and Extensions for STIR 💖

Okay bestie, this one is about bringing STIR's caller-ID protection (the stuff that fights robocall impersonation 📞🚫) over to texts and multimedia messages. The title block is the crew list and paperwork. ✨

  • RFC number: 9475
  • Title: Messaging Use Cases and Extensions for Secure Telephone Identity Revisited (STIR)
  • Authors: J. Peterson (Neustar) and C. Wendt (Somos) 👑
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: December 2023
  • Obsoletes / Updates: the title block doesn't list anything here, so this RFC doesn't obsolete or update any others 🧚

Abstract

Secure Telephone Identity Revisited (STIR) lets a phone call's caller prove who they are with a signed token, so nobody can fake the calling party number. That matters because fake caller IDs are a huge tool for illegal robocalling 📵. Bad actors also fake identities in texts and multimedia messages, so this document looks at how STIR's Personal Assertion Token (PASSporT) and certificate issuance framework could work for those messages. It covers messages carried as a payload in SIP requests and messages sent in sessions negotiated by SIP. 💅

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. More info on Internet Standards is in Section 2 of RFC 7841.

For the current status of this document, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9475. 🦋

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, because they explain your rights and restrictions for this document. 🫶 Any Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Applicability to Messaging Systems
     3.1.  Message Sessions
     3.2.  PASSporTs and Individual Messages
       3.2.1.  PASSporT Conveyance with Messaging
   4.  Certificates and Messaging
   5.  IANA Considerations
     5.1.  JSON Web Token Claims Registration
     5.2.  PASSporT Type Registration
   6.  Privacy Considerations
   7.  Security Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

Okay so the STIR problem statement [RFC7340] lays out the mess that impersonation causes on the phone network 😭. We're talking illegal robocalling, voicemail hacking, and swatting. Phone service is moving onto the Internet and running on Voice over IP (VoIP) protocols like SIP [RFC3261], so those protocols need stronger identity tools to stop impersonation. [RFC8224] defines a SIP Identity header that can carry PASSporT [RFC8225] objects. Those let the call's originator cryptographically prove they're allowed to use the calling party number (or, for SIP cases, the SIP URI) tied to them. It's giving security guard at the door 🔥.

But bulk, unwanted commercial messages aren't just a phone problem. Spammers and fraudsters are moving to messaging apps to push unwanted stuff at people 🙈. This kind of spam kind of looks like email spam. For example, you can analyze the text of a message to fingerprint content that spammers generated. The catch is that encrypted messaging is getting more common, and if nobody can read message contents, that analysis may stop working as a way to fight messaging spam. As STIR gets more deployed on the phone network, the governance structures set up to secure telephone-network resources with STIR could be reused to help secure the messaging ecosystem 🌈.

Emergency services are one of the most sensitive areas for message security 🚨. Next-generation emergency services are adding messaging as a way to talk with public safety personnel (see [RFC8876]). Identity assurance could help reduce denial-of-service attacks and help track down where emergency communications come from, including swatting attacks (see [RFC7340]).

So this specification looks at how the PASSporT mechanism defined for STIR could protect textual and multimedia messaging. It focuses on messages that use telephone numbers as the sender's identity 📱. It also considers reusing existing STIR certificates, which are starting to get widely deployed for signing PASSporTs that protect messages. To do that, it defines a new PASSporT type and an element that protects message integrity. You'll find a mix of normative and informative guidance here, including new claims for use in PASSporTs and an overview of how STIR might apply to messaging in different environments. 💜

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. Applicability to Messaging Systems 🧚

At a high level, PASSporT [RFC8225] claims give number-based messaging the same kind of value they give telephone calls 💖. A signature over the calling and called party numbers, plus a timestamp, could already help stop impersonation in the mobile-messaging ecosystem.

When it comes to protecting message contents, there are roughly a few ways the PASSporT mechanism of STIR could apply to messaging:

  1. a PASSporT could be used to securely negotiate a session over which messages will be exchanged (see Section 3.1), and
  2. in sessionless scenarios, a PASSporT could be generated on a per-message basis with its own built-in message security (see Section 3.2).

3.1. Message Sessions 🦋

In the first case, SIP negotiates a session where the media will be text messages or MIME content, for example with the Message Session Relay Protocol (MSRP) [RFC4975] 📨. This usage of STIR would barely deviate from [RFC8224]. An INVITE request sent with an Identity header containing a PASSporT with the right calling and called party numbers would negotiate an MSRP session the same way an INVITE for a phone call negotiates an audio session. This could apply to MSRP sessions negotiated for Rich Communication Suite (RCS) [RCC.07]. Note that if TLS is used to secure MSRP (per RCS [RCC.15]), fingerprints of those TLS keys could be secured with the "mky" claim of PASSporT, using the framework described in [RFC8862] 🔐. Similar practices would apply to sessions that negotiate real-time text over RTP ([RFC4103], [RFC5194]). Anything that can run over DTLS/SRTP (Secure Real-time Transport Protocol) should work with the "mky" PASSporT claim. For the most basic use cases, STIR for messaging should not require any further protocol enhancements 🎉.

Current usage of [RFC8224] Identity is mostly limited to INVITE requests that start telephone calls. RCS-style applications would need PASSporTs for all conversation participants, which could get complicated in multiparty conversations 😵‍💫. Any solution in this space would likely need STIR-connected identity [CONNECT-ID-STIR] implemented, but specifying PASSporT-signed session conferencing is out of scope for this document.

Also, the assurance [RFC8862] offers is "end-to-end" in the sense that it covers the stretch between an authentication service and a verification service. If the endpoints don't implement those services themselves, there are still chances for tampering before messages get signed and after they get verified 👀. But STIR isn't really trying to stop machine-in-the-middle attacks so much as spoofed origination, so the protection may be enough to cut down on nuisance messaging. Honestly that's a solid win 🍓.

3.2. PASSporTs and Individual Messages 💌

Okay so, the second case from Section 3 is where SIP gets its own messaging moment 💅. SIP has a method for sending messages in the body of a SIP request, and it's the MESSAGE method [RFC3428]. It's giving emergency services energy, since MESSAGE shows up in some North American emergency services use cases 🚨. Now, the STIR + MESSAGE combo is honestly not as straightforward as the MSRP one 🥺. You could slap an Identity header on any SIP MESSAGE request, but without an extension to the PASSporT claims, the PASSporT wouldn't protect the message content at all 😬. It could get reused for cut-and-paste attacks, where the Identity header field from a legit request for one user gets copied into a request for a different user 💀.

Since SIP request bodies are MIME encoded, S/MIME [RFC8591] has been proposed as a way to give integrity for MESSAGE (and some MSRP cases too) 🔐. Using Common Presence and Instant Messaging (CPIM) [RFC3862] as a MIME body lets message integrity hold up when it interworks with protocols that aren't SIP 🌈. The interaction of STIR certificates with S/MIME (see [RFC8226]) for messaging apps would require further specification 📝. PASSporT can also bring its own integrity check for message contents through a new claim that provides a hash over message contents 🧚.

In order to tell apart a PASSporT for an individual message from one that secures a telephone call or message stream, this document defines a new msg PASSporT type 🦋. msg PASSporTs may carry a new optional JSON Web Token (JWT) [RFC7519] claim msgi, which provides a digest over a MIME body that contains a text or multimedia message. Authentication services MUST NOT include msgi elements in PASSporT types other than msg, but msgi is OPTIONAL in msg PASSporTs, as integrity for messages may be provided by some other service (e.g. [RFC8591]). Verification services MUST ignore the presence of msgi in non-msg PASSporT types. 🙈

The claim value of the msgi claim key is a string that defines the crypto algorithm used to generate the digest, concatenated by a hyphen with a digest string. Implementations MUST support the hash algorithms SHA-256, SHA-384, and SHA-512. These hash algorithms are identified by sha256, sha384, and sha512, respectively. SHA-256, SHA-384, and SHA-512 are part of the SHA-2 set of cryptographic hash functions [RFC6234] defined by the US National Institute of Standards and Technology (NIST). [SHA2] implementations MAY support additional recommended hash algorithms in the "COSE Algorithms" registry (https://www.iana.org/assignments/cose). That is, the hash algorithm has "Yes" in the "Recommended" column of the IANA registry. Hash algorithm identifiers MUST use only lowercase letters, and they MUST NOT contain hyphen characters. The character following the algorithm string MUST be a hyphen character ("-" or ASCII character 45). 🔥

The subsequent characters in the claim value are the base64-encoded [RFC4648] digest of a canonicalized and concatenated string or binary-data-based MIME body of the message. An msgi message digest is computed over the entirety of the MIME body (be it carried via SIP or not). Per [RFC3428], this may be any sort of MIME body, including a multipart body in some cases, especially when multimedia content is involved. Those MIME bodies may or may not contain encrypted content, or as the sender desires. The digest becomes the value of the JWT msgi claim, as per this example:

"msgi" :
"sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52t+eX6xO"

Per [RFC8224], this specification leaves it to local policy to determine how messages are handled after verification succeeds or fails. Broadly, if a SIP-based verification service wants to tell the sender that the msgi hash does not correspond to the received message, using a SIP 438 response code would be most appropriate. ✨

Note that, in some CPIM environments, intermediaries may add or consume CPIM headers used for metadata in messages. MIME-layer integrity protection of msgi would be broken by a modification along these lines. Any such environment would require a profile of this specification that reduces the scope of protection only to the CPIM payload, as discussed in Section 9.1 of [RFC8591]. 🧐

Finally, messages may be subject to store-and-forward treatment that differs from the delivery expectations of SIP transactions. In such cases, the expiry freshness window recommended by [RFC8224] may be too strict, as routine behavior might dictate the delivery of a MESSAGE minutes or hours after it was sent. The potential for replay attacks can, however, be largely mitigated by the timestamp in PASSporTs. Duplicate messages are easily detected, and the timestamp can be used to order messages displayed in the user inbox in a way that precludes showing stale messages as fresh. Relaxing the expiry timer would require support for such features on the receiving side of the message. ⏰

3.2.1. PASSporT Conveyance with Messaging

If the message is being conveyed in SIP, via the MESSAGE method, then the PASSporT could be conveyed in an Identity header in that request. The authentication and verification service procedures for populating that PASSporT would follow the guidance in [RFC8224], with the addition of the msgi claim defined in Section 3.2. 📦

In text messaging today, Multimedia Messaging Service (MMS) messages are often conveyed with SMTP. That means there's a whole suite of email security tools available in this environment for sender authentication, such as "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" [RFC7489]. The interaction of these mechanisms with STIR certificates and/or PASSporTs would require further study and is outside the scope of this document. 📧

For other cases where messages are conveyed by some protocol other than SIP, that protocol itself might have some way of conveying PASSporTs. There will surely be cases where legacy transmission of messages will not permit an accompanying PASSporT. In such a situation, something like out-of-band [RFC8816] conveyance would be the only way to deliver the PASSporT. For example, this may be necessary to support cases where legacy Short Message Peer-to-Peer [SMPP] systems cannot be upgraded. 🥹

A MESSAGE request can be sent to multiple destinations in order to support multiparty messaging. In those cases, the dest claim of the PASSporT can accommodate the multiple targets of a MESSAGE without the need to generate a PASSporT for each target of the message. However, if the request is forked to multiple targets by an intermediary later in the call flow, and the list of targets is not available to the authentication service, then that forking intermediary would need to use diversion PASSporTs [RFC8946] to sign for its target set. 👯‍♀️

4. Certificates and Messaging 🎀

"Secure Telephone Identity Credentials: Certificates" [RFC8226] defines a way to issue certificates that sign PASSporTs. Those PASSporTs attest, through their TNAuthList, a Service Provider Code (SPC) and/or a set of one or more telephone numbers. This specification proposes that the semantics of these certificates should suffice for signing for messages from a telephone number without further modification. 🔏

The certificate referenced by the x5u of a PASSporT can change over time due to certificate expiry or rollover. In particular, the use of short-lived certificates can entail rollover on a daily basis, or even more frequently. Thus, any store-and-forward messaging system relying on PASSporTs must take into account the possibility that the certificate that signed the PASSporT, though valid at the time the PASSporT was generated, could expire before a user reads the message. This might require:

  • storing some indicator of the validity of the signature and certificate at the time the message was received, or
  • securely storing the certificate along with the PASSporT

so that the iat claim can be compared with the expiry freshness window of the certificate prior to validation. ⏳

As the orig and dest claims of PASSporTs may contain URIs without telephone numbers, the STIR for messaging mechanism contained in this specification is not inherently restricted to the use of telephone numbers. This specification offers no guidance on appropriate certification authorities for designing orig values that do not contain telephone numbers. 🌸

5. IANA Considerations 📋

5.1. JSON Web Token Claims Registration

IANA has added one new claim to the "JSON Web Token Claims" registry that was defined in [RFC7519]. 🏷️

Claim Name:  msgi

Claim Description:  Message Integrity Information

Change Controller:  IETF

Specification Document(s):  RFC 9475

5.2. PASSporT Type Registration

This specification defines one new PASSporT type for the "Personal Assertion Token (PASSporT) Extensions" registry defined in [RFC8225]. 🦋

ppt value:  msg

Reference:  Section 3.2 of RFC 9475

6. Privacy Considerations 🙈

Signing messages or message sessions with STIR has little direct bearing on the privacy of messaging for SIP as described in [RFC3428] or [RFC4975]. An authentication service signing a MESSAGE method may compute the msgi hash over the message contents. If the message is in cleartext, that will reveal its contents to the authentication service, which might not otherwise be in the call path. 👀

The implications for anonymity of STIR are discussed in [RFC8224], and those considerations would apply equally here for anonymous messaging. Creating a msg PASSporT does not add any additional privacy protections to the original message content. 🫣

7. Security Considerations 🚨

Okay, this section is serious business, bestie. Read every word. 💀

This specification inherits the security considerations of [RFC8224]. The carriage of messages within SIP per Section 3.2 has a number of security and privacy implications, as documented in [RFC3428] and expanded in [RFC8591]. These considerations apply here as well. The guidance about store-and-forward messaging and replay protection in Section 3.2 should also be recognized by implementers. 🔐

Note that a variety of protocols that are not SIP, both those integrated into the telephone network and those based on over-the-top applications, are responsible for most of the messaging that is sent to and from telephone numbers today. Introducing this capability for SIP-based messaging will help to mitigate spoofing and nuisance messaging for SIP-based platforms only. 📵

8. References 📚

8.1. Normative References 📚✨

Okay bestie, these are the must-reads. You can't really get the spec without them 💅

8.2. Informative References 🌸

These ones are the extra-credit reading. Super useful for the full picture, lowkey obsessed 🤓🎀

Acknowledgments 🫶

A huge thank-you to Christer Holmberg, Brian Rosen, Ben Campbell, Russ Housley, and Alex Bobotek for their contributions to this specification. The real MVPs 👑💖

Authors' Addresses 🦋

Jon Peterson Neustar, Inc. Email: jon.peterson@team.neustar

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

📦 where this page comes from