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

Greg Hudson <> Thu, 02 April 2015 16:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 00AAD1B2D45 for <>; Thu, 2 Apr 2015 09:20:27 -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 7hUNYW5i1Zf5 for <>; Thu, 2 Apr 2015 09:20:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 92AED1B2D30 for <>; Thu, 2 Apr 2015 09:20:13 -0700 (PDT)
X-AuditID: 12074422-f79cb6d000000d7b-08-551d6c3cb1d6
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 A6.70.03451.D3C6D155; Thu, 2 Apr 2015 12:20:13 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t32GK762026256; Thu, 2 Apr 2015 12:20:07 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t32GK5Im007881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2015 12:20:06 -0400
Message-ID: <>
Date: Thu, 02 Apr 2015 12:20:05 -0400
From: Greg Hudson <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Benjamin Kaduk <>,
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixG6nomubIxtqcHAOm8XRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfxDVcF1sYrfX7qYGxj7hboYOTkkBEwkbi2bxQRhi0lcuLee rYuRi0NIYDGTxNbJ51kgnA2MErfX7mGHcA4zSbzofcsO0sIroCYx78FUsHYWAVWJBe33mUFs NgFlifX7t7KA2KICYRKz111khKgXlDg58wlYXETAWOLuzxtgtrCAi8SsLSvAZgoJOEq8XHgF aCYHB6eAk8TtxyEgYWYBPYkd13+xQtjyEs1bZzNPYBSYhWTqLCRls5CULWBkXsUom5JbpZub mJlTnJqsW5ycmJeXWqRrqpebWaKXmlK6iREcki5KOxh/HlQ6xCjAwajEw5uxRyZUiDWxrLgy 9xCjJAeTkijvzEzZUCG+pPyUyozE4oz4otKc1OJDjBIczEoivFppQDnelMTKqtSifJiUNAeL kjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQlexmygRsGi1PTUirTMnBKENBMHJ8hwHqDhQiA1 vMUFibnFmekQ+VOMilLivNEgCQGQREZpHlwvLGW8YhQHekWY1x2kigeYbuC6XwENZgIa7DBP GmRwSSJCSqqB0VjS8sfCdU9SawwVBPM5/y91lZ1kICGdt3fH7vSrQaXNE/Qic1fz6tz6oj8h fa0DZ8jdd1MmVyctE/yiav7t6JITJybUXOZKs//7pPr9AckDNrbVnbu4zFkCtQ7MMC7KFTg6 we+xl9LbG3MOXuENerPV8RB3Sf+NHWeFvBgdJ/9f0dO+cYd1lBJLcUaioRZzUXEiAFi9Dtj0 AgAA
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: Thu, 02 Apr 2015 16:20:27 -0000

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).

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?

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

* 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 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
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.

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.

* 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.

* 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.

(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.)