Subject: [kitten] RFC 3961 key-derivation operation

From: Greg Hudson <[email-masked]>
Date: Sun, 03 May 2015 11:16:49 -0400

RFC 3961 defines an abstract interface for an encryption algorithm
profile (colloquially known as an enctype) and a checksum algorithm
profile.  It also defines a "simplified profile," which can be used to
construct an enctype from a block cipher and hash, and several specific
enctypes and checksum profiles.  The operations specified in sections 3
and 4 are visible to consumers such as RFC 4120 and AFS, while other
sections define internal details of specific enctypes and cksumtypes.

I was recently surprised to notice that section 3 includes a
key-derivation operation, (protocol-key, integer)->(specific-key).  I
had previously assumed that key derivation was an internal detail of
enctypes, aside from the requirement that consumers provide a key usage
number for each encryption and checksum operation.

The presence of a key-derivation operation in section 3 suggests that a
consumer could invoke the key-derivation operation explicitly.  I don't
think any Kerberos specification does this.  I'm not sure there is any
reason to do so other than to directly use the bits of the specific-key,
and the PRF operation is probably more suited to that kind of use.

Things only get more confusing as one looks into this further:

* Section 2 says "The specific key should not be explicitly referenced
  outside of this document."  So why does a public enctype operation
  produce a specific-key output?

* Section 5.3, which defines the transformation from simplified profile
  to enctype, specifies a key-derivation function which does not meet
  the abstract form of the key-derivation.  It picks a byte depending on
  whether Kc, Ke, or Ki is being derived.  Note that section 3 states
  "no additional or implicit inputs... are permitted."

* RFC 4757 does not explicitly define a key-derivation operation,
  although it of course uses key derivation internally.

* RFC 6803 mirrors RFC 3961 section 5.3 in defining a key-derivation
  function which does not fit the form of RFC 3961 section 3.

MIT krb5 does not provide a public interface for key derivation.
Heimdal provides a krb5_derive_key() function which accepts a
byte-string input instead of an integer, and implements the
simplified-profile key derivation function; it appears to return an
error for a key of any enctype other than DES3 or the AES-SHA1s.

I think the best conclusion is that RFC 3961 section 3 was mistaken to
include a key-derivation operation, and that future enctype
specifications should not that operation as part of their enctype
profiles.  They should, of course, continue to use key derivation
internally, using the consumer-provided key usage number.

Do others agree?  Should we file an erratum?  This has an impact on
the aes-sha2 spec (as a matter of form, not function, of course).