MOQ C. Jennings Internet-Draft R. L. Barnes Intended status: Informational S. Nandakumar Expires: 4 September 2024 Cisco 3 March 2024 Secure Group Key Agreement with MLS over MoQ draft-jennings-moq-e2ee-mls-latest Abstract TODO Abstract About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://suhashere.github.io/moq-e2ee-mls. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- jennings-moq-e2ee-mls/. Discussion of this document takes place on the Media over QUIC Working Group mailing list (mailto:moq@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at https://www.ietf.org/mailman/listinfo/moq/. Source for this draft and an issue tracker can be found at https://github.com/suhasHere/moq-e2ee-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 4 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 1. Introduction 2. Conventions and Definitions 3. MLS Overview 3.1. Critical Invariants 4. MLS and MOQ 4.1. Bootstrapping MLS Session 4.2. Joining to MLS Group 4.3. Processing the Welcome Message 4.4. Removing from the group 4.5. Processing the MLS Commit Messages 5. MLS MoQ Tracks 5.1. KeyPackage 5.2. Welcome 5.3. Commit 6. Centralized Lock Service 7. Interactions with MOQ Secure Objects 8. Security Considerations 9. IANA Considerations 10. Normative References Acknowledgments Authors' Addresses 1. Introduction TODO Introduction 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. MLS Overview MLS protocol provides continuous group authenticated key exchange. MLS provides several important security properties * Group Key Exchange: All members of the group at a given time know a secret key that is inaccessible to parties outside the group. * Authentication of group members: Each member of the group can authenticate the other members of the group. * Group Agreement: The members of the group all agree on the identities of the participants in the group. * Forward Secrecy: There are protocol events such that if a member's state is compromised after the event, group secrets created before the event are safe. * Post-compromise Security: There are protocol events such that if a member's state is compromised before the event, the group secrets created after the event are safe. At a very high level, MLS protocol operates by participants sending proposals to add/remove/update the group state and an active member of the group commit the proposals to move the group’s cryptographic state from one epoch to the next. In order to setup end to end encryption of media delivered over MOQT delivery network, producders and consumers participate in the MLS exchange to setup group secret through which are used to derived the keys needed for encrypting the media/data published by the members of the MLS group. Below figure captures a typical setup for clients to participate in the MLS protocol, with Delivery Service (DS) acting as the rendezvous point. In the example setting, participants A, B and C involve in protocol exchange to setup end to end encrypted session keyed via MLS. TODO: Add a simple call-flow here 3.1. Critical Invariants * Only one group is created per moq session * Linear sequence of Commits - Each Commit has exactly one successor 4. MLS and MOQ Unit of MLS functionality is a group, where at any given time, a group represents a secret known only to its members. Membership to the group can change over time. Each time membership changes (batch of joins or leaves), the shared secret is changed to one known only by the current members. Each period of time with stable membership/ secret is an epoch 4.1. Bootstrapping MLS Session As part of bootstrapping a MLS Session, each MOQT endpoint needs to perform following 2 actions: 1. Subscribe to MOQT track for processing MLS KeyPackages (see mls- tracks) for processing addition of new members to the group. 2. Publishing their MLS keypackages identifying the credentials to the "keypackage" track 4.2. Joining to MLS Group Adding or joining an MLS group requires one of the following: 1. A way for boostrapping the group when the first member joins. 2. A way to choose an existing member to add a new member. In order to realize the above functionalities and ensure the criticial invariants, a centralized lock service is required to help resolve contention. Participants intending to join try to acquire lock to create/join the group. If the lock can be successfully acquired and the response indicates "Create", the participant is the first participant and he creates the group unilaterally and generate the initial secret. Then the pariticipant release the "crate_or_join" lock. Alternately, if the repsonse indicate "Join", then the participant awaits for an e existing member to process the request to join the group. When an existing member receives KeyPackage, the process of adding the new member is as follows: 1. Acquire lock to commit to the group for a given epoch 2. If lock acquired sucessfully, process the keyPackage for duplicates/error, create MLS Welcome and Commit messages, publish them to the "Welcome" and "Commit" tracks for the MLS Group and the epoch. See Section 5 for further details on the tracks. 3. If lock cannot be acquired due to conflict for a given epoch, retry after a confgured timeout. One of the 2 things might happen: * Another member was able to successfuly perform group update for the current epoch, in which case it is recommended for the member to process MLS messages before retrying the operation again for the same epoch to ensure the group updates are already what the member wants. * Another member updated the group state with commits that are different from the member attempting to obtain the lock. In such a scenario, the member needs to wait to process the commits in transit and retry step 1 for the next right epoch in the sequence 4.3. Processing the Welcome Message Participants await MLS Welcome message after publishing their Keypackage to join the group. They do so by subscribing to the "Welcome" track. On receipt of the Welcome message, local MLS state is updated with the recevied Welcome message to obtain the group secret for the current epoch. If the participant is already a member of the group, the Welcome message is dropped/ignored. 4.4. Removing from the group TODO: Add details 4.5. Processing the MLS Commit Messages All the participants subscribe to "Commit" track for a given MLS group. This allows them to process MLS commit messages being published under the following group update operations * Add a new member * Remove an existing member TODO: SHOULD we even support other updates ? 5. MLS MoQ Tracks For all the various tracks: * The TrackNamespace is scoped to the combination of MLS Group and MLS operation. The MLS group name chosen should be unique within a MOQ relay network. TrackNamespace := | * TrackName identifies the sender performing the operation. The value chosen for sender MUST be unique within a MOQ application. TODO: add notes on ways to choose the sender 5.1. KeyPackage Subscribe happens on the track namespce TrackNamespace := mls-group | "keypackage" and and publishes happens on the FullTrackName := mls-group | "keypackage" | sender-id There is one MOQT group and objects within that group identify different updates of the KeyPackage with objectId of 0 being sent at the time of joining a MLS group 5.2. Welcome Subscribes happens on the on the track namespce TrackNamespace := mls-group | "welcome" and Publish happens on ~~~ FullTrackName := mls-group | "welcome" | sender-id ~~~ There is one MOQT group per MLS epoch and objectId 0 carries the MLS Welcome message. 5.3. Commit Subscribe happens on the namespace TrackNamespace := mls-group | "commit" and Publishes happens on ~~~~ FullTrackName := mls-group | "commit" | sender-id ~~~~ There is one MOQT group per MLS epoch and objectId 0 carries the MLS Commit message. 6. Centralized Lock Service TODO: Define API for the lock service 7. Interactions with MOQ Secure Objects TODO: Describe epoch secret -> track_base_key 8. Security Considerations TODO Security 9. IANA Considerations This document has no IANA actions. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Acknowledgments TODO acknowledge. Authors' Addresses Cullen Jennings Cisco Email: fluffy@cisco.com Richard L. Barnes Cisco Email: rlb@ipv.sx Suhas Nandakumar Cisco Email: snandaku@cisco.com