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 |
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 |
(Once more from correct email address –)
There’s an implementation of GS2 in Cyrus SASL if it helps.
_______________________________________________ Kitten mailing list [hidden email] https://www.ietf.org/mailman/listinfo/kitten |
In reply to this post by Rick van Rein (OpenFortress)
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 |
On Tue, 21 Apr 2020 at 22:33, Simon Josefsson <simon=[hidden email]> wrote: Rick van Rein <[hidden email]> writes: 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 |
In reply to this post by Simon Josefsson-2
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 |
In reply to this post by Dave Cridland
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. 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 |
On Tue, 28 Apr 2020 at 23:50, Simon Josefsson <[hidden email]> wrote: Dave Cridland <[hidden email]> writes: 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. 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 |
Free forum by Nabble | Edit this page |