Subject: [Ietf-krb-wg] authenticated encryption modes (GCM, CCM, etc.)

From: Tom Yu <[email-masked]>
Date: Wed, 28 Oct 2009 16:55:41 -0400

Is there interest in specifying authenticated encryption modes such as
GCM and CCM for Kerberos?  Would you want a specification for AES in
those modes, or do you prefer to wait for a different block cipher?

This doesn't get into the use of authenticated encryption modes that
support additional data (AEAD), which would require some revision to
RFC 3961 if we want to support the additional data feature.

GCM and CCM both have the advantage of using counter mode for
encryption, which increases speed and minimizes ciphertext expansion.
As several other have pointed out, our use of CTS mode for AES,
partially for the properties of minimizing ciphertext expansion, can
cause implementation difficulties...
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Oct 2009 15:59:38 -0500

> those modes, or do you prefer to wait for a different block cipher?

I believe there is/will be interest for political reasons (namely, that
HMAC-SHA-1 uses SHA-1, which is weak, and this weakness causes
perception problems even if we all believe that HMAC-SHA-1 is strong)
and for performance reasons (partly because of the CTS mode performance
issues, and partly because, I suspect, over time we'll see hardware
where AES-GCM will run significantly faster than AES + HMAC-SHA-256 and
AES + HMAC-SHA-1).

I don't believe there's any need to wait for a different block cipher.
A framework for using AEAD enctypes with any 128-bit block cipher should
be feasible.

> RFC 3961 if we want to support the additional data feature.

However, for the GSS-API mechanism, and for the GSS-API generally, a
wrap token with additional data feature would be very useful.

> cause implementation difficulties...

Yes.

Nico
--