[Standards] Proposed XMPP Extension: Instant Stream Resumption
flo at geekplace.eu
Tue Mar 1 17:13:08 UTC 2016
On 01.03.2016 09:26, Dave Cridland wrote:
> I wonder - and I've not thought through the implications of this -
> whether instead of trying to build a SASL-equivalent authentication into
> '198, with all that entails, is it worth approaching this from the other
> I mean instead of something like this:
> > S: <enabled
> > xmlns='urn:xmpp:sm:3'
> > xmlns:isr='urn:xmpp:isr:0'
> > isr:id='6956e8e5-b123-4a1a-9d23-939199568c4f'
> > isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>
> Something more like:
> <authenticate mechanism='YAP-SHA256-TLS-UNIQ'
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).
> 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. :)
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 603 bytes
Desc: OpenPGP digital signature
More information about the Standards