Re: KDC model and atomicity

On Wed, 2012-06-13 at 09:41 -0400, Simo Sorce wrote:
> On Wed, 2012-06-13 at 14:57 +0200, Leif Johansson wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > 
> > > To me, that means a schema must be able to map to/from that
> > > attribute in the data model. It's entirely reasonable for a schema
> > > to store more information so long as the mapping exists. Nico has
> > > proposed an excellent mapping of this attribute to LDAP: a list of
> > > failed authentications. What in the current text prohibits that?
> > 
> > Because if you need it to be reset at each successful authn then
> > if C(lient) talks to K1 and first fails n-1 times, then succeeds
> > once and fails once and if K2 receives status updates from K1 then
> > if the message about the success arrives after the message about
> > the last failure then a mgmt client talking to K2 could lock
> > the user before the success message arrived at K2 to reset the
> > counter. I'm not sure how mapping the attribute helps there...
> 
> FWIW we currently do note replicate the account lock/success status in
> our LDAP setups, because it completely kills replication infrastructure.

As it turns out, regardless of whether failed-auth status is fully
replicated, fully independent, or propagated only from the master to the
slaves, it is possible for a given set of policy parameters to compute
an upper bound on the number of tries an attacker gets before the
lockout or throttling mechanism prevents any further tries.


It is certainly possible to apply a hand-wavy "three strikes" policy, in
which case replication might become a problem.  However, for those being
more careful, the goal is generally to satisfy a set of constraints that
relate required password strength to the number guesses an attacker gets
over the life of the password.  The latter of course is controlled by
lockout and throttling mechanisms as well as by maximum password
lifetimes and related parameters.  In such cases it is totally possible
to take into account the effects of replication, and even 15 tries
(worst case for 3 tries and 2 slaves) is not impossible to overcome with
appropriate password lifetime and strength policies.


In any case, what we're talking about right now is a data model.  It's
supposed to provide a _model_ of the data the KDC needs to do its job,
or rather the subset of that data which we might want to observe and
manage in a standardized way.  It does not need to be all-inclusive; a
KDC can and should store whatever data it needs to implement whatever
lockout policies it supports.  It also does not need to contain only
fields which every KDC must support.  And, it's _only a model_; it does
not require that values be stored or computed in a particular way, only
that they behave according to the specified semantics.



I think it is entirely reasonable for the data model to include a failed
authentication count for a principal.  If it does, it must be specific
about the semantics of such a value, including details like whether it
is reset on successful authentication, when the keys are changed, or
never.  Without that information, it is useless to standardize the
value, because people and especially code looking at it won't know what
it means.  Because of this, it may turn out to be useful to specify
several different values with different semantics.  Probably none of
those should be required.


Remember, the goal here is not to nail down the contents of the KDB or
require implementations to work in a particular way.  It's to produce a
_model_ of what's in the KDB, to serve as the basis for interfaces to
view and manipulate that data.

-- Jeff

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