Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256

Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr> Sat, 23 May 2015 06:07 UTC

Return-Path: <karthikeyan.bhargavan@inria.fr>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186F81A90E2; Fri, 22 May 2015 23:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level:
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 VmAdDZGomZ4W; Fri, 22 May 2015 23:07:22 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A08A1A90D7; Fri, 22 May 2015 23:07:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.13,480,1427752800"; d="asc'?scan'208";a="126053707"
Received: from 178.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.178]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 May 2015 08:07:19 +0200
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
In-Reply-To: <20150216115457.3c16fdbf@latte.josefsson.org>
Date: Sat, 23 May 2015 08:07:17 +0200
Message-Id: <F2896AD9-127C-4F7B-BC21-CF29C148D36D@inria.fr>
References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <CABkgnnWbCV6kWF0F4zCj+-jjf67MkkkCb-nYNonsTA04Ojd5jQ@mail.gmail.com> <20150216115457.3c16fdbf@latte.josefsson.org>
To: Simon Josefsson <simon@josefsson.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/m-iQVrQAgbtVfDb4lvDTRc8HHkg>
Cc: "kitten@ietf.org" <kitten@ietf.org>, "http-auth@ietf.org" <http-auth@ietf.org>, Martin Thomson <martin.thomson@gmail.com>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 May 2015 06:07:27 -0000

>> We have a solution for that:
>> https://tools.ietf.org/html/draft-ietf-tls-session-hash

If a TLS connection uses the tls-session-hash, the tls-unique channel binding becomes
a good channel identifier for use in SCRAM (avoiding Triple Handshake-style attacks).
So either SCRAM could require tls-session-hash, or we could update RFC5929 to require it
(in the same way that it already requires RFC5746).

I have a separate question: would there be value in defining a new session-level channel binding (updating rfc5929)
based on tls-session-hash?

The advantage would be to obtain authenticated session resumption.
That is, once a client has used SCRAM to authenticate on one connection, it can reuse that credential
on all resumed connections, until a new full handshake is performed. I don’t know how commonly
we use session resumption in non-web scenarios, but the vast majority of connections initiated by
web browsers use abbreviated handshakes.

Best,
Karthik

> 
> Then SCRAM-SHA256 should normatively references that and require that
> it is implemented for secure use of SCRAM with channel bindings.  There
> are drawbacks with that approach: it is not widely implemented, not
> published as an RFC that updates earlier TLS versions, and difficult
> for SCRAM implementers to validate (usually the TLS stack is opaque to
> the SCRAM implementer).  I could live with that though, as a way of
> pushing the current security problem down from the IETF protocol layer
> into the implementation layer.
> 
> Alternatively, use a new channel binding type that use the extended
> master secret derivation as described by the document above.  I could
> update draft-josefsson-sasl-tls-cb to describe this approach.
> 
> /Simon
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten