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

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 :
http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf )

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

On Wed, Apr 15, 2015 at 5:05 PM, Nico Williams <nico@cryptonector.com>
wrote:

> 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
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>