Re: KDC model and atomicity

Nico Williams <[email protected]> Wed, 13 Jun 2012 21:56:09 -0500
Newsgroups gmane.ietf.krb-wg
Message-ID <CAK3OfOiqAM8xzFAA9qE3ufQgk4efGr907P3cj3pHgnQzREwiXQ@mail.gmail.com>
On Wed, Jun 13, 2012 at 9:35 PM, Henry B. Hotz <[email protected]> wrote:
>> - 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.

The problem with this is that there's a lot of stats that an
implementation could produce, but the KDC data model barely touches on
that, and if all it covers is a failed auth count with limited
semantics, well, then it's rather lame.  I'd much rather think about
what we want generically for stats out of a KDC.  I've been wanting
(and developed) some schemas based on aggregations of log data and
having that replicated so all log entries are properly aggregated and
made available at least on a master KDC.  This is a much saner
architecture that, among other things, might make it much easier to
heuristically detect password guessing attacks.  But so far we've not
even broached that subject (just did!).

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

Yes, of course.

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

It should probably be a rate expressed in pre-auth attempts per unit
of time.  (This should not be locally adjusted for number of KDCs
because that presumes knowing how many KDCs there are, which may not
always be easy to determine.)

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

That's the main alternative I've seen used.
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg