Per-group Credential Anchors for Message Layer Security (MLS)

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 14 September 2023.¶

Copyright Notice

Copyright (c) 2023 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

1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2219].¶

The terms MLS client, MLS group, LeafNode, GroupContext, KeyPackage, GroupContextExtensions Proposal, Credential, CredentialType, and RequiredCapabilities have the same meanings as in the MLS protocol [I-D.ietf-mls-protocol].¶

2. Introduction

A typical desktop or mobile operating system may have hundreds of root certificates configured. Not all of these certificates are appropriate to make identity assertions about every domain which participates in a federated MLS group. The members of a federated group should be able to restrict the specific trust anchors expected, on a per-domain basis. The root of the trust anchor still needs to be among the operating system or application trusted root certificates.¶

In addition, this extension allows the domain validation to be restricted to an intermediary certificate which is anchored in one of the trusted root certificates. For example, the domain example.com might use the Certificate Authority "Large Commercial Certificate Authority LLC" as the root for its domain certificates, but only the intermediate certificate ca.messaging.example.com actually makes assertions about MLS identities for that domain.¶

While this extension initially only specifies behavior for X.509 certificates and the x509 credential type in MLS, other credential types with strong cryptographic verification, such as VerifiableCredentials, could extend this extension to include the relevant notion of trust anchors.¶

3. Example Use

Consider an MLS group containing MLS clients from three domains: alpha.example, beta.example, and charlie.example. All three use compatible MLS-based instant messaging services which are federated [I-D.ietf-mls-federation].¶

• alpha.example is a very large company or national government with their own root certificate authority which is already present in most operating systems.¶
• beta.example is a large company which uses certificate authority yankee.example.¶
• charlie.example is a small organization whose service is hosted by a cloud provider cirrus.example. Their certificates (both charlie and cirrus) are issued by the certificate authority zulu.example.¶

Alice is a user on alpha.example, and creates a private federated MLS group, inviting Andy (from alpha.example), Bob and Betty (from beta.example), and Cathy and Chuck (from charlie.example). Every client in the group would like to verify the identities of the other clients. If alpha.example is compromised, we don't want an attacker to be able to impersonate Bob, Betty, Cathy, or Chuck without detection. Likewise if yankee.example is compromised, we don't want an attacker to be able to impersonate Alice, Andy, Cathy, or Chuck without detection.¶

With this extension, the clients in an MLS group maintain a list of identity domains and each of their corresponding trust anchors. This does not replace the operating system or application trusted root certificates, it just associates a specific domain with a specific trust anchor.¶

4. Extension Description

This document specifies a GroupContext MLS extension group_trust_anchors of type PerDomainTrustAnchors. The syntax is described using the TLS Presentation Language [RFC8446].¶

Each PerDomainTrustAnchor represents a specific identity domain which is expected and authorized to participate in the MLS group. It contains the domain name and the specific trust anchor used to validate identities for members in that domain.¶

struct {
    opaque domain_name<V>;
    CredentialType credential_type;
    select (Credential.credential_type) {
        case x509:
            Certificate chain<V>;
    };
} PerDomainTrustAnchor;

struct {
    PerDomainTrustAnchor domain_anchors<V>;
} PerDomainTrustAnchors;

PerDomainTrustAnchors group_trust_anchors;

An MLS client which implements this specification SHOULD include the group_trust_achors extension in the extensions field in the GroupContext of groups it creates. It includes the per-domain trust anchors for all the domains expected and authorized to participate in the group. As new members of the group are added or removed, the member which Commits these membership changes is expected to maintain the list of trust roots up-to-date by also including an appropriate GroupContextExtensions Proposal any time the list of expected federated domains changes. Likewise, when any of the trust anchors used in a domain changes, an appropriate member needs to Commit a GroupContextExtensions Proposal updating the list of trust roots.¶

5. IANA Considerations

This document proposes registration of a new MLS Extension Type.¶

RFC EDITOR: Please replace XXXX throughout with the RFC number assigned to this document¶

  Template:
  Value: 0x000A
  Name: group_trust_anchors
  Message(s): This extension may appear in GroupContext objects
  Recommended: Y
  Reference: RFC XXXX

6. Security Considerations

The Security Considerations of MLS apply.¶

Improper use of the extension in this document could allow the creator of an MLS group or the sender of a GroupContextExtensions Proposal to maliciously add or remove authorized domains from a group, and to impersonate members from specific domains. Therefore it is vital that all clients which implement this extension validate that changes to their own domain trust anchors conform to their domain policies.¶

Author's Address