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

From: Rick van Rein <[email-masked]>
Date: Thu, 09 Apr 2020 15:10:49 +0200

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?

Thanks,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Thu, 09 Apr 2020 15:30:42 +0200

Oops,

I was blinded... have been focussing on the three forms, overlooking that there is a value after "p".

    gs2-cb-flag     = ("p=" cb-name) / "n" / "y"
                      ;; GS2 channel binding (CB) flag
                      ;; "p" -> client supports and used CB
                      ;; "n" -> client does not support CB
                      ;; "y" -> client supports CB, thinks the server
                      ;;           does not

Sorry :)
 -Rick

---

From: Luke Howard <[email-masked]>
Date: Thu, 9 Apr 2020 23:46:13 +1000

(Once more from correct email address –)

There’s an implementation of GS2 in Cyrus SASL if it helps.

Luke Howard
web <http://lukehoward.com/> / facebook <https://www.facebook.com/lukehowardmusic> / instagram <http://instagram.com/lukehowardmusic/> / spotify <https://open.spotify.com/artist/3duTXsC49HoPt4f4EySDKf>

> On 9 Apr 2020, at 11:30 pm, Rick van Rein <[email-masked]> wrote:
> 
> Oops,
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 21 Apr 2020 23:33:00 +0200

> 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.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 21 Apr 2020 23:12:48 +0100

> 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.

Dave.

---

From: Rick van Rein <[email-masked]>
Date: Wed, 22 Apr 2020 12:29:54 +0200

Hello,

> issues.  See RFC 7627.

You mean that it requires extended master secrets to be reliable, right?
 AFAIK that has been fixed most everywhere?

> GS2 does not provide any facility to (reliably)
> come from the SASL application protocol or out-of-band.

Yes, that is the sort of thing I was also thinking of.  It's resolved in
the place where I want to use it --an encrypting wrapper around a SASL
exchange to support forwarding it-- by incorporating the GS2 header into
the key computions.  (Current spec does not do this yet.)

> See section 5.2

Coming up :-)

I need it to support realm crossover, which I am developing in
draft-vanrein-diameter-sasl
which we have working, though not stable enough to demo.

> https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03

Well, with channel binding modifying the computation there would at
least be a detection if the SASL client and server don't agree.  And
with the server aware of offering a non-PLUS mechanism, it should be
prepared to see clients not requesting channel binding.  Intermediates
could only cause degredation if both client and server are willing to
adopt the level of security without channel binding.

Thanks,
 -Rick

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Apr 2020 00:50:05 +0200

> of channel bindings (should be a simple stream feature), you might find

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.

/Simon

---

From: Dave Cridland <[email-masked]>
Date: Wed, 29 Apr 2020 09:17:10 +0100

> 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.