[Standards] A new SASL Profile strawman

Dave Cridland dave at cridland.net
Wed May 4 21:39:02 UTC 2016


On 4 May 2016 at 21:16, Ralph Meijer <ralphm at ik.nu> wrote:

>
>
> 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.
>
>
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-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160504/1b94f6bd/attachment-0001.html>


More information about the Standards mailing list