Re: KDC model and atomicity

On Jun 13, 2012, at 6:29 PM, Nico Williams wrote:

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

To some extent anyway.

> (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 think there is at least consensus that it isn't the only solution.  Possibly I'm reading too much into lack of objection to alternatives.

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

I think I'm voting for something between this and the next.

Define several optional statistics.  If the right ones are implemented, then you can do N-strikes---.  If you choose a different (hopefully overlapping) set, you can do something else.

Also provide an unlock/un-slow operation.  Our operations folk expect to be able to inspect if a user is locked (slowed?), so I'd vote for that to be readable, not only writable.

Question:  Should the "slowed" attribute be a number instead of a boolean like "locked"?  Should it be defined to be something different at all?

Another question:  Can anyone think of some other behavior that deserves discussion?  "Send warning notice if used" maybe?

Just asking.  I think I'm getting a bit too speculative.  I think I vote for just a reset operation that clears the response to the statistics, and clears (some of?) the statistics.  I think what we should worry about is what kind of statistics make sense, which includes what can be reliably exposed without requiring global KDB synchronization.

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

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email protected], or [email protected]

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