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

[Greg Hudson <[e-mail]>]

On 04/20/2015 11:56 AM, Michael Peck wrote:
> Our draft's current practice of truncating the pseudo-random function
> output to 128 bits (for enctype aes128-cts-hmac-sha256-128) and 256 bits
> (for enctype aes256-cts-hmac-sha384-192) rather than providing the full
> HMAC output has the benefit of discouraging misuse of the output.  If
> the full HMAC output is returned by the PRF, I'd be afraid it may imply
> an output of 256 or 384 bit strength when the maximum strength is in
> reality limited to 128 or 256.  It's not clear to me the potential ways
> the PRF output might be used - certainly I could see both appropriate
> and inappropriate ways to use the output.

To the best of my knowledge, all current users of the RFC 3961 PRF have
a fixed amount of desired output, and iterate and truncate the PRF
function to produce the number of desired bytes.  See the definitions of
PRF+ in RFC 4402 and RFC 6112.

So, for example, if someone asks for 256 bits of PRF output (e.g. via
gss_pseudo_random()) and the enctype is aes128-cts-hmac-sha256-128 with
the PRF truncated to 128 bits.  The user will wind up invoking

  PRF(K, 00 00 00 00 || string)
  PRF(K, 00 00 00 01 || string)

and concatenating the results.  The application has not in any way been
discouraged from producing a 256-bit string with only 2^128 possible
values; it has merely been made twice as slow.

> If the working group prefers the full output be returned, we can do that
> and could attempt to address it in the security considerations.

I think the audience of this enctype's security considerations is mainly
implementors of the enctype.  Applications aren't written to specific
enctypes; they are written to RFC 3961 or a higher layer.  If you want
to say something about the inherently limited entropy of the PRF output
then I won't object, but I don't think it is necessary or useful.

> We
> provide the PRF definition to comply with the RFC 3961 framework but
> would probably prefer a NIST SP 800-108 KDF be used to derive keys for
> other uses.  I could see the PRF output potentially being used as the Ki
> key derivation key input to a NIST SP 800-108 KDF for those who want to
> use that.

The PRF+ construction is pretty similar to the KDF used in the aes-sha2
draft, except that it doesn't append a length to the end of each PRF
invocation's input string.  I believe the only potential problem there
is that PRF+(K, 256, S) will be an extension of PRF+(K, 128, S) rather
than a totally different value.  That's a potential safety issue, but as
long as callers use different S values for different kinds of keys, it's
not a real problem.