Re: KDC model and atomicity

Nico Williams <[email protected]> Wed, 13 Jun 2012 20:29:16 -0500
Newsgroups gmane.ietf.krb-wg
Message-ID <CAK3OfOhcfmbSsKZc4PSy8M0rkqsjiLsssLFa8HPPgkZbt3Sj0g@mail.gmail.com>
On Wed, Jun 13, 2012 at 7:31 PM, Henry B. Hotz <[email protected]> wrote:
>> 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.
>
> The Kerberos admin may not get a choice.  There are lots of N-strikes--- requirements out there.  If you can't support the requirement maybe you have to use a different technology.

As a reputable standards development organization we get a say, and as
a result we get to influence the situation and perhaps improve the
admin's ability to resist this bit of cargo cult.

(I know of several places where log/audit analysis is used to
heuristically detect and respond to password guessing attacks in
better ways than locking the hapless user.  And they do this *in
spite* of putative requirements to implement N-strikes-you're-locked.
When you dig you find that either what's required is a mitigation of
password guessing attempts, or that alternative solutions are
acceptable.)

> There appears to be consensus for defining some generic statistics the model could expose, and leaving the actual interpretation and resulting actions to the specific implementations?  (Except that an unlock action is clearly needed.  I'd generalize that to something that can clear an intentional slow-down as well.)

It's not yet clear to me that there's a consensus that we should do
anything in particular regarding N-strikes-you're-locked.

I'd be happy with any of these results, in order of preference:

 - We say no to N-strikes-you're-locked, but possibly list some
   things that implementations might do to detect and respond
   to password guessing attacks.

 - We discourage N-strikes-you're-locked, but ...

 - We specify OPTIONAL interfaces for dealing with
   N-strikes-you're-locked and explain why they are optional.

 - We say nothing at all about N-strikes-you're-locked, but
   possibly specify a locked attribute.

We are making progress on my objection to atomicity requirements, at
least, but I'd like us to also address my objection to
N-strikes-you're-locked.

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