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

Karthikeyan Bhargavan <> Sat, 23 May 2015 06:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 186F81A90E2; Fri, 22 May 2015 23:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.56
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VmAdDZGomZ4W; Fri, 22 May 2015 23:07:22 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (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 (HELO []) ([]) by 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 <>
In-Reply-To: <>
Date: Sat, 23 May 2015 08:07:17 +0200
Message-Id: <>
References: <> <> <> <>
To: Simon Josefsson <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: "" <>, "" <>, Martin Thomson <>, "" <>
Subject: Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 23 May 2015 06:07:27 -0000

>> We have a solution for that:

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.


> 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