Subject: [tcpm] Comments on draft-ietf-tcpm-tcp-ao-crypto-01

From: Brian Weis <[email-masked]>
Date: Thu, 14 Jan 2010 09:49:34 -0800

Hi Gregory,

In prototyping TCP-AO, I noticed the following relatively minor issues  
with this draft, but not fixing them has interoperability consequences.

1. In order to have an interoperable KDF, the number of bytes for  
"i" (the counter) and "Output_length" need to be defined. If one side  
hashes a 4 byte value and the other a 1 byte value, the resulting KDF  
output will differ. I suggest amending the text something similar to  
as follows:

  * In the description of "i", after the sentence "A counter, a binary  
string that is an input to each
iteration of the PRF in counter mode." add the following sentence:  
"The counter is represented in a single octet."

  * In the description of "Output_length" add a sentence after "The  
length in bits of the key that the KDF will produce." add "The  
Output_length is represented within two octets."

I believe 255 iterations ought to be enough for an KDF, which is why I  
suggest one octect for "i". Also, the overall length of key being  
produce shouldn't be larger than 65535 bytes. If you're concerned with  
arbitrary limiting the size of the values for all KDFs that might be  
defined in the future, you could instead make these statements part of  
the definition of KDF_HMAC_SHA1 and KDF_AES_128_CMAC. I doesn't matter  
to me, I just have observed that if everyone doesn't do it the same  
way there are issues!

2. This example in Section 3.1.1 doesn't match SP 800-108:

        Traffic_Key = KDF_alg(Master_Key, 0 || Label || Context ||  
Output_length) ||
                      KDF_alg(Master_Key, 1 || Label || Context ||  
Output_length)

All of the KDFs in SP 800-108 start the counter at "1", not "0". It  
would be very helpful to start the counter here at "1" as well. As one  
data point, I could not use my general-purpose KDF that conforms with  
SP 800-108 for TCP-AO, which was annoying. I also think this singly  
inconsistency could easily lead to errors in implementations that  
don't noticed the difference.

Thanks,
Brian

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]