[16033] in Kerberos_V5_Development
Re: Camellia-CCM and defaults
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Tue Aug 10 16:48:44 2010
Date: Tue, 10 Aug 2010 16:48:40 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: ghudson@mit.edu, krbdev@mit.edu
Message-ID: <EE26ED74691971C22C186B87@minbar.fac.cs.cmu.edu>
In-Reply-To: <201008041647.o74Glkvx018638@outgoing.mit.edu>
MIME-Version: 1.0
Content-Disposition: inline
Cc: jhutz@cmu.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
--On Wednesday, August 04, 2010 12:47:46 PM -0400 ghudson@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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
