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

"Gregory M. Lebovitz" <gregory.ietf@gmail.com> Mon, 27 July 2009 08:29 UTC

Return-Path: <gregory.ietf@gmail.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 981023A68CF for <tcpm@core3.amsl.com>; Mon, 27 Jul 2009 01:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 YW6I-H69q3nT for <tcpm@core3.amsl.com>; Mon, 27 Jul 2009 01:29:26 -0700 (PDT)
Received: from mail-px0-f194.google.com (mail-px0-f194.google.com [209.85.216.194]) by core3.amsl.com (Postfix) with ESMTP id 3FBBB28C108 for <tcpm@ietf.org>; Mon, 27 Jul 2009 01:28:50 -0700 (PDT)
Received: by pxi32 with SMTP id 32so1570922pxi.29 for <tcpm@ietf.org>; Mon, 27 Jul 2009 01:28:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type; bh=Q17idZyXvWFhpsdrUyQI0CGLag3cpcl7010rRtUvQLI=; b=Saa2xvi3wqQPZqOW3fwkoZAes2D5npLFu3loHE9LLrwudm2AcTGY4xWrzF9RXP2TNQ gZ2/D4Abjrbp+3KG+ZOqKKBUx0NQXKesfmzxWFO6vhJt3pNcKjYEU3/VI3nt7p1uMWrf y9/mWaq4JOn8A5rizU1jGCzYrIsZH5XK2EkBA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type; b=oTtXcqt70Kkl4VL1/EMVuZ3puyVJzqI07imGNUAdQOWMJU7izF+0pmVzyU90R6M1tl MBQy5QHd6L0p4lPJfXiuW7gAER2m3sj4B2K+y8lCAMsdd49SoCgo3VUHu4QlXiaya2pQ h4YRfQKDxqtw7MITOQJAh4caafL8Odb83z6Gw=
Received: by 10.114.95.20 with SMTP id s20mr9520134wab.114.1248683329150; Mon, 27 Jul 2009 01:28:49 -0700 (PDT)
Received: from Gregory-T60.gmail.com (dhcp-14dc.meeting.ietf.org [130.129.20.220]) by mx.google.com with ESMTPS id m25sm13076789waf.9.2009.07.27.01.28.46 (version=SSLv3 cipher=RC4-MD5); Mon, 27 Jul 2009 01:28:48 -0700 (PDT)
Message-ID: <4a6d6540.19bd720a.7437.ffffd84b@mx.google.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 27 Jul 2009 01:28:41 -0700
To: "Polk, William T." <william.polk@nist.gov>, Eric Rescorla <ekr@rtfm.com>
From: "Gregory M. Lebovitz" <gregory.ietf@gmail.com>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C49307859925BA@MBCLUSTER.xchan ge.nist.gov>
References: <D7A0423E5E193F40BE6E94126930C49307859925B8@MBCLUSTER.xchange.nist.gov> <20090726232624.B2E5050822@romeo.rtfm.com> <D7A0423E5E193F40BE6E94126930C49307859925BA@MBCLUSTER.xchange.nist.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "Pasi.Eronen@nokia.com" <Pasi.Eronen@nokia.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "mcgrew@cisco.com" <mcgrew@cisco.com>, "housley@vigilsec.com" <housley@vigilsec.com>
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: Mon, 27 Jul 2009 08:29:27 -0000

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 [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