near-term strategy for "disable DES" effort

[Nicolas Williams]

On Fri, Jan 30, 2009 at 02:20:54PM -0500, Tom Yu wrote:
> Near term (krb5-1.7-alpha1 timeline) strategy for the "disable DES"
> effort will include the following:
> 
> * Remove single-DES enctypes from the "supported_enctypes" list for
>   libkadm5.  This will prevent kadmind from creating new single-DES
>   long-term keys unless explicitly configured otherwise.  This may
>   cause problems for users running old client software, and I
>   encourage you to propose strategies for mitigating this issue.

I agree with this.  But you may want to be aware of some changes made in
this area in Solaris.

To better support older releases that supported only 1DES enctypes
Solaris' kadmind does the following:

 - If the client called kadm5_randkey_principal() then assume it wants
   1DES only.  Old clients don't use the kadm5_*_3() functions

 - Otherwise use supported_enctypes.

And Solaris' kadmin/kadmin.local do the following:

 - randkey w/o the -e option acts as though -e with the list of all
   permitted_enctypes was provided.

> * Implement the "allow_weak_crypto" libdefault setting.  I was leaning
>   in favor of "false" but recent discussion of the transition issues
>   is calling that into question.  Unless I hear strong objections, I
>   will assert that defaulting to "false" is acceptable for the alpha
>   release and am willing to reconsider prior to final release.

I would like to see clarification of what contexts allow_weak_crypto is
intended to apply to.  Is it every context that default_tkt/tgs_enctypes
and permitted_enctypes applies to?  I think that would be too
constraining for realms that want to get away from 1DES for password-
derived long-term keys first.

I would almost rather you defer this project until consensus is reached.

> We expect to make the release branch and the krb5-1.7-alpha1 release
> later today.

I thought the review deadline was February 13, 2009.  Is that still the
case?

Nico
--