KDC model and atomicity (was Re: Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt])

I'm quite concerned about the failed authentication count and last
failed authentication timestamp fields.  Their purpose is, clearly, to
implement N-strikes-you're-locked.  Setting aside the wisdom of such
policies, I have a fundamental objection to the prescriptive nature of
the I-D regarding implementation: the prescribed implementation design
requires atomic increment operations on the KDB, something that is
rather difficult to obtain, has far reaching design and operational
considerations, and is unnecessary to the implementation of
N-strikes-you're-locked.

Specifically I object to any requirement, particularly any implied
requirement, that a KDC support atomic operations on principal
records.  We have never before had such a requirement, and to add it
now for a controversial feature (a DoS, for goodness' sake) is... not
acceptable.

I also object to the idea that the only correct  (required to
implement) response to password guessing attacks is to lock the
principal.  Other possibilities include: delay replies to AS-REQs for
principals under attack (Hank's suggestion, IIRC), bring forward
password expiration for the principal, or inform the affected user /
ask them if the failed login attempts are theirs or not.

I understand that LDAP is supposed to support such operations, but we
all know of at least one major implementation that does not implement
such atomicity.  Moreover, just because LDAP is supposed to provide
for atomic modify operations does not mean that it's a good idea to
rely on that feature, or that it's easy to implement it....  LDAP
atomic modifies imply either single mastering (possibly with
elections), single mastering individual objects, a distributed locking