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

["Peck, Michael A" <[e-mail]>]

Ben,

Thanks for the comments, I'll fix those.

Could you help me understand or give an example of what the pseudo-random
function defined in the protocol parameters is used for?  I'm not quite
following the RFC 3961 section 3 definition.

We already separately define how a base-key is derived from a passphrase
(in cases where a passphrase is used), and how the Kc, Ke, and Ki keys are
derived from the base-key. What are the additional use cases for a generic
PRF?

Right now our pseudo-random function definition refers to KDF-HMAC-SHA2,
which we define in section 3 but in the context of deriving the base-key,
Kc, Ke, or Ki key (so that we get the right output length) rather than
arbitrary keys, so we may need to clean up that language a bit.  Then
you're right that it just says "HMAC" which would mean an output of 256 or
384 bits, which probably isn't right (RFC 3961 says the "pseudo-random
function should generate an octet string of some size" - but how do we
know what size is needed?).  Also, calling HMAC a second time rather than
just passing the octet-string (and perhaps a desired output length?) into
KDF-HMAC-SHA2 may be redundant.

Thanks,
Mike

On 5/22/14, 5:15 PM, "Benjamin Kaduk" <[e-mail]> wrote:

>On Mon, 19 May 2014, Shawn M Emery wrote:
>
>>
>> This message officially starts the kitten Working Group Last Call for
>>the 
>> following document:
>>
>> AES Encryption with HMAC-SHA2 for Kerberos 5
>> http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-02
>>
>> The Working Group Last Call for this document starts today on Sunday,
>>May 
>> 18th and will end on Sunday, June 1st.
>
>This looks pretty much okay.
>
>A few minor things:
>
>The specification of en/decryption in section 5 assigns the new
>cipherstate as "next-to-last 128-bit block of C"; this is slightly
>ambiguous when C does not end on a block boundary.  I believe the intent
>is that the last full block will be used in this case, but one could read
>the current text as saying that the next-to-last full block would be used.
>Also, the description of D() says it is an AES encryption function, not a
>decryption function.
>
>There are no test vectors for the PRF.  Having such vectors would also
>make it clear what the output length of the PRF is (luckily, we are not
>using the simplified profile, with its ambiguous language "truncate tmp1
>to multiple of m").  (The PRF output length looks to be 256 and 384 bits
>for the two variants, to me.)
>
>In section 8.1, "at least 128 bits of random" feels ungrammatical.  Also
>in that section, the third and fourth bullet points may be specific to
>the 
>MIT krb5 implementation; it might be worth tweaking the wording to
>reflect 
>that this is only known to affect some implementations, or something like
>that.
>
>I did not attempt to verify the test vectors.
>
>-Ben
>
>_______________________________________________
>Kitten mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/kitten