Re: KDC model and atomicity
Jeffrey Hutzelman <[email protected]> Mon, 25 Jun 2012 11:41:06 -0400
| Newsgroups | gmane.ietf.krb-wg |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 2012-06-25 at 08:25 -0400, Sam Hartman wrote: > >>>>> "Nico" == Nico Williams <[email protected]> writes: > > Nico> What's wrong with Jeff's proposal? > Nico> _______________________________________________ > > > With my chair hat on, I don't think we have consensus. FWIW, at this point, I agree. > I think I see you and Jeff supporting; myself with concerns and don't > think I've seen any other comments expressing support or lack. > > With my individual hat on, I'm concerned because it does not promote > interoperability. > Jeff proposes to have about as many standardized attributes as there > are likely to be implementations in an ideal world, all of them > optional. > How likely are people to implement enough of the various options that we > get value from standardization? That's a valid point. What I _don't_ want to see is a single attribute with vaguely-defined semantics, such that every KDC implementation includes the attribute but they all mean something different with no way to tell what is meant. I'd rather not have a standardized attribute at all then end up in that situation. I think we have agreement that we don't expect attributes exposing the state of a lockout or throttling mechanism to be writeable (with the possible exception of a "locked" attribute that could be used to reset the entire state). So, any such attributes... 1) are for information only 2) are not needed to manage the lockout/throttling mechanism 3) are not needed to implement any part of the Kerberos specifications. Thus, I would not object to dropping them entirely. I do think this discussion has uncovered a need for a means to tell whether a principal has been locked out, and to reset such a lockout. I feel like those would not be unreasonable things to include in a standard data model, though they should of course be optional, since a KDC might not implement a lockout mechanism. -- Jeff _______________________________________________ ietf-krb-wg mailing list [email protected] https://lists.anl.gov/mailman/listinfo/ietf-krb-wg