How to extend kadmin

[ghudson@MIT.EDU]

We've had some private discussions recently about how to best extend
kadmin, prompted by the account lockout work.  I'm bringing this to
the larger community.

There are three plausible ways to extend kadmin:

1. Bump the api_version, which is communicated to the server through
the init_2 RPC when a connection is established.  This has now been
done three times: twice before the code was incorporated into the MIT
tree in 1996, and once for the lockout code.  The api_version is
explicitly chosen by the caller.  Support for API versions 0 and 1 was
removed from the trunk (by me) in August 2009.

2. Bump the struct_version.  This field's value is determined by
admin.h, rather than the caller.  Its value is passed to the
kadm5_init functions but is never communicated to the server.  The
struct_version has never been bumped before; when the principal
structure was changed prior to 1996, the OpenVision developers
apparently chose to bump the api_version instead of the
struct_version.  Because the struct_version is not communicated to the
server, protocol compatibility would demand that this mechanism be
used in combination with (3) below.

3. Define new RPCs.  This was done once in 1998 when keysalt support
was added to chpass_principal, create_principal, setkey_principal, and
randkey_principal.  The client side of those functions choose whether
to use the new or old RPCs depending on whether keysalts are
specified.  I do not currently know whether the GSSRPC encoding allows
a client to try a newer RPC and then fall back to an old one--that is,
I don't know if the server can try and fail to process an unknown RPC
type and still keep the connection in sync.

The api_version bumps from 1->2 (ancient history) and 2->3 (lockout)
both correspond to structure changes.  The encoding of a
principal_ent_rec changed from 1->2 and the encoding of a
policy_ent_rec changed from 2->3.  To accomplish this, the output of
rpcgen was hacked to pass the version number into the relevant
encoding functions and conditionalize on the version.  As a result,
the MIT tree has never generated the kadmin RPC encoders at build or
distro-preparation time; we have always stored modified rpcgen C
output in the source tree.  I am told that Sun uses rpcgen at build
time instead (they removed api v1 support in order to do this), and
that they may have trouble with the lockout code in its current form
as a result.

I don't personally have a strong opinion as to how this should work.
I have never been a fan of the RPC model of network protocols, so for
me this is a question of how to make the best of an architecture I
wouldn't have chosen.