On 1 March 2016 at 17:13, Florian Schmaus <f...@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 come from. 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 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. :) > > 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. > 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-unsubscr...@xmpp.org > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
