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

Ekr,

Your objections on the magic number are well taken.  Since zeroes would
be a holdover from 4615 and 4434, that value won't introduce any new
issues.  I think that would be the best course of action.

Tim

________________________________________
From: Eric Rescorla [ekr@networkresonance.com]
Sent: Sunday, July 26, 2009 7:26 PM
To: Gregory M. Lebovitz
Cc: Polk, William T.; mcgrew@cisco.com; housley@vigilsec.com; tcpm@ietf.org; Pasi.Eronen@nokia.com
Subject: Re: [tcpm] handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto

At Sun, 26 Jul 2009 12:43:37 -0700,
Gregory M. Lebovitz wrote:
>
> Tim,
> This is helpful, thanks. We will proceed toward WG LC with the
> mechanism as represented in draft v-01.

I'll be sending my comments on v-01 shortly, but I object to
the magic number in the current mechanism. If we're going to
use a magic key, it should be zero or some other anchor point.
The use of a random number pulled out of the air is highly
inappropriate in cryptographic systems [I refer you to the
contrroversy over the DES S-boxes].

-Ekr

> 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
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm