Re: [TLS] MITM Attacks on Client Authentication after Resumption

Xuelei Fan <xuelei.fan@vimino.com> Thu, 03 April 2014 13:57 UTC

Return-Path: <xuelei.fan@vimino.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850A31A0299 for <tls@ietfa.amsl.com>; Thu, 3 Apr 2014 06:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 58fQ82oSLjNv for <tls@ietfa.amsl.com>; Thu, 3 Apr 2014 06:57:12 -0700 (PDT)
Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id EDA371A02AC for <tls@ietf.org>; Thu, 3 Apr 2014 06:57:11 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id x10so1832385pdj.20 for <tls@ietf.org>; Thu, 03 Apr 2014 06:57:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SlqdRgVJ6x90kMubHTnrdjIWLZROVklqtbdH7VlkS1U=; b=bEMRQeAD/r9EEdeyJK5neoT4Kwhm7hwH5OZqhFkvfg4quFpQCLDB/2Xi3cwUdclmFz 1Q0hxldvDrlLhmGZzxtv/b39TLRhkp9zdYfR8ORcjGZg/Q6wVbcmdcO0ulM7sQkgzjEM aYd+DGCH47F6UW+Q8xysOPd0DY2LDupcUOrv8aId/ZNYggVg4HazlBKvDnaUbNx2P7th j1xPVXb+gaf+uNEfMz+72EAbPEJs7nKFKxwT/BmvboBRo1VSh8qixipZwfVe+J6nwOxM qNzu+pR5PvXXATUVEgMmpS+HGqRXdO6FGyWTvptA4cyliLnMu6eZsus4KAVKgguAb19t wevQ==
X-Gm-Message-State: ALoCoQm2OMxchVfCrDGA7B7O4qLYNjSo5gWJWBz+KPCUxEqywbIJIxJZS574DByxO5GWxFYQI4vg
X-Received: by 10.66.148.230 with SMTP id tv6mr7436860pab.155.1396533427821; Thu, 03 Apr 2014 06:57:07 -0700 (PDT)
Received: from [192.168.1.105] ([222.129.109.127]) by mx.google.com with ESMTPSA id n6sm11432098pbj.22.2014.04.03.06.57.02 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 06:57:07 -0700 (PDT)
Message-ID: <533D68A6.3020702@Vimino.COM>
Date: Thu, 03 Apr 2014 21:56:54 +0800
From: Xuelei Fan <xuelei.fan@vimino.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Karthik Bhargavan <karthik.bhargavan@gmail.com>
References: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> <5315DD23.30901@drh-consultancy.co.uk> <CABkgnnVYj-2BKwMLTgH-hVxSSGncoppOv-gZhbdBQB=QCBB-Ew@mail.gmail.com> <5315F9BA.4060805@drh-consultancy.co.uk> <5316A363.3000801@Vimino.COM> <CA+_8ft7cckoO_YGncQ89NmdoVcSUNiLO1pPJbu=UAJRUnB9aGA@mail.gmail.com> <533D62FE.2060400@Vimino.COM> <CA+_8ft6gAD8gQq-KMW+eqWQWE8uwt3sykDn+Pboaw31ggCVdEg@mail.gmail.com>
In-Reply-To: <CA+_8ft6gAD8gQq-KMW+eqWQWE8uwt3sykDn+Pboaw31ggCVdEg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SIIQ6CyK672GxhQH13w5GMPloIk
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 03 Apr 2014 13:57:16 -0000

On 4/3/2014 9:44 PM, Karthik Bhargavan wrote:
> We cannot modify Renegotiation Indication since TLS extensions are not
> versioned.
>
Sure, need to use a new extension ID.

> But we do have another internet draft called Secure Resumption
> Indication that does this.
> Specifically, it takes the session hash of the initial handshake that
> set up a session and sends it within an extension in the hello messages
> of the abbreviated handshake.
Is it published?  Can I have the link of the draft?

Thanks & Regards,
Xuelei

> This would indeed fix the renegotiation attack and it would fix
> tls-unique, but note that it would not fix master-secret based channel
> bindings (e.g. PEAP).
>
> Best,
> Karthik
>
>
>
>
> On Thu, Apr 3, 2014 at 3:32 PM, Xuelei Fan <xuelei.fan@vimino.com
> <mailto:xuelei.fan@vimino.com>> wrote:
>
>     I was wondering, can an extension of the renegotiation indication
>     (RFC 5746) be used to bind the client and server?
>
>     At present, in session resumption initial handshake, the
>     "renegotiation_info" should be empty in both ClientHello and
>     ServerHello messages.
>
>     In order to bind the client and server more tightly, the
>     renegotiation indication can be extended to use the previous
>     client_verify_data and server_verify_data in session resumption
>     initial handshake (probably only if previous connection supports
>     secure renegotiation).  That's, in session resumption initial
>     handshake, client sends previous client_verify_data and server
>     responses with previous client_verify_data plus server_verify_data.
>
>     This extension of the renegotiation indication need to cache
>     client_verify_data and server_verify_data.
>
>     Regards,
>     Xuelei
>
>
>     On 3/5/2014 9:09 PM, Karthik Bhargavan wrote:
>
>         After my talk at the meeting, its worth summarizing comments on the
>         triple handshake attack and its impact on client-authenticated TLS
>         renegotiation.
>
>         In the common case (e.g HTTPS) where a server presents  a
>         certificate in
>         both the initial handshake and during renegotiation, it would be
>         enough
>         for the client to verify that the certificate doesn't change. (More
>         precisely, the client needs to verify that the principals
>         represented by
>         both certificates are equally trustworthy.)
>
>         There are other cases, and I'd be curious to know how common
>         they are,
>         when one or both handshakes does not have a server certificate.
>         These
>         would be more difficult to fix with a general TLS library-level
>         policy.
>
>         Typical examples (from discussion at the meeting):
>
>         - Initial handshake uses DH_anon or a self-signed server cert
>             and renegotiation uses the real server certificate
>         - Initial handshake uses a server certificate,
>             and renegotiation uses PSK or SRP to authenticate the user
>
>         In the first case, I guess the purpose is to protect the server name
>         from passive attackers. In the second, the purpose is privacy
>         for the
>         user's SRP/PSK identity.
>
>         In both cases, if both handshakes happen on the same connection,
>         RFC5746
>         (renego indication) gives us a pretty strong guarantee that the
>         principals on both ends do not change. In effect, the second
>         handshake
>         retroactively authenticates the first.
>
>         The triple handshake attack shows that this nice guarantee does
>         not hold
>         if there is session resumption between the two handshakes.
>
>         I can't think of easy implementation-level ways of fixing the
>         DH_anon
>         and PSK/SRP cases.
>
>         Best,
>         Karthik
>
>
>
>         On Wed, Mar 5, 2014 at 5:09 AM, Xuelei Fan
>         <xuelei.fan@vimino.com <mailto:xuelei.fan@vimino.com>
>         <mailto:xuelei.fan@vimino.com <mailto:xuelei.fan@vimino.com>>__>
>         wrote:
>
>              On 3/5/2014 12:05 AM, Dr Stephen Henson wrote:
>
>                  On 04/03/2014 15:23, Martin Thomson wrote:
>
>                      On 4 March 2014 14:03, Dr Stephen Henson
>                      <lists@drh-consultancy.co.uk
>         <mailto:lists@drh-consultancy.co.uk>
>                      <mailto:lists@drh-consultancy.__co.uk
>         <mailto:lists@drh-consultancy.co.uk>>> wrote:
>
>
>                          I performed a few checks with an experimental
>         option to
>                          change the server
>                          certificate during renegotiation, which I believe
>                          simulates the attack
>                          mechanism. If the client checks certificates in
>         band
>                          then all versions choke
>                          with a verification error if a chain is
>         untrusted. For
>                          1.0.2 only it also chokes
>                          if the chain is trusted but the hostname
>         doesn't match.
>
>
>                      This is an interesting option.  I like the general
>         idea, but
>                      wonder
>                      what "hostname doesn't match" means in this case.
>
>              JSSE enabled the hostname checking during handshaking for
>         HTTPS and
>              LDAP.  If hostname doesn't match, the handshaking is terminated
>              immediately.
>
>
>                  I'd be interested if anyone knows of examples where the
>         server
>                  certificate does
>                  have to change during renegotiation and how common that
>         practice is.
>
>              I was wondering, if the cipher suite is changed from RSA
>         cert based
>              to EC cert based (and vice versa), the server certificate
>         would have
>              to change accordingly.  Not sure about the case in practice.
>
>              Xuelei
>
>
>              ___________________________________________________
>              TLS mailing list
>         TLS@ietf.org <mailto:TLS@ietf.org> <mailto:TLS@ietf.org
>         <mailto:TLS@ietf.org>>
>         https://www.ietf.org/mailman/____listinfo/tls
>         <https://www.ietf.org/mailman/__listinfo/tls>
>              <https://www.ietf.org/mailman/__listinfo/tls
>         <https://www.ietf.org/mailman/listinfo/tls>>
>
>
>
>
>
>         _________________________________________________
>         TLS mailing list
>         TLS@ietf.org <mailto:TLS@ietf.org>
>         https://www.ietf.org/mailman/__listinfo/tls
>         <https://www.ietf.org/mailman/listinfo/tls>
>
>
>