Review of ending February 13, 2009

Tom Yu tlyu at MIT.EDU
Fri Jan 30 13:44:50 EST 2009

Sam Hartman <hartmans at MIT.EDU> writes:

> Tom, I have a couple of concerns here.
> First, I don't understand what the use case is or functional
> requirements are.
> I mean we all know that we'd like to stop using DES.  However I'd like
> to understand the drivers for this to understand what the right
> functionality is?

Motivation: make preparations for completely removing single-DES
support in the krb5-1.8 release.  Note that Heimdal implements
complete disabling of single-DES using "allow_weak_crypto" (which
defaults to false).  We can debate (and indeed seem to be doing so
quite actively) whether this strategy is deployable.

> The main questions I have that would be answered by functional
> requirements surround  what the security/interoperability tradeoff is.
> For example, much of the value of disabling DES could be accomplished
> by disabling DES at the KDC.  If the KDC does not issue tickets keyed
> with DES or using DES as a session key, then for the most part clients
> and servers will not use DES.  ((Clients may still try to use DES for
> string2key).

As I mentioned elsewhere, disabling DES at the KDC is probably a
reasonable interim step.

> Also, the current project write up does not describe how the
> krb5_c_weak_enctype will be used.  If we're planning on moving to
> something like permitted_enctypes = default - des then shouldn't that
> be krb5int_c_weak_enctype instead?

It could be krb5int_c_weak_enctype, and it is currently not exported.
We have appear to have precedent for having internal crypto functions
with a krb5_c_ prefix rather than a krb5int_c_ prefix.

More information about the krbdev mailing list