On 4 May 2016 at 21:16, Ralph Meijer <ral...@ik.nu> wrote: > > > On 04-05-16 20:45, Lance Stout wrote: > >> >> On May 4, 2016, at 7:00 AM, Dave Cridland <d...@cridland.net> wrote: >>> >>> Folks, >>> >>> I had a nice chat with Ralph Meijer, and we idly discussed replacing the >>> SASL profile in order to gain access to 2FA, fold in the Stream Resumption >>> (Florian Schmaus's design, in effect), and make it a little more >>> extensible, particularly with more detailed error messaging. >>> >>> >> The basic proposal here looks sensible to me, and support for 2FA would >> be awesome. However, it does carry the cost of needing to upgrade one of >> the fundamental parts of XMPP session negotiation. >> >> To be honest, if any such price is to be paid, I want it to bring >> significant benefits that can simplify the startup process. >> > > While Dave proposes an entirely new namespace for this, I believe that > all of the new features could be done by extending the current > functionality: > > * The new attributes could be used as-is on the current <auth/> and > <success/> elements. > > * Instead of having <continue/>, you'd have to use <failure/> more > creatively: > > * Introduce a new defined condition <continue/> (or somesuch). > > * Allow for meta-data of this condition, to hold the > optional success data and mechanisms for the next step, either > as child-elements or as an application-specific condition element. > > * If we would start allowing application-specific error conditions, > we could use <mechanism-too-weak/> as the main condition. > Unfortunately that is currently defined to only be in response to > an <auth/> request, and not after <response/>. > > * After this 'failure', the next step would simply be a new round > starting with <auth/>. > > > The down-side of this might be that we need to do this work at the IETF. > > I think the other downside is that it's getting pretty hacky - but even the strawman I proposed would need to be run through the IETF, probably. This is all very much RFC territory.
> Dave and I also discussed doing (just) 2FA from within new SASL > mechanisms, but for me that has some downsides: > > * Harder to reuse existing implementations of mechanisms, as you need > to somehow wrap the exchanges. > > * Often, a server will determine the need for another factor only > *after* completing the first one, based on the verified identity. So > a server cannot advertise such wrapping mechanism, nor can the client > choose this if presented with it. > > In practice, uou are quickly building a protocol within a mechanism. > > > The proposal is already tying itself to stream management, so let's push >> that further: >> >> 1. Opting to use new-SASL is also enabling stream management. This seems >> to be implied already for the proposal to meet its goals, but it would need >> to be more explicit. >> > > Yeah, this might be a bit weird. I wonder if, instead, we could do the > stream management exchange around SASL like so: > > C: <resume ... h='314' previd='whatever'/> > > C: <auth/> > [..] > S: <success/> > > C: <stream/> > S: <stream/> > S: <features/> > S: <resumed/> > > Maybe with some indicator that the client knows that it has to complete > SASL before resumption is acknowledged. I am thinking of an attribute on > <resume/> to that effect. This way, it could all still be a single round > trip. > > > 2. JID binding included in new-SASL success response, so no need to >> manually request a binding (maybe even go so far as to not allow requesting >> a resource, just be assigned one) >> > > Even though people have suggested that client-chosen resource is a bad > idea, I haven't seen compelling argument for it yet. A stable identifier > for specific client instances still seems like a valid use-case to me. > Also note that this is a all Core, so isn't specific to IM-type > applications. > > If you are saying that one shouldn't need / be able to bind a resource > when resuming a session, I fully agree. I expect switching resources for > a resumed session yields all kinds of weird issues. > > > Yes, this combines several existing, but related, stream features. This >> combination of features is one of the most well-trod of cow paths, and is >> what inflates the number of round-trip requests needed to start a usable >> session. >> > > Agreed. > > -- > Cheers, > > ralphm > > _______________________________________________ > Standards mailing list > Info: http://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
