Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD toSHOULD+

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

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