ktadd default enctype

Greg Hudson ghudson at mit.edu
Fri Jun 5 11:11:12 EDT 2015


On 06/05/2015 07:24 AM, John Devitofranceschi wrote:
> How is ktadd *supposed* to figure out which enctype(s) to use?

In the absence of the optional keysaltlist parameter, it's supposed to
be determined by supported_enctypes on the KDC.

> But when we run ktadd the resulting keytab’s key has des-cbc-md5
> 
> The  client is an Oracle Linux with 1.6.1 krb5 client software.
> 
> Also, the KDC is using Sun Solaris 10 Kerberos software (not MIT).

The short answer: Solaris implements transitional logic which isn't
really compatible with the MIT kadmin client for this operation.  We
have a workaround in MIT krb5 release 1.13.

kadmin's ktadd invokes a chrand RPC in order to get the new keys for the
keytab.  There are two versions of this RPC, chrand_principal and
chrand_principal3.  The former accepts a principal name and optionally
returns a list of keys; the latter also accepts an optional keysalt list.

Prior to release 1.13, the MIT krb5 behavior is to invoke
chrand_principal3 if a keysalt list is specified, and chrand_principal
otherwise, so that typical randomize-key requests work against old
kadmind servers without an extra round trip.

In Solaris Kerberos, however, the client behavior is to always invoke
chrand_principal3 and then fall back to chrand_principal if that fails.
 Furthermore, the kadmind server assumes that a chrand_principal request
must come from an old client, and picks a different keysalt list (which
I guess is just des-cbc-md5:normal).

MIT krb5 1.13 matches the Solaris Kerberos client behavior and should
not display the odd behavior you're seeing.


More information about the Kerberos mailing list