Re: [tcpm] handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto

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

Tim,
This is helpful, thanks. We will proceed toward WG LC with the 
mechanism as represented in draft v-01.

If later, after further discussions within the cryptographic 
community, it is decided that the randomness extraction mechanism to 
go from a variable-length user-given string to a 128-bit key would be 
better accomplished some other way, then we can always do a quick 
-bis on the RFC and update the mechanism. That's easy enough for a 
small RFC like this.

Gregory.

At 08:40 AM 7/26/2009, Polk, William T. wrote:
>Gregory,
>
>As requested, Pasi and I took a look at how 
>draft-lebovitz-ietf-tcpm-tcp-ao-crypto
>handles the AES-CMAC case when the master key is not 128 bits.
>
>The method currently used (using AES-CMAC with a known fixed key as a
>"randomness extractor") is basically the same as used in IKEv2 (RFC
>4615 and 4434), except IKEv2 uses all-zeroes key (but the specific
>value of the known fixed key shouldn't matter much -- just pick one).
>
>Using the same method in TCP-AO would be acceptable us, and seems
>strongly preferable to requiring network admins to configure exactly
>128 bit keys.
>
>Other methods of getting from "what the admin configures" to 128 bits
>could work, too. Since the output of this step is *only* used as the
>key for further PRF calculations (and for *nothing* else), the
>requirements for it are very limited. If all keys were <= 128 bits,
>even something trivial such as padding with zeroes would work -- so
>this step doesn't even have to be one-way.  Since we need to handle
>also keys >128 bits, simple padding isn't enough, of course. If the WG
>wants AES-only method, the one that's in the draft now seems OK to us.
>
>I hope this was helpful.
>
>Tim Polk
>Pasi Eronen