Subject: [IPsec] AD review of draft-ietf-ipsecme-aes-ctr-ikev2-04

From: <[email-masked]>
Date: Wed, 27 Jan 2010 11:06:04 +0100

Now that traffic-visibility has progressed, I've finally done my AD
review of draft-ietf-ipsecme-aes-ctr-ikev2-04.

This document copies most of its text verbatim from RFC 3686, and does
not even acknowledge the source (or have the disclaimer about pre-5378
text).

However, it's been noted that people have already managed to implement
AES CTR mode for IKEv2, because RFC 3686 and 4306 already contain 99%
of the details, and people have guessed the remaining 1%.

Instead of repeating several pages worth of complex technical text
(such as the precise definitions of CTR modes and their security
considerations), this document should focus on the remaining 1%.

Here's a rough sketch what the edits should look like:

- Keep the first two paragraphs of section 1, and whole 1.1 (and 
  remove everything else)
- Remove section 2.
- Replace sections 3 and 4 with something like this:

   "When using AES-CTR in the IKEv2 Encrypted Payload, the
   Initialization Vector is 8 octets.  Requirements for this IV are
   specified in [RFC3686] Section 3.1; the counter block is
   constructed as specified in [RFC3686], Section 4.

   When AES-CTR is used in IKEv2, no padding is required; the Padding
   Length field of the Encrypted Payload SHOULD be set to
   zero. However, the recipient MUST accept any length."

- Replace section 5 with something like this:

   "The use of AES-CTR for the IKE SA is negotiated the same way as
   AES-CTR for ESP. The Transform ID (ENCR_AES_CTR) is the same; the
   key length transform attribute is used the same way; and the keying
   material (consisting of the actual key and the nonce) is derived
   the same way."

- Replace section 6 with something like this:

   "The security considerations for using AES-CTR in IKEv2 are similar
   to its use in ESP with fresh keys and integrity protection; see
   [RFC3686] for details.  (Note that static keys are never used for
   the IKE SA, and the IKE_SA always uses integrity protection.)"

- Replace section 7 with something like this:

   "The IKEv2 Encryption Transform ID "ENCR_AES_CTR" has already been
   assigned by IANA. IANA is asked to add a reference to this RFC in
   that entry."

With these changes, the whole document (without boilerplate and 
reference list) should be probably less than two pages.

Best regards,
Pasi