Internet-Draft STIR MLS March 2024
Peterson & Barnes Expires 5 September 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-peterson-stir-mls-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Peterson
TransUnion
R. Barnes
Cisco

Secure Telephone Identity for Message Layer Security

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.

Table of Contents

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.

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.

[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!].

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.

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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8174>.
[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, , <https://www.rfc-editor.org/info/rfc8224>.
[RFC8225]
Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, , <https://www.rfc-editor.org/info/rfc8225>.
[RFC8226]
Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, , <https://www.rfc-editor.org/info/rfc8226>.
[RFC9060]
Peterson, J., "Secure Telephone Identity Revisited (STIR) Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, , <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, , <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, , <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, , <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, , <https://datatracker.ietf.org/doc/html/draft-rosenberg-mimi-discovery-reqs-00>.
[RFC7340]
Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, , <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, , <https://www.rfc-editor.org/info/rfc8862>.

Authors' Addresses

Jon Peterson
TransUnion
Richard Barnes
Cisco