[Kdc-info] prelim draft of kdc information model

[Nicolas Williams]

On Mon, Jul 21, 2003 at 01:09:23PM -0400, Sam Hartman wrote:
>     Ken> I don't see any point in perpetuating the overloading we do
>     Ken> in the MIT database where the set of service key enctypes
>     Ken> also describes the encryption types supported by the
>     Ken> application server software.  

SAM> I think there are too many enctype related options, not too
SAM> few.  If you want to separate enctypes a service supports from
SAM> keys that a service has, I think that you should justify the
SAM> additional complexity/options.

SAM> I agree that there is no need for both the supported enctypes
SAM> and keyed enctypes to be the same.  However I don't see any
SAM> harm in doing things this way and it is one less thing to
SAM> configure or get out of sync.

The complexity is in the password/key change protocol and we'll need
this for extensions anyways, which I think amply justifies the
additional complexity.

Besides, the number of UI options visible to users and/or admins
need not go up.  When changing a service principal's keys the
admin could be given the option of listing the enctypes that the
principal accepts in order of preference and the principal should
magically end up with a single key of the first enctype in that
list.  This list of acceptable enctypes need not be provided
every time that the service principal's keys change either.

Cheers,

Nico
--