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

[Simon Josefsson <simon at josefsson.org>]

Simon Josefsson <simon at josefsson.org> writes:

> http://josefsson.org/sasl-gs2/draft-josefsson-sasl-tls-cb-02.txt
>
> It makes sure to bind the channel binding uniquely to BOTH the current
> connection and the current session.  The
> draft-altman-tls-channel-bindings-07 document only binds to the current
> TLS connection.  So from this perspective, my work has the same issue,
> but it is different in other aspects.

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 means
there is only an indirect cryptographic binding between the SCRAM user
authentication and the X.509 client authentication.

/Simon