Re: ktadd default enctype
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 -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ktadd default enctype
On Fri, Jun 05, 2015 at 07:24:06AM -0400, John Devitofranceschi wrote: > How is ktadd *supposed* to figure out which enctype(s) to use? Long ago I made Solaris' ktadd use the locally supported enctype list as the default for ktadd, as if they'd been passed via the -e option (which still works, natch). > I am seeing an issue where kadmin’s ktadd, if left to its own devices, > will generate a key with an encryption type that has nothing to do > with the KDC’s supported_enctype list and ktadd seems to completely > ignore the local client’s default/permitted enctype settings. Eh? No, it should not ignore the KDC's supported_enctype list unless it implements the change I mentioned above. The supported_enctypes list was meant to apply only when the client didn't use the -e option. > KDC supports: des3-cbc-sha1 des-cbc-crc (I know, I know) > > Client's krb5.conf tells it to support: des-cbc-crc (I know, I know) ... > > 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). > > Thanks for any insight! I bet the Oracle client is using the kadm5_create_principal_3() RPC, which means you don't get the supported_enctypes. Try using the -e option. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ktadd default enctype
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
ktadd default enctype
How is ktadd *supposed* to figure out which enctype(s) to use? I am seeing an issue where kadmin’s ktadd, if left to its own devices, will generate a key with an encryption type that has nothing to do with the KDC’s supported_enctype list and ktadd seems to completely ignore the local client’s default/permitted enctype settings. KDC supports: des3-cbc-sha1 des-cbc-crc (I know, I know) Client’s krb5.conf tells it to support: des-cbc-crc (I know, I know) 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). Thanks for any insight! jd smime.p7s Description: S/MIME cryptographic signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
