[Standards] Proposed XMPP Extension: Instant Stream Resumption

Tobias Markmann tmarkmann at googlemail.com
Tue Mar 1 18:37:10 UTC 2016


Hi Florian,

On Tue, Mar 1, 2016 at 6:13 PM, Florian Schmaus <flo at geekplace.eu> wrote:

>
> There is a reason ISR is built on top of SM, and thus the token/key is
> found only after successful SM activation, i.e. in <enabled/>. As far as
> I understand it, your suggestion doesn't provide the same key feature as
> the current ISR approach does: 0-Round Trip session resumption
> (neglecting the TLS handshake, which is not in the scope of ISR).


Right, we should aim for a minimum number of round trips for ISR, else you
could just do normal SASL for authentication.



> > I would think this design would address Tobias's current veto:
> >
> > [16:11:09] Tobias: but yeah..i'm -1, will post on list, and as it aims
> > to replace the whole SASL step for a reconnection it's currently pretty
> > light on the discussion on how it obtains the same level of security
>
> I'm still waiting for Tobias's mail. :)
>

Yes, sorry for the delay.

>
> There are different views that will come to different answers to this
> concern. For example one could say that ISR doesn't need to provide the
> same level of security that SASL does, since ISR is only possible after
> at least one successful SASL authentication. The lifetime of an ISR key
> is limited, and I assume, since I didn't hear anyone complaining yet,
> that the latest HMAC based scheme proposed for ISR provides sufficient
> security for the use case.


> Or, one could say that, if you neglect 2FA and such, a securely
> generated key with 128 or more bits is good enough. I believe the real
> answer lies in between. For what ISR tries to achieve, it's pretty
> solid, sound and more then sufficiently secure. If I wrong, then I'm
> more than happy be corrected and (if possible) fix the issues in the ISR
> approach.


Right. My major concern was that the way it was described in the proposed
XEP, the resumption provided less secure authentication compared to SASL
with SCRAM-* or SCRAM-*-PLUS, and did very little on describing what level
of authentication it provides compared t the SASL layer it proposed to
replace.

With standard TLS and SCRAM at the first authentication the client is
authenticated only by proving knowledge of the password and the server by
TLS certificate authentication and also proving knowledge of the password
to the client, both without leaking the clear password.

Something like Thijs proposal or your adaptation sounds like a sensible way
to go, considering a more depth security analysis when it's accepted.

Cheers,
Tobi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160301/0c9135f3/attachment.html>


More information about the Standards mailing list