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

[Simon Josefsson <[e-mail]>]

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?

I believe this is one of the serious problems with GS2, that some day
could warrant an update of it.  The problem can be resolved in the same
way as RFC 7677 did for SCRAM's use of insecure tls-unique.  Another
solution is to hard code a channel binding that has better secure
properties -- perhaps a revised version of
https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03

/Simon

5.2.  Default Channel Binding

   A default channel binding type agreement process for all SASL
   application protocols that do not provide their own channel binding
   type agreement is provided as follows.

   'tls-unique' is the default channel binding type for any application
   that doesn't specify one.

   Servers MUST implement the "tls-unique" [RFC5929] channel binding
   type, if they implement any channel binding.  Clients SHOULD
   implement the "tls-unique" channel binding type, if they implement
   any channel binding.  Clients and servers SHOULD choose the highest-
   layer/innermost end-to-end TLS channel as the channel to which to
   bind.

   Servers MUST choose the channel binding type indicated by the client,
   or fail authentication if they don't support it.