[1178] in Kerberos_V5_Development
kadm5 (ovsec_kadm) api, version 2
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Wed May 15 13:43:32 1996
Date: Wed, 15 May 1996 13:43:19 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU, secure@cam.ov.com
In order to fully support the latest features of Kerberos 5 and to
integrate the admin system tightly within the system, the kadm5
(ovsec_kadm) api has to be updated. Enclosed below is a list of
issues that need to be addressed, and although I mention solutions for
some of them the list is really intended only as requirements.
I realize that most of the people reading this message are not familar
enough with the admin system or the internals of Kerberos 5 to comment
on this list, and most of the api change requirements probably won't
turn up until the design is well underway. I'm sending this primarily
so that Marc, jik, and others at OV can remind me of features we've
talked about adding to the API in the past, since this is a good time
to do so.
Barry
Version 2 of kadm5 (ovsec_kadm) API
o Rename everything to kadm5, leaving ovsec_kadm duplicates for
compatibility.
o Add new fields to policy: enc/salt types, default/max ticket lifetime,
XXX. One issue affecting what should be put into a policy is whether
the KDC will be required to retrieve policies in order to answer
requests. For enc/salt types to use, it won't, but for default ticket
lifetime, it will.
o New database entry type & features (multiple keys/princ, etc). This
will require changing ovsec_kadm_principal_ent_t.
o Support more/all of the KDC attributes.
o Require all principals to have a policy assigned, using a defaut
policy if none is assigned.
o Update authorization error codes and ovsec_kadm_get_privs() spec.
o Update ovsec_kadm_init_* to take a krb5_realm_params argument.
Right now, the admin system uses the default for everything; this will
allow the program (perhaps via command-line options) to specify other
values for things like preauthentication, database name, etc.
o Add ovsec_kadm_flush (already added, actually).
o Update create_principal to support multiple key/salt types.. or
perhaps not to set any keys at all, so that chpass or randkey must
always be called after create (to eliminate duplicate code).
o Rethink when functions should take krb5_principals as opposed to
string names.
o Update chpass_principal and randkey_principal to support multiple
key/salt types.
o Update get_principal to return key information on server-side only
(returns empty fields on client side).
