Extensible kadm5 policies

[Greg Hudson]

What I like about this proposal:

* Many of the fields in principal entries are ticket policy fields and
belong more properly in a (currently nonexistent) ticket policy object.
 This proposal more or less rectifies that mistake.

* It gives us a path away from the separate .kadm5 database in the DB2
back end.

* iprop magically starts handling policies, which it currently doesn't.

What I dislike or am nervous about:

* In order to actually get rid of the .kadm5 database, we need to force
a dump and load at upgrade time for the DB2 back end.  Our upgrade
instructions have always recommended this, but I don't know that we've
actually required it in any release since at least 1.2, so admins might
find it disruptive or surprising.  Maybe not a big deal.  We'd need a
safety mechanism to make sure that a dump and load was performed
(otherwise the KDC appears to work but policies aren't enforced, which
is bad).

* I don't know what the transition path would be for the LDAP back end.
 It's much less reasonable to force a dump and load for LDAP upgrades.

* Representing existing policy fields as tl-data entries in kadmin would
be a bit painful.  Maybe we could make nice wrappers for it.

* We'd have to maintain two-way kadmin compatibility for a long time to
avoid making people's lives difficult (people are slow to upgrade KDCs).
 That's a lot of legacy code.  We'd also need legacy transition code for
dump and load.

* This might be overkill for the underlying needs.  The kadm5 policy
structure has been amended as recently as 1.8, abusing the handle API
version as a structure version field.  It's very hackish but there's
precedent for it in MIT kadmin (principal entry encoding also depended
on handle version before kadmin v1 was removed).  Adding tl-data and/or
string attributes to policy objects would probably not be very difficult
and would not make the kadmin protocol substantially worse than it
already is.

* I have to try hard to see this as elegant.  If we were designing our
KDC data model from scratch with no baggage, I don't think there'd be
much justification for representing principals and policies the same
way.  It's only because principals are already loaded with a bunch of
ticket policy fields that it starts to look approximately as elegant as
what we have now.

Some of the above points are negated by not representing policy as
principal in the back end (kadmind could translate policy principals
back into policies), but if we don't go all the way then this just
becomes an ugly protocol hack with minimal benefits.