[Standards] Proposed XMPP Extension: Instant Stream Resumption
dave at cridland.net
Tue Mar 1 19:52:48 UTC 2016
On 1 March 2016 at 17:13, Florian Schmaus <flo at geekplace.eu> wrote:
> 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
> > direction?
> > 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'
> > isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'>...</authenticate>
> 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).
FWIW, ISR is 1-RTT, unless you pipeline through, which doesn't really
count. Calling it 0-RTT is marketing.
So the main reason I'm thinking of wrapping ISR around SASL is because ISR
replaces SASL to some degree, which is where Thijs and Tobias's concerns
If you wrap ISR around SASL - and we can discuss removing the stream
restart post-SASL in this case, too - then the security properties of the
authentication portion of ISR become a matter of choosing the SASL
mechanism, which is both vastly simpler to define and also allows us to
easy handle things like hash agility.
To put it another way, ISR effectively combine the authentication and 198
into one step. Your proposal builds ISR by taking '198, and adding a brand
new authentication mechanism. I'm suggesting that it seems worthwhile to
explore building it the other way around, so we take SASL and add the '198
bits we need onto that.
The net result will be identical, except that the bits most likely to
require changing have already-existing discovery and selection.
For example, assuming we remove post-SASL stream restarts if ISR is in
play, using SASL PLAIN gives the same number of RTTs, and the same security
properties, as the original ISR proposal. Using YAP would be 1-RTT with
channel binding. Using SCRAM would be 2-RTT, with SASL-level mutual
> > 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
I think your proposal is trying to be a one-size-fits all approach, and I
don't think such an approach is either viable or desirable.
> - Florian
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards