< draft-ietf-mls-federation-00.txt   draft-ietf-mls-federation-01.txt >
Network Working Group E. Omara Network Working Group E. Omara
Internet-Draft Google Internet-Draft Google
Intended status: Informational R. Robert Intended status: Informational R. Robert
Expires: March 14, 2020 Wire Expires: 20 November 2022 19 May 2022
September 11, 2019
The Messaging Layer Security (MLS) Federation The Messaging Layer Security (MLS) Federation
draft-ietf-mls-federation-00 draft-ietf-mls-federation-01
Abstract Abstract
This document describes how the Messaging Layer Security (MLS) can be This document describes how the Messaging Layer Security (MLS)
used in a federated environment where different MLS implementations protocol can be used in a federated environment.
can interoperate by defining the message format for user key
retrieval. The document also describes some use cases where Discussion Venues
federation could be useful.
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/mlswg/mls-federation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 14, 2020. This Internet-Draft will expire on 20 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Federated environments . . . . . . . . . . . . . . . . . . . 2
3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Delivery Services . . . . . . . . . . . . . . . . . . . . 3
3.1. Different Delivery Servers . . . . . . . . . . . . . . . 4 2.1.1. Different client applications . . . . . . . . . . . . 3
3.2. Different client applications . . . . . . . . . . . . . . 4 2.1.2. Different Delivery Services . . . . . . . . . . . . . 3
4. Functional Requirements . . . . . . . . . . . . . . . . . . . 4 2.2. Authentication Service . . . . . . . . . . . . . . . . . 4
4.1. Delivery service . . . . . . . . . . . . . . . . . . . . 4 3. Further considerations . . . . . . . . . . . . . . . . . . . 4
4.1.1. Client fanout . . . . . . . . . . . . . . . . . . . . 5 3.1. Network protocol between different domains . . . . . . . 4
4.1.2. Server fanout . . . . . . . . . . . . . . . . . . . . 5 4. Discovery service for clients/users on a specific domain . . 5
4.2. Authentication service . . . . . . . . . . . . . . . . . 6 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Message format . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Different Delivery Servers . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5.2. Different client applications . . . . . . . . . . . . . . 5
6.1. Version negotiation . . . . . . . . . . . . . . . . . . . 7 6. Functional Requirements . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6.1. Delivery service . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Authentication Service . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8 7.1. Version & ciphersuite negotiation . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
MLS Architecture draft [MLSARCH] describes the overall MLS system MLS Architecture draft [I-D.ietf-mls-architecture] describes the
architecture assuming the client and servers (Delivery Service and overall MLS system architecture, assuming the client and servers
Authentication Service) are operated by the same entity. This (Delivery Service and Authentication Service) are operated by the
document describes the minimum changes needed to allow different MLS same entity. This is however not a strict requirement, the MLS
clients operated by the same or different entities to communicate protocol does not have an inherent dependency on one single entity
with each and explaining The use cases where federation could be and can instead be used between multiple entities.
useful.
The focus of this document will be the interaction between the client The focus of this document is on the different components of the MLS
and the Delivery Service, specifically how the client retrieves the architecture when used in a federated environment.
identityKey and InitKeys for another client. There is no changes
needed for the Authentication Service.
Discovering which Delivery service the client communicates with is 2. Federated environments
out of the scope of this document.
The below diagram shows an MLS group where all clients are operated Federated environments are environments where multiple entities are
under the same deliver service: operating independent MLS services. In particular, the assumption is
that Delivery Services and Authentication Services are not
necessarily operated by the same entity.
Entities operating independent MLS services are commonly called
domains. In most cases these domains might correspond to the Domain
Name System, but it is not strictly required. Operating MLS services
in a federated environment can therefore be regarded as federation
between different domains.
Federation is however not limited to the MLS services themselves.
For example, a federated environment could also contain clients that
are provided by different entities. Specifically, different vendors
could provide different applications that differ in scope and
functionality but are interoperable.
2.1. Delivery Services
Depending on the kind of federated environment, the two following
types of federated Delivery Services are possible:
2.1.1. Different client applications
The diagram below shows an MLS group where all clients are provided
by potentially different vendors but operate on the same Delivery
Service:
+------------+ +------------+
+ Delivery + + Delivery +
+ Service (DS) + + Service (DS) +
+-----+------+ +-----+------+
/ + \ Group / + \ Group
********************************************************* *********************************************************
* / + \ * * / + \ *
* / | \ * * / | \ *
* +--------+ +----+---+ +--------+ * * +--------+ +----+---+ +--------+ *
* + Client 0 + + Client 1 + + Client 3 + * * + Client 0 + + Client 1 + + Client 3 + *
* +--------+ +--------+ +--------+ * * +--------+ +--------+ +--------+ *
* ............................. ............ * * ............................. ............ *
* User 0 User 1 * * User 0 User 1 *
* * * *
********************************************************* *********************************************************
one possible environment is to have different client implementations 2.1.2. Different Delivery Services
operated by the same delivery service, which will look like the
diagram above, another environment is to have different or same The diagram below shows a federated environment in which different or
clients operated By different delivery services: identical clients applications operate on different Delivery
Services:
+-----------------+ +-----------------+ +-----------------+ +-----------------+
+ Deliver Service 1 + + Deliver Service 2 + + Deliver Service 1 + + Deliver Service 2 +
+ + + + + + + +
+-----------------+ +--------+--------+ +-----------------+ +--------+--------+
| | | | | |
| | | Group | | | Group
***************|*********|*******************|*********** ***************|*********|*******************|***********
* | | | * * | | | *
* | | | * * | | | *
* +--------+ +--------+ +--------+ * * +--------+ +--------+ +--------+ *
* + Client 0 + + Client 1 + + Client 3 + * * + Client 0 + + Client 1 + + Client 3 + *
* +--------+ +--------+ +--------+ * * +--------+ +--------+ +--------+ *
* ............................. ............ * * ............................. ............ *
* User 0 User 1 * * User 0 User 1 *
* * * *
********************************************************* *********************************************************
2. Terminology 2.2. Authentication Service
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.
Client: An agent that uses this protocol to establish shared
cryptographic state with other clients. A client is defined by
the cryptographic keys it holds. An application or user may use
one client per device (keeping keys local to each device) or sync
keys among a user's devices so that each user appears as a single
client.
User Init Key: A short-lived HPKE key pair used to introduce a new In a federated environment, authentication becomes more important.
client to a group. Initialization keys are published for each While the sepcifics of an Authentication Service are out-of-scope for
client (UserInitKey). MLS in general, it is important that strong authentication is
accessible to all clients of a federated environment. As an example,
a shared transparency log like [keytransparency] could be used.
Identity Key: A long-lived signing key pair used to authenticate the 3. Further considerations
sender of a message.
We use the TLS presentation language [RFC8446] to describe the The following aspects of federated communication are important for
structure of protocol messages. successful federation but are not considered in scope of the MLS
charter:
3. Use cases ## Common format for the content of application messages
3.1. Different Delivery Servers The MLS protocol does not impose any format on the content of
application messages. Instead, application messages are considered
to be an opaque sequence of bytes. Applications in a federated
environment are expected to agree on a common format. The
negotiation can be done at the KeyPackage level, or through the MLS
extension mechanism.
Different applications operated by different entities can use MLS to 3.1. Network protocol between different domains
exchange E2EE messages. For example in email applications, clients
of email1.com can encrypt and decrypt E2EE email messages from
email2.com.
3.2. Different client applications Cross-domain operations such as sending and receiving messages,
fetching KeyPackages, and querying the Authentication Services have
to be part of a common network protocol that is supported by all
domains in a federated environment.
Different client applications operated by the same server can use MLS 4. Discovery service for clients/users on a specific domain
to exchange E2EE handshake and application messages. For example
different browsers can implement the MLS protocol, and web developers
write web applications that use the MLS implementation in the browser
to encrypt and decrypt the messages. This will require a new
standard Web API to allow the client applications to set the address
of the delivery service in the browser. A more concrete example is
using MLS in the browser to exchange SRTP keys for multi-party
conference call.
4. Functional Requirements Searching for users and other discovery services are typically part
of messaging systems. In the context of MLS, this functionality
might overlap with the fetching of KeyPackages and message routing.
4.1. Delivery service 5. Use cases
In MLS environment the messages can either be delivered using client 5.1. Different Delivery Servers
fanout or server fanout, each will have different requirements.
In a federated environment the client may communicate with one or Different applications operated by different entities can use MLS to
more delivery services. Discovering the delivery service and syncing exchange end-to-end encrypted messages. For example, in a messaging
between different delivery services are out of scope of this applications, clients of messaging1.tld can encrypt and decrypt end-
document. to-end encrypted messages from messaging2.tld.
4.1.1. Client fanout 5.2. Different client applications
In this mode, the client SHOULD support communicating with multiple Different client applications operating on the same server can use
delivery services. Discovering the delivery service is out of scope MLS to exchange end-to-end encrypted handshake and application
of this document. messages. For example, different browsers can implement the MLS
protocol, and web developers write web applications that use the MLS
implementation in the browser to encrypt and decrypt the messages.
This will require a new standard Web API to allow the client
applications to set the address of the delivery service in the
browser. A more concrete example is using MLS in the browser to
negotiate SRTP keys for multi-party conference calls.
+-----------------+ +---------+ 6. Functional Requirements
+ Deliver Service B + +------> + Client B1 +
+----------> + + +---------+
| +-----------------+
|
+---------+ | +-----------------+ +---------+
+ Client A1 +-----------> + Deliver Service A + +------> + Client A2 +
+---------+ | + + +---------+
| +-----------------+
|
| +-----------------+ +---------+
+----------> + Deliver Service C + +------> + Client C1 +
+ + +---------+
+-----------------+
In this mode, the delivery service SHPULD be stateless, and it the 6.1. Delivery service
clients responsibility to maintain the group state. OPEN QUESTION:
How ordering could be enforced in this mode?
4.1.2. Server fanout While there is no strict requirement regarding the network topology,
there are practical advantages when clients only connect to their own
Delivery Service rather than to the whole federated environment.
This routing strategy can possibly make the design of a cross-domain
network protocol easier in the context of access control.
Multiple delivery services can be avoided, with server side fan out, In such a topology, the client's own Delivery Service relays messages
and all keys requests can be proxied through a single delivery to the Delivery Service in charge for a specific group.
service. The protocol between different delivery services is out of
the scope of this document.
+-----------------+ +---------+ When several Delivery Services are involved in relaying messages, it
+--> + Deliver Service B + +---> + Client B1 + is important that all of them agree on which one is responsible for
| + + +---------+ ordering handshake messages of a specific group at any given time in
| +-----------------+ order to enforce the total ordering of handshake messages required by
| the MLS protocol.
+---+-------------+ +---------+
+---------+ + Deliver Service A + +-------------> + Client A2 +
+ Client A1 + +---> + + +---------+
+---------+ +------+----------+
|
| +-----------------+ +---------+
+--> + Deliver Service C + +---> + Client C1 +
+ + +---------+
+-----------------+
OPEN QUESTION: How server assist could be used with multiple servers? Depending on the functional requirements (such high availability and
how the server state is shared and synced ? redundancy), the different Delivery Services can elect a dedicated
Delivery Service to be responsible for ordering handshake messages
for a certain period of time. The election process can be repeated
when the availability of Delivery Services change.
4.2. Authentication service The diagram below shows a federated environment where a client
connects to its own Delivery Service that in turn relays messages to
other Delivery Services.
There is no change needed for the authentication service, however the +-----------------+ +---------+
authentication in a federated environment becomes more important. +--> + Deliver Service B + +---> + Client B1 +
The ideal solution would be using a shared transparency log like | + + +---------+
[KeyTransparency]. | +-----------------+
|
+---+-------------+ +---------+
+---------+ + Deliver Service A + +-------------> + Client A2 +
+ Client A1 + +---> + + +---------+
+---------+ +------+----------+
|
| +-----------------+ +---------+
+--> + Deliver Service C + +---> + Client C1 +
+ + +---------+
+-----------------+
 
5. Message format 6.2. Authentication Service
The encrypted message payload is defined in the MLS protocol document The MLS specification only describes how the signatures on the
[MLSPROTO], in order to get federation between different systems, the contents of the leaf nodes of a given group can be verified and that
identity key and user init key retrieval MUST be defined as well. clients have to support the signature schemes of all other clients in
The identity key can always be included in the user init key each group.
response.
enum { The credential (and thus the binding between identity of the group
P256_SHA256_AES128GCM(0x0000), member and its signature public key) in each (non-blank) leaf node
X25519_SHA256_AES128GCM(0x0001), has to be authenticated by the AS. This becomes relevant in a
(0xFFFF) federated setting, as the AS, and thus the authentication process of
} CipherSuite; each member in a given group might differ.
struct { This problem can be solved in a variety of ways, for example, by
opaque identity<0..2^16-1>; having all applications and/or service providers involved in a
CipherSuite supported_suites<0..255>; federation agree on a shared process, or by having clients advertise
} GetUserInitKeyRequest; their authentication process in a similar way as their ciphersuite,
with the requirement that all members of a group must support each
others authentication processes.
struct { Depending on the design of the AS of a given client, other, federated
opaque user_init_key_id<0..255>; clients might have to trust that client's service provider to
CipherSuite cipher_suites<0..255>; authenticate its credential. Confidence in authentication provided
HPKEPublicKey init_keys<1..2^16-1>; by service providers in general can be strengthened by using a scheme
Credential credential; such as [keytransparency], which allows both local and federated
opaque signature<0..2^16-1>; clients to assert a shared view of the authentication information
} UserInitKey; provided by the service.
struct { In a federated environment, the AS should provide the same degree of
opaque identity<0..2^16-1>; transparency as in a non-federated environment, i.e. end-to-end
UserInitKey user_init_key; authentication should be possible.
} UserInitKeyBundle;
The delivery service will return one or more user init key bundles, 7. Security Considerations
one for each member.
struct { 7.1. Version & ciphersuite negotiation
UserInitKeyBundle user_init_keys<0..2^32-1>;
} GetUserInitKeyResponse;
OPEN QUESTION: What if different clients have different cipher In a federated environment, version & ciphersuite negotiation is more
suites? critical, to avoid forcing a downgrade attack by malicious third
party Delivery Services. This is due to the fact that the thread
model is extended to include the following:
6. Security Considerations * Different entities might have diverging security policies, e.g.
they don't enforce validation of KeyPackages the same way.
6.1. Version negotiation * Entities might be malicious and act as a threat actor, e.g. might
generate fake clients controlled by them.
In a federated environment, version negotiation is more critical, to The negotiation of version numbers & ciphersuites can be done at the
avoid forcing a downgrade attack by malicious 3rd party delivery KeyPackage level.
services. The negotiation could either be done in the
UserInitKeyBundle or in a separate handshake message.
7. IANA Considerations 8. IANA Considerations
This document makes no requests of IANA. This document makes no requests of IANA.
8. References 9. References
8.1. 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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References 9.1. Normative References
[KeyTransparency] [I-D.ietf-mls-architecture]
Google, ., "Key Transparency", n.d., Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., Kwon,
<https://KeyTransparency.org>. A., and A. Duric, "The Messaging Layer Security (MLS)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-mls-architecture-07, 4 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-mls-
architecture-07>.
[MLSARCH] Omara, E., Barnes, R., Rescorla, E., Inguva, S., Kwon, A., 9.2. Informative References
and A. Duric, "Messaging Layer Security Architecture",
2018.
[MLSPROTO] [keytransparency]
Barnes, R., Millican, J., Omara, E., Cohn-Gordon, K., and "Key Transparency", n.d.,
R. Robert, "Messaging Layer Security Protocol", 2018. <https://github.com/google/keytransparency>.
Authors' Addresses Authors' Addresses
Emad Omara Emad Omara
Google Google
Email: emadomara@google.com Email: emadomara@google.com
Raphael Robert Raphael Robert
Wire Email: ietf@raphaelrobert.com
Email: raphael@wire.com
 End of changes. 55 change blocks. 
212 lines changed or deleted 212 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/