Re: KDC model and atomicity

On Wed, Jun 13, 2012 at 6:41 PM, Jeffrey Hutzelman <[email protected]> wrote:
> Right.  However, note that the present attribute as described may not be
> the one that a KDC can provide, depending on how its policy works.  I'd
> suggest three attributes:
>
> - failed auths since last successful auth
> - failed auths since last key/pw change
> - failed auths since "forever"
>
> ... where "forever" does not necessarily extend past deleting and
> recreating the principal, or administratively resetting the counter, or
> whatever.

I see no point for the third one unless forever means [effectively]
"since unlock".

> All three attributes should be both read-only and optional, with the
> expectation that most KDCs will implement at most one.

At most?  As long as it isn't "at least".

> Same deal with timestamp of last successful/unsuccessful/attempt.

I'd rather not have that attribute at all.  Because why not list all
times of unsuccessful attempts since some point in time?

But also, none of this really says anything at all about password
guessing attacks.

A smart attacker will try a safe number of passwords < N for each
principal in whatever period of time the attacker can expect the users
to successfully authenticate.  This way the attacker can mount a slow
attack, but if there's lots of users the attacker can still make
progress fairly quickly.  Which really goes to my second objection: I
object to N-strikes-you're-locked.  It's not a good feature; it's a
_DoS_ attack vector where none need exist; it's hard to implement
correctly; it doesn't actually protect against password guessing
attacks, and it protects less well as the number of users in a realm
goes up.

I'd be much happier just ripping this out.  If it must stay in I want
all of it to be optional, and I want the security considerations
section to discuss the DoS issue and the low effectiveness of this
feature in stopping password guessing attacks.

>> We need to describe how to unlock a principal though.
>
> Yup.  For this I'd suggest a boolean attribute indicating the principal
> is locked out, which MAY be write-only, and in fact MAY support only
> writing a value of "false".

As long as it's clear that this can be a virtual attribute such that
modifying it is possibly equivalent to an operation.  But see above.

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