On 04-05-16 20:45, Lance Stout wrote:
On May 4, 2016, at 7:00 AM, Dave Cridland <[email protected]> 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.
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: [email protected]
_______________________________________________
