[Standards] Proposed XMPP Extension: Instant Stream Resumption

Florian Schmaus flo at geekplace.eu
Wed Feb 17 18:18:01 UTC 2016

On 17.02.2016 17:29, Daniel Gultsch wrote:
> The remote-tok thing doesn't work because at this point it is already
> too late as the server (read a potential MiM attacker) already receiced
> the token. I think the server needs to be authenticated before the
> clients sends the tok. Or am I misunderstanding the problem? Maybe the
> client could at the very least verify that the certificate hasn't changed?

You are right, exposing the 'tok' in <inst-resume/> without having the
server verified seems like a bad idea.

How about

- hashing 'tok' in <inst-resume/> then (and maybe even hashing
'prev-remotetok' in <inst-resumed/>), so that they are not exposed
- requiring the initiator to save the server cert and verify that it
hasn't changed (which matches ISR's design principle to expose the 'tok'
only over TLS secured connection, thus requiring TLS for ISR)
- doing both of the above

I always liked the mutual authenticated of modern SASL mechanisms. I
didn't thought about haveing that property in ISR, because unlike SASL
passwords, the ISR token is ephemeral as it is limited to the maximum SM
resumption period, which should be usually something like a few minutes.

But if the above mentioned approaches add mutual authentication, without
having to introduce another step or round-trip, then I'm happy to add it
to the XEP.

Your comments please. :)

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160217/6ee829d0/attachment.sig>

More information about the Standards mailing list