Camellia-CCM and defaults

Jeffrey Hutzelman jhutz at cmu.edu
Tue Aug 10 16:48:40 EDT 2010


--On Wednesday, August 04, 2010 12:47:46 PM -0400 ghudson at mit.edu wrote:

> We're hopefully close to being able to merge the camellia256-ccm and
> camellia128-ccm enctype implementations to the trunk; the code is
> ready, although I'd ideally like to get IANA assignments first.

That's going to be a while.  The policy is Standards Action or Expert 
Review, but requires a published specification for the enctype in either 
case.  IANA is therefore unlikely to assign numbers until late in the 
publication process, regardless of whether the specification ends up as a 
work item of krb-wg or not, and regardless of whether it ends up on the 
standards track.

Until then, of course you could use private-use numbers, but it would be 
inappropriate to ship software that assigns meaning to private-use enctypes 
except when explicitly configured to do so (so, lacking real numbers, the 
answers to your questions should be no and no).


Assuming real numbers, I'm not sure what the right answers are.  I'm 
inclined to agree with Sam that it would be desirable to require explicit 
configuration at the realm level while having clients just magically start 
using a new enctype when the KDC and servers support it.  However, getting 
that effect quickly requires having keys already present for client 
principals in the KDB, since getting people to change their passwords in a 
short time ranges from really unpopular to downright impossible.  That 
argues for enabling the new enctypes in clients and servers, disabling it 
in the KDC, but generating its keys for client principals with passwords on 
creation and password change (which I don't think corresponds to any 
combination of answers).

OTOH, as Sam points out, there can be interop issues when a service has 
keys for an enctype it doesn't support, and it may be difficult to insure 
that clients get a full set of keys but servers get only what they support 
(it would be nice to solve that problem).  Also, anytime you introduce a 
new enctype, you have the possibility of a mixture of client software, some 
of which supports it and some of which doesn't, and the usability issues 
that arise out of that.

This doesn't help, but I think the answers are mostly that there are no 
good answers. :-(

-- Jeff



More information about the krbdev mailing list