Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding

From: Tony Hansen <[email-masked]>
Date: Fri, 22 May 2015 20:16:15 -0400

On 3/2/15 2:23 PM, Alexey Melnikov wrote:
>
> On 25/02/2015 15:25, Simon Josefsson wrote:
>> Tony Hansen <[email-masked]> writes:
>>
>>> On 2/24/15 6:56 AM, Stephen Farrell wrote:
>>>> But in addition, there were two substantive issues that ought be
>>>> resolved before IETF LC:
>>>>
>>>> 1. a new channel binding or requiring tls-session-hash (and I guess
>>>>      some explanatory text about why that is good/needed)
>>> To recap:
>>>
>>> Simon Josefsson made this comment:
>>>
>>>> Since SCRAM was published, we have learned that the tls-unique channel
>>>> binding is insecure -- it would be nice if we could combine the SHA256
>>>> update with another default channel binding type to resolve that
>>>> problem.  In my view, the problem with SCRAM today isn't primarily its
>>>> use of SHA1 but it's broken channel binding.
>>> Martin Thompson responded:
>>>
>>>> We have a solution for that:
>>>> https://tools.ietf.org/html/draft-ietf-tls-session-hash
>>> I've read through tls-session-hash and am unsure how to proceed here.
>>>
>>> One of my goals when proposing SCRAM-SHA-256 was to not change the
>>> protocol at all, other than updating the hash algorithm.
>>>
>>> I'm not sure how to incorporate a recommendation for session hashing
>>> here. I'm thinking this would be best handled by adding something to
>>> the Security Considerations section. Does that seem right?
>>>
>>> Would anyone be willing to suggest text changes for these comments?
>> I believe the problem is that RFC 5802 is insecure as currently
>> specified, and we are bringing this up as a problem with your draft,
>> which is unfair to you since the problem was not introduced by you.
>>
>> If people like the tls-session-hash approach (I'm not in that category,
>> but there may be consensus around it), the proper fix is to update RFC
>> 5802 and reference tls-session-hash as a normative reference.  This will
>> take care of the problem, as you could copy that text into your
>> document.  If you are looking for a text change here, it would be:
>>
>>    To be secure SCRAM-SHA-256-PLUS has to be used over a TLS channel
>> that
>>    MUST have [TLS-SESSION-HASH] negotiated.
>>
>> Personally, I would prefer to change to another mandatory channel
>> binding that is secure for all TLS versions.
> Before we make the decisions between referencing tls-session-hash
> versa a new channel binding, can you sketch out how the new channel
> binding is going to be defined?
>
> (If we choose to define a new channel binding, I think Kitten WG is
> the right place for doing this work.)

I added the following to the security section:

>     The strength of this mechanism is dependent in part on the
hash-iteration count, as denoted by "i" in
>     <xref target="RFC5802"/>.
>     As a rule of thumb, the hash-iteration count should be such that a
modern machine will take 0.1 seconds
>     to perform the complete algorithm; however this is unlikely to be
practical on mobile devices and
>     other relatively low-performance systems.
>     At the time this was written, the rule of thumb gives around
15,000 iterations required;
>     however an iteration count of 4096 takes around 0.5 seconds on
current mobile handsets.
>     This computational cost can be avoided by caching the ClientKey
(assuming the Salt and iteration count is stable).
>     Therefore the recommendation of this specification is that the
iteration count SHOULD be at least 4096, but careful
>     consideration ought to be given to using a significantly higher
value, particularly where mobile use is less important.

If anyone has suggestions for additions to this, or changes, please
suggest it now.

    Tony Hansen

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Sat, 23 May 2015 08:07:17 +0200

>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 23 May 2015 16:27:28 +0200

Den Fri, 22 May 2015 20:16:15 -0400
skrev Re: [kitten] draft-hansen-scram-sha256 and incorporating
session         hashing for channel binding:

> >>>> 1. a new channel binding or requiring tls-session-hash (and I
> >>>> guess some explanatory text about why that is good/needed)
> >>> To recap:
> >>>
> >>>> Since SCRAM was published, we have learned that the tls-unique
> >>>> channel binding is insecure -- it would be nice if we could
> >>>> combine the SHA256 update with another default channel binding
> >>>> type to resolve that problem.  In my view, the problem with
> >>>> SCRAM today isn't primarily its use of SHA1 but it's broken
> >>>> channel binding.
> >>> I'm not sure how to incorporate a recommendation for session
> >>> hashing here. I'm thinking this would be best handled by adding
> >>> something to the Security Considerations section. Does that seem
> >>> right?
> >>>
> >> specified, and we are bringing this up as a problem with your
> >> draft, which is unfair to you since the problem was not introduced
> >> by you.
> >>
> >> If people like the tls-session-hash approach (I'm not in that
> >> category, but there may be consensus around it), the proper fix is
> >> to update RFC 5802 and reference tls-session-hash as a normative
> >> reference.  This will take care of the problem, as you could copy
> >> that text into your document.  If you are looking for a text
> >> change here, it would be:
> >>
> >>    To be secure SCRAM-SHA-256-PLUS has to be used over a TLS
> >> channel that

This text has nothing to do with the tls-session-hash issue?

If you don't want to ship a known insecure protocol, I believe the
options are to either include text similar to what I proposed above, or
to replace tls-unique with a secure TLS channel binding (e.g.,
draft-josefsson-sasl-tls-cb).  Shipping a known insecure protocol is
another option, but then you should add a security consideration
explaining that tls-unique is not secure without tls-session-hash and
that consistency with (the also insecure) RFC 5802 was deemed more
important security.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 23 May 2015 16:35:26 +0200

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

I offered
https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 as an
alternative to tls-unique back in the days.  The issue with using only
the client/server-random (a'la TLS Finished) was discussed back then
and for -01 in 2008 I fixed the construct to be more secure (credit to
Eric Rescorla and Sam Hartman who made me aware of the concern).

My draft derives the channel binding in a way similar to
tls-session-hash.  I would appreciate if you could take a look and tell
me if you believe that it would solve the triple-handshake concern.

/Simon

---

From: Nico Williams <[email-masked]>
Date: Sat, 23 May 2015 15:26:19 -0500

On Mon, Mar 02, 2015 at 07:23:36PM +0000, Alexey Melnikov wrote:
> >   To be secure SCRAM-SHA-256-PLUS has to be used over a TLS channel that

There is no need to define a new channel binding.  Existing TLS
implementations need to be fixed regardless.  There's nothing GSS- or
SASL-mechanism-specific here.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 23 May 2015 22:39:46 +0200

Den Sat, 23 May 2015 15:26:19 -0500
skrev Re: [kitten] draft-hansen-scram-sha256 and incorporating session
hashing for channel binding:

> > > channel that MUST have [TLS-SESSION-HASH] negotiated.
> > >

There is, since no GS2 mechanism is secure with tls-unique without
tls-session-hash.  The fault is not GSS/SASL's, but as far as I
understand, it is a fact nonetheless.  Thus a normative reference to
tls-session-hash can be added to documents to resolve the problem, or a
new channel binding can be used.  I don't see any other solution, but
ideas welcome.

As far as I see, the tls-session-hash document does not update earlier
TLS specs to require that tls-session-hash is implemented. Thus, it is
perfectly valid and compliant to implement TLS without tls-session-hash
when used for GSS/SASL since there is no normative reference to
tls-session-hash anywhere.

Finally, I think for the forseeable future there will be widely
deployed TLS stacks without support for tls-session-hash.

/Simon

---

From: Nico Williams <[email-masked]>
Date: Sat, 23 May 2015 16:43:51 -0500

> tls-session-hash.  The fault is not GSS/SASL's, but as far as I

TLS needs fixing regardless.  tls-unique is perfectly fine when the
session hash is used.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 24 May 2015 00:44:38 +0200

Den Sat, 23 May 2015 16:43:51 -0500
skrev Re: [kitten] draft-hansen-scram-sha256 and incorporating session
hashing for channel binding:

> > > implementations need to be fixed regardless.  There's nothing
> > > GSS- or SASL-mechanism-specific here.
> > 

Perhaps this is a question for the TLS WG -- whether they intend
tls-session-hash to apply as a mandatory fix to all TLS versions or
not.  The document does not say anything about updates now, which means
"TLS needs fixing" won't necessarily happen.

/Simon

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 23 May 2015 23:57:07 +0100

> "TLS needs fixing" won't necessarily happen.

So this may be helpful or not depending on how much one
considers IETF minutae important...

During IESG evaluation we agreed to have the session hash
document be an update of 5246. The start of that thread is
at [1] and the resolution is downthread or maybe in some
other thread but was on the TLS list. The update to the
draft hasn't yet happened but will shortly.

The impact is that our formalities then expect any new TLS
code to include session hash. But that of course does not
affect already deployed code so make of that what you will.

Cheers,
S.

[1] https://www.ietf.org/mail-archive/web/tls/current/msg16231.html

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 May 2015 16:26:50 -0500

> considers IETF minutae important...

We've discussed this in the TLS WG.  There was no consensus call as
such, so... I don't know what the status is.

Regardless, it's not really appropriate for a SASL/GSS mechanism to
introduce a new TLS channel binding.  Nor is it necessary assuming that
TLS is fixed to use the session hash.

It would be appropriate to:

a) add security considerations text about the dangers of using
   tls-unique with an unpatched TLS implementation with resumed
   sessions;

b) separately pursue a new TLS channel binding, though perhaps having
   an informative references from any new SASL/GSS mech(s) on the new
   TLS channel binding.

   Normative references would belong in the _application_ protocols, not
   the SASL/GSS mechanism.

There isn't consensus for (b) yet.  I'm not against it, but I note that
it shouldn't be necessary.  The TLS session hash fix has to get
deployed, full stop.

> document be an update of 5246. The start of that thread is

It should probably also update RFC5929.  I made a comment as to that on
the DISCUSS.  There was no further discussion.

> affect already deployed code so make of that what you will.

The same is true for adding new TLS channel bindings, and adding
security considerations text to new SASL/GSS mechanisms about that:
existing TLS stacks and applications won't be using the new TLS CB.

But fixing TLS stacks to use the session hash can be done in a
backwards-compatible way at the API level, and so fixing TLS *is* the
right thing to do, and the only thing that will fix existing apps
without having to change them.

That's why I much prefer focusing on getting the TLS session hash
deployed.

> [1] https://www.ietf.org/mail-archive/web/tls/current/msg16231.html

My reply is at

https://www.ietf.org/mail-archive/web/tls/current/msg16335.html

Nico
--

---

From: Tony Hansen <[email-masked]>
Date: Tue, 26 May 2015 18:23:57 -0400

On 5/23/15 10:27 AM, Simon Josefsson wrote:
> ...

Sorry, it has the text I added because of earlier issues brought up
within this thread. No, it doesn't address tls-session-hash.

> options are to either include text similar to what I proposed above,
> or to replace tls-unique with a secure TLS channel binding (e.g.,

Your suggested text is:

    "To be secure SCRAM-SHA-256-PLUS has to be used over a TLS channel
that MUST have [TLS-SESSION-HASH] negotiated."

You then go on to say: "Personally, I would prefer to change to another
mandatory channel binding that is secure for all TLS versions."

Given the other comments in this thread, I'm not sure the suggested text
is the right thing to add.

    Tony Hansen

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 May 2015 17:32:07 -0500

> that MUST have [TLS-SESSION-HASH] negotiated."

That is fine, though I'd add "or session resumption MUST NOT have been
used".

> mandatory channel binding that is secure for all TLS versions."

This is not really appropriate here because it's the applications that
need to do this, and we can't say anything here about this that will
force them to.  But we can repeat what should be security considerations
elsewhere, especially since there's currently no RFC providing this
particular security consideration.  A reference to TLS-SESSION-HASH of
the same level (i.e., normative or informative) as RFCs 5246 and 5929
would be nice.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 May 2015 17:11:22 +0200

> > You then go on to say: "Personally, I would prefer to change to
> > another mandatory channel binding that is secure for all TLS
> > versions."
> 
> force them to.

> A reference to TLS-SESSION-HASH of the same level (i.e., normative
> or informative) as RFCs 5246 and 5929 would be nice.

I believe that what is required is

  1) scram-sha256 has a normative reference to tls-session-hash; or

  2) tls-session-hash uses an Update: that makes it applicapable to all
  TLS versions, and that it is clarified (if not already the case) that
  tls-session-hash must be used; or

  3) scram-sha256 uses a new channel binding that is secure with or
  without tls-session-hash.

I believe 1) and 2) would be worse than 3) for the next ~5 years or
so, and things being equal after that.  SASL libraries/applications
rarely have any influence over TLS internals, but they directly
influence the channel binding used.  Using another channel binding for
hansen-scram-sha256 should not be difficult, as far as I can tell --
SCRAM implementations needs to be changed to support the other stuff
for SCRAM-SHA256 so they could just as well be modified to support a
new channel binding too.  But I would not object to 1) or 2), if people
prefer that.

/Simon

---

From: Tony Hansen <[email-masked]>
Date: Thu, 28 May 2015 11:25:57 -0400

> new channel binding too.  But I would not object to 1) or 2), if people

Simon, right now scram-sha256 does not change anything in the SCRAM base
spec other than setting the hash mechanism to SHA256.

I *think* what you are asking for would actually be a change to the
SCRAM base spec, which so far has been out of scope for this document.

    Tony Hansen

---

From: Nico Williams <[email-masked]>
Date: Thu, 28 May 2015 11:40:02 -0500

>   tls-session-hash must be used; or

And RFC5929.

My vote is for (2).  I don't mind (1) in addition, but I want (2).

>   without tls-session-hash.

We disagree as to (3).  This is advice we can give to apps in the
security considerations section, not something we can force a SASL or
GSS mechanism to do because API-wise the mechanism doesn't get a choice.

> [...]

No, they don't.  Certainly not GSS ones, and the SASL implementations
I'm familiar with don't either.

E.g., GSS_Init_sec_context() doesn't get a handle to a channel to bind
to, it only gets the channel binding as already extracted by the app.
Worse, GSS_Init_sec_context() doesn't even get the channel binding type.

(3) is unworkable.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 May 2015 21:53:36 +0200

> spec other than setting the hash mechanism to SHA256.

Right.

> SCRAM base spec, which so far has been out of scope for this document.

You are right -- the SCRAM base spec has the same issue.  Depending on
which RFCs the tls-session-hash document will end up Update:'ing, it may
be necessary to revise SCRAM.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 May 2015 22:01:42 +0200

> > > This is not really appropriate here because it's the applications
> > > that need to do this, and we can't say anything here about this
> > > that will force them to.
> > 
> >   2) tls-session-hash uses an Update: that makes it applicapable to
> > all TLS versions, and that it is clarified (if not already the
> > case) that tls-session-hash must be used; or
> 
> And RFC5929.

That's not strictly necessary, is it?  5929 refer to TLS, so if
tls-session-hash update TLS specs, 5929 indirectly refer too
tls-session-hash.  At least that is how I would interprete it.  But
I'm all for making things explicit.

> My vote is for (2).  I don't mind (1) in addition, but I want (2).

There is precedent for that for TLS, several of the security fixes
Update:'s all TLS RFCs.
 
> GSS mechanism to do because API-wise the mechanism doesn't get a

I don't understand this...

> > influence the channel binding used.  Using another channel binding
> > for [...]
> 

...and I don't understand any of this.

A new channel binding in SCRAM-SHA256 would work exactly the same way
as tls-unique works in SCRAM-SHA1 today.

In my SASL library, the app has to provide the tls-unique channel
binding (either upfront or in a callback) when SCRAM-SHA1 is used.  If
I would implement SCRAM-SHA256, and assuming that document referred
directly to tls-unique-prf, the app would need to supply the
tls-unique-prf data upfront or in a callback when SCRAM-SHA256 is
used.  I don't see any problem with this.  The channel binding type is
hardcoded with the SASL mechanism name.

> (3) is unworkable.

We disagree.

/Simon

---

From: Nico Williams <[email-masked]>
Date: Thu, 28 May 2015 15:36:56 -0500

> I'm all for making things explicit.

Less not-strictly-necessary than the change you're proposing to SCRAM...

After all, it'd be useful if anyone reading RFC5929 saw that there's a
security consideration when using TLS w/o the session hash (namely: that
tls-unique is insecure when used with connections made by resuming
sessions).

> There is precedent for that for TLS, several of the security fixes

Yes.

> I don't understand this...

The mechanism is not in a position to use any one CB type or other.  The
application chooses the CB type.

> ...and I don't understand any of this.

I don't understand how you can't understand it.

GSS_Init_sec_context() doesn't have access to the TLS (or whatever)
channel, and therefore the mechanism can't be involved in getting the
channel binding.

> hardcoded with the SASL mechanism name.

The CB type is NOT a part of the mechanism name.  The CB type name is
prefixed to the CB data in the SASL/GS2 case (but not in the non-SASL
GSS case).  The best SCRAM-SHA256 could do is detect that tls-unique is
used in the SASL/GS2 case and fail.

Nico
--

---

From: Tony Hansen <[email-masked]>
Date: Thu, 28 May 2015 16:47:04 -0400

> be necessary to revise SCRAM.

One slight modification to my previous statement: I *am* updating the
SCRAM registration mechanism for SCRAM, which is turning out to be more
involved than I had originally expected. Nonetheless, I already have the
"updating RFC5802" mark on this draft. If we can agree on a (hopefully
upwards-compatible) change for the channel binding issue, it could be
done now.

However, doing so would probably also reset the IETF Last Call on it.

    Tony