Re: KDC model and atomicity

On Wed, Jun 13, 2012 at 4:55 PM, Jeffrey Hutzelman <[email protected]> wrote:
> 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.

However, the user experience may not be as deterministic.  I'm
referring here not to lockout but to unlock upon successful
authentication.  Failed auth counts might accumulate on some KDCs but
not others and sometimes the user may get lockout errors and other
times it just works.  I want the user experience not to suck.

> 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

The key here being about what we want to observe and manage.  We only
need to manage:

 - policy (value of N)

 - unlock a principal

We do not need to manage the count of failed authentication attempts.
That's an implementation detail.  We may need to observe it.

Given that I think it'd be good to leave this attribute in place but
describe it as read-only.

We need to describe how to unlock a principal though.

> 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

Or manually (by an admin).

> 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.

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