RE: [Ipsec] Last Call: 'The AES-CMAC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)' to Proposed Standard

A couple of comments for IETF last call. Nothing major, mostly
the document seems OK.

1) Section 3 writes "When using the PRF described in this document 
   with IKEv2, the PRF is considered to be fixed-length for generating 
   keying material but variable-length for authentication."

   Draft-hoffman-rfc3664bis included this "somewhat tortured logic" to
   preserve compatibility with RFC 3664. Here we don't have the
   compatibility issue, so wouldn't it be simpler to consider it
   variable-length for all purposes?

2) Section 6 says: "However, if using collision-resistant hash
   function such as AES-CMAC when generating new key for 
   pseudo-random function"

   It's pretty trivial to show that f(x)=AES-CMAC(0^128,x) is not 
   a collision-resistant hash function. But collision-resistance is 
   not exactly the property we need here, because the input VK is 
   secret.

3) Section 6 says: "Keys need to be chosen at random based on RFC 
   4086 [RFC4086] and should be kept in safe and periodically 
   refreshed."

   This paragraph doesn't make much sense in a document which defines 
   a PRF for IKEv2. The keys come from the DH exchange (etc.), and 
   thus cannot be chosen at random according to RFC 4086 (with
   the exception of manually configured shared secret).

4) An extremely quick and rough implementation (not based on the
   draft-songlee-aes-cmac code) produced the same values as the 
   test vectors listed in the draft.

Purely editorial suggestions:

5) idnits: "There are 37 instances of too long lines in the document,
   the longest one being 717 characters in excess of 72."

6) Abstract: The abstact is copied from RFC 3664 (and was OK there),
   but might need some rephrasing here: we already have one 
   AES-based PRF for IKEv2, so why another? (draft-songlee-aes-
   cmac-96 has some motivational text)

7) Section 1: "128 bits output is useful as a long-lived pseudo-
   random function (PRF) in either IKE version 1 or version 2." 
   Since this document does not specify a PRF for IKEv1, mentioning 
   it is a bit confusing.

8) Section 9.1: IKEv2 is now RFC 4306.

9) Section 9.2: Neither [AH] not [ROADMAP] are cited anywhere in
   the text; suggest removing them. 

Best regards,
Pasi 

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec