[tcpm] handling variable length keys with AES-128-CMAC in TCP-AO-crypto draft

["Gregory M. Lebovitz" <[e-mail]>]

Team,
So, Dave McGrew doesn't like the idea of using the variable length 
master key in the input portion of AES-128-CMAC, and using some fixed 
128 bit blob in the key portion in a key-sizing pre-run, in order to 
get a 128 bit key from a variable length key in order to feed that 
back into the AES-128-CMAC a second time to get the traffic key. 
(i.e. the method currently documented in 
draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01, and used in rfc 4615)

We are trying to handle the case where MK is the *variable length* 
master key, and sometimes MK < 128 bits, and sometimes MK > 128 bits, 
and sometimes VK = 128 bits.

If we constrain the problem to:
  - we need to show people what to do if they get variable length keys
  - we don't want to use any other PRF in the AES-128-CMAC case (i.e. 
mandating the use of yet another algo like SHA256 increases the 
burden on implementations, and, for agility reasons we don't want the 
AES KDF to be built atop SHA1),
  - the same variable length master key entered on two different 
implementations MUST produce the same traffic key for any given connection,

then, could we solve it like this:
  - Normative text:  AES-128-CMAC needs a 128-bit key. Therefore 
administrators SHOULD use a suitable key of exactly 128 bits, as 
represented by a 16 character ASCII string. Implementation UI's 
SHOULD force the administrators to enter a 128-bit key when selecting 
AES-128-CMAC as the KDF. UI's SHOULD reject with an error any key not 
equal in length to 128 bits. If, for whatever reason this is not 
acceptable for certain environments, implementations MAY consider 
accepting keys from the UI with lengths not equal to 128bits and 
using AES-128-CMAC as described in appendix A to create a 128-bit key 
from a non-128-bit string.

- Appendix A (non-Normative):
   - if the UI will allow strings of length not equal to 128 bits, and
   - if you get a string > 128-bit or <128-bit, then
      - if > 128-bit, truncate the string to 128-bits, and use them as the key
      - if < 128-bit, pad the end of the string with zeros until the 
string length equals 128-bit, and use that as the key string.

I realize this isn't great, but I'm not sure how else to solve the 
problem that hasn't already been shot down. If neither the method in 
draft-01 nor the above work for you, then PLEASE send text for 
something better. Remember, we need to get this done asap, and I'd 
like to have a scrubbed proposal for the TCPM WG meeting in Stockholm.

Thanks,

Gregory.

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m