[16030] in Kerberos_V5_Development
Camellia-CCM and defaults
daemon@ATHENA.MIT.EDU (ghudson@mit.edu)
Wed Aug 4 12:47:50 2010
Date: Wed, 4 Aug 2010 12:47:46 -0400 (EDT)
From: ghudson@mit.edu
Message-Id: <201008041647.o74Glkvx018638@outgoing.mit.edu>
To: krbdev@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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.
Two questions:
1. Should we add these enctypes to the default etypes list used for
the default values of default_tgs_enctypes, default_tkt_enctypes,
and permitted_enctypes?
This would make it easier to deploy Camellia from the KDC when the
configurations of clients are not tightly controlled. It would,
obviously, expose clients to a bit of additional risk.
2. Should we add these enctypes to the default value of
supported_enctypes? (This is the default key:salt list used when
creating new principals or changing passwords.)
This would make it easier to switch a realm from using AES to
Camellia if, say, AES or SHA-1 were suddenly found to be weak,
since principal entries created after a 1.9 deployment will already
have Camellia keys.
Adding more enctypes here increases the database size and exposes
realms to additional risk if Camellia turns out to be weak.
If I receive no feedback, I will go with yes and yes, following the
precedent of the RC4 enctypes.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
