Internet DRAFT - draft-omara-mls-federation

draft-omara-mls-federation







Network Working Group                                           E. Omara
Internet-Draft                                                    Google
Intended status: Informational                                 R. Robert
Expires: September 12, 2019                                         Wire
                                                          March 11, 2019


             The Messaging Layer Security (MLS) Federation
                     draft-omara-mls-federation-00

Abstract

   This document describes how the Messaging Layer Security (MLS) can be
   used in a federated environment where different MLS implementations
   can interoperate by defining the message format for user key
   retrieval.  The document also describes some use cases where
   federation could be useful.

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 September 12, 2019.

Copyright Notice

   Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of




Omara & Robert         Expires September 12, 2019               [Page 1]

Internet-Draft               MLS Federation                   March 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Different Delivery Servers  . . . . . . . . . . . . . . .   4
     3.2.  Different client applications . . . . . . . . . . . . . .   4
   4.  Functional Requirements . . . . . . . . . . . . . . . . . . .   4
     4.1.  Delivery service  . . . . . . . . . . . . . . . . . . . .   4
       4.1.1.  Client fanout . . . . . . . . . . . . . . . . . . . .   5
       4.1.2.  Server fanout . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Authentication service  . . . . . . . . . . . . . . . . .   6
   5.  Message format  . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     6.1.  Version negotiation . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   MLS Architecture draft [MLSARCH] describes the overall MLS system
   architecture assuming the client and servers (Delivery Service and
   Authentication Service) are operated by the same entity.  This
   document describes the minimum changes needed to allow different MLS
   clients operated by the same or different entities to communicate
   with each and explaining The use cases where federation could be
   useful.

   The focus of this document will be the interaction between the client
   and the Delivery Service, specifically how the client retrieves the
   identityKey and InitKeys for another client.  There is no changes
   needed for the Authentication Service.

   Discovering which Delivery service the client communicates with is
   out of the scope of this document.

   The below diagram shows an MLS group where all clients are operated
   under the same deliver service:







Omara & Robert         Expires September 12, 2019               [Page 2]

Internet-Draft               MLS Federation                   March 2019


                          +------------+
                         + Delivery     +
                         + Service (DS) +
                          +-----+------+
                       /        +        \             Group
   *********************************************************
   *                 /          +          \               *
   *                /           |           \              *
   *      +--------+       +----+---+       +--------+     *
   *     + Client 0 +     + Client 1 +     + Client 3 +    *
   *      +--------+       +--------+       +--------+     *
   *     .............................     ............    *
   *     User 0                            User 1          *
   *                                                       *
   *********************************************************



   one possible environment is to have different client implementations
   operated by the same delivery service, which will look like the
   diagram above, another environment is to have different or same
   clients operated By different delivery services:

              +-----------------+      +-----------------+
             + Deliver Service 1 +    + Deliver Service 2 +
             +                   +    +                   +
              +-----------------+      +--------+--------+
                  |         |                   |
                  |         |                   |      Group
   ***************|*********|*******************|***********
   *              |         |                   |          *
   *              |         |                   |          *
   *      +--------+       +--------+       +--------+     *
   *     + Client 0 +     + Client 1 +     + Client 3 +    *
   *      +--------+       +--------+       +--------+     *
   *     .............................     ............    *
   *     User 0                            User 1          *
   *                                                       *
   *********************************************************




2.  Terminology

   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



Omara & Robert         Expires September 12, 2019               [Page 3]

Internet-Draft               MLS Federation                   March 2019


   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
      client to a group.  Initialization keys are published for each
      client (UserInitKey).

   Identity Key:  A long-lived signing key pair used to authenticate the
      sender of a message.

   We use the TLS presentation language [RFC8446] to describe the
   structure of protocol messages.

3.  Use cases

3.1.  Different Delivery Servers

   Different applications operated by different entities can use MLS to
   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

   Different client applications operated by the same server can use MLS
   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

4.1.  Delivery service

   In MLS environment the messages can either be delivered using client
   fanout or server fanout, each will have different requirements.




Omara & Robert         Expires September 12, 2019               [Page 4]

Internet-Draft               MLS Federation                   March 2019


   In a federated environment the client may communicate with one or
   more delivery services.  Discovering the delivery service and syncing
   between different delivery services are out of scope of this
   document.

4.1.1.  Client fanout

   In this mode, the client SHOULD support communicating with multiple
   delivery services.  Discovering the delivery service is out of scope
   of this document.

                             +-----------------+            +---------+
                            + 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
   clients responsibility to maintain the group state.  OPEN QUESTION:
   How ordering could be enforced in this mode?

4.1.2.  Server fanout

   Multiple delivery services can be avoided, with server side fan out,
   and all keys requests can be proxied through a single delivery
   service.  The protocol between different delivery services is out of
   the scope of this document.














Omara & Robert         Expires September 12, 2019               [Page 5]

Internet-Draft               MLS Federation                   March 2019


                                +-----------------+         +---------+
                          +--> + Deliver Service B + +---> + Client B1 +
                          |    +                   +        +---------+
                          |     +-----------------+
                          |
                      +---+-------------+                   +---------+
  +---------+        + Deliver Service A + +-------------> + Client A2 +
 + Client A1 + +---> +                   +                  +---------+
  +---------+         +------+----------+
                          |
                          |     +-----------------+         +---------+
                          +--> + Deliver Service C + +---> + Client C1 +
                               +                   +        +---------+
                                +-----------------+


   OPEN QUESTION: How server assist could be used with multiple servers?
   how the server state is shared and synced ?

4.2.  Authentication service

   There is no change needed for the authentication service, however the
   authentication in a federated environment becomes more important.
   The ideal solution would be using a shared transparency log like
   [KeyTransparency].

5.  Message format

   The encrypted message payload is defined in the MLS protocol document
   [MLSPROTO], in order to get federation between different systems, the
   identity key and user init key retrieval MUST be defined as well.
   The identity key can always be included in the user init key
   response.


















Omara & Robert         Expires September 12, 2019               [Page 6]

Internet-Draft               MLS Federation                   March 2019


   enum {
           P256_SHA256_AES128GCM(0x0000),
           X25519_SHA256_AES128GCM(0x0001),
           (0xFFFF)
   } CipherSuite;

   struct {
      opaque identity<0..2^16-1>;
      CipherSuite supported_suites<0..255>;
   }  GetUserInitKeyRequest;

   struct {
           opaque user_init_key_id<0..255>;
           CipherSuite cipher_suites<0..255>;
           HPKEPublicKey init_keys<1..2^16-1>;
           Credential credential;
           opaque signature<0..2^16-1>;
   } UserInitKey;

   struct {
           opaque identity<0..2^16-1>;
           UserInitKey user_init_key;
   } UserInitKeyBundle;

   The delivery service will return one or more user init key bundles,
   one for each member.

   struct {
      UserInitKeyBundle user_init_keys<0..2^32-1>;
   }  GetUserInitKeyResponse;

   OPEN QUESTION: What if different clients have different cipher
   suites?

6.  Security Considerations

6.1.  Version negotiation

   In a federated environment, version negotiation is more critical, to
   avoid forcing a downgrade attack by malicious 3rd party delivery
   services.  The negotiation could either be done in the
   UserInitKeyBundle or in a separate handshake message.

7.  IANA Considerations

   This document makes no requests of IANA.





Omara & Robert         Expires September 12, 2019               [Page 7]

Internet-Draft               MLS Federation                   March 2019


8.  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

   [KeyTransparency]
              Google, ., "Key Transparency", n.d.,
              <https://KeyTransparency.org>.

   [MLSARCH]  Omara, E., Barnes, R., Rescorla, E., Inguva, S., Kwon, A.,
              and A. Duric, "Messaging Layer Security Architecture",
              2018.

   [MLSPROTO]
              Barnes, R., Millican, J., Omara, E., Cohn-Gordon, K., and
              R. Robert, "Messaging Layer Security Protocol", 2018.

Authors' Addresses

   Emad Omara
   Google

   Email: emadomara@google.com


   Raphael Robert
   Wire

   Email: raphael@wire.com








Omara & Robert         Expires September 12, 2019               [Page 8]