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

Michael Peck <> Thu, 16 April 2015 02:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F13C11B2AAD for <>; Wed, 15 Apr 2015 19:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hVwqAKOlDdNe for <>; Wed, 15 Apr 2015 19:20:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5A5A1B2AAA for <>; Wed, 15 Apr 2015 19:20:57 -0700 (PDT)
Received: by wiun10 with SMTP id n10so80558350wiu.1 for <>; Wed, 15 Apr 2015 19:20:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gX65q/BJAf9nxTetpHs7WBy3DMuExRyj/HB9seoNnT0=; b=KdpwJ+ybrAppPV0uLL8GqFNb4zD59aO0OR/C9z9gvk40AGcb0HfcPwKTQZ4D8DMhXz JBg4u7p3oOifFfJuN1uT1B/V1r8xJANPa6KNYMSEa/qWhSWigVGzdUS6/wnRLr9BtzzP CLvojkCefMO/abWyMT+khixWXvzjQRx/DcwedKRoBF75Y46u/JAH8gwCTv0cPlOo2807 n7b+SW4wp3yOZE8IhrrI5mos2Y3GW6LeciyGOB9x/yVfzqtw4uBnw01iC5AMMCTXeDj4 kgEEyIPbiuCpWA0mN5abxELNRNpbm0aPzksOKzEEcFRdHjQKQa1UZbhP9GLpjfFgR5qZ ynaQ==
MIME-Version: 1.0
X-Received: by with SMTP id wj7mr55700578wjb.57.1429150856368; Wed, 15 Apr 2015 19:20:56 -0700 (PDT)
Received: by with HTTP; Wed, 15 Apr 2015 19:20:56 -0700 (PDT)
In-Reply-To: <20150415210538.GG29890@localhost>
References: <> <20150415205159.GF29890@localhost> <> <20150415210538.GG29890@localhost>
Date: Wed, 15 Apr 2015 22:20:56 -0400
Message-ID: <>
From: Michael Peck <>
To: Nico Williams <>
Content-Type: multipart/alternative; boundary=089e013c6b5a1fd9ae0513ce1d4c
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, 16 Apr 2015 02:21:00 -0000

Hi -

To try to address the comments on the draft:

1. HMAC-SHA-384 truncated to 192 bits versus HMAC-SHA-256 truncated to 192
bits :

Suite B was our motivation for proposing the two encryption types.
Suite B pairs AES-128 with SHA-256, and pairs AES-256 with SHA-384.  When
used in the digital signature context, SHA-256 provides an expected 128 bit
security level, and SHA-384 an expected 192 bit security level because of
the dependence on collision resistance.
In the case of our proposed Kerberos enctypes, we're using the hashes with
HMAC for message authentication and for a KDF so collision resistance is
not a factor - in this case, SHA-384 truncated to 192 bits appears to add
no cryptographic value over SHA-256 truncated to 192 bits.
However, our preference would still be to keep the hash choice as is for
consistency with the Suite B pairing of AES-256 with SHA-384.  This could
theoretically enable someone using just that option to not even need
SHA-256, and might also help avoid confusing compliance assessors.
(NIST SP 800-107 has a discussion of hash strengths as used in various
contexts : )

2. With aes256-cts-hmac-sha384-192, why is a 192-bit HMAC key used for Ki
and Kc but not for Kp?

Kp is used for the Kerberos pseudo-random function (PRF).
RFC3961 states that the PRF output "should be suitable for use in key
generation" - if i recall correctly, our thinking here was that we didn't
know what types of keys could potentially be derived from the PRF output,
so we'd output the full 256 bits (whether the strength of the PRF output is
actually 256 bits would of course depend on how the base-key is
generated/derived) in case the PRF might be used to generate an AES-256 key
- figured no need to drop bits even if our expected strength of the enctype
overall is 192 bits.

3. Greg's suggestion to change KDF-HMAC-SHA2 to include an explicit length
parameter, add the length parameter everywhere KDF-HMAC-SHA2 is invoked,
and remove the discussion of the constant values from section 3:

I need to work through this still, but it seems reasonable.  We'll need to
separately list invocations of KDF-HMAC-SHA2 for each encryption type, but
that might help make the draft more readable, particularly if we instead
separately refer to it as KDF-HMAC-SHA-256 and KDF-HMAC-SHA-384.

4. Provide more detail in the test vectors
We can do this -- and thank you to those who wrote and shared test vector

On Wed, Apr 15, 2015 at 5:05 PM, Nico Williams <>

> On Wed, Apr 15, 2015 at 04:58:08PM -0400, Benjamin Kaduk wrote:
> > On Wed, 15 Apr 2015, Nico Williams wrote:
> > >  - SHA-256 is used at the 192-bit security level, and the HMAC is
> > >    truncated to 192 bits.  The keys for the HMAC are 192 bits at the
> > >    192-bit security level.
> > >
> > >    AES-256 is used at the 192-bit security level because AES-192
> > >    implementations are not as universally available as AES-256, or
> > >    something.  In any case, I've no objection.
> > >
> > >    I also do not object to the use of HMAC-SHA256-192 with 192-bit keys
> > >    at the 192 bit security level.
> >
> > I think that some of these "256" should be "384", unless you have
> > progressed from summarizing the document to describing what you would
> like
> > to see...
> Yes, sorry.
> Nico
> --
> _______________________________________________
> Kitten mailing list