Re: KDC model and atomicity

It occurs to me that in the process of dealing with Nico's global atomicity issue, that we've invented another KDB characteristic that's just as alien to current implementations: a partitioning between some as-yet hypothetical local statistics data, and the ordinary global data.  I don't think we intended to diverge from existing practice that far.

One resolution would be to simply declare that global usage statistics are out of scope for this document.  They're probably collected by some external log-watcher system anyway.

On Jun 13, 2012, at 7:56 PM, Nico Williams wrote:

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

Agreed.

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

Multi-KDC aggregations of log data sounds like something that's out-of-scope.  (Useful, but out-of-scope.)  The question is what kinds of things make sense inside a KDC.

Or are you arguing that *all* the useful statistics are in that category?  In which case the only thing that goes in the model are the lock/rate-limit control knobs?  (Hence the comment I just added at the top.)

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

So that's an allowed rate (which nobody implements yet) and separately a locked boolean.  A KDC must provide at least one of the two?  (Anything else?)

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


Make it a boolean named "honeypot".  ;-)
------------------------------------------------------
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