[37075] in Kerberos
Re: ktadd default enctype
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jun 5 11:12:25 2015
Message-ID: <5571BC10.4080507@mit.edu>
Date: Fri, 05 Jun 2015 11:11:12 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: John Devitofranceschi <jdvf@optonline.net>, kerberos@mit.edu
In-Reply-To: <6DBA609A-440B-4C5D-A62E-EE0CEFD471B3@optonline.net>
Content-Type: text/plain; charset="windows-1252"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
