[Standards] Reconnections and fast reauth

Dave Cridland 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  
> speedup
> 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  
> the
>  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  
reauth, either.

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.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list