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

Karthik Bhargavan <karthik.bhargavan@gmail.com> Thu, 03 April 2014 13:45 UTC

Return-Path: <karthik.bhargavan@gmail.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 9B8491A01FC for <tls@ietfa.amsl.com>; Thu, 3 Apr 2014 06:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 E78SsvH3JG1F for <tls@ietfa.amsl.com>; Thu, 3 Apr 2014 06:45:20 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0A54B1A01B5 for <tls@ietf.org>; Thu, 3 Apr 2014 06:45:19 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id hm4so921638wib.0 for <tls@ietf.org>; Thu, 03 Apr 2014 06:45:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rmPtpPc4JtIpF70B1xg2hRC7PHAoN2iD3R4chRvs+ns=; b=EKpIVW2EFanezdfrbn4+YNo3GTaqk2ypS8Wk86vPQcZ8mouE9Sa+kMCASERoGsPI4l w22tnN6Z+jVp17+2fje6f72xFeaQ4vn8/M5dm9vBLFivCZM41FgSnafC/Lsas2jfzLZN 7yG1PHZTB+Eqr2O/+Qm/YR2dCDJ/NwvRvwHnlwYn54MsVN3QLB5I+ddU6dsJrfo/nRUm zSeUZ3GUX3KpXOn1OeHkX9Vl0mBDLLrhEX3vzSKUwCM4G59JxKeJClX+NailEK7m2lY3 snWH27K4RkbzK81frTebVlqS8jxrM8TZfdDD91gnRUyH6y/O1uR1YN/aOLYJ0iJZ17FW L6Xg==
X-Received: by 10.180.81.228 with SMTP id d4mr37877463wiy.49.1396532715153; Thu, 03 Apr 2014 06:45:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.98.38 with HTTP; Thu, 3 Apr 2014 06:44:55 -0700 (PDT)
In-Reply-To: <533D62FE.2060400@Vimino.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>
From: Karthik Bhargavan <karthik.bhargavan@gmail.com>
Date: Thu, 3 Apr 2014 15:44:55 +0200
Message-ID: <CA+_8ft6gAD8gQq-KMW+eqWQWE8uwt3sykDn+Pboaw31ggCVdEg@mail.gmail.com>
To: Xuelei Fan <xuelei.fan@vimino.com>
Content-Type: multipart/alternative; boundary=f46d043bdb0e6770df04f6239ce8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UdMOv3_DYue_svaQYwImwEl_nPk
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:45:25 -0000

We cannot modify Renegotiation Indication since TLS extensions are not
versioned.

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.
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> 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>> 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
>>
>>
>