Login Failure and Sessions

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

I'm working on putting a state diagram in the EPP draft per a last-call
comment from our AD.  While working through this I came across something
that we haven't captured in the documents: what should a server do in case
of a login failure due to bogus credentials?

My preference would be for consistent behavior across all transports.  I see
a few options for dealing with login failures:

1. Send an error response and end the session/close the connection.

2. Send an error response, but allow N failures before ending the
session/close the connection.

3. Send an error response and allow an unlimited number of failures.

Option 1 is the safest for the server as it helps slow down an attacker, and
it some situations it can eliminate processing of batched commands that
won't be able to succeed because of the login failure.

Option 3 is easiest for clients, but it provides a means for a DoS attack on
the server if misused.

Option 2 is a compromise between options 1 and 3, but what's the right value
of N -- maybe three?

I'm leaning towards option 1 myself as it seems best suited for all
transports.  For example, if an email transport allows a complete
"login-commands-logout" session to be sent in one mail message, aborting
after the login failure means that all of the other commands (which won't be
able to succeed anyway because of the login failure) won't get processed,
which makes the server more efficient.  It would also work for a TCP or BEEP
transport, though it would slow down the client a little.

Any other thoughts/comments?

-Scott-