Re: [kitten] New EncTypes?

[Benjamin Kaduk <[e-mail]>]

On Thu, 19 Nov 2015, Rick van Rein wrote:

> Hello,
>
> > It seems to be time to do housecleaning on algorithms selections. Is
> > anyone interested in adding a new enctype to Kerberos?
> >
> One thing I would like to bring into any such discussion is that it
> would be possible to use through PKCS #11, the de-facto standard for
> storing keys on tokens, including hardware keys that will never share
> keys directly but allow their use through the API.  This extends the
> range of possible uses for Kerberos, I think.

It is probably premature to insist on this as a requirement, but it can
certainly be a part of the discussion.

> For instance, AES-CTS-HMAC uses plain standard AES and HMAC, and CTS can
> be implemented in terms of standard CBC, so it ought to be possible to
> implement with PKCS #11 (not that I've already actually tried, but it
> looks possible).

The argument would be more compelling if there was some prior art for it,
though -- I don't know of any hardware devices implementing such a scheme
at present.

> Of a similar stance, I've been wanting to see more Checksum Types, such
> as SHA256/384/512, for use with my TLS-KDH work.

Registering a new Checksum type is not particularly difficult, but seeing
that it gets implemented and used can be harder.  The de facto state of
affairs at present seems to be that Checksum types go hand-in-hand with
encryption types, and the required checksum for a given encryption type is
the only one ever used with it.  There may not be full support for using a
non-required checksum type with a given encryption type, but of course
use of checksums outside of traditional encryption types will require new
code anyway, so adding use of Checksums without encryption would not
present additional implementation effort other than that needed to
actually implement the new protocol feature.

-Ben