Re: KDC model and atomicity

On Thu, Jun 14, 2012 at 2:50 AM, Henry B. Hotz <[email protected]> wrote:
> 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.

I'm OK with just this one small set of stats (for N-strikes) provided
they are OPTIONAL.

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

Well, I am, but I'm willing to have just the failed login attempts
stats in this I-D as OPTIONAL.  But really I think what we're asking
KDC implementors to do is exactly that: to implement an architecture
for statistics collection and aggregation.  I think that's a very
desirable thing (unlike atomicity!) but I do not like merely implying
this.

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

Yes.  But I'll note that there are difficulties in implementing an
allowed rate knob, as that requires some keeping state on each KDC
(and it has to be available in a synchronized way if the KDC is
multi-processed/threaded).  And the naive approach of delaying AS-REPs
doesn't work -- the KDC has to respond with KRB-ERROR or drop the
AS-REQ when the rate of requests goes up.  A client might want to get
an error telling it to slow down.

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