Re: draft-karppinen-imap-conman-00.txt

["RL 'Bob' Morgan" <[e-mail]>]

A few points about all this.

LDAP, which otherwise uses SASL in a very similar manner to IMAP (since it
was following the example set by IMAP), has an Unbind operation (see RFC
2251 section 4.3) which is more or less identical to the proposed IMAP
USERLOGOUT command.  I believe this was part of the DAP command set that
was just carried over into LDAP.  But certainly as the LDAP authentication
details were being worked on (in draft-ietf-ldapext-ldapv3-tls-05.txt and
draft-ietf-ldapext-authmeth-04.txt) implementors made it known that being
able to de- and re-authenticate the connection was important to them, I
think for more or less the same reasons as the pro-USERLOGOUT folks give
here.  I have no idea how much this is used in practice.

The connection-reuse strategy proposed by the USERLOGOUT proponents is
similar to the "connection pooling" technique that is universally used, in
my experience, in 3-tier database-oriented apps these days, especially
those with a web front end (ie, all new ones).  A set of database
connections is created by the app-server at system startup time, and
connections are grabbed and released by app-server threads as needed.  
The authentication story is somewhat different than it would be with IMAP,
though, since generally the app-server authenticates to the database
service as itself at connection start time, and app-level authentication
identity is one of the parameters in each database op; so there isn't a
USERLOGOUT equivalent in this case.

So, there's certainly adequate precedent in other areas for the approach
proposed in this draft; I think the question at hand is whether this is
worth adding to a protocol that doesn't have it already.  I think what the
anti-USERLOGOUT implementors are saying is that if you came to them and
said that the performance cost of simply making a TCP connection is a
substantial fraction of the total cost of starting an authenticated
session, as is claimed in the draft:

   Initial profiling suggests
   that persistent IMAP4 connections can lead to a performance increase
   of an order of magnitude when compared to separate IMAP4 connections
   per mailbox action.

that they would scurry off and make it not be so, and that this is doable,
and should be done, without requiring any protocol changes.

So, this is a performance hack.  The only way to decide whether it's
justified is with numbers.  I think it's up to the proponents to post real
observed numbers; and then for the anti- implementors to refute them or do
the implementation mods to prove that the remediation can be done without
protocol mods.

As someone mentioned, adding this capability in the context of TLS makes
things even trickier.  Let me philosophize on this point.  TLS basically
has its own set of security states that can change more or less
independently of the application protocol (SASL) states; the job of the
profile is to tie these together appropriately.  We dealt with some of
this in the ldapv3-tls spec, see specifically section 7.2 which says that
ending a TLS connection undoes any authentication state in the LDAP
connection; but that the LDAP connection itself can continue after TLS is
stopped.  (RFC 2595 doesn't address this issue, which is an omission.)  
See

 http://www.stanford.edu/~hodges/doc/StartTLSStateDiagram-8-May-1998.html

for an excellent state diagram of this behavior.  This is necessary to
specify the relevant behavior if you want TLS to be STOPpable as well as
STARTable.

Another look at RFC 2246 on TLS shows that at any time during a TLS
connection the handshake protocol can happen again, which can result in a
new set of security conditions and in particular a new client cert.  I
don't think any of the current app profiles for TLS take this into
account, even to the extent of saying "prohibited".  But if you wanted 
USERLOGOUT to work in the TLS+client_cert case (and surely this is an
increasingly important case) you'd probably say that *if* TLS is in use
and the client was authenticated via a cert, *then* USERLOGOUT would also
cause the server to issue a handshake protocol hello to renegotiate the
TLS authentication; or you might say that the TLS connection had to close,
but that's going to knock holes in the performance argument.

I find it hard to believe that performance gains (that aren't achievable
any other way) are enough to motivate USERLOGOUT as a standard facility,
given the non-trivial complexity of fully specifying (not to mention
implementing) the behavior it implies.

 - RL "Bob"