MLS R. Mahy Internet-Draft Wire Intended status: Informational 13 March 2023 Expires: 14 September 2023 Per-group Credential Anchors for Message Layer Security (MLS) draft-mahy-mls-group-anchors-00 Abstract This document describes a Message Layer Security (MLS) GroupContext extension to restrict the set of trust anchors used for identity validation in MLS groups. It is useful in federated or interoperability environments to allow a specific federated domain to assert identities for its own identifiers but not for the identifiers of other domains. 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. Mahy Expires 14 September 2023 [Page 1] Internet-Draft MLS Group Credential Anchors March 2023 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Example Use . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Extension Description . . . . . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5.1. group_trust_anchors MLS Extension Type . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 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. Mahy Expires 14 September 2023 [Page 2] Internet-Draft MLS Group Credential Anchors March 2023 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. Mahy Expires 14 September 2023 [Page 3] Internet-Draft MLS Group Credential Anchors March 2023 struct { opaque domain_name; CredentialType credential_type; select (Credential.credential_type) { case x509: Certificate chain; }; } PerDomainTrustAnchor; struct { PerDomainTrustAnchor domain_anchors; } 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 5.1. group_trust_anchors MLS Extension Type The group_trust_anchors MLS Extension Type is used inside GroupContext objects. It contains a PerDomainTrustAnchors object representing the trust anchors which are expected for identity validation inside the MLS group. Template: Value: 0x000A Name: group_trust_anchors Message(s): This extension may appear in GroupContext objects Recommended: Y Reference: RFC XXXX Mahy Expires 14 September 2023 [Page 4] Internet-Draft MLS Group Credential Anchors March 2023 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. 7. Normative References [I-D.ietf-mls-protocol] Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", Work in Progress, Internet- Draft, draft-ietf-mls-protocol-18, 13 March 2023, . [RFC2219] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, DOI 10.17487/RFC2219, October 1997, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Author's Address Rohan Mahy Wire Email: rohan.mahy@wire.com Mahy Expires 14 September 2023 [Page 5]