Re: [Unbearable] Possible attack on Token Binding with RSA key exchange

Nick Harper <nharper@google.com> Wed, 06 September 2017 00:23 UTC

Return-Path: <nharper@google.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FEB1321A0 for <unbearable@ietfa.amsl.com>; Tue, 5 Sep 2017 17:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syE6LtMZhsRn for <unbearable@ietfa.amsl.com>; Tue, 5 Sep 2017 17:23:09 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 AE4391321A4 for <unbearable@ietf.org>; Tue, 5 Sep 2017 17:23:09 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id r141so15919308qke.2 for <unbearable@ietf.org>; Tue, 05 Sep 2017 17:23:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CSxrzGIbyFkr9c2YvbRgQ4lnFz+kEis6i7nNM0QtzQk=; b=TuKomkVzftJ1K92sWsVQr1T6yvq/DXTEHIoYZwHoV9gvtPfWaUGRb9s2IDH1wSqLHF K3eLmsmYhGeYxW8as4SuiK49GBAYfpt+rLEideR2V06BLBCXMfA+xch9PlmDa7MRUqsb YOeKhCAGg8ZeFzbDmQmQvyLauggPkBdJGF8rzV5/osa3RoyxD5/CDUX31EZjVshi2qtX P9piq4JtWe1krmYqbuejDWrmcHcYfOVDodhxB5zA/WwoqpUJbOcL9kR+1YMWC/9PYvbn 6Zf8b4DyAeF1XGWSwfGsm1vEnocRM33ROcRccR8j5HfLmMxaqwrrtmK/1LeY2Dd87oJc DUNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CSxrzGIbyFkr9c2YvbRgQ4lnFz+kEis6i7nNM0QtzQk=; b=mCbk/ZiNCJSSYeNVw7IfcIC2UiJKK4VybxSCLcFEXD+7dZmHJbDqAvzYgBMUTBdxNK akE/UaafoaH56jI5m2Mew77kKIIBCOH0hDBFi4km1l6n3KFWXbPQNSrJB5w90r5jWyIB 8LJQPbXHDtYWs235iOxzBosaqMK+pOw9o+tJzsRkNCHA6K11qWgYwgSyDz0+BCqCcfG4 rAtkSef8LyDyeGpY3wPvVIh3tReDkFhI2dUEGbkMJX6nJELrrVA65pkCxzzl7d8BBoB7 Mru8tGvk1Nzwr7eyV7ngItZWeUQo4pbnd6/tr006KP/Rb2nsv//2tecAYqw57yZPCIjL nlYA==
X-Gm-Message-State: AHPjjUjSXaeGMWvRZiPAvV94Gvj/EilY0ZC0+AS9DgBt/788I4bUseGF +1geo8Gk6LtwdkL1TdjHLC+9LPoUCZVsEEA=
X-Google-Smtp-Source: ADKCNb622bZQB+V8YkX6zj0pC9NtivYKXsn9aw9tcBM+vSAEmusq33QKLQLz9QJQDm9Uv6l0V37C49qWmJZrDfnKzpc=
X-Received: by 10.55.165.202 with SMTP id o193mr1128852qke.291.1504657388487; Tue, 05 Sep 2017 17:23:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.36.138 with HTTP; Tue, 5 Sep 2017 17:22:47 -0700 (PDT)
In-Reply-To: <CY4PR21MB0120ED0B8619A2960F3462368C910@CY4PR21MB0120.namprd21.prod.outlook.com>
References: <CACdeXiJK_=C8-DB=jd=pTb5VBT250_3+ptScqT5S_kDPDZK+qg@mail.gmail.com> <MWHPR15MB14559C4298AF55C40193F405B6920@MWHPR15MB1455.namprd15.prod.outlook.com> <MWHPR15MB14556750C654628F47186232B6920@MWHPR15MB1455.namprd15.prod.outlook.com> <CY4PR21MB0120ED0B8619A2960F3462368C910@CY4PR21MB0120.namprd21.prod.outlook.com>
From: Nick Harper <nharper@google.com>
Date: Tue, 05 Sep 2017 17:22:47 -0700
Message-ID: <CACdeXiLJo_LAijxW0nE77NC+nHKm3n-VgJ5myWm6xtyqEO3=uQ@mail.gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Subodh Iyengar <subodh@fb.com>, IETF Tokbind WG <unbearable@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/ySL_6Zym2RhR4xT6_z99-vrmszw>
Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Sep 2017 00:23:12 -0000

I agree that at this point it doesn't make sense to limit TB to (EC)DHE.

I'm fine with writing a PR to cover this, but I'm unsure what to put
in it. I liked how draft-balfanz-tls-channelid started its security
considerations by describing 4 classes of network attackers, and I'd
like to do something similar here. However, it's unclear to me which
of those classes of network attackers are considered as part of the
threat model for Token Binding. Would it be reasonable to say that
defending against attackers with possession of a server's private key
is outside of the scope of Token Binding?

On Mon, Sep 4, 2017 at 3:59 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> It seems clear that binding tokens to broken TLS channels does one no good,
> but I don’t mind adding some statements to this effect in the security
> considerations.
>
> The statements would need to be general enough to cover TLS client and
> server compromise, PFS and non—PFS.
>
>
>
> Nick, please feel free to author a PR. If we get to IESG review someday,
> there will be more edits, and we can incorporate this as well.
>
>
>
> I don’t think it makes sense to limit TB to (EC)DHE, especially if we’re
> going to allow TB in combination with TLS 1.3 0-RTT mode.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Subodh
> Iyengar
> Sent: Friday, September 1, 2017 3:28 PM
> To: Nick Harper <nharper@google.com>; IETF Tokbind WG <unbearable@ietf.org>
>
>
> Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key
> exchange
>
>
>
> Having said that, even if we only support forward secure ciphers, I do not
> think we can reasonably claim that we are secure against the threat of
> stolen private keys.
>
> I like the the carrot opportunity this brings to encourage adoption of
> forward secure cipher suites.
>
>
>
> Subodh
>
> ________________________________
>
> From: Subodh Iyengar
> Sent: Friday, September 1, 2017 3:24:25 PM
> To: Nick Harper; IETF Tokbind WG
> Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key
> exchange
>
>
>
> +1 to requiring that token binding only be used with forward secure cipher
> suites.
>
> I believe the extended master secret requirement of token binding prevents
> the attack on forward secure suites, i.e. an attacker cannot change the DH
> share advertised by the real server and thus needs to get the private key
> for it.
>
> Subodh
>
> ________________________________
>
> From: Unbearable <unbearable-bounces@ietf.org> on behalf of Nick Harper
> <nharper@google.com>
> Sent: Friday, September 1, 2017 3:03:37 PM
> To: IETF Tokbind WG
> Subject: [Unbearable] Possible attack on Token Binding with RSA key exchange
>
>
>
> I came across an attack on Token Binding today, which I think is worth
> addressing in TBPROTO in some fashion (likely another paragraph in
> Security Considerations). This attack involves an adversary with the
> private key of a server it wishes to impersonate, and was mentioned in
> draft-balfanz-tls-channelid in the last paragraph of its Security
> Considerations.
>
> In brief, if an attacker has possession of a server's private key, it
> can hijack a TLS connection between client and server if the
> connection uses RSA key exchange instead of (EC)DHE key exchange,
> which allows the attacker to exercise the bound token without
> possession of the Token Binding private key.
>
> I realize that we're past WGLC at this point, but I think this should
> be addressed. On one end, we could require forward-secret key exchange
> modes with Token Binding. We could also describe this specific attack
> in the Security Considerations, or we could expand the Security
> Considerations to describe what attacks are and aren't in the Token
> Binding threat model, to say that attacks where the adversary has the
> server's private key are out of scope.
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_unbearable&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=aK_8DMmoWWiiQJmFt3JvhVLT6eh7Qm3nf3WuMhMC7vM&s=B0sKQEO8i8hDpLizsh7X8ins9EGGwOwcckYqZku7zEE&e=