Re: [tcpm] handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto
Eric Rescorla <ekr@networkresonance.com> Sun, 26 July 2009 23:22 UTC
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC983A67DF for <tcpm@core3.amsl.com>; Sun, 26 Jul 2009 16:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.312
X-Spam-Level:
X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[AWL=1.287, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qiAVj+1C369 for <tcpm@core3.amsl.com>; Sun, 26 Jul 2009 16:22:49 -0700 (PDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 665353A67DA for <tcpm@ietf.org>; Sun, 26 Jul 2009 16:22:49 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id B2E5050822; Sun, 26 Jul 2009 16:26:24 -0700 (PDT)
Date: Sun, 26 Jul 2009 16:26:24 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Gregory M. Lebovitz" <gregory.ietf@gmail.com>
In-Reply-To: <4a6cb1f2.0506d00a.33a2.18df@mx.google.com>
References: <D7A0423E5E193F40BE6E94126930C49307859925B8@MBCLUSTER.xchange.nist.gov>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20090726232624.B2E5050822@romeo.rtfm.com>
Cc: "Pasi.Eronen@nokia.com" <Pasi.Eronen@nokia.com>, "housley@vigilsec.com" <housley@vigilsec.com>, "mcgrew@cisco.com" <mcgrew@cisco.com>, "Polk, William T." <william.polk@nist.gov>, "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] handling variable length keys in draft-lebovitz-ietf-tcpm-tcp-ao-crypto
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jul 2009 23:22:50 -0000
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
- Re: [tcpm] handling variable length keys in draft… Gregory M. Lebovitz
- Re: [tcpm] handling variable length keys in draft… Eric Rescorla
- Re: [tcpm] handling variable length keys in draft… Gregory M. Lebovitz
- [tcpm] handling variable length keys in draft-leb… Polk, William T.
- Re: [tcpm] handling variable length keys in draft… Polk, William T.
- Re: [tcpm] handling variable length keys in draft… Eric Rescorla