rfc9475.original   rfc9475.txt 
Network Working Group J. Peterson Internet Engineering Task Force (IETF) J. Peterson
Internet-Draft Neustar Request for Comments: 9475 Neustar
Intended status: Standards Track C. Wendt Category: Standards Track C. Wendt
Expires: 8 January 2024 Somos ISSN: 2070-1721 Somos
7 July 2023 December 2023
Messaging Use Cases and Extensions for STIR Messaging Use Cases and Extensions for Secure Telephone Identity
draft-ietf-stir-messaging-08 Revisited (STIR)
Abstract Abstract
Secure Telephone Identity Revisited (STIR) provides a means of Secure Telephone Identity Revisited (STIR) provides a means of
attesting the identity of a telephone caller via a signed token in attesting the identity of a telephone caller via a signed token in
order to prevent impersonation of a calling party number, which is a order to prevent impersonation of a calling party number, which is a
key enabler for illegal robocalling. Similar impersonation is key enabler for illegal robocalling. Similar impersonation is
sometimes leveraged by bad actors in the text and multimedia sometimes leveraged by bad actors in the text and multimedia
messaging space. This document explores the applicability of STIR's messaging space. This document explores the applicability of STIR's
Personal Assertion Token (PASSporT) and certificate issuance Personal Assertion Token (PASSporT) and certificate issuance
framework to text and multimedia messaging use cases, including framework to text and multimedia messaging use cases, including
support both for messages carried as a payload in SIP requests and support for both messages carried as a payload in SIP requests and
for messages sent in sessions negotiated by SIP. messages sent in sessions negotiated by SIP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 8 January 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9475.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Please review these documents carefully, as they describe your rights carefully, as they describe your rights and restrictions with respect
and restrictions with respect to this document. Code Components to this document. Code Components extracted from this document must
extracted from this document must include Revised BSD License text as include Revised BSD License text as described in Section 4.e of the
described in Section 4.e of the Trust Legal Provisions and are Trust Legal Provisions and are provided without warranty as described
provided without warranty as described in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Applicability to Messaging Systems . . . . . . . . . . . . . 3 3. Applicability to Messaging Systems
3.1. Message Sessions . . . . . . . . . . . . . . . . . . . . 4 3.1. Message Sessions
3.2. PASSporTs and Individual Messages . . . . . . . . . . . . 4 3.2. PASSporTs and Individual Messages
3.2.1. PASSporT Conveyance with Messaging . . . . . . . . . 6 3.2.1. PASSporT Conveyance with Messaging
4. Certificates and Messaging . . . . . . . . . . . . . . . . . 7 4. Certificates and Messaging
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5.1. JSON Web Token Claims Registration
6.1. JSON Web Token Claims Registration . . . . . . . . . . . 8 5.2. PASSporT Type Registration
6.2. PASSporT Type Registration . . . . . . . . . . . . . . . 8 6. Privacy Considerations
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
1. Introduction 1. Introduction
The STIR problem statement [RFC7340] describes widespread problems The STIR problem statement [RFC7340] describes widespread problems
enabled by impersonation in the telephone network, including illegal enabled by impersonation in the telephone network, including illegal
robocalling, voicemail hacking, and swatting. As telephone services robocalling, voicemail hacking, and swatting. As telephone services
are increasingly migrating onto the Internet and using Voice over IP are increasingly migrating onto the Internet and using Voice over IP
(VoIP) protocols such as SIP [RFC3261], it is necessary for these (VoIP) protocols such as SIP [RFC3261], it is necessary for these
protocols to support stronger identity mechanisms to prevent protocols to support stronger identity mechanisms to prevent
impersonation. [RFC8224] defines a SIP Identity header capable of impersonation. [RFC8224] defines a SIP Identity header capable of
carrying PASSporT [RFC8225] objects in SIP as a means to carrying PASSporT [RFC8225] objects in SIP as a means to
cryptographically attest that the originator of a telephone call is cryptographically attest that the originator of a telephone call is
authorized to use the calling party number (or, for native SIP cases, authorized to use the calling party number (or, for SIP cases, SIP
SIP URI) associated with the originator of the call. URI) associated with the originator of the call.
The problem of bulk, unsolicited commercial communications is not, However, the problem of bulk, unsolicited commercial communications
however, limited to telephone calls. Spammers and fraudsters are is not limited to telephone calls. Spammers and fraudsters are
increasingly turning to messaging applications to deliver undesired increasingly turning to messaging applications to deliver undesired
content to consumers. In some respects, mitigating these unwanted content to consumers. In some respects, mitigating these unwanted
messages resembles the email spam problem: textual analysis of the messages resembles the email spam problem; for example, textual
message contents can be used to fingerprint content that is generated analysis of the message contents can be used to fingerprint content
by spammers, for example. However, encrypted messaging is becoming that is generated by spammers. However, encrypted messaging is
more common, and analysis of message contents may no longer be a becoming more common, and analysis of message contents may no longer
reliable way to mitigate messaging spam in the future. And as STIR be a reliable way to mitigate messaging spam in the future. As STIR
sees further deployment in the telephone network, the governance sees further deployment in the telephone network, the governance
structures put in place for securing telephone network resources with structures put in place for securing telephone-network resources with
STIR could be repurposed to help secure the messaging ecosystem. STIR could be repurposed to help secure the messaging ecosystem.
One of the more sensitive applications for message security is One of the more sensitive applications for message security is
emergency services. As next-generation emergency services emergency services. As next-generation emergency services
increasingly incorporate messaging as a mode of communication with increasingly incorporate messaging as a mode of communication with
public safety personnel (see [RFC8876]), providing an identity public safety personnel (see [RFC8876]), providing an identity
assurance could help to mitigate denial-of-service attacks, as well assurance could help to mitigate denial-of-service attacks and
as ultimately helping to identify the source of emergency ultimately help to identify the source of emergency communications in
communications in general (including swatting attacks, see general (including swatting attacks, see [RFC7340]).
[RFC7340]).
This specification therefore explores how the PASSporT mechanism Therefore, this specification explores how the PASSporT mechanism
defined for STIR could be applied to providing protection for textual defined for STIR could be applied in providing protection for textual
and multimedia messaging, but focuses particularly on those messages and multimedia messaging, but it focuses particularly on those
that use telephone numbers as the identity of the sender. It messages that use telephone numbers as the identity of the sender.
moreover considers the reuse of existing STIR certificates, which are Moreover, it considers the reuse of existing STIR certificates, which
beginning to see widespread deployment, for signing PASSporTs that are beginning to see widespread deployment for signing PASSporTs that
protect messages. For that purpose it defines a new PASSporT type protect messages. For that purpose, it defines a new PASSporT type
and an element that protects message integrity. It contains a and an element that protects message integrity. It contains a
mixture of normative and informative guidance that specifies new mixture of normative and informative guidance that specifies new
fields for use in PASSporTs as well as an overview of how STIR might claims for use in PASSporTs as well as an overview of how STIR might
be applied to messaging in various environemnts. be applied to messaging in various environments.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Applicability to Messaging Systems 3. Applicability to Messaging Systems
At a high level, baseline PASSporT [RFC8225] claims provide similar At a high level, PASSporT [RFC8225] claims provide similar value to
value to number-based messaging as they do to traditional telephone number-based messaging as they do to telephone calls. A signature
calls. A signature over the calling and called party numbers, along over the calling and called party numbers, along with a timestamp,
with a timestamp, could already help to prevent impersonation in the could already help to prevent impersonation in the mobile-messaging
mobile messaging ecosystem. When it comes to protecting message ecosystem.
contents, broadly, there are a few ways that the PASSporT mechanism
of STIR could apply to messaging: first, a PASSporT could be used to When it comes to protecting message contents, broadly, there are a
securely negotiate a session over which messages will be exchanged; few ways that the PASSporT mechanism of STIR could apply to
and second, in sessionless scenarios, a PASSporT could be generated messaging:
on a per-message basis with its own built-in message security.
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 3.1. Message Sessions
For the first case, where SIP negotiates a session where the media In the first case, SIP negotiates a session in which the media will
will be text messages or MIME content, as, for example, with the be text messages or MIME content, as, for example, with the Message
Message Session Relay Protocol (MSRP) [RFC4975], the usage of STIR Session Relay Protocol (MSRP) [RFC4975]. This usage of STIR would
would deviate little from [RFC8224]. An INVITE request sent with an deviate little from [RFC8224]. An INVITE request sent with an
Identity header containing a PASSporT with the proper calling and Identity header containing a PASSporT with the proper calling and
called party numbers would then negotiate an MSRP session the same called party numbers would then negotiate an MSRP session the same
way that an INVITE for a telephone call would negotiate an audio way that an INVITE for a telephone call would negotiate an audio
session. This could be applicable to MSRP sessions negotiated for session. This could be applicable to MSRP sessions negotiated for
RCS [RCC.07]. Note that if TLS is used to secure MSRP (per RCS Rich Communication Suite (RCS) [RCC.07]. Note that, if TLS is used
[RCC.15]), fingerprints of those TLS keys could be secured via the to secure MSRP (per RCS [RCC.15]), fingerprints of those TLS keys
"mky" claim of PASSporT using the [RFC8862] framework. Similar could be secured via the "mky" claim of PASSporT using the framework
practices would apply to sessions that negotiate real-time text over described in [RFC8862]. Similar practices would apply to sessions
RTP ([RFC4103], [RFC5194]); any that can operate over DTLS/SRTP that negotiate real-time text over RTP ([RFC4103], [RFC5194]); any
that can operate over DTLS/SRTP (Secure Real-time Transport Protocol)
should work with the "mky" PASSporT claim. For the most basic use should work with the "mky" PASSporT claim. For the most basic use
cases, STIR for messaging should not require any further protocol cases, STIR for messaging should not require any further protocol
enhancements. enhancements.
Current usage of baseline [RFC8224] Identity is largely confined to Current usage of [RFC8224] Identity is largely confined to INVITE
INVITE requests that initiate telephone calls. RCS-style requests that initiate telephone calls. RCS-style applications would
applications would require PASSporTs for all conversation require PASSporTs for all conversation participants, which could
participants, which could become complex in multi-party become complex in multiparty conversations. Any solution in this
conversations. Any solution in this space would likely require the space would likely require the implementation of STIR-connected
implementation of STIR connected identity identity [CONNECT-ID-STIR], but the specification of PASSporT-signed
[I-D.peterson-stir-rfc4916-update], but the specification of session conferencing is outside the scope of this document.
PASSporT-signed session conferencing is outside the scope of this
document.
Also note that the assurance offered by [RFC8862] is "end-to-end" in Also note that the assurance offered by [RFC8862] is "end-to-end" in
the sense that it offers assurance between an authentication service the sense that it offers assurance between an authentication service
and verification service. If those are not implemented by the and verification service. If those are not implemented by the
endpoints themselves, there are still potential opportunities for endpoints themselves, there are still potential opportunities for
tampering before messages are signed and after they are verified. tampering before messages are signed and after they are verified.
For the most part, STIR does not intend to protect against machine- However, for the most part, STIR does not intend to protect against
in-the-middle attacks so much as spoofed origination, however, so the machine-in-the-middle attacks so much as spoofed origination; so the
protection offered may be sufficient to mitigate nuisance messaging. protection offered may be sufficient to mitigate nuisance messaging.
3.2. PASSporTs and Individual Messages 3.2. PASSporTs and Individual Messages
In the second case, SIP also has a method for sending messages in the In the second case described in Section 3, SIP also has a method for
body of a SIP request: the MESSAGE [RFC3428] method. MESSAGE is used sending messages in the body of a SIP request: the MESSAGE method
for example in some North American emergency services use cases. The [RFC3428]. For example, MESSAGE is used in some North American
interaction of STIR with MESSAGE is not as straightforward as the emergency services use cases. The interaction of STIR with MESSAGE
potential use case with MSRP. An Identity header could be added to is not as straightforward as the potential use case with MSRP. An
any SIP MESSAGE request, but without some extension to the PASSporT Identity header could be added to any SIP MESSAGE request, but
claims, the PASSporT would offer no protection to the message without some extension to the PASSporT claims, the PASSporT would
content, and potentially be reusable for cut-and-paste attacks where offer no protection to the message content; it would potentially be
the Identity header field from a legitimate request for one user is reusable for cut-and-paste attacks where the Identity header field
reused in a request for a different user. As the bodies of SIP from a legitimate request for one user is reused in a request for a
requests are MIME encoded, S/MIME [RFC8591] has been proposed as a different user. As the bodies of SIP requests are MIME encoded, S/
means of providing integrity for MESSAGE (and some MSRP cases as MIME [RFC8591] has been proposed as a means of providing integrity
well). The use of CPIM [RFC3862] as a MIME body allows the integrity for MESSAGE (and some MSRP cases as well). The use of Common
of messages to withstand interworking with non-SIP protocols. The Presence and Instant Messaging (CPIM) [RFC3862] as a MIME body allows
interaction of [RFC8226] STIR certificates with S/MIME for messaging the integrity of messages to withstand interworking with protocols
applications would require further specification; and additionally, that are not SIP. The interaction of STIR certificates with S/MIME
PASSporT can provide its own integrity check for message contents (see [RFC8226]) for messaging applications would require further
through a new claim defined to provide a hash over message contents. specification; additionally, PASSporT can provide its own integrity
check for message contents through a new claim defined to provide a
hash over message contents.
In order to differentiate a PASSporT for an individual message from a In order to differentiate a PASSporT for an individual message from a
PASSporT used to secure a telephone call or message stream, this PASSporT used to secure a telephone call or message stream, this
document defines a new "msg" PASSporT Type. "msg" PASSporTs may carry document defines a new "msg" PASSporT type. "msg" PASSporTs may carry
a new optional JWT [RFC7519] claim "msgi" which provides a digest a new optional JSON Web Token (JWT) [RFC7519] claim "msgi", which
over a MIME body that contains a text or multimedia message. provides a digest over a MIME body that contains a text or multimedia
Authentication services MUST NOT include "msgi" elements in PASSporT message. Authentication services MUST NOT include "msgi" elements in
types other than "msg", but "msgi" is OPTIONAL in "msg" PASSporTs, as PASSporT types other than "msg", but "msgi" is OPTIONAL in "msg"
integrity for messages may be provided by some other service (e.g. PASSporTs, as integrity for messages may be provided by some other
[RFC8591]). Verification services MUST ignore the presence of "msgi" service (e.g. [RFC8591]). Verification services MUST ignore the
in non-"msg" PASSporT types. presence of "msgi" in non-"msg" PASSporT types.
The claim value of "msgi" claim key is a string that defines the 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 crypto algorithm used to generate the digest concatenated by a hyphen
with a digest string. Implementations MUST support the hash with a digest string. Implementations MUST support the hash
algorithms SHA-256, SHA-384, and SHA-512. These hash algorithms are algorithms SHA-256, SHA-384, and SHA-512. These hash algorithms are
identified by "sha256", "sha384", and "sha512", respectively. SHA- identified by "sha256", "sha384", and "sha512", respectively. SHA-
256, SHA-384, and SHA-512 are part of the SHA-2 set of cryptographic 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 hash functions [RFC6234] defined by the US National Institute of
Standards and Technology (NIST). [SHA2] Implementations MAY support Standards and Technology (NIST). [SHA2] implementations MAY support
additional recommended hash algorithms in [IANA-COSE-ALG] additional recommended hash algorithms in the "COSE Algorithms"
(https://www.iana.org/assignments/cose/cose.xhtml#algorithms); that registry (https://www.iana.org/assignments/cose); that is, the hash
is, the hash algorithm has "Yes" in the "Recommended" column of the algorithm has "Yes" in the "Recommended" column of the IANA registry.
IANA registry. Hash algorithm identifiers MUST use only lowercase Hash algorithm identifiers MUST use only lowercase letters, and they
letters, and they MUST NOT contain hyphen characters. The character MUST NOT contain hyphen characters. The character following the
following the algorithm string MUST be a hyphen character, "-", or algorithm string MUST be a hyphen character ("-" or ASCII character
ASCII 45. 45).
The subsequent characters in the claim value are the base64 encoded The subsequent characters in the claim value are the base64-encoded
[RFC4648] digest of a canonicalized and concatenated string or binary [RFC4648] digest of a canonicalized and concatenated string or
data based MIME body of the message. A "msgi" message digest is binary-data-based MIME body of the message. An "msgi" message digest
computed over the entirety of the MIME body (be it carried via SIP or is computed over the entirety of the MIME body (be it carried via SIP
no), which per [RFC3428] may be any sort of MIME body, including a or not); per [RFC3428], this may be any sort of MIME body, including
multipart body in some cases, especially when multimedia content is a multipart body in some cases, especially when multimedia content is
involved. Those MIME bodies contain encrypted content or not as the involved. Those MIME bodies may or may not contain encrypted content
sender desires. The digest becomes the value of the JWT "msgi" or as the sender desires. The digest becomes the value of the JWT
claim, as per this example: "msgi" claim, as per this example:
"msgi" : "msgi" :
"sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52t+eX6xO" "sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52t+eX6xO"
Per baseline [RFC8224], this specifications leaves it to local policy Per [RFC8224], this specification leaves it to local policy to
to determine how messages are handled after verification succeeds or determine how messages are handled after verification succeeds or
fails. Broadly, if a SIP-based verification service wants to fails. Broadly, if a SIP-based verification service wants to
communicate back to the sender that the "msgi" hash does not communicate back to the sender that the "msgi" hash does not
correspond to the received message, using a SIP 438 response code correspond to the received message, using a SIP 438 response code
would be most appropriate. would be most appropriate.
Note that in some CPIM environments, intermediaries may add or Note that, in some CPIM environments, intermediaries may add or
consume CPIM headers used for metadata in messages. MIME-layer consume CPIM headers used for metadata in messages. MIME-layer
integrity protection of "msgi" would be broken by a modification integrity protection of "msgi" would be broken by a modification
along these lines. Any such environment would require a profile of along these lines. Any such environment would require a profile of
this specification that reduces the scope of protection only to the this specification that reduces the scope of protection only to the
CPIM payload, as discussed in [RFC8591] Section 9.1. CPIM payload, as discussed in Section 9.1 of [RFC8591].
Finally, note that messages may be subject to store-and-forward Finally, note that messages may be subject to store-and-forward
treatment that differs from traditional delivery expectations of SIP treatment that differs from delivery expectations of SIP
transactions. In such cases, the expiry freshness window recommended transactions. In such cases, the expiry freshness window recommended
by [RFC8224] may be too strict, as routine behavior might dictate the by [RFC8224] may be too strict, as routine behavior might dictate the
delivery of a MESSAGE minutes or hours after it was sent. The delivery of a MESSAGE minutes or hours after it was sent. The
potential for replay attacks can, however, be largely mitigated by potential for replay attacks can, however, be largely mitigated by
the timestamp in PASSporTs; duplicate messages are easily detected, the timestamp in PASSporTs; duplicate messages are easily detected,
and the timestamp can order messages displayed to the user inbox in a and the timestamp can be used to order messages displayed in the user
way that precludes showing stale messages as fresh. Relaxing the inbox in a way that precludes showing stale messages as fresh.
expiry timer would require support for such features on the receiving Relaxing the expiry timer would require support for such features on
side of the message. the receiving side of the message.
3.2.1. PASSporT Conveyance with Messaging 3.2.1. PASSporT Conveyance with Messaging
If the message is being conveyed in SIP, via the MESSAGE method, then 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 PASSporT could be conveyed in an Identity header in that request.
The authentication and verification service procedures for populating The authentication and verification service procedures for populating
that PASSporT would follow [RFC8224], with the addition of the "msgi" that PASSporT would follow the guidance in [RFC8224], with the
claim defined in Section 3.2. addition of the "msgi" claim defined in Section 3.2.
In text messaging today, multimedia message system (MMS) messages are In text messaging today, Multimedia Messaging Service (MMS) messages
often conveyed with SMTP. There are thus a suite of additional email are often conveyed with SMTP. Thus, there is a suite of additional
security tools available in this environment for sender email security tools available in this environment for sender
authentication, such as DMARC [RFC7489]. The interaction of these authentication, such as "Domain-based Message Authentication,
mechanisms with STIR certificates and/or PASSporTs would require Reporting, and Conformance (DMARC)" [RFC7489]. The interaction of
further study and is outside the scope of this document. 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 For other cases where messages are conveyed by some protocol other
than SIP, that protocol might itself have some way of conveying than SIP, that protocol itself might have some way of conveying
PASSporTs. But there will surely be cases where legacy transmission PASSporTs. There will surely be cases where legacy transmission of
of messages will not permit an accompanying PASSporT, in which case messages will not permit an accompanying PASSporT; in such a
something like out-of-band [RFC8816] conveyance would be the only way situation, something like out-of-band [RFC8816] conveyance would be
to deliver the PASSporT. This may be necessary to support cases the only way to deliver the PASSporT. For example, this may be
where legacy Short Message Peer-to-Peer [SMPP] systems cannot be necessary to support cases where legacy Short Message Peer-to-Peer
upgraded, for example. [SMPP] systems cannot be upgraded.
A MESSAGE request can be sent to multiple destinations in order to A MESSAGE request can be sent to multiple destinations in order to
support multiparty messaging. In those cases, the "dest" field of support multiparty messaging. In those cases, the "dest" claim of
the PASSporT can accommodate the multiple targets of a MESSAGE the PASSporT can accommodate the multiple targets of a MESSAGE
without the need to generate a PASSporT for each target of the without the need to generate a PASSporT for each target of the
message. If however the request is forked to multiple targets by an 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 intermediary later in the call flow, and the list of targets is not
available to the authentication service, then that forking available to the authentication service, then that forking
intermediary would need to use diversion [RFC8946] PASSporTs to sign intermediary would need to use diversion PASSporTs [RFC8946] to sign
for its target set. for its target set.
4. Certificates and Messaging 4. Certificates and Messaging
The [RFC8226] STIR certificate profiles defines a way to issue "Secure Telephone Identity Credentials: Certificates" [RFC8226]
certificates that sign PASSporTs, which attest through their defines a way to issue certificates that sign PASSporTs, which attest
TNAuthList a Service Provider Code (SPC) and/or a set of one or more through their TNAuthList a Service Provider Code (SPC) and/or a set
telephone numbers. This specification proposes that the semantics of of one or more telephone numbers. This specification proposes that
these certificates should suffice for signing for messages from a the semantics of these certificates should suffice for signing for
telephone number without further modification. messages from a telephone number without further modification.
Note that the certificate referenced by the "x5u" of a PASSporT can Note that the certificate referenced by the "x5u" of a PASSporT can
change over time, due to certificate expiry/rollover; in particular change over time due to certificate expiry/rollover; in particular,
the use of short-lived certificates can entail rollover on a daily the use of short-lived certificates can entail rollover on a daily
basis, or even more frequently. Thus any store-and-forward messaging basis or even more frequently. Thus, any store-and-forward messaging
system relying on PASSporTs must take into account the possibility system relying on PASSporTs must take into account the possibility
that the certificate that signed the PASSporT, though valid at the that the certificate that signed the PASSporT, though valid at the
time the PASSporT was generated, could expire before a user reads the time the PASSporT was generated, could expire before a user reads the
message. This might require storing some indicator of the validity message. This might require:
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" field can be compared with the expiry
freshness window of the certificate prior to validation.
As the "orig" and "dest" field of PASSporTs may contain URIs * storing some indicator of the validity of the signature and
containing SIP URIs without telephone numbers, the STIR for messaging certificate at the time the message was received, or
mechanism contained in this specification is not inherently
restricted to the use of telephone numbers. This specification
offers no guidance on certification authorities who are appropriate
to sign for non-telephone number "orig" values.
5. Acknowledgments * securely storing the certificate along with the PASSporT
We would like to thank Christer Holmberg, Brian Rosen, Ben Campbell, so that the "iat" claim can be compared with the expiry freshness
Russ Housley, and Alex Bobotek for their contributions to this window of the certificate prior to validation.
specification.
6. IANA Considerations 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.
6.1. JSON Web Token Claims Registration 5. IANA Considerations
This specification requests that the IANA add one new claim to the 5.1. JSON Web Token Claims Registration
JSON Web Token Claims registry as defined in [RFC7519].
Claim Name: "msgi" IANA has added one new claim to the "JSON Web Token Claims" registry
that was defined in [RFC7519].
Claim Description: Message Integrity Information Claim Name: msgi
Change Controller: IESG Claim Description: Message Integrity Information
Specification Document(s): [RFCThis] Change Controller: IETF
6.2. PASSporT Type Registration Specification Document(s): RFC 9475
This specification defines one new PASSporT type for the PASSport 5.2. PASSporT Type Registration
Extensions Registry defined in [RFC8225], which resides at
https://www.iana.org/assignments/passport/passport.xhtml#passport-
extensions.
ppt value: "msg" This specification defines one new PASSporT type for the "Personal
Assertion Token (PASSporT) Extensions" registry defined in [RFC8225].
Reference: [RFCThis] Section 3.2 ppt value: msg
7. Privacy Considerations Reference: Section 3.2 of RFC 9475
6. Privacy Considerations
Signing messages or message sessions with STIR has little direct Signing messages or message sessions with STIR has little direct
bearing on the privacy of messaging for SIP as described in [RFC3428] bearing on the privacy of messaging for SIP as described in [RFC3428]
or [RFC4975]. An authentication service signing a MESSAGE method may or [RFC4975]. An authentication service signing a MESSAGE method may
compute the "msgi" hash over the message contents; if the message is compute the "msgi" hash over the message contents; if the message is
in cleartext, that will reveal its contents to the authentication in cleartext, that will reveal its contents to the authentication
service, which might not otherwise be in the call path. service, which might not otherwise be in the call path.
The implications for anonymity of STIR are discussed in [RFC8224], The implications for anonymity of STIR are discussed in [RFC8224],
and those considerations would apply equally here for anonymous and those considerations would apply equally here for anonymous
messaging. Creating a "msg" PASSporT does not add any additional messaging. Creating an "msg" PASSporT does not add any additional
privacy protections to the original message content. privacy protections to the original message content.
8. Security Considerations 7. Security Considerations
This specification inherits the security considerations of [RFC8224]. This specification inherits the security considerations of [RFC8224].
The carriage of messages within SIP per Section 3.2 has a number of The carriage of messages within SIP per Section 3.2 has a number of
security and privacy implications as documented in [RFC3428], which security and privacy implications as documented in [RFC3428], which
are expanded in [RFC8591]; these considerations apply here well. The are expanded in [RFC8591]; these considerations apply here as well.
guidance about store-and-forward messaging and replay protection in The guidance about store-and-forward messaging and replay protection
Section 3.2 should also be recognized by implementers. in Section 3.2 should also be recognized by implementers.
Note that a variety of non-SIP protocols, both those integrated into Note that a variety of protocols that are not SIP, both those
the traditional telephone network and those based on over-the-top integrated into the telephone network and those based on over-the-top
applications, are responsible for most of the messaging that is sent applications, are responsible for most of the messaging that is sent
to and from telephone numbers today. Introducing this capability for to and from telephone numbers today. Introducing this capability for
SIP-based messaging will help to mitigate spoofing and nuisance SIP-based messaging will help to mitigate spoofing and nuisance
messaging for SIP-based platforms only. messaging for SIP-based platforms only.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
skipping to change at page 9, line 47 skipping to change at line 421
Huitema, C., and D. Gurle, "Session Initiation Protocol Huitema, C., and D. Gurle, "Session Initiation Protocol
(SIP) Extension for Instant Messaging", RFC 3428, (SIP) Extension for Instant Messaging", RFC 3428,
DOI 10.17487/RFC3428, December 2002, DOI 10.17487/RFC3428, December 2002,
<https://www.rfc-editor.org/info/rfc3428>. <https://www.rfc-editor.org/info/rfc3428>.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, Messaging (CPIM): Message Format", RFC 3862,
DOI 10.17487/RFC3862, August 2004, DOI 10.17487/RFC3862, August 2004,
<https://www.rfc-editor.org/info/rfc3862>. <https://www.rfc-editor.org/info/rfc3862>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
skipping to change at page 10, line 24 skipping to change at line 449
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>. <https://www.rfc-editor.org/info/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226, Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018, DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>. <https://www.rfc-editor.org/info/rfc8226>.
9.2. Informative References 8.2. Informative References
[I-D.peterson-stir-rfc4916-update] [CONNECT-ID-STIR]
Peterson, J. and C. Wendt, "Connected Identity for STIR", Peterson, J. and C. Wendt, "Connected Identity for STIR",
Work in Progress, Internet-Draft, draft-peterson-stir- Work in Progress, Internet-Draft, draft-ietf-stir-rfc4916-
rfc4916-update-04, 12 July 2021, update-04, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-peterson- <https://datatracker.ietf.org/doc/html/draft-ietf-stir-
stir-rfc4916-update-04>. rfc4916-update-04>.
[RCC.07] GSMA RCC.07 v9.0 | 16 May 2018, "Rich Communication Suite [RCC.07] GSMA, "Rich Communication Suite 8.0 Advanced
8.0 Advanced Communications Services and Client Communications Services and Client Specification", Version
Specification", 2018. 9.0, May 2018, <https://www.gsma.com/futurenetworks/wp-
content/uploads/2019/09/RCC.07-v9.0.pdf>.
[RCC.15] GSMA PRD-RCC.15 v5.0 | 16 May 2018, "IMS Device [RCC.15] GSMA, "IMS Device Configuration and Supporting Services",
Configuration and Supporting Services", 2018. Version 7.0, October 2019, <https://www.gsma.com/newsroom/
wp-content/uploads//RCC.15-v7.0.pdf>.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
<https://www.rfc-editor.org/info/rfc4103>. <https://www.rfc-editor.org/info/rfc4103>.
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
"The Message Session Relay Protocol (MSRP)", RFC 4975, "The Message Session Relay Protocol (MSRP)", RFC 4975,
DOI 10.17487/RFC4975, September 2007, DOI 10.17487/RFC4975, September 2007,
<https://www.rfc-editor.org/info/rfc4975>. <https://www.rfc-editor.org/info/rfc4975>.
skipping to change at page 11, line 43 skipping to change at line 519
[RFC8876] Rosen, B., Schulzrinne, H., Tschofenig, H., and R. [RFC8876] Rosen, B., Schulzrinne, H., Tschofenig, H., and R.
Gellens, "Non-interactive Emergency Calls", RFC 8876, Gellens, "Non-interactive Emergency Calls", RFC 8876,
DOI 10.17487/RFC8876, September 2020, DOI 10.17487/RFC8876, September 2020,
<https://www.rfc-editor.org/info/rfc8876>. <https://www.rfc-editor.org/info/rfc8876>.
[RFC8946] Peterson, J., "Personal Assertion Token (PASSporT) [RFC8946] Peterson, J., "Personal Assertion Token (PASSporT)
Extension for Diverted Calls", RFC 8946, Extension for Diverted Calls", RFC 8946,
DOI 10.17487/RFC8946, February 2021, DOI 10.17487/RFC8946, February 2021,
<https://www.rfc-editor.org/info/rfc8946>. <https://www.rfc-editor.org/info/rfc8946>.
[SHA2] National Institute of Standards and Technology FIPS PUB [SHA2] National Institute of Standards and Technology (NIST),
180-3. http://csrc.nist.gov/publications/fips/fips180-3/ "Secure Hash Standard (SHS)", FIPS PUB 180-3, 2008,
fips180-3_final.pdf, "Secure Hash Standard (SHS)", 2018. <http://csrc.nist.gov/publications/fips/fips180-3/
fips180-3_final.pdf>.
[SMPP] SMS Forum v5.0 | 19 February 2003, "Short Message Peer to [SMPP] SMS Forum, "Short Message Peer-to-Peer Protocol
Peer Protocol Specification", 2003. Specification", Version 5.0, February 2003,
<https://smpp.org/SMPP_v5.pdf>.
Acknowledgments
We would like to thank Christer Holmberg, Brian Rosen, Ben Campbell,
Russ Housley, and Alex Bobotek for their contributions to this
specification.
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
Email: jon.peterson@team.neustar Email: jon.peterson@team.neustar
Chris Wendt Chris Wendt
Somos Somos
Email: chris-ietf@chriswendt.net Email: chris-ietf@chriswendt.net
 End of changes. 71 change blocks. 
236 lines changed or deleted 251 lines changed or added

This html diff was produced by rfcdiff 1.48.