Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+

Hugo Krawczyk <hugo@ee.technion.ac.il> Mon, 09 June 2003 23:57 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 TAA25597 for <ipsec-archive@lists.ietf.org>; Mon, 9 Jun 2003 19:57:26 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00402 Mon, 9 Jun 2003 18:10:55 -0400 (EDT)
Date: Tue, 10 Jun 2003 01:16:47 +0300
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
To: Uri Blumenthal <uri@bell-labs.com>
cc: Theodore Ts'o <tytso@mit.edu>, David Blaker <DBlaker@NetOctave.com>, IPsec WG <ipsec@lists.tislabs.com>
Subject: Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+
In-Reply-To: <3EE10F4A.7000303@bell-labs.com>
Message-ID: <Pine.GSO.4.21.0306090130250.13704-100000@ee.technion.ac.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk


On Fri, 6 Jun 2003, Uri Blumenthal wrote:

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

Uri, 

I see no need for further I-D's. As I said in a recent message all is
needed is a pointer to the AES-XCBC-MAC draft for the definition of what
ikev2 calls PRF_AES128_CBC. All other issues regarding the use of prf are
taken care by the ikev2 draft itself. In particular, the draft completely
specifies the use of prf's whether with variable length key (such as
HMAC-SHA) or fixed length key (such as aes128-cbc). The only prf's that
are defined as MUST NOT USE are those whose output is shorter than the key
itself (such as 3DES). All other discussions regarding prf use in ikev2
were resolved and reflected in the ikev2 draft.

Hugo

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