ktadd default enctype
Nico Williams
nico at cryptonector.com
Fri Jun 5 11:21:06 EDT 2015
On Fri, Jun 05, 2015 at 11:11:12AM -0400, Greg Hudson wrote:
> > 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.
Oh, right, that's right, I forgot to mention that in my other post: the
Solaris kadmind uses a 1DES enctype as supported_enctypes for the old _1
kadm5 randkey_principal RPC. The idea (this was like a decade ago, maybe
more) was that Solaris 8 and 9 used the _1 RPC and only supported 1DES,
while Solaris 10's ktadd client would always use the _3 RPC.
(I also confused create_principal with randkey_principal in my previous
post. Sigh. Need more coffee.)
So there you go. You should just use the ktadd -e option.
> 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.
FYI (for JD), the difference between those two RPCs is mainly that one
takes a keysalt list (-e) and the other one doesn't. But also the _3
RPCs were added much later, so Solaris 8 and 9 (for example) didn't
support them.
> 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).
That must be it, though why MD5 I don't know (or recall).
Thanks,
Nico
--
More information about the Kerberos
mailing list