[Standards] Reconnections and fast reauth
dave at cridland.net
Thu Nov 8 10:20:25 UTC 2007
On Wed Nov 7 23:29:47 2007, Fabio Forno wrote:
> On Nov 7, 2007 11:53 PM, Dave Cridland <dave at cridland.net> wrote:
> > (Hmm, this reminds me, I need to get around to finishing and
> > publishing an I-D before the deadline on fast reauth).
> Perhaps I'm missing something... Fast reauth? You mean just a
> in the login process (e.g. a token for rebinding a session) or also
> some optimizations such as avoiding the initial presence burst when
> going online?
> One of the reasons I tend to use id bosh is the ability of keeping
> session open when the client temporary disconnects
XEP-0198 handles a lot of this, but you still have overhead involved
in the round-trips required to setup TLS and reauthenticate. Now, TLS
has some magic involved in session reuse, which allows a clever
client and server to avoid going through a full TLS session setup,
and DIGEST-MD5 has a single RTT fast reauth, too.
The trouble is, few implementations of DIGEST-MD5 fast reauth exist -
most servers force you through the full auth sequence - and
DIGEST-MD5 is getting phased out. New mechanisms don't have the fast
But in combination, there's no real reason why, given a successful
TLS session reuse, the server can't offer EXTERNAL, or something very
similar, since the server can assert that the client is "the same as"
a previous usage of the session.
This yields a single RTT auth, which, unlike DIGEST-MD5's
fast-reauth, is an assertion based mechanism, rather than a
negotiation based mechanism - the distinction being that if the
server says "Hey, I know you!", then you know that if you make that
assertion, it will result in a successful login.
In simpler language, you can pipeline the reauth, which - sort of -
eliminates the round-trip.
(The assertion, and usage of it, gets complicated by whether channel
binding has been involved, and MITMs - even legitimate ones like BOSH
- complicate the issue enormously, but you get the drift).
It's not just an XMPP thing, it hopefully applies to all protocols
using SASL and TLS, and therefore it's not a protoXEP, but an I-D.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards