]> Cisco

rlb@ipv.sx

Wire

rohan.mahy@wire.com

Applications and Real-Time More Instant Messaging Interoperability end to end security identity End-to-end (E2E) security is a critical property for modern user communications systems. E2E security protects users' communications from tampering or inspection by intermediaries that are involved in delivering those communcations from one logical endpoint to another. In addition to the much-discussed E2E encryption systems, true E2E security requires an identity mechanism that prevents the communications provider from impersonating participants in a session, as a way to gain access to the session. This document describes a high-level architecture for E2E identity, identifying the critical mechanisms that need to be specified. About This Document Status information for this document may be found at . Discussion of this document takes place on the More Instant Messaging Interoperability Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction End-to-end (E2E) security protects users' communications from tampering or inspection by intermediaries that are involved in delivering those communcations from one logical endpoint to another. Almost all user-to-user communications systems today involve application-level intermediaries, such as message queues or media servers. In this context, "hop-by-hop" security refers to the security properties of the channel between the client and application-level intermediary, despite the fact that this channel may transit a number of network-level intermediaries. "End-to-end" security refers to security properties of the communications between one end client and another. Given the ubiquity of application-level intermediation, E2E security is a critical property for modern user communications systems. E2E security is typically implemented with two separate mechanisms:

• E2E encryption, which establishes keys among a group of communicating clients, and authenticates them at a cryptographic level, and
• E2E identity, which associates non-cryptographic attributes to the cryptographic representation of clients in the E2E encryption protocol.

Broadly speaking, E2E encryption protects against passive attacks by intermediaries. E2E identity protects against active attacks such as impersonation attacks. Both layers are required to attain a complete notion of E2E security. An overview of identity considerations for messaging systems is provided in . In this document, we describe a concrete framework for E2E identity, drawing on some initial deployment experience, and highlighting the mechanisms that need to be defined for an interoperable solution.

Conventions and Definitions 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. We use the following terms below:

Client:

The hardware or software used by a user to interact with an E2E-secure communications system.

Communications provider:

The system of intermediaries that connects communicating clients.

Identity authority:

An entity that is trusted to make statements about the identity attributes associated to clients.

Session:

An E2E-secure interaction among clients, e.g., an MLS group

Credential:

An object issued by an identity authority that associates identity attributes with a client's public key.

Operational Context and Assumptions The context in which E2E identity is implement is shown in . It involves the following actors:

• A number of clients participating in an E2E-encrypted session
  • A presenting client that is claiming to represent certain identity attributes
  • Verifying clients that authenticate the claimed identity attributes
• One or more communications providers that facilitates communications among the clients
• An identity authority that asserts identity attributes of the presenting client, and which is trusted by the verifying client to make such assertions

Note that in most settings, each client will act as both a presenting client and a verifying client, authenticating itself and verifying the other clients in the session or group. Each client could use a different identity authority for its identity attributes. We assume that the E2E encryption for the session is provided by means of an E2E encryption protocol such as DoubleRatchet or MLS , in which each participant is cryptographically authenticated by means of a digital signature key pair. The phrase "identity attributes" above is deliberately broad, to encompass any attribute of the client that is not directly cryptographcally verifiable. This includes technical identifiers such as DNS names or URLs, but also user-meaningful identifers such as given or family names, or names of organizations or roles.

Operational context for E2E identity | Client | | +-----------+ +----------------+ | +------------+ | Communications | | +-----------+ | Presenting | | Provider(s) | | | Verifying | | Client +-----------------------------+--->| Client | +-----+------+ | | +-----+-----+ | +----------------+ | | | | | | +-----------+ | +------------------+ Identity +----------------+ | Authority | +-----------+ ]]>

In this context, the goal of E2E identity is to protect the authenticity of the binding between the presenting client's public key (which represents them in the E2E encryption protocol) and their identity attributes, against attack by the communications provider. Only a client that legitimately represents the claimed attributes should be able to cause a verifying client to associate those attributes with the first client. More succinctly, E2E identity protects against impersonation attacks by the communications provider. The architecture described here achieves this protection by means of role separation between communications provider and the identity authority. The communications provider is untrusted, in the same way that network attackers are untrusted in the traditional Internet Threat Model . The identity authority is trusted to correctly assert bindings between identity attributes and public keys. This includes verifying that presenting clients control the corresponding public keys, to avoid Unknown Key Share attacks analogous to those in . There are other techniques that can reduce the trust that is placed in the identity authority, for example CONIKS or various self-sovereign identity approaches. These approaches have not been deployed at scale in the same way authority-based approaches have, and they can be layered on top of a authority-based scheme. (Certificate Transparency was deployed many years after the Web PKI ). Thus this document focuses on an authority-based system for E2E identity, as a baseline to which these other approaches might later be added. A secondary goal is to minimize the amount of information about the clients and sessions that is exposed to the identity authority. The identity authority should not learn which communications providers or verifying clients a presenting client is interacting with. Verifying clients use ultimately authenticated identity attributes to make policy decisions as to the security state of the meeting. For example, a verifying client may have attempted to reach the holder of the SIP URI sip:bob@exmaple.com, and would regard the session as compromised if they were not actually connected to that entity. Or a verifying client might wish to require that all participants in a session belong to a given organization. E2E identity assures that these policies are evaluated on correct inputs.

An Architecture for E2E Identity shows the three critical steps in a system E2E identity:

1. Issuance: An identity authority provides the presenting client with a credential associating identity attributes to a public key.
2. Presentation: The presenting client provides its credential to the verifying client, along with proof that the presenting client controls the corresponding private key.
3. Verification: The verifying client verifies that the credential was issued by a trusted identity authority, and verifies the presenting clients proof of control of the corresponding private key. The verifying client may verify by communicating with the identity authority, or autonomously using previously configured information about the identity authority.

If all three of these steps is successfully completed, with the security properties described below, then the verifying client can safely associate the identity attributes in the credential with the presenting client.

A three-step process for assuring E2E identity | Client | +-----+------+ +-----+-----+ ^ ^ | | | | | +-----------+ | +------------------+ Identity +<---------------+ 1. Issuance | Authority | 3. Verification +-----------+ ]]>

Issuance The issuance process is similar to existing widely-deployed processes for issuing public-key credentials, such as ACME . This process results in the presenting client holding a credential that associates a public key to a set of identity attributes. So the issuance process must assure the identity authority of two things about the presenting client:

• That it controls the private key corresponding to the public key
• That it legitimately represents the identity attributes

In addition, to prevent unknown key share attacks (UKS), the issuance process must verify these properties jointly -- that the entity that controls the private key is the same as the entity that holds the identity attributes. These assurances are typically provided by having the presenting client create a signature with the private key over an object that reflects the identity attributes. In ACME, the client sends a Certificate Signing Request , which contains both the desired identity attributes and a signature by the client's private key.

Presentation The presentation process accomplishes two things:

• It conveys the presenting client's credential to the verifying client.
• It proves to the verifying client that the presenting client holds the corresponding private key.

The latter function ties the presentation process to the E2E encryption protocol being used. The credential used for E2E identity authenticates the key pair that represents a client in the E2E encryption protocol. The E2E encryption protocol will thus already include mechanisms for the presenting client to prove they hold the private key corresponding to the credential. If the E2E encryption protocol can also deliver the credential (as opposed to passing it in some other way), then in addition to simplifying application architecture, the E2E encryption protocol can provide some additional security benefits. E2E encryption protocols where the presenting client signs the credential being presented are generally immune to unknown key share attacks, even if there is a UKS vulnerability in the underlying issuance process. As a concrete example: In the MLS protocol mentioned above, each client presents its credential in a LeafNode structure that is signed with the client's private key. This structure is conveyed to the other participants in an MLS-based session when the presenting client joins the session. This provides the other participants with both the credential and a signature over the credential (and the other contents of the LeafNode) which acts as a proof of possession of the private key.

Verification A credential will typically be an object signed by the identity authority, so the verifying client will only need to know the identity authority's public key in order to verify that the credential was authentically issued by the identity authority. Credentials will typically also have some notion of expiration, e.g., the notBefore/notAfter fields in X.509 or the nbf/exp fields in JWT . Verification at this level is simple, fast, and privacy-preserving. In some cases, though, it is necessary to have a notion of revocation of credentials. Here revocation of a credential means that the credential will no longer be accepted by verifying clients, even though the credential itself is otherwise valid (e.g., its signature is valid and it has not expired). Since the credential itself cannot reflect revocation information, a verifying client needs to get revocation information from the identity authority independently. Several design patterns for revocation have been explored in the PKI context:

1. Short-lived certificates with no revocation checking
2. Online Certificate Status Protocol (OCSP) checks by clients
3. OCSP stapling and the "TLS Feature" extension
4. Certificate Revocation Lists (CRLs) fetched by clients
5. CRLs fetched by vendors and redistributed to clients

The Web PKI has generally settled on central CRL fetching (5), by the following process of elimination:

• Short-lived certificates are unacceptable in settings where clients might be offline for longer than the revocation checking interval.
• OCSP has bad performance properties and leaks lots of information to the identity authority.
• OCSP stapling with the "must-staple" extension is equivalent to short-lived certificates.
• CRL fetches by clients are either highly inefficient or require complicated caching schemes that are better done centrally.

These design patterns and arguments also apply, mutatis mutandis, in the context of E2E identity. Thus, revocation mechanisms developed for E2E identity should be oriented toward centralized CRL fetching, but accounting for an important difference -- that the client vendor is often the communications service provider, and thus an untrusted actor. This means that clients will need to verify the authenticity of revocation information, and mechanisms such as CRLite will not work. Rather than having the vendor compress an uncompressed representation (as in CRLite), the revocation data provided by the identity authority will have to already be compact.

Instantiations There are a few deployed and emerging models for E2E identity that can be viewed as instantiations of the above architecture. In this section, we examine a few example cases.

Manual Verification of Key Fingerprints E2E-encrypted messaging apps used by billions of users today rely on users manually comparing each others' key fingerprints for their only E2E identity assurance. This can be viewed as a degenerate case of the above architecture:

• The credential is only the presenting client's public key, without identity attributes.
• Each user acts as their own identity authority.
• Issuance is done by the user's client generating a key pair.
• Presentation comprises the E2E encryption protocol's proof of possession of the presenting client's private key.
• Verification is the manual comparison of key fingerprints, the user of the verifying client confirming with the user of the presenting client that they have the same view of the presenting client's public key.

This case is degenerate in the sense that it does not actually authenticate any identity attributes; the only non-cryptographic attributes attested are those claimed by the presenting client in the verification interaction. This system is thus vulnerable to UKS attacks when the user of the presenting client abuses their position as a trusted identity authority .

X.509 X.509 and related PKI technologies are a widely used instantiation of authority-based authentication, and map naturally in to this architecture:

• The credentials are certificates.
• The identity authorities are certificate authorities (CAs).
• Issuance is done via issuance protocols such as ACME or EST .
• Several key exchange protocols contain the required mechanics for presentation, e.g., the X509Credential mechanism in MLS.
• Verification follows the process in , with revocation checking done via one of the several mechanisms discussed in .

This scheme works well for cases where a PKI is available with authorities that will attest to the required idenitty attributes, and where the operational context allows for certificates to be provisioned to clients. Multiple E2E-secure communications products today use this scheme.

Verifiable Credentials Certificates and PKI protocols tend to be a bad fit for authenticating user identities. Systems like SAML and OpenID Connect are more commonly used for user identity, but only produce bearer tokens, not the public key credentials required for E2E identity -- using bearer tokens for E2E identity would allow the verifying client to impersonate the presenting client! Likewise, because the verifier needs to check a bearer tokens validity directly with the issuer, the identity authority learns every verifier to whom a client authenticates. More recently, there has been work to apply the W3C Verifiable Credentials (VC) framework to this problem . The VC model aligns well conceptually with the above architecture, and some of the required protocols are in development:

• Credentials would be verifiable credentials or verifiable presentations.
• The identity authorities would be Issuers in the VC model. (Likewise, the presenting client would be a Holder and the verifying client a Verifier.)
• The issuance process here corresponds to the issuance interaction in the VC model, for example using OpenID for Verifiable Credential Issuance
• The presentation process here corresponds to the presentation interaction in the VC model, for example using an integration with the E2E encryption protocol analogous to the X509Credential integration in MLS mentioned above.
• The verification process here corresponds to VC verification, using a mechanism such as for revocation.

A VC-based model for E2E identity is clearly still incomplete, but given the good conceptual alignment and potential for a better fit with user identity than PKI, it seems like a promising candidate for further development.

Requirements for Interoperable Identity The MIMI working group is focused on establishing interoperability among messaging systems. In order to have E2E identity protections in an interoperable context, the interoperating parties will need to agree on the answers to a few questions:

• What E2E encryption protocol is being used?
• How are credentials integrated with the E2E encryption protocol?
  • How is a credential verified against a participant public key?
  • What mechanisms for revocation are used (if any)?
  • How are credentials associated to the encryption protocol?
• What types of credentials are clients expected to be able to verify?
• Which identity providers are trusted?

Most of these questions are addressed at the presentation and verification phases in the above architecture. The interoperability considerations around issuance are different: For issuance, there does not need to be a common solution across the population of clients, only between a client and the authority that issues its credential. Nonetheless, having a common, interoperable issuance interface is still valuable, since it simplifies integration between clients and authorities.

Security Considerations This document describes a scheme for authentication in E2E security contexts. Security requirements are described in , a general architecture in , and some candidate instantiations of the architecture in .

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References n.d. n.d. n.d. n.d. Wire This document discusses concepts in instant messaging identity interoperability when using end-to-end encryption, for example with the MLS (Message Layer Security) Protocol. The goal is to explore the problem space in preparation for framework and requirements documents. Cisco Inria & Mozilla Phoenix R&D Meta Platforms Google University of Oxford Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP). Similar attacks are described on the use of DTLS-SRTP with the identity bindings used in Web Real-Time Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be misled about the identity of a communicating peer. This document defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK] An old version; see RFC 638. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.