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

Xuelei Fan <xuelei.fan@vimino.com> Thu, 03 April 2014 13:33 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 EF3961A01BC for <tls@ietfa.amsl.com>; Thu, 3 Apr 2014 06:33:09 -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 75Z4__ETHrMP for <tls@ietfa.amsl.com>; Thu, 3 Apr 2014 06:33:05 -0700 (PDT)
Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id 97DB51A0152 for <tls@ietf.org>; Thu, 3 Apr 2014 06:33:05 -0700 (PDT)
Received: by mail-pd0-f171.google.com with SMTP id r10so1804019pdi.30 for <tls@ietf.org>; Thu, 03 Apr 2014 06:33:01 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=84/17TxdK0O2mLLwIOAom8DPwhahY9eXdcjqjk0tsxI=; b=Bch6I08pqEiwziQhdMGFMS4ix0a3BH9eIBJNhfOypN6a35A32rCZEsT5tXRapxo61b mY/GkDJSe9r4g6P650q/RT2FvVWY8RMV6mn08KXsVZCuW2+O4GxCk56eIW90qKdRlo55 t6GokjXVsbcr8ySaQG/q4TTfhTD1j0fHmG9rIVIyai4bNEhka3HPeBKMXkvzDbXVHNxf S9wnEsifhTAA/9tcSr/0CzsmrAYLJlPA1NvEiscDZpDqBkNjQQrYcXA0KntyppIZ/RYs Qhdy906C7EzJYZYnt2VSlPfZuCea5vDStW2ub0biIMA9SiwoTWZpsGR5aD/mOEBcbcfI zpGw==
X-Gm-Message-State: ALoCoQnNHOD+b38egAxD1AEVjxbwSjktNPqubsbtEHHbo73sMsDv8mqXQYyvrlV2RBowNWX01hPm
X-Received: by 10.68.254.5 with SMTP id ae5mr7302094pbd.83.1396531981423; Thu, 03 Apr 2014 06:33:01 -0700 (PDT)
Received: from [192.168.1.105] ([222.129.109.127]) by mx.google.com with ESMTPSA id pe3sm11307496pbc.23.2014.04.03.06.32.57 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 06:33:00 -0700 (PDT)
Message-ID: <533D62FE.2060400@Vimino.COM>
Date: Thu, 03 Apr 2014 21:32:46 +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>, tls@ietf.org
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>
In-Reply-To: <CA+_8ft7cckoO_YGncQ89NmdoVcSUNiLO1pPJbu=UAJRUnB9aGA@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/gQkaIIUCmbOZG42a-91kQcwizjM
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:33:10 -0000

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>> 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>> 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>
>     https://www.ietf.org/mailman/__listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>