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