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