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