mailing list archives

The subject section of the RFC states that if a server has an inactivity 
autologout timer it can not be less than 30 minutes.  I'd like to propose 
that the 30 minute rule only apply to client connections that have entered 
the authenticated state.  Connections that have not authenticated could be 
subject to a much shorter timeout value, perhaps 1 minute or less. 
Thoughts/comments ... Perry

Perry Ruiter
250-658-6517
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20061123/d3343de3/attachment.html>

On Thu, 23 Nov 2006, Perry Ruiter wrote:
>   The subject section of the RFC states that if a server has an inactivity 
> autologout timer it can not be less than 30 minutes.  I'd like to propose 
> that the 30 minute rule only apply to client connections that have entered 
> the authenticated state.  Connections that have not authenticated could be 
> subject to a much shorter timeout value, perhaps 1 minute or less.

Section 5.4 was never intended to apply to non-authenticated sessions.

I have made a note in the RFC 3501 errata to add "that applies to sessions 
after authentication" before the comma.
 	ftp://ftp.cac.washington.edu/mail/imap.rfcs/rfc3501-errata

This explicitly makes the specification be silent on the question of 
autologout prior to authentication, and not imply that the 30-minute rule 
applies to non-authenticated sessions.

I believe that the specification should be silent on that point, as 
otherwise it triggers security considerations.  By being silent, it is 
left up to implementation discretion, and possibly a future security rule 
imposed by the IESG.

For what it's worth, UW imapd has a 3 minute pre-authentication autologout 
timer.  There are actually two pre-authentication autologout timers: the 
normal inactivity autologout timer, and an non-authenticated session age 
time which is enforced at command completion.  The latter is cancelled by 
a successful authentication; a session could be over-age but still within 
the 3 minute inactivity grace, but it must authenticate at that point. 
The upshot is that a non-authenticated session will die between 3 and 6 
minutes from its startup.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Thu, 23 Nov 2006, Mark Crispin wrote:

> For what it's worth, UW imapd has a 3 minute pre-authentication autologout 
> timer.  There are actually two pre-authentication autologout timers: the 
> normal inactivity autologout timer, and an non-authenticated session age time 
> which is enforced at command completion.  The latter is cancelled by a 
> successful authentication; a session could be over-age but still within the 3 
> minute inactivity grace, but it must authenticate at that point. The upshot 
> is that a non-authenticated session will die between 3 and 6 minutes from its 
> startup.

This addresses a concern that immediately came to mind, that of someone 
setting a 30 second timeout. Remember that the client can't prompt for a 
password until it knows which authentication mechanism is to be used. So 
we wind up with a scenario like:

C: 0 authenticate digest-md5
[client asynchronously prompts user for password]
S: + mumblefooetc ...
[user fumbles for scrap of paper with password, then slowly types it in, 
backspacing and correcting along the way ...]
S: * BYE you type too slowly
[server closes connection]
[client terminates login attempt due to server error]

I admit this is a bit contrived, but people will do stupid things in the 
name of "security."  And too often people assume best case behaviour of 
the network (and software, for that matter).  Instead of a slow typer, 
imagine a BGP route flap, or just plain old router conjestion induced 
packet loss that forces the TCP session into exponential backoff.  Voila, 
you cannot log in.

So, if you do change the errata, please mandate a minimum 5 minute timer 
in pre-authenticated state so that we can retain some robustness in the 
protocol


--lyndon

   NT as a file server is faster than a dead bat carrying Post-It notes
   underwater. But not by much.

On Thu, 23 Nov 2006, Lyndon Nerenberg wrote:
> So, if you do change the errata, please mandate a minimum 5 minute timer 
> in pre-authenticated state so that we can retain some robustness in the 
> protocol

Sadly, just about every attempt to legislate against stupidity in protocol 
specifications have been miserable failures...  :-(

Isn't 5 minutes excessive?  Nobody has ever complained about UW imapd's 3 
minute timer.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

On 23 Nov 2006, at 23:20, Lyndon Nerenberg wrote:

> On Thu, 23 Nov 2006, Mark Crispin wrote:
>
>> For what it's worth, UW imapd has a 3 minute pre-authentication  
>> autologout timer.  There are actually two pre-authentication  
>> autologout timers: the normal inactivity autologout timer, and an  
>> non-authenticated session age time which is enforced at command  
>> completion.  The latter is cancelled by a successful  
>> authentication; a session could be over-age but still within the 3  
>> minute inactivity grace, but it must authenticate at that point.  
>> The upshot is that a non-authenticated session will die between 3  
>> and 6 minutes from its startup.
>
> This addresses a concern that immediately came to mind, that of  
> someone setting a 30 second timeout. Remember that the client can't  
> prompt for a password until it knows which authentication mechanism  
> is to be used. So we wind up with a scenario like:
>
> C: 0 authenticate digest-md5
> [client asynchronously prompts user for password]
> S: + mumblefooetc ...
> [user fumbles for scrap of paper with password, then slowly types it  
> in, backspacing and correcting along the way ...]
> S: * BYE you type too slowly
> [server closes connection]
> [client terminates login attempt due to server error]

But the client will store (securely) the password locally and send it  
automatically without the user has to type the password.
The alternative for the client is to reconnect to send the password  
that was typed if the session disconnected (it will occur once while  
the password is still valid if the password is stored on client-side  
(hopefully passwords don't change too often)).

-- 
DINH Vi?t Ho?

> Isn't 5 minutes excessive?  Nobody has ever complained about UW  
> imapd's 3 minute timer.

I guess I'm sensitive to this right now as I've been battling some  
horrible network conditions at work for the last week.  The OpenSSH  
default timeout of 45 seconds makes it impossible for me to try to  
fix the problem, because I can't stay logged in long enough to even  
begin to find out where the problem is.  This ranks right up there  
with the five-minute TCP session state timeouts in most of the low  
budget home wifi/nat/router appliances.

Given that an IMAP server doesn't have a problem with sitting idle in  
selected state for 30 minutes, I really don't see an argument why it  
can't cope with 5 minutes in pre-auth state.

If the server is really starved for resources and has to start  
killing off connections then all bets are off anyway, and I would  
expect a smart server to blow off pre-auth sessions first, down to a  
certain idle time, and then attack authenticated connections in a  
similar manner.  There are lots of ways to decide how, and many  
depend on what resources are important to the server.

But in the absence of server resource starvation, it is not  
unreasonable to ask for five minutes grace to accommodate problems  
the server has no knowledge of.  This is just good defensive protocol  
design.

--lyndon

On Thu, 2006-11-23 at 16:48 -0800, Mark Crispin wrote:
> On Thu, 23 Nov 2006, Lyndon Nerenberg wrote:
> > So, if you do change the errata, please mandate a minimum 5 minute timer 
> > in pre-authenticated state so that we can retain some robustness in the 
> > protocol
> 
> Sadly, just about every attempt to legislate against stupidity in protocol 
> specifications have been miserable failures...  :-(
> 
> Isn't 5 minutes excessive?  Nobody has ever complained about UW imapd's 3 
> minute timer.

Dovecot has 1 minute and no-one's ever complained about that either. But
I hadn't thought too much about that value, I guess I'll increase it to
3 minutes as well.

I think most people use clients which save the password so this isn't an
issue for more than a couple of people, and those are probably fast
enough typers anyway since they're willing to write their password every
time.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20061124/f518c284/attachment.sig>

> But the client will store (securely) the password locally and send it 
> automatically without the user has to type the password.

Please point out the text in RFC 3501 that mandates that client behaviour.


--lyndon

   If you were plowing a field what would you rather use, 2 strong oxen or
   1024 chickens?
   			-- Seymour Cray (apocryphal)

Hi Lyndon -

I agree with you *completely* about the excessive propensity of certain 
modern network software to destroy sessions in the face of temporary 
network conditions.

Please remember that I was dragged from the TOPS-20 world, kicking and 
screaming.  I remember well the good old days where, if the network got 
cut (and that happened a lot in the "good" old days) for a few hours, I 
could just keep paws off the TELNET client; once the network was restored, 
my session to the TOPS-20 server would still be there.  Even if the 
connection was declared lost, the session would merely be detached, not 
killed, and could be reattached to a new session.

But the world went a different way.  Ultimately HTTP will be the only 
protocol.  :-(

I don't think that extending an IMAP server's non-authenticated timeout 
will changing the tide; nor does anecdotal evidence suggest otherwise.  I 
am surprised to learn that the Dovecot server got away with a 1 minute 
timeout (but note that he's changing it to match UW's 3 minute).

I just don't see how 3 minutes for non-authenticated sessions is a 
problem, or why 5 minutes would be a benefit.  I oppose the proposal to 
stipulate 5 minutes on the grounds that it's unnecessary and it renders 
currently-compliant implementations non-compliant.

I also think that it's a bad idea to put security policy in a protocol 
without input from the security wonks.  For all I know, the SWs may turn 
around and say that 3 minutes is too long and it needs to be shortened.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Lyndon Nerenberg wrote:

> > But the client will store (securely) the password locally and send it 
> > automatically without the user has to type the password.
> 
> Please point out the text in RFC 3501 that mandates that client  
> behaviour.

That's implementation details. At least, RFC 3501 don't disallow this.
Similarly, RFC 3501 does not disallow you to use a hard drive to store  
your messages on server side.

-- 
DINH V. Hoa

> I just don't see how 3 minutes for non-authenticated sessions is a problem, 
> or why 5 minutes would be a benefit.  I oppose the proposal to stipulate 5 
> minutes on the grounds that it's unnecessary and it renders 
> currently-compliant implementations non-compliant.

Okay, I'm not going to beat this to death.  But I am going to set the 
pre-auth idle timeout to 1 second on everyone's IMAP servers :-P


--lyndon

   >What about all the people who hoarded tonnes of spam in their bunkers?

   I hoard spam on my hard drive.  When I heard about the coming
   Y2K worries, I downloaded a lifetime supply from the net.
   			-- Charlie Gibbs in alt.folklore.computers