aes-sha2 preference

Greg Hudson ghudson at
Fri Sep 23 10:34:06 EDT 2016

On 09/23/2016 04:05 AM, Wang Weijun wrote:
> Now that draft-ietf-kitten-aes-cts-hmac-sha2-11 is waiting for publication and IANA already assigned numbers to the new etypes, is MIT krb5 about to support it soon?

Yes. should be merged soon, and
we expect to branch for 1.15 not long after that.

> I am mainly interested in what the preference order will be? Will the new etypes appear after existing aes128-cts and aes256-cts? Or before?

Currently in that pull request, aes-sha1 is preferred to aes-sha2, and
aes-sha2 isn't in the default supported_enctypes.  My thinking was that
while aes-sha2 comes with some security benefits (longer integrity tag,
stronger hash primitive, encrypt-then-mac):

* aes-sha1 has no known security weaknesses other than the ones inherent
to a 96-bit authentication tag (which do not lead to any practical
attacks that I am aware of).

* aes-sha1 is faster and consumes less extra token space.

* aes-sha1 is much more widely supported.  In theory this should not
matter due to enctpe negotiation.  In practice though, if aes-sha2 is
present in a server principal's keys (perhaps not as the first key, so
that tickets printed for the server are still encrypted in an aes-sha1
key) and a piece of software on the server doesn't support aes-sha2,
negotiating an aes-sha1 session key will work while negotiating an
aes-sha2 session key will not.

Nothing prevents us from changing the default order in a later release.

More information about the krbdev mailing list