< draft-ietf-stir-messaging-01.txt   draft-ietf-stir-messaging-02.txt >
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Standards Track C. Wendt Intended status: Standards Track C. Wendt
Expires: May 13, 2022 Somos Expires: 23 October 2022 Somos
November 9, 2021 21 April 2022
Messaging Use Cases and Extensions for STIR Messaging Use Cases and Extensions for STIR
draft-ietf-stir-messaging-01 draft-ietf-stir-messaging-02
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 messaging space. This sometimes leveraged by bad actors in the text messaging space. This
document considers the applicability of STIR's Persona Assertion document considers the applicability of STIR's Persona Assertion
Token (PASSporT) and certificate issuance framework to text and Token (PASSporT) and certificate issuance framework to text and
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 13, 2022. This Internet-Draft will expire on 23 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
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 Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability to Messaging Systems . . . . . . . . . . . . . 3 3. Applicability to Messaging Systems . . . . . . . . . . . . . 3
3.1. Message Sessions . . . . . . . . . . . . . . . . . . . . 4 3.1. Message Sessions . . . . . . . . . . . . . . . . . . . . 4
3.2. PASSporTs and Messaging . . . . . . . . . . . . . . . . . 4 3.2. PASSporTs and Individiual Messages . . . . . . . . . . . 4
3.2.1. PASSporT Conveyance with Messaging . . . . . . . . . 5 3.2.1. PASSporT Conveyance with Messaging . . . . . . . . . 6
4. Certificates and Messaging . . . . . . . . . . . . . . . . . 6 4. Certificates and Messaging . . . . . . . . . . . . . . . . . 7
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. JSON Web Token Claims Registration . . . . . . . . . . . 6 6.1. JSON Web Token Claims Registration . . . . . . . . . . . 7
6.2. PASSporT Type Registration . . . . . . . . . . . . . . . 7 6.2. PASSporT Type Registration . . . . . . . . . . . . . . . 7
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 field capable impersonation. [RFC8224] defines a SIP Identity header field capable
skipping to change at page 4, line 44 skipping to change at page 4, line 44
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 man-in- For the most part, STIR does not intend to protect against man-in-
the-middle attacks so much as spoofed origination, however, so the the-middle attacks so much as spoofed origination, however, so the
protection offered may be sufficient to mitigate nuisance messaging. protection offered may be sufficient to mitigate nuisance messaging.
3.2. PASSporTs and Messaging 3.2. PASSporTs and Individiual Messages
In the second case, SIP also has a method for sending messages in the In the second case, SIP also has a method for sending messages in the
body of a SIP request: the MESSAGE [RFC3428] method. MESSAGE is used body of a SIP request: the MESSAGE [RFC3428] method. MESSAGE is used
for example in some North American emergency services use cases. The for example in some North American emergency services use cases. The
interaction of STIR with MESSAGE is not as straightforward as the interaction of STIR with MESSAGE is not as straightforward as the
potential use case with MSRP. An Identity header could be added to potential use case with MSRP. An Identity header could be added to
any SIP MESSAGE request, but without some extension to the PASSporT any SIP MESSAGE request, but without some extension to the PASSporT
claims, the PASSporT would offer no protection to the message claims, the PASSporT would offer no protection to the message
content, and potentially be reusable for cut-and-paste attacks. As content, and potentially be reusable for cut-and-paste attacks. As
the bodies of SIP requests are MIME encoded, S/MIME [RFC8591] has the bodies of SIP requests are MIME encoded, S/MIME [RFC8591] has
been proposed as a means of providing integrity for MESSAGE (and some been proposed as a means of providing integrity for MESSAGE (and some
MSRP cases as well). The use of CPIM [RFC3862] as a MIME body allows MSRP cases as well). The use of CPIM [RFC3862] as a MIME body allows
the integrity of messages to withstand interworking with non-SIP the integrity of messages to withstand interworking with non-SIP
protocols. The interaction of [RFC8226] STIR certificates with protocols. The interaction of [RFC8226] STIR certificates with S/
S/MIME for messaging applications requires some further explication; MIME for messaging applications requires some further explication;
and additionally, PASSporT can provide its own integrity check for and additionally, PASSporT can provide its own integrity check for
message contents through a new claim defined to provide a hash over message contents through a new claim defined to provide a hash over
message contents. 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 JWT [RFC7519] claim "msgi" which provides a digest
over a MIME body that contains a text or multimedia message. "msgi" over a MIME body that contains a text or multimedia message. "msgi"
MUST NOT appear in PASSporTs with a type other than "msg", but they MUST NOT appear in PASSporTs with a type other than "msg", but they
skipping to change at page 5, line 36 skipping to change at page 5, line 36
A "msgi" message digest is computed over the entire MIME body of a A "msgi" message digest is computed over the entire MIME body of a
SIP message, which per [RFC3428] may any sort of MIME body, including SIP message, which per [RFC3428] may any sort of MIME body, including
a multipart body in some cases, especially when multimedia content is a multipart body in some cases, especially when multimedia content is
involved. The digest becomes the value of the JWT "msgi" claim, as involved. The digest becomes the value of the JWT "msgi" claim, as
per this example: per this example:
"msgi" : "msgi" :
"sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52t+eX6xO" "sha256-H8BRh8j48O9oYatfu5AZzq6A9RINQZngK7T62em8MUt1FLm52t+eX6xO"
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 [RFC8946] Section 9.1.
Finally, note that messages may be subject to store-and-forward
treatment that differs from traditional delivery expectations of SIP
transactions. In such cases, the expiry timers 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 order mesages displayed to 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 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 field in that the PASSporT could be conveyed in an Identity header field in that
request. The authentication and verification service procedures for request. The authentication and verification service procedures for
populating that PASSporT would follow [RFC8224], with the addition of populating that PASSporT would follow [RFC8224], with the addition of
the "msgi" claim defined in Section 3.2. the "msgi" claim defined in Section 3.2.
In text messaging today, multimedia message system (MMS) messages are In text messaging today, multimedia message system (MMS) messages are
often conveyed with SMTP. There are thus a suite of additional email often conveyed with SMTP. There are thus a suite of additional email
skipping to change at page 9, line 14 skipping to change at page 9, line 43
[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 9.2. Informative References
[I-D.peterson-stir-rfc4916-update] [I-D.peterson-stir-rfc4916-update]
Peterson, J. and C. Wendt, "Connected Identity for STIR", Peterson, J. and C. Wendt, "Connected Identity for STIR",
draft-peterson-stir-rfc4916-update-04 (work in progress), Work in Progress, Internet-Draft, draft-peterson-stir-
July 2021. rfc4916-update-04, 12 July 2021,
<https://www.ietf.org/archive/id/draft-peterson-stir-
rfc4916-update-04.txt>.
[RCC.07] GSMA RCC.07 v9.0 | 16 May 2018, "Rich Communication Suite [RCC.07] GSMA RCC.07 v9.0 | 16 May 2018, "Rich Communication Suite
8.0 Advanced Communications Services and Client 8.0 Advanced Communications Services and Client
Specification", 2018. Specification", 2018.
[RCC.15] GSMA PRD-RCC.15 v5.0 | 16 May 2018, "IMS Device [RCC.15] GSMA PRD-RCC.15 v5.0 | 16 May 2018, "IMS Device
Configuration and Supporting Services", 2018. Configuration and Supporting Services", 2018.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
skipping to change at page 10, line 14 skipping to change at page 10, line 44
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC8591] Campbell, B. and R. Housley, "SIP-Based Messaging with [RFC8591] Campbell, B. and R. Housley, "SIP-Based Messaging with S/
S/MIME", RFC 8591, DOI 10.17487/RFC8591, April 2019, MIME", RFC 8591, DOI 10.17487/RFC8591, April 2019,
<https://www.rfc-editor.org/info/rfc8591>. <https://www.rfc-editor.org/info/rfc8591>.
[RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity [RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity
Revisited (STIR) Out-of-Band Architecture and Use Cases", Revisited (STIR) Out-of-Band Architecture and Use Cases",
RFC 8816, DOI 10.17487/RFC8816, February 2021, RFC 8816, DOI 10.17487/RFC8816, February 2021,
<https://www.rfc-editor.org/info/rfc8816>. <https://www.rfc-editor.org/info/rfc8816>.
[RFC8862] Peterson, J., Barnes, R., and R. Housley, "Best Practices [RFC8862] Peterson, J., Barnes, R., and R. Housley, "Best Practices
for Securing RTP Media Signaled with SIP", BCP 228, for Securing RTP Media Signaled with SIP", BCP 228,
RFC 8862, DOI 10.17487/RFC8862, January 2021, RFC 8862, DOI 10.17487/RFC8862, January 2021,
 End of changes. 13 change blocks. 
30 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/