Subject: [lemonade] Alternate Reconnect Model

From: Rob Siemborski <[email-masked]>
Date: Wed, 16 Mar 2005 23:49:32 -0500 (EST)

The current authentication model used by the reconnect draft has several problems.

* The MITM attack I described earlier
* The problem of how to send the untagged responses directly following a
successful AUTHENTICATE or LOGIN command.

Additionally, it might be nice to be able to do multiple reconnects within 
a single connection (e.g. maintain a session for each of several folders, 
so that one would not have to reconnect in order to avoid resyncing each 
session.)  I propose the following model instead of what is in the current 
draft:

Instead of extending both LOGIN and AUTHENTICATE, add a separate RECONNECT 
command that takes an SID, and may be issued at any time during the 
session.

In this model, if the RECONNECT command is issued in a non-authenticated 
state, then the request is simply queued by the server (note that the 
server may issue an immediate BAD, but SHOULD NOT issue an immediate NO if 
the SID is bad, since the user isn't authenticated).  Obviously since the 
user isn't authenticated, an OK isn't possible. Note that these responses 
are all tagged.

When the session does finally enter the AUTHENTICATED state, then the 
server can finally process the RECONNECT command.  This allows the 
reconnect untagged responses to have their own tagged OK to indicate that 
the server has completed sending them, and does not potentially cause a 
problem with sending untagged responses before the AUTHENTICATE OK.

Note that it is probably prudent that if any commands are between the 
RECONNECT and the AUTHENTICATE or LOGIN, then the server SHOULD respond NO 
to the RECONNECT before processing the other command.  If another 
RECONNECT is issued before authentication, the server MUST respond NO to 
the first.

Also note that the RECONNECT can be pipelined with an AUTHENTICATE or 
LOGIN safely.

This model looks something like:

C: a RECONNECT (SID foo)
C: b AUTHENTICATE MY-MECH
S: + asdf
C: hjlk
S: b OK User Authenticated
S: * NEWSID asdf
S: * FOLDER INBOX
S: a OK Session Resumed

Note that this is the first time that we'd be actually requiring a server 
to perform out of order responses, but this is definately allowed by the 
spec (and clients should be able to support it for non-ambiguous cases 
such as this even today).

This also significantly mitigates the MITM problem (as I sent in my 
message, the server should also be sending back the SID to the client 
now).  This will still result in some data being improperly sent by the 
server, however.  But the client can completely avoid this at the expense 
of an additional round trip if it waits to send the RECONNECT until after 
the authentication has completed (provided this is all under integrity 
protection of course :).

----

You can also now perform multiple reconnects during a session.  Simply 
record the current modseq and contents, then issue a new RECONNECT 
command.  (It may be nice to extend CLOSE and UNSELECT to allow you to 
checkpoint a session also).

About the only thing I don't like about this is that it creates an 
interaction between two commands where the server needs to wait for the 
second before it responds to the first, which is ugly, but the benefits 
might be worth it.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Dave Cridland <[email-masked]>
Date: Thu, 17 Mar 2005 08:58:36 +0000

> successful AUTHENTICATE or LOGIN command.

Out of interest, is there any comparison in round-trips and data transfer between using RECONNECT and using the equivalent commands, assuming a CONDSTORE capable server, etc?

As far as I can tell, RECONNECT is purely a shorthand - nothing in either the current draft, nor Rob's suggestion here, gains any functionality over and above CONDSTORE.

Something like:

C: A01 AUTHENTICATE XMECH
...
S: A01 OK Completed.
C: A02 SELECT INBOX
C: A03 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 1)
C: A04 UID SEARCH RETURN (ALL) UID 3000:*
S: ...

This is assuming that the A04 above is good enough to find all expunged messages, which generally speaking it seems to be in my experience.

This exchange appears, to me, to add one round-trip over RECONNECT, but not require a new extension. Moreover, it's reusable, just as Rob would like - A02-A04 above can be pipelined again for a different mailbox. The client just has to cope with A03 and A04 both returning BAD in the case where the SELECT fails.

Am I missing some crucial functionality here?

Dave.