[MLS] Authentication vulnerability in mls-03; better framing to the rescue

Richard Barnes <rlb@ipv.sx> Mon, 18 February 2019 22:22 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 95E60131055 for <mls@ietfa.amsl.com>; Mon, 18 Feb 2019 14:22:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LgYBDOebrt0F for <mls@ietfa.amsl.com>; Mon, 18 Feb 2019 14:22:43 -0800 (PST)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C63B13104B for <mls@ietf.org>; Mon, 18 Feb 2019 14:22:43 -0800 (PST)
Received: by mail-ot1-x32f.google.com with SMTP id 98so31028865oty.1 for <mls@ietf.org>; Mon, 18 Feb 2019 14:22:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=eKLn4117ZcVbl/v6X57F0u18NgwWRD4ctGa4GXFX82I=; b=dEP0dz7UnoMOCs0fwPNFPEnstmcbrU8HoEP7D7RC10KkxMYvNCRiuoIzLAncKFYu1g l2ecOoZP1Y+i6EORVVjynSD5nsGzz4qprH7Rfwi9FGUM/Ax2R96W1hKVGYCk8LPfQho6 arlgltPLJXdNjrnJz5bIG3BdTIB1icvjWeex/FX15bI23VXCNDrgOgqKYWvcrLYDyqzm wMc4C81D1zYS7vS7a5F3WTTlkcgwc0zqBTtJU1BSZY5I2EREVwfMEWV8t1/UuLPdYG24 qedTP0VAJyNYoNMRUxkuTdFxjIJudV0+cEYdkHM0Y6K6/kAH5IZhGqUCMliXTlKuRSVM Uv3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eKLn4117ZcVbl/v6X57F0u18NgwWRD4ctGa4GXFX82I=; b=Igw9OKU7F4GEEfTg897YGLSVb0mU2mOMfiwWBqrFYvlFFcWOBj8gdnAoJMyx9XRivd VaUxzh+VEfrICYjjLaFEujBkbkpxfbxkQXmDmFpQawYGnRbVT0ehyDKsHgbpFmhOAehM ZYwLZs61Abp6W/3Pm59sXgWzjYfn76m6iheKQYzMKGnYHn/8JFrtog2w8hb8/6sVfGIr IzOBXhRT9Ns6czC+eMIXqSGKHwrTNBefTW0AvPNvgL5mRoTBwsIiipDZcOuJPiWFnBd7 v2C8I+EjYI3h1XCyqANHMroQqq5IAphQZIu15E5bT4aPQ5Lxo/aGpL6XFDylCJIP41K+ LrpA==
X-Gm-Message-State: AHQUAuYW8aIXWeQBuk4/Yr2iTNfAa7sj3O0Ew4fecNHZMZyMHF4jw5Wv 9YtIs/2vbJkimA91UY7sybOLmmC/eKrms4DiiSsmzp3E2Oc=
X-Google-Smtp-Source: AHgI3IaNOAEtY2SUJST96y9sBoG1PavXMfpLmmaLkQNJJK0vGsJwamwmNLyZazsEyFNEY7eOs6P063Zp0/WrS7BC9CQ=
X-Received: by 2002:a9d:6347:: with SMTP id y7mr15081724otk.331.1550528561753; Mon, 18 Feb 2019 14:22:41 -0800 (PST)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 18 Feb 2019 17:22:28 -0500
Message-ID: <CAL02cgT1LHdGeF2mLBnGrppxsKaFHdgowbgnMU-8D1xxqzzvWg@mail.gmail.com>
To: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000023452d0582329071"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/UXKN9t1TUTyNFZrXWK74WbwRSv4>
Subject: [MLS] Authentication vulnerability in mls-03; better framing to the rescue
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Feb 2019 22:22:45 -0000

Hey all,

Over the weekend, I drafted a proposed common framing layer that would
entail some changes to how authentication is done.  To make sure this
wasn't harmful, I build some Tamarin models this morning of the two-party
scenario in -03 and my proposed -04.  The bad news is that Tamarin pointed
out a weakness in -03; the good news is that the proposed -04 structure
fixes it, at least in the two-party case.

The vulnerability in -03 unfolds as follows [2]:

- Client A posts an InitKey
- Client B downloads the InitKey and constructs a Welcome and Add messages
- Attacker intercepts Welcome and Add
- Attacker creates a new Welcome message with his own InitKey, and replaces
the MAC on the Add message with one derived from his InitKey
- As a result:
  - Client B will encrypt messages to the attacker thinking they are
encrypting to Client A
  - Client B will never successfully receive a message, because the
attacker doesn't have Client A's private key, and Client A doesn't have the
encryption key.

This vulnerability arises because the Welcome message is too loosely
coupled to the Add message, allowing the init_key to be sent by someone
other than the sender of the Add.  There are two approaches to improving
this binding that seem to solve the problem (as verified by Tamarin):

a) Moving the confirmation MAC under the message signature [3]
b) Including a hash of the WelcomeInfo in the Add message [4]

(The former prevents the attacker from replacing the MAC; the latter the
Welcome message.) Option (a) was already included in PR#120; in addition to
fixing this problem, it makes for better parallelism between Application
and Handshake messages.  Option (b) also seems worth doing, since it gets
the Welcome into the transcript, and allows other participants to verify
that it was correct.

I've updated PR#120 to also include (b).  If folks have other thoughts on
that PR or this analysis, they would be helpful. Likewise, if anyone wanted
to take the Tamarin models linked below and extend them to larger cases (3
or 4 parties shouldn't be crazy), that would help give more confidence in
this change.


[1] https://github.com/mlswg/mls-protocol/pull/120
[2] https://github.com/bifurcation/tamarin-ake/blob/master/mls-03.spthy
[3] https://github.com/bifurcation/tamarin-ake/blob/master/mls-04a.spthy
[4] https://github.com/bifurcation/tamarin-ake/blob/master/mls-04b.spthy