Re: [kitten] SASL, how to choose the type of channel binding?

[Dave Cridland <[e-mail]>]

On Tue, 28 Apr 2020 at 23:50, Simon Josefsson <[e-mail]> wrote:

> Dave Cridland <[e-mail]> writes:
>
> > On Tue, 21 Apr 2020 at 22:33, Simon Josefsson <simon=
> > [e-mail]> wrote:
> >
> >> Rick van Rein <[e-mail]> writes:
> >>
> >> > Hello,
> >> >
> >> > I can see that the GS2 negotiates *whether* to use channel binding,
> but
> >> > how can a client and server agree on *which* form to use?
> >>
> >> Practically it is hard-coded to 'tls-unique' that, alas, has security
> >> issues.  See RFC 7627.  GS2 does not provide any facility to (reliably)
> >> negotiate which channel binding type to use, that negotiation has to
> >> come from the SASL application protocol or out-of-band.  See section 5.2
> >> of the document.  I don't recall any SASL application protocols that
> >> provide this feature -- does anyone know of any example?
> >>
> >
> > No, but the XMPP community uses channel bindings quite heavily (or at
> > least, more so than anywhere else I've noticed).
> >
> > If you feel like throwing a XEP (or an I-D) toward the XSF on negotiation
> > of channel bindings (should be a simple stream feature), you might find
> > some interest there.
>
> I have started to think that this complexity of SCRAM/GS2 was a bad
> idea.  Providing a half-baked negotiation mechanisms for a security
> critical component invites problems.  I would be happier if this feature
> was removed, and that the channel binding type negotiation happens
> implicitly at SASL mechanism negotiation time.  This is what happens in
> practice today when SCRAM/GS2 always means tls-unique.  If nobody knows
> examples of, or intend to use, this feature, I think we should
> discourage it before someone uses it.


I'm actually not entirely sure what you mean by `this` in several cases
here (in my defence, I've been doing a lot of JavaScript recently), so
please forgive me if you think I've misunderstood you - I probably have.

Within the XMPP world, SCRAM-SHA1 and SCRAM-SHA1-PLUS are MTI mechanisms.
There are existing examples of libraries which cannot support tls-unique
due to underlying access to the binding information being unavailable.
These sometimes do not do channel binding at all, and sometimes use the
tls-endpoint binding instead. The lack of explicit negotiation makes for
entertaining cases here.

Example:
https://github.com/igniterealtime/Smack/commit/1f1bc236fd6650fba2f9e59e2aa03969b0700402

So this horse has left the station - it would be more beneficial to have a
way that the server could advertise what channel bindings it supports, in
my opinion, even if this mandates it would have to accept those binding
types across any advertised mechanisms.

That in turn isn't too bad, since the design of GS2 means that channel
binding data is explicitly passed to the server, which is then trusted to
verify it (rather than synthesize it anew). This means that an unknown
channel binding can be accepted blind, in extremis. I don't like this
design, I have to say, but it does have the advantage here.

Without explicit advertising, though, a client is forced to assume (or just
guess, or even make up a channel binding type on the spot).

Dave.