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

[Karthikeyan Bhargavan <[e-mail]>]

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