[Standards] A new SASL Profile strawman

Dave Cridland dave at cridland.net
Wed May 4 19:16:18 UTC 2016


On 4 May 2016 at 19:45, Lance Stout <lancestout at gmail.com> 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.
>
>
Yes, indeed.


>
> To be honest, if any such price is to be paid, I want it to bring
> significant benefits that can simplify the startup process.
>
>
The (possibly hopeful) intention is that we should be able to "tack on"
other startup costs into the same exchange.


>
> 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.
>

Seems entirely reasonable; though we could simply make the negotiation
explicit.


> 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)
>
>
Great idea! And one that proves the initial extensibility isn't there, too.
However, I'll resist having entirely server-assigned resource strings.
There's a number of cases where not having the client able to specify a
resource string makes things much more complex (and introduces round-trips,
in fact).

Perhaps if we add an inner element to <authenticate/> and
<next-authenticate/> to enclose the initial response?

Something like:

<authenticate xmlns='urn:xmpp:sasl' mechanism='SASL-MECH-NAME'
      [sm-id='SessionResumptionIdentifier' h='314']
  >
  <initial-response>
    SW1wcm92ZWQgZW5jYXNwdWxhdGlvbiBvZiBvcHRpb25hbCBTQVNMLUlSIGRhdGE=
  </initial-response>
</authenticate>

Then the bind request can be embedded in with the <authenticate/>:

<authenticate xmlns='urn:xmpp:sasl' mechanism='SASL-MECH-NAME'
      [sm-id='SessionResumptionIdentifier' h='314']
  >
  <initial-response>
    U0FTTC1JUiBlbmNvZGVkIGFsb25nc2lkZSBiaW5kIHJlcXVlc3Q=
  </initial-response>
  <bind xmlns='urn:xmpp:whatever:bind:is'>Office</bind>
</authenticate>

We'd want the bind result to be embedded into the <success/> and/or
<continue/>.


>
> 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.
>
>
Summarizing the chat Lance and I had over IM:

- Lance wasn't clear there was any point in offering a list of next
mechanisms in <continue/>, I suggested that only having one was probably
the usual case but it didn't hurt to have the capability for multiple
options.
- Lance also suggested that having a <text/> indicator for why the continue
was requested would be useful. We may have to think this through if there's
multiple next mechanism choices.
- We agreed that at the <continue/> and <success/> points, the client
should be told its bare jid (and maybe full in the bind case).

Dave.


>
> /Lance
>
>
> _______________________________________________
> 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/2996f1c7/attachment.html>


More information about the Standards mailing list