Re: [sasl] [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Wed, Nov 04, 2009 at 03:34:38PM +0100, Pasi.Eronen at nokia.com wrote:
> Simon Josefsson wrote:
> > This reminded me of an earlier observation, and it might be relevant
> > to re-iterate it here.  Consider this:
> > 
> > Day 1:
> > 
> > 1. Client establish TLS anon-anon to server.
> > 2. User authenticates using SCRAM with channel binding to the TLS
> >    channel
> > 3. User/client disconnects
> > 
> > Day 2:
> > 
> > 4. Client resumes the TLS anon-anon connection
> > 5. Client rehandshake with X.509 client + server authentication
> > 6. User authenticates using SCRAM with channel binding to the
> >    TLS channel
> > 7. User/client disconnects
> > 
> > Day 3:
> > 
> > 7. Client resumes the TLS session
> > 8. Client rehandshake it as anon-anon
> > 9. User authenticates using SCRAM with channel binding to the
> >    TLS channel
> > 10. User/client disconnects
> > 
> > With draft-altman-tls-channel-bindings-07, the channel binding data
> > used in all three SCRAM authentications is the same bit sequence.
> 
> That certainly was not the intent (the Finished messages used by
> SCRAM would be from steps 1, 4, and 7 -- and they're all different).

Indeed, that's absolutely not the intent.  The intent is that you use
the first client Finished message sent on each of those "connections".

Note, incidentally, that Simon's view of how tls-unique was intended to
work, would not be flawed, cryptographically.  It wouldn't interoperate
with other implementations, and it'd be hard to implement (since it
means updating saved session state).  It would conflict the very name of
the channel binding type and it's description as being a "unique"
channel binding type in the RFC5056 sense -- that should be the biggest
clue that Simon's interpretation is incorrect.

I have a very, very hard time understanding how this might not by now be
clear.  It doesn't help that TLS doesn't have a name for the entity from
which we're extracting the channel binding, but that's the only real
problem here.

I also have a very, very hard time understanding how the previous text
could have led anyone to think that TCP connection state should track
TLS channel binding data.  RFC5246 may not have a name for the entity...
but it does speak of "TLS connections", which you can see from the
naming of section 6.1: "Connection States".

Nonetheless I'm happy to revise text to make this matter clearer.  I'd
be happy even to introduce text naming that entity which RFC5246 does
not name.

Nico
--