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

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Sun, 26 Jul 2009 12:43:37 -0700

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 26 Jul 2009 16:26:24 -0700

At Sun, 26 Jul 2009 12:43:37 -0700,
> 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

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Mon, 27 Jul 2009 01:28:41 -0700

ack. change made in crypto-02.
(I'm feeling like a ping-pong ball here -- take it out... no, put it 
in... no, out... no, in... -- but such is life for an I-D editor ;-)
Gregory.

At 11:40 PM 7/26/2009, Polk, William T. wrote:
>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 [[email-masked]]
>Sent: Sunday, July 26, 2009 7:26 PM
>To: Gregory M. Lebovitz
>Cc: Polk, William T.; [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]
>Subject: Re: [tcpm] handling variable length keys in

---

From: "Polk, William T." <[email-masked]>
Date: Sun, 26 Jul 2009 11:40:50 -0400

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.

I hope this was helpful.

Tim Polk
Pasi Eronen

---

From: "Polk, William T." <[email-masked]>
Date: Mon, 27 Jul 2009 02:40:55 -0400

Ekr,

Tim

________________________________________
From: Eric Rescorla [[email-masked]]
Sent: Sunday, July 26, 2009 7:26 PM
To: Gregory M. Lebovitz
Cc: Polk, William T.; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tcpm] handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Jul 2009 08:08:18 -0700

At Sun, 26 Jul 2009 11:40:50 -0400,
Polk, William T. wrote:
> this step doesn't even have to be one-way.

It seems like you're putting a lot of weight on AES to assume that
a key that is 24 random bits and 104 bits of zeros at the end
really has strength 2^24

-Ekr