Secure Telephone Identity for Message Layer Security

The STIR problem statement 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, it is necessary for these protocols to support stronger identity mechanisms to prevent impersonation. defines a SIP Identity header capable of carrying PASSporT 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. 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 , both for signing individual messages with STIR and securing message streams negotiated by SIP. Message Layer Security (MLS) 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 certificates to MLS, and how both service-provider level certificates and delegate certificates 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 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.

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 when, and only when, they appear in all capitals, as shown here.

MLS already specifies the use of X.509 certificates as an MLS Credential Type. The guidance in 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. 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. 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 . 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 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.

; } STIRCertificateCredential; ]]>

Instead of using a STIR certificate, implementations may also use a STIR PASSporT 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.

; // 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; } STIRPASSporTCredential; ]]>

The use of telephone numbers as identities is a component of the More Instant Messaging Interoperability (MIMI) effort . The potential applicability of traditional STIR certificates described in to that effort is largely in the "consumer operator aligned" category of messaging providers (per ). There are however a variety of ways that non-carrier entities such as enterprises can acquire STIR credentials, including via delegate certificates (). 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.

TBD.

This specification inherits the security considerations of . 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.