Messaging Use Cases and Extensions for Secure Telephone Identity Revisited (STIR)
Extracted elements (24)
Existing STIR certificates (RFC 8226) attesting telephone numbers via TNAuthList are proposed to suffice for signing message PASSporTs without modification, enabling reuse of the emerging STIR certificate infrastructure.
In multiparty messaging, the "dest" claim of a single PASSporT can accommodate multiple targets of a MESSAGE without generating a PASSporT per target. If an intermediary forks to unlisted targets, diversion PASSporTs (RFC 8946) must be used.
The expiry freshness window recommended by RFC 8224 may be too strict for store-and-forward messaging, where routine delivery of a MESSAGE may occur minutes or hours after it was sent. The PASSporT timestamp can still mitigate replay attacks and allow ordering messages in a user inbox.
Two high-level approaches for applying STIR PASSporTs to messaging are identified: (1) a PASSporT securing a SIP-negotiated session (e.g., MSRP) with little deviation from RFC 8224, and (2) a per-message PASSporT with the new "msgi" claim for sessionless scenarios such as the SIP MESSAGE method.
Without the "msgi" extension, a PASSporT in a SIP MESSAGE request offers no protection to message content and would be vulnerable to cut-and-paste attacks where the Identity header from a legitimate request is reused in a request for a different user.
For MSRP sessions secured with TLS (as in RCS), fingerprints of TLS keys can be secured via the "mky" claim of PASSporT using RFC 8862. Similar practices apply to sessions negotiating real-time text over DTLS/SRTP.
For non-SIP messaging protocols (e.g., legacy SMPP systems that cannot be upgraded), out-of-band PASSporT conveyance per RFC 8816 may be the only viable mechanism to deliver a PASSporT alongside a message.
In some CPIM environments, intermediaries may add or consume CPIM headers used for message metadata; such modification would break the MIME-layer integrity protection of "msgi". Deployments in those environments would need a profile reducing protection scope to only the CPIM payload.
MMS messages are often conveyed with SMTP, where email sender authentication tools (e.g., DMARC) are available. The interaction of DMARC with STIR certificates and PASSporTs is outside scope and requires further study.
Authentication services MUST NOT include "msgi" elements in PASSporT types other than "msg". The "msgi" claim is OPTIONAL in "msg" PASSporTs, as integrity for messages may be provided by some other service.
Hash algorithm identifiers in the "msgi" claim MUST use only lowercase letters and MUST NOT contain hyphen characters. The character immediately following the algorithm string MUST be a hyphen ("-", ASCII 45).
Implementations MAY support additional recommended hash algorithms listed in the IANA "COSE Algorithms" registry where the "Recommended" column is "Yes".
Implementations MUST support the hash algorithms SHA-256, SHA-384, and SHA-512 (identified as "sha256", "sha384", and "sha512" respectively) for computing the "msgi" digest.
Verification services MUST ignore the presence of "msgi" in non-"msg" PASSporT types.
Creating a "msg" PASSporT does not add any additional privacy protections to the original message content. Anonymity implications from RFC 8224 apply equally to anonymous messaging scenarios.
When an authentication service computes the "msgi" hash over cleartext message contents, the message body is necessarily revealed to the authentication service, which might not otherwise be in the call path.
The "msgi" JWT claim provides a digest over a MIME body. Its value is a string consisting of the crypto algorithm name (e.g., "sha256") concatenated with a hyphen and the base64-encoded digest of the canonicalized MIME body of the message.
This document defines a new "msg" PASSporT type to differentiate a PASSporT for an individual message from a PASSporT used to secure a telephone call or message stream. "msg" PASSporTs may carry the optional "msgi" JWT claim providing a digest over a MIME body containing a text or multimedia message.
IANA has added a new claim to the "JSON Web Token Claims" registry: Claim Name "msgi", Claim Description "Message Integrity Information", Change Controller IETF, Specification Document RFC 9475.
IANA has added a new entry to the "Personal Assertion Token (PASSporT) Extensions" registry: ppt value "msg", Reference Section 3.2 of RFC 9475.
Introducing STIR-based message signing for SIP-based platforms will help mitigate spoofing and nuisance messaging only for those platforms; the many non-SIP protocols responsible for most telephone-number messaging are unaffected.
Store-and-forward messaging systems relying on PASSporTs must account for certificate expiry: a certificate valid when the PASSporT was generated could expire before the user reads the message. Mitigations include storing a signed indicator of validity at receipt time or securely storing the certificate alongside the PASSporT.
This specification inherits the security considerations of RFC 8224 (authenticated SIP identity) and RFC 3428 (SIP MESSAGE), expanded in RFC 8591. Replay attacks on store-and-forward messages are largely mitigated by the PASSporT timestamp.
The "msgi" claim value is formatted as: algorithm-identifier (lowercase, no hyphens) + "-" (ASCII 45) + base64url-encoded digest. Example: "sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52t+eX6xO". The digest is computed over the entirety of the MIME body.