Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

Eric Rescorla <ekr@rtfm.com> Sun, 18 March 2018 15:28 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CC61270AC for <tls@ietfa.amsl.com>; Sun, 18 Mar 2018 08:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 26bvR1c5lXJp for <tls@ietfa.amsl.com>; Sun, 18 Mar 2018 08:28:26 -0700 (PDT)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 E878F12D87A for <tls@ietf.org>; Sun, 18 Mar 2018 08:28:15 -0700 (PDT)
Received: by mail-qk0-x22d.google.com with SMTP id z184so15898931qkc.1 for <tls@ietf.org>; Sun, 18 Mar 2018 08:28:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MoJuLrkVAu+iq0j+sN85O+dZ0WRwLBJE7dUJ4u9mu54=; b=Pqniw3PLg7J6gpokknKtZE/Ao40fQbS9QLAi3TqsCJClooMUFJeV+Cj3gyr3Vaa0SS pdHBlzuTotFk2T97YRHhas8PbG/z5flJ5XWwaiOGFIiv1Qyldfn8ObulvbOhSFXxEnk4 dQSaLgm4BoZOMSgMkd75Wtz7VxzUUJBgjwALwO2qm7OliWbkUXs+rOOqXXdC/t0LVOvf I0U6B1FjxwcL+QnZ6OfkiFD+C/LgTD3dHtc2OAeFaMTFV0Bm59LZhjPrTVyUeFHN/Dh/ tU5wE5G7/TuYc+Ady7Zwc3cPmgDc/K2/VuLER85bs+E0Y7zORvgTptgEFZV4ZKAm9/Vz RivQ==
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; bh=MoJuLrkVAu+iq0j+sN85O+dZ0WRwLBJE7dUJ4u9mu54=; b=dDbnsDn00M4mJW5fSnIHMMqZfGy1amBq47yoSZI7uErHCW21ixiNhXju/SFhabIMbN QQEj1FBNcpPvYa+AzifJn3cS4zT6+XLax+wcgoKUY4pbfCvWPwRmzVXVxi5LU4Lufz2Y 4xW+1rSR1qk6KkHeZe3KTcfQiaJzw3oukwKZXCiNcTfG5HU5r8biLuxcg8DpW0LfhbmC lBmn8b2pXyEJcHKbk/2kyQNcQXI4LdpG+XlyA4thUqB13we6zvGZ3fgppBIGWzDpmECw D4SIJUL1jsB0vc8k8E9RZljERZBk1t/csDDC+aybBSz0y/agx6Uknj6fCLuR9bnr14pF FBpw==
X-Gm-Message-State: AElRT7E+M2BeyGkIvvOmbL71GrV6OM00iAYIxQ8U7Zi8kyl09tuJAz37 6qpgI+K7W2afIAb885sySxmvmj8c48RTYv0+vnTb/w==
X-Google-Smtp-Source: AG47ELv/RDwYehGfEw2sN+h/YTCRx3fEwj8yDIOD14SB/c3nCF9TeBGF5wYuJlvS5FAms5MlrObPKKxm6QPS9RUZfBI=
X-Received: by 10.55.89.7 with SMTP id n7mr13478878qkb.15.1521386894987; Sun, 18 Mar 2018 08:28:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.37.234 with HTTP; Sun, 18 Mar 2018 08:27:34 -0700 (PDT)
In-Reply-To: <6112806.hxzZ6NivhB@pintsize.usersys.redhat.com>
References: <6112806.hxzZ6NivhB@pintsize.usersys.redhat.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 18 Mar 2018 15:27:34 +0000
Message-ID: <CABcZeBOFvdfV3b5+yfJbeYxHLi_uDY34X7u3cbpiLa6RtnmFkQ@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: TLS WG <tls@ietf.org>, The IESG <iesg@ietf.org>, tls-chairs <tls-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="001a114c91aa712c740567b17db2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JW8nx0rPZByUIHb7EE0mZSBBwFQ>
Subject: Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Mar 2018 15:28:28 -0000

After discussion with the chairs and the AD, I have opted to just add a
section
that explains the attack. I just merged that (but managed not to get it
into -27
due to fumble fingering).

-Ekr


On Mon, Mar 12, 2018 at 8:27 AM, Hubert Kario <hkario@redhat.com>; wrote:

> When the server supports externally set PSKs that use human readable
> identities (or, in general, guessable identities), the current text makes
> it
> trivial to perform enumeration attack.
>
> The proposed fix was identified as conflicting with the "Client Hello
> Recording" security section, the severity of that conflict wasn't
> quantified
> though.
>
>
> Issue in detail:
>
> Problematic paragraph as it stands in draft-ietf-tls-tls13-26 (section
> 4.2.11):
>    Prior to accepting PSK key establishment, the server MUST validate
>    the corresponding binder value (see Section 4.2.11.2 below).  If this
>    value is not present or does not validate, the server MUST abort the
>    handshake.  Servers SHOULD NOT attempt to validate multiple binders;
>    rather they SHOULD select a single PSK and validate solely the binder
>    that corresponds to that PSK.  In order to accept PSK key
>    establishment, the server sends a "pre_shared_key" extension
>    indicating the selected identity.
>
> That means, given a server with both PSK and PKI authentication, if
> attacker
> sends multiple PSK identities with garbage binders, the server will abort
> the
> connection if and only if at least one of the identities was recognised by
> server. Applying the well known binary search method allows the attacker to
> then narrow it down to a single identity in O(log_2(n)) steps.
>
> The solution to ignore that one selected binder, and continuing the
> connection
> in case that binder does not validate (this is the version in the PR
> mentioned
> below), unfortunately doesn't solve this issue either;
>
> If the attacker is in possession of a known good PSK secret (established
> either through session resumption mechanism or of a less-privileged
> identity),
> it can list the known good one as the very last one in the PSK extension.
> If
> server recognises one of the identities earlier in the list it will choose
> no
> identity (as the binder didn't validate) or the known good identity if
> none of
> the previous identities were recognised. Again, applying binary search
> method
> allows the attacker to narrow the list to a single entry in just
> O(log_2(n))
> steps.
>
>
> Proposed solution:
>
> in paragraph above, in description of `binders`:
>   binders
>   : A series of HMAC values, one for
>    each PSK offered in the "pre_shared_keys" extension and in the same
>    order, computed as described below. If the number of binders does not
> match
>    number of identities the server MUST abort the connection with
>    "illegal_parameter" alert.
>
> problematic paragraph after changes:
>    Prior to accepting PSK key establishment, the server MUST validate
>    the corresponding binder value (see Section 4.2.11.2 below).  If this
>    value does not validate, the server MUST ignore the
>    associated identity and retry selection of identity. If no identity is
>    recognised or, for recognised identities, no binder could be validated
>    the server MUST continue connection as if PSK key establishment wasn't
>    attempted.  In order to accept PSK key
>    establishment, the server sends a "pre_shared_key" extension
>    indicating the selected identity.
>
> Unfortunately that solution was identified as conflicting with "Client
> Hello
> Recording" section.
>
> Do we consider that conflict to be severe enough to block this change?
>
> Or should we just add more information to that security section, that it
> needs
> to deal with this kind of attack?
>
> PS: some discussion on this issue already happened in the github PR:
> https://github.com/tlswg/tls13-spec/pull/1167
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky┼łova 115, 612 00  Brno, Czech Republic
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>