[Kdc-info] prelim draft of kdc information model

Nicolas Williams Nicolas.Williams at sun.com
Mon Jul 21 12:43:51 EDT 2003


On Mon, Jul 21, 2003 at 12:17:55PM -0400, Ken Raeburn wrote:
> I don't see any point in perpetuating the overloading we do in the MIT
> database where the set of service key enctypes also describes the
> encryption types supported by the application server software.  Given
> that, in many cases I suspect there's no need for the service to have
> more than one key and enctype.  Obviously, that enctype must be one
> supported by the software, but there doesn't have to be a key for each
> supported enctype.

Indeed, service principals need have no more than one key shared with
the KDC.

As I said, draft-ietf-krb-wg-kerberos-set-passwd-01.txt will have a
facility by which clients can tell the KDC what Kerberos features are
supported by the principal whose keys are changing.

The KDC needs to know at the very least what enctypes a service
principal accepts, for ticket session key enctype is the one thing that
is negotiated between a client and service by proxy in the KDC
exchanges.

As we've discussed before, the Kerberos extensions work will only add to
the number of things negotiated in this way and the KDC will have to
know what version of Kebreros V is supported by service principals, at
the very least.

Cheers,

Nico
-- 


More information about the kdc-info mailing list