Subject: RE: [lemonade] Alternate Reconnect Model

From: [email-masked]
Date: Mon, 21 Mar 2005 09:41:32 -0600

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Rob Siemborski
> Sent: Wednesday, March 16, 2005 23:50 PM
> To: [email-masked]
> Subject: [lemonade] Alternate Reconnect Model
> 
> 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.)

Several people have tried to address this where we can sync multiple
folders simultaneously.
I don't think QR should be the method to solve this since it goes so far
beyond QR and can be a more generalized method for quick sync and
multi-folder notifications through IDLE.

>  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.

Allowing it to be issued at any time seems to defeat the purpose of
doing a QR at the beginning of the session.
I do agree that we may not want to bind the action into a specified
sequence, but allow it to be executed asynchronously.

> 
> 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.

I definitley would NOT want to allow this in non authenticated state.
It breaks the security model.
It allows DoS attacks at pre-auth time.
It also exports account state information without requiring
authentication (If no BAD or NO is received, assume the SID is correct).
This is a fundamental breach in security.

> 
> 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.

This may cause undetermenistic behavior between the client-server
communication.
Say I issue a RECONNECT w/SID pre-auth and don't authenticate.
Now I log in with another device which has a different SID.  Which SID
should the server process?
The delay in processing generates a processing hole which generates
quite a few corner cases.

> 
> 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.

Agreed, it is ugly.  I'd prefer this to be as clean and simple as
possible.
I will take a look at your sugestions and see if they mesh.
The only part here I strenuously object to is the multi folder sync.  I
think this should be a separate draft.

> 
> -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
> 

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