Secure Telephone Identity for Message Layer Security
draft-peterson-stir-mls-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jon Peterson , Richard Barnes | ||
| Last updated | 2024-03-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-peterson-stir-mls-01
Network Working Group J. Peterson
Internet-Draft TransUnion
Intended status: Standards Track R. Barnes
Expires: 5 September 2024 Cisco
4 March 2024
Secure Telephone Identity for Message Layer Security
draft-peterson-stir-mls-01
Abstract
This document specifies Message Layer Security (MLS) Credential Types
for use with Secure Telephone Identity Revisited (STIR), one for STIR
certificates and another for the Personal Assertion Token (PASSporT).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 September 2024.
Copyright Notice
Copyright (c) 2024 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) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Peterson & Barnes Expires 5 September 2024 [Page 1]
Internet-Draft STIR MLS March 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MLS Credential Type for STIR Certificates . . . . . . . . . . 3
3.1. MLS STIR Certificate Credential Structure Definitions . . 4
4. MLS Credential Type for STIR PASSporTs . . . . . . . . . . . 4
4.1. MLS PASSporT Credential Structure Definitions . . . . . . 5
5. Interaction with MIMI . . . . . . . . . . . . . . . . . . . . 5
6. MLS Group Messaging with STIR . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . 6
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The STIR problem statement [RFC7340] describes widespread problems
enabled by impersonation in the telephone network, including illegal
robocalling, voicemail hacking, and swatting. As telephone services
have migrated onto the Internet using Voice over IP (VoIP) protocols
such as SIP [RFC3261], it is necessary for these protocols to support
stronger identity mechanisms to prevent impersonation. [RFC8224]
defines a SIP Identity header capable of carrying PASSporT [RFC8225]
objects in SIP as a means to cryptographically attest that the
originator of a telephone call is authorized to use the calling party
number (or, for native SIP cases, SIP URI) associated with the
originator of the call. [RFC8226] in turn defines an extension to
X.509 certificates (TNAuthList) suitable attesting ownership of
telephone numbers and signing PASSporTs.
The problem of bulk, unsolicited commercial communications is not,
however, limited to telephone calls. Spammers and fraudsters are
increasingly turning to messaging applications to deliver undesired
content to consumers. And as STIR sees further deployment in the
telephone network, the governance structures put in place for
securing telephone network resources with STIR could be repurposed to
help secure the messaging ecosystem. This problem and its
applicability to STIR is described in [RFC9475], both for signing
individual messages with STIR and securing message streams negotiated
by SIP.
Peterson & Barnes Expires 5 September 2024 [Page 2]
Internet-Draft STIR MLS March 2024
Message Layer Security (MLS) [RFC9420] defines a key exchange
mechanism to enable secure messaging between groups of users.
Members in MLS groups are identified by credentials, which can
include X.509 certificates. Because many messaging systems use
telephone numbers as identifiers for users, having a secure means to
identify MLS group members by telephone number is desirable.
This specification explores the applicability of [RFC8226]
certificates to MLS, and how both service-provider level certificates
and delegate certificates [RFC9060] might be used as credentials for
MLS users for those cases where a telephone number is the primary
identifier of a group member. It also specifies a way to use a
[RFC8225] PASSporT as an MLS Credential. These MLS Credential Types
could be used for carrier-adjacent deployments (e.g. RCS) or for
over-the-top implementations.
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. MLS Credential Type for STIR Certificates
MLS already specifies the use of X.509 certificates as an MLS
Credential Type. The guidance in [RFC9420] Section 5.3 allows MLS
applications significant leeway in determining how to derive
identifiers that will be rendered to users. An application could,
for example, extract identifiers from the subjectAltName extension of
an X.509 certificate.
[RFC8226] certificates used by STIR contain a TNAuthList extension,
which may contain one or more telephone numbers, telephone number
ranges, or Service Provider Codes (SPCs). In North American carrier
deployments, the Service Provider Code field is most commonly used to
convey an Operating Company Number (sometimes also known as a Service
Provider ID), which designates only the serving carrier. These
certificates do not convey any individual telephone number associated
with a potential member in an MLS group, so that identifier would
need to be conveyed separately by the application. Moreover, the
keying material would in this case be held by a carrier, rather than
an end-user device, so any security association created with that
keying material would not be end-to-end.
Peterson & Barnes Expires 5 September 2024 [Page 3]
Internet-Draft STIR MLS March 2024
[RFC9060] specifies delegate certificates in STIR, which allow
intermediate certification authorities to issue subordinate keys that
attest to a subset of a given carrier's authority. Delegate
certificates may be issued down to the individual telephone number
level, and are recommended for applications where end-to-end security
is required, per [RFC8862]. MLS applications could extract the
telephone number from the TNAuthList field to use as an identifier
for the group member.
The subjectAltName field, or a similar X.509 extension, could be used
to convey the user's name in delegate certificates. Another
[RFC8226] extension is JWTClaimsConstraint, which can place
restrictions on the content of PASSporT objects that can be signed
with a certificate. These can include constraints on Rich Call Data
(RCD), which includes elements like proper names and images or logos
associated with the certificate. A claim constraint on the "nam" RCD
element, for example, could also be used by MLS applications as an
alternative way to find a proper name for a group member.
In deployments at this time, however, delegate certificates are
rarely used, and few intermediate certification authorities exist who
are capable of issuing delegate certificates.
3.1. MLS STIR Certificate Credential Structure Definitions
struct {
// Certificate chain, where Certificate is defined in RFC 9420 (and the same
// ordering requirements apply), and certificates are in the form defined by
// RFC 8226 / RFC 9060. The subjectPublicKey of the first certificate MUST
// match the signature_key of the enclosing LeafNode.
Certificate certificates<V>;
} STIRCertificateCredential;
4. MLS Credential Type for STIR PASSporTs
Instead of using a STIR certificate, implementations may also use a
STIR PASSporT [RFC8225] as an MLS Credential Type. The PASSporT's
contents contain identity information that could be consumed by
messaging applications. Effectively, in this case a PASSporT would
be created on a per-group basis.
The "orig" field of a PASSporT would indicate the telephone number
identity of the group member. Further RCD data, including the "nam"
field, could give additional identifiers for the member, including a
proper name. The "dest" field of the PASSporT would contain a
suitable identifier for the MLS group [TBD!].
Peterson & Barnes Expires 5 September 2024 [Page 4]
Internet-Draft STIR MLS March 2024
While PASSporTs themselves do not convey keying material suitable for
MLS, they can carry an "mky" field containing a fingerprint of keying
material. This allows a PASSporT signed by an SPC-level certificate
to contain an "mky" field with keying material generated by an end-
user device. While this introduces certain security risks (see the
Security Considerations), it provides a means to integrate STIR as
commonly deployed today with MLS.
Note that PASSporTs as traditionally used by STIR have a short
expiry, typically less than one minute, in order to prevent replay.
Sessions negotiateed by SIP that use PASSporTs only check their
validity at session initiation, even if the session itself is long-
lived. With the use of "mky", however, the risk of a success replay
attack is significantly mitigated, and it is safer to use longer
expiry timers. PASSporTs created for use with MLS MUST contain an
"mky" element.
4.1. MLS PASSporT Credential Structure Definitions
struct {
// Certificate chain, where Certificate is defined in RFC 9420 (and the same
// ordering requirements apply), and certificates are in the form defined by
// RFC 8226 / RFC 9060. The subjectPublicKey of the first certificate MUST
// verify the signature on the object in the passport field.
Certificate certificates<V>;
// A PASSporT encoded as a byte string, signed by the first certificate in the
// `certificates` vector. The PASSporT MUST have an "mky" claim, which MUST
// match the signature_key field in the enclosing LeafNode.
opaque passport<V>;
} STIRPASSporTCredential;
5. Interaction with MIMI
The use of telephone numbers as identities is a component of the More
Instant Messaging Interoperability (MIMI) effort
[I-D.mahy-mimi-identity]. The potential applicability of traditional
STIR certificates described in Section 3 to that effort is largely in
the "consumer operator aligned" category of messaging providers (per
[I-D.rosenberg-mimi-discovery-reqs]). There are however a variety of
ways that non-carrier entities such as enterprises can acquire STIR
credentials, including via delegate certificates ([RFC9060]).
For consumer OTT services, an alternative credential system would be
needed, as the platforms that use telephone numbers in those systems
are (typically) not affiliated with carriers.
Peterson & Barnes Expires 5 September 2024 [Page 5]
Internet-Draft STIR MLS March 2024
6. MLS Group Messaging with STIR
TBD.
7. Acknowledgments
8. IANA Considerations
TBD.
9. Privacy Considerations
TBD.
10. Security Considerations
This specification inherits the security considerations of [RFC9475].
The use of PASSporTs as MLS Credentials signed with SPC-level STIR
certificates creates a potential key substitution attack where a
rogue service provider injects its own "mky" value before signing the
PASSporT. MLS applications would need some out-of-band way to check
the epoch authenticator in order to detect this substitution.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Peterson & Barnes Expires 5 September 2024 [Page 6]
Internet-Draft STIR MLS March 2024
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>.
[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
September 2021, <https://www.rfc-editor.org/info/rfc9060>.
[RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
Omara, E., and K. Cohn-Gordon, "The Messaging Layer
Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
July 2023, <https://www.rfc-editor.org/info/rfc9420>.
[RFC9475] Peterson, J. and C. Wendt, "Messaging Use Cases and
Extensions for Secure Telephone Identity Revisited
(STIR)", RFC 9475, DOI 10.17487/RFC9475, December 2023,
<https://www.rfc-editor.org/info/rfc9475>.
11.2. Informative References
[I-D.mahy-mimi-identity]
Mahy, R., "More Instant Messaging Interoperability (MIMI)
Identity Concepts", Work in Progress, Internet-Draft,
draft-mahy-mimi-identity-02, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-mahy-mimi-
identity-02>.
[I-D.rosenberg-mimi-discovery-reqs]
Rosenberg, J., "MIMI Discovery Requirements and
Considerations", Work in Progress, Internet-Draft, draft-
rosenberg-mimi-discovery-reqs-00, 27 August 2023,
<https://datatracker.ietf.org/doc/html/draft-rosenberg-
mimi-discovery-reqs-00>.
Peterson & Barnes Expires 5 September 2024 [Page 7]
Internet-Draft STIR MLS March 2024
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>.
[RFC8862] Peterson, J., Barnes, R., and R. Housley, "Best Practices
for Securing RTP Media Signaled with SIP", BCP 228,
RFC 8862, DOI 10.17487/RFC8862, January 2021,
<https://www.rfc-editor.org/info/rfc8862>.
Authors' Addresses
Jon Peterson
TransUnion
Email: jon.peterson@transunion.com
Richard Barnes
Cisco
Email: rlb@ipv.sx
Peterson & Barnes Expires 5 September 2024 [Page 8]