Secure Telephone Identity for Message Layer Security

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.¶

Table of Contents

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.¶

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.¶

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.¶

Authors' Addresses