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
mechanism, or other such designs, most or all of which have obnoxious
operational considerations.

Besides, an implementor should not be forced to use LDAP or develop a
KDB backend with similar semantics, not for this obnoxious feature,
not if there are alternative designs that don't require it, such as:

 - Analyze logs/audit trails in real-time to decide when to
[temporarily, one hopes] lock a principal.

 - Replicate failed login attempt information in such a way that a
deterministic merge of this data is possible, allowing each KDC to
independently decide when to lock a principal.  Sam's proposal to me
(on the phone) for this is to keep a list of failed login attempt
{timestamp, id}, where the ID identifies a KDC or an AS-REQ, or is,
perhaps, just a UUID.  Such a list can clearly be merged and each KDC
can clearly use it to deterministically decide (though the timing will
depend on replication latency) when to apply a defense against
password guessing.

I'm not sure what text to propose to address this, but let's take it
one step at a time: first let's seek consensus as to my objections,
then let us write new text.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg