Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 08 April 2015 21:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E66F51B36A2 for <>; Wed, 8 Apr 2015 14:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lDDqkbRrx7Av for <>; Wed, 8 Apr 2015 14:26:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E01541B36C1 for <>; Wed, 8 Apr 2015 14:26:47 -0700 (PDT)
X-AuditID: 1209190f-f79d16d000000d3d-11-55259d168136
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F4.38.03389.61D95255; Wed, 8 Apr 2015 17:26:46 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t38LQjsm028653; Wed, 8 Apr 2015 17:26:46 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t38LQi6x014900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Apr 2015 17:26:45 -0400
Received: (from kaduk@localhost) by ( id t38LQfxB023329; Wed, 8 Apr 2015 17:26:41 -0400 (EDT)
Date: Wed, 8 Apr 2015 17:26:41 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Greg Hudson <ghudson@MIT.EDU>
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixCmqrSs2VzXUYNYubYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY+Xcf6wFa/UrDm3rZG5gfKzaxcjJISFgIjH5zSR2CFtM4sK9 9WxdjFwcQgKLmSSmHL4F5WxglFjROZcVwjnIJPHh5zuwFiGBeolbsycwg9gsAloSe95OZQGx 2QRUJGa+2cgGYosIKEr8XvmWEcRmFhCWWH9uBli9sICLxKwtK4DmcHBwCqhLvJ/PBBLmFXCU +HtsGwvE+BiJ5sbJYOWiAjoSq/dPYYGoEZQ4OfMJC8RILYnl07exTGAUnIUkNQtJagEj0ypG 2ZTcKt3cxMyc4tRk3eLkxLy81CJdE73czBK91JTSTYzgoJTk38H47aDSIUYBDkYlHl6BxSqh QqyJZcWVuYcYJTmYlER5d81WDRXiS8pPqcxILM6ILyrNSS0+xCjBwawkwnt7JlCONyWxsiq1 KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCl3cOUKNgUWp6akVaZk4JQpqJgxNk OA/QcA+QGt7igsTc4sx0iPwpRkUpcd4zIBcJgCQySvPgemFJ4xWjONArwrwWIO08wIQD1/0K aDAT0GD+Z0ogg0sSEVJSDYwynjEyKva3dMJn76/gzp29s3Vyr12V5PqbMt8/vTnBeF73mXVl RNPFCvtHR29KuYXU+eUpcCsKFJqYOyvF7l7fupinz8RZv/TVi6KY5Cs5ZkrctrtV3xxm4F4Z m8kWsEExcVXWiweaGxWfzD7c+2Dex+7zZiq2Tz83qFmzpzyqXxGXqWPhpsRSnJFoqMVcVJwI AK632Yr1AgAA
Archived-At: <>
Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Apr 2015 21:26:51 -0000

On Thu, 2 Apr 2015, Greg Hudson wrote:

> On 03/30/2015 12:40 PM, Benjamin Kaduk wrote:
> > This message begins the Working Group Last Call (WGLC) of "AES Encryption
> > with HMAC-SHA2 for Kerberos 5" <draft-ietf-kitten-aes-cts-hmac-sha2-06>.
> > The WGLC will last two weeks, ending on Monday, April 13th.
> I put together a simple implementation of this draft in Python, and
> verified some of the test vectors (but not all; see below).

Thank you!

> There are several aspects of the enctype design whose motivations are
> unclear to me.  They affect performance but not security.  They are:
> * For the 192-bit security level, why use SHA-384 and truncate to 192
> bits?  Why not use SHA-256 and truncate to 192 bits?

I did not go on a full trawl through the archives, but implies
that NIST is generating a document covering "what you get from what you
used" indicating that SHA-256 only gives you 128 bits, under some set of

> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

I don't think there is logic supporting this choice in the list archives;
if I remember correctly, Kp was added rather late in the document's
history, and the decision to have an explicit intermediate Kp instead of
just making the PRF use the base key direction (in some form) was made
pretty arbitrarily ("it feels better to keep the behavior parallel across
enctypes" or thereabouts).

Leaving k as 256 allows the PRF = k-truncate(HMAC-SHA2(Kp, octet-string))
to produce a pseudo-random function output which is a multiple of the
random-to-key input size (and the underlying cipher block size), which is
a nice feature to retain.  I don't know of a reason why we could not
retain 256-truncate using a 192-bit Kp, though.

> * Why use 128/256-bit PRF output lengths?  Why not just output the full
> hash?  It can't be for consistency with RFC 3962, as
> aes256-cts-hmac-sha1-96 has a 128-bit PRF output length.  It can't be
> out of some desire to consistently truncate SHA-2 results in half, or we
> would have 128/192-bit output lengths.

I think there is some desire to always truncate SHA-2 results in half,
though, for the reasons mentioned above.  But a 192-bit output would not
be a multiple of the blocksize or random-to-key input size, so in that
sense (random-to-key input), 256 bits makes more sense.  This is probably
"okay" in the sense of wanting to always cut SHA-2 outputs in half,
because the aes256-...-192 enctype only claims to provide 192 bits of

> I have one concern about formal correctness:
> * Following the lead of the simplified profile, the formulation of the
> key derivation function in section 3 ends by calling random-to-key() as
> if the result had the same abstract type as a protocol key.  But for the
> AES256 variant, Ki and Kc have a 192-bit length, so it cannot be of the
> same abstract type as a 256-bit protocol key.  The formalism is also

So random-to-key() only applies for generating base keys, and the
derivation of Kc/Ki/Ke/Kp should just be k-truncate(...)?

Or is the argument rather that since we are not using the simplified
profile, we just don't need random-to-key() at all because we are defining
things manually and can make use of the fact that it is the identity
function for these enctypes?

> sloppy because it depends on context; instead of taking a length
> parameter, it uses an implicit length based on what operation the
> invoker is performing.  In a similar vein, section 3 talks about what
> the input constant is for each derivation use; this is not the case for
> RFC 3961 or RFC 6803 and seems out of place.

So you want to rely just on the (type of the) key being derived and not
mention the last octet of the constant?  I think that would be a valid way
to specify things, but want to confirm the nature of your comment.

> I have several concerns about the presentation of the test vectors:
> * The PRF test vectors do not list a base key; instead it lists a Kp
> value.  This requires tests to exercise only a component of the PRF
> implementation, which may be inconvenient.  The base keys are present in
> the key derivation test vectors, but this is not immediately clear.

We could add text so the PRF test vectors say "Kp value (repeated from
above):"; would that help?

> * The encryption test vectors do not list base keys and key usages;
> instead they only list "AES key" and "HMAC key" values which are
> presumably Kc and Ki.  For the first 128-bit test vector, the base key
> and usage is recoverable from the key derivation test vectors, but that
> does not appear to be the case for any of the other encryption test
> vectors.  Because of this, I only verified the first encryption test vector.

Hmm.  I don't really want to propose removing test vectors to replace them
with new ones, but could we add some additional test vectors which do
possess the desired properties?  (I.e., that the Kc and Ki are listed in a
previous test vector from base key and usage, or that they are test
vectors starting from base key.)

> * The checksum test vectors do not list a base key or key usage.  The
> base keys and usages are present in the key derivation test vectors, but
> this is not immediately clear.

Similarly to the PRF, does "HMAC key (repeated from above):" help enough?

> (It looks like RFC 6803 is missing key usages for encryption test
> vectors, which may have contributed to some of the above issues.  I will
> submit an erratum.)


My own review notes that section 8.2 contains an extra space in "The
encryption".  It additionally claims that this document is proposing "the
use of [...] AES-256 with a 192-bit key", but this is confusing since
AES-256 definitionally requires a 256-bit encryption key, and the base key
is also a 256-bit key.  Perhaps "AES-256 with some derived keys of length
192 bits" is better, albeit clunky.