Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+
Uri Blumenthal <uri@bell-labs.com> Sun, 08 June 2003 02:23 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29119 for <ipsec-archive@lists.ietf.org>; Sat, 7 Jun 2003 22:23:08 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA22752 Sat, 7 Jun 2003 20:28:38 -0400 (EDT)
Cc: David Blaker <DBlaker@NetOctave.com>, ipsec@lists.tislabs.com
Message-ID: <3EE10F4A.7000303@bell-labs.com>
Date: Fri, 06 Jun 2003 18:01:46 -0400
From: Uri Blumenthal <uri@bell-labs.com>
Organization: Lucent Tehcnologies / Bell Labs
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en, zh-cn, ru, de, he
MIME-Version: 1.0
To: Theodore Ts'o <tytso@mit.edu>
Original-CC: David Blaker <DBlaker@netoctave.com>, ipsec@lists.tislabs.com
Subject: Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+
References: <49B96FCC784BC54F9675A6B558C3464ED7C15F@mail.netoctave.com> <20030606195203.GB4070@think>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit
I'd volunteer, since I've been working on the thing (on and off) for a while now. But as the discussion demonstrated, it's not as simple - if you want to use that PRF in IKEv2. Theodore Ts'o wrote: > On Wed, Jun 04, 2003 at 12:47:57PM -0400, David Blaker wrote: > >>Although I have seen discussions of using AES for a PRF function on >>the IPSec mailing list, I am unaware of a formal definition that is >>documented in a draft. draft-ietf-ipsec-ciph-aes-cbs-05.txt makes no >>mention of a prf function, as far as I can tell. If PRF_AES128_CBC >>is to be either a SHOULD or a SHOULD+, then someone first needs to >>define it somewhere. Would one of the proposers of this algorithm please >>provide a draft? > > > Good catch. It appears that ikev2-algorithms-01 is in error: > PRF_AES128_CBC is not defined in draft-ietf-ipsec-aes-cbc-05, and I > don't see any drafts where it is defined. So we need to modify > ikev2-algorithms to point at a (currently non-existent) I-D, and we > need to find a volunteer to quickly gin up an I-D which defines > PRF_AES128_CBC. > > Barbara and I believe that this shouldn't hold up the IETF last call > for draft-ietf-ipsec-algorithms, since writing up this PRF AES I-D > should be something that can be done quickly, however, with the > dangling reference the algorithms document will stall when it hits the > RFC editor, so we will need to plug this reference quickly.
- Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 fro… Paul Hoffman / VPNC
- RE: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96… David Blaker
- Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96… Theodore Ts'o
- Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96… Hugo Krawczyk
- Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96… Uri Blumenthal
- Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96… Hugo Krawczyk
- Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96… Hugo Krawczyk
- Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96… Hugo Krawczyk
- Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96… Uri Blumenthal
- Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96… Uri Blumenthal
- Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96… Paul Hoffman / VPNC