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