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

[Rick van Rein (OpenFortress)]

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

[Rick van Rein (OpenFortress)]

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

[Luke Howard]

(Once more from correct email address –)

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

Luke Howard

web / facebook / instagram / spotify

On 9 Apr 2020, at 11:30 pm, Rick van Rein <[hidden email]> wrote:

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

[Simon Josefsson-2]

Rick van Rein <[hidden email]> 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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

[Dave Cridland]

On Tue, 21 Apr 2020 at 22:33, Simon Josefsson <simon=[hidden email]> wrote:

Rick van Rein <[hidden email]> 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.

Dave.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

[Rick van Rein (OpenFortress)]

Hello,

> Practically it is hard-coded to 'tls-unique' that, alas, has security
> 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)
> negotiate which channel binding type to use, that negotiation has to
> 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
> of the document.  I don't recall any SASL application protocols that
> provide this feature -- does anyone know of any example?

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.

> 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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

[Simon Josefsson-2]

Dave Cridland <[hidden email]> writes:

> On Tue, 21 Apr 2020 at 22:33, Simon Josefsson <simon=
> [hidden email]> wrote:
>
>> Rick van Rein <[hidden email]> 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.

/Simon

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

[Dave Cridland]

On Tue, 28 Apr 2020 at 23:50, Simon Josefsson <[hidden email]> wrote:

Dave Cridland <[hidden email]> writes:

> On Tue, 21 Apr 2020 at 22:33, Simon Josefsson <simon=
> [hidden email]> wrote:
>
>> Rick van Rein <[hidden email]> 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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten