[Standards] A new SASL Profile strawman

Ralph Meijer ralphm at ik.nu
Wed May 4 20:16:27 UTC 2016



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

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


More information about the Standards mailing list