Extensible kadm5 policies

[Nico Williams]

On Mon, Oct 31, 2011 at 4:25 PM, Tom Yu <tlyu at mit.edu> wrote:
> Nico Williams <nico at cryptonector.com> writes:
>>  - Do we want any policy fields to also be fields of principals?  Why/why not?
>
> No.  Too much policy information is already stored on a per-principal
> basis that should never have been stored there.  For example, I've
> seen many queries about "why can't I increase the max ticket
> lifetime?", which tend ultimately to reflect the inflexibility of
> per-principal ticket policy settings.  (Globally increasing the max
> ticket lifetime requires editing every principal in the database.)

I have thought about this and talked to Jeff A. about it and my
conclusion is that yes, we would want policy-type fields in
principals, not just in policies.

Supposing that I couldn't think of a good reason for it, there's still
the fact that someone else might, and I wouldn't want to prevent
someone else from making use of policy fields in principals if they
had a use for it.

But I do have a good reason for this, courtesy of Jeff: not all
Kerberos realms will be enforcing a corporate policy, but rather a
user policy.  Consider a commercial Kerberos realm, or a commercial
service that uses Kerberos for authentication, including having a
realm for its users (or some of them).  Why wouldn't the service
operator want to allow users to be more paranoid than the service
operator is?  Why wouldn't the service operator at least want this
option?

Now, policy fields in principals should be constrained by the same
fields in policies, assuming they are set.

>>  - Do we want extensible policies at all?
>
> Probably, even though we should manage it carefully.

No, I think we have significant evidence that policies should be more
complicated than just the password quality policies.  Ticket lifetimes
is the example that Greg brought up.  "Supported enctypes" is the one
that's causing me to bring this up.  New authz-data and pre-auth will
almost certainly create the need for more policies.

But more than that, I can't imagine why anyone today would want to not
make policies extensible.

>>  - Do we want to add a new kadm5 API version and overload the C types
>> one more time?  Do note the need to do the same in the protocol, or to
>> add new RPCs.
>
> I'd like to see us move to an approach that better abstracts
> operations on principals and policies.  Currently, API users must deal
> with the entire structure (principal or policy) all at once, whether
> or not they need to.  (It might not necessarily be completely filled
> in.)  Some people refer to this as the interface being too "blobby".
> I believe it's a result of revealing too many of the implementation
> details of how we store the information in a simple key-value databse,
> instead of designing an interface that would be easy to use.

Sure.  I think what we could do is add per-field type accessor
"methods".  We could leave the existing C structs mostly the same, so
as to help preserve source compatibility for a short while to help
developers transition -- or not, but hopefully we could make this the
last time we break the kadm5 API/ABI.

Since this would be the most visible non-UI aspect of the proposed
change, some guidance here as to what MIT and the community would like
to see would be useful.

>> I must say that I'm not too upset by the idea of adding a new kadm5
>> API version and doign more type overloading *in MIT krb5*.  It would
>> never happen in Heimdal, but we can break kadm5 ABI there, so that's
>> not a big deal.  But for the db2 backend I'd still propose
>> policies-as-principals just so we can get policy iprop.
>
> We make far weaker stability assurances for the admin API than we do
> for the krb5 API.  Where I do want to try to maintain backward
> compatibility is in the protocol.

Clearly it'd be bad to break compatibility in the protocol.  I've not
and would not have proposed *that*.  I do think that a stable kadmin
API is badly needed though.  I remember writing expect scripts around
kadmin a decade ago, because it was not possible to script around
kadmin in any other way, and the then-available Perl5 CPAN module for
kadm5 was incomplete (IIRC) and loudly proclaimed its instability (I
should have used it anyways).

And no, I don't think that LDAP is teh answer.  Sure, LDAP is *an*
answer, but there are operations that LDAP can't model as
modifications to objects -- mainly the password/key set/change
operations, and the retrieve keys operation (since the keys are
encrypted in the master key).  (And trust me, we need a "get principal
keys" operation.  If necessary I can go into why.)  Sure, we could
define extended LDAP operations to match these, but there will be
users who don't want LDAP.  Moreover, it's clearly possible to have a
kadm5-like API interface to a multitude of KDB backends, and that is a
useful thing.

Nico
--