Subject: [IPsec] Working Group Last Call: draft-ietf-ipsecme-aes-ctr-ikev2-02.txt

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Sep 2009 07:38:17 -0700

Greetings again. This message starts the WG Last Call on draft-ietf-ipsecme-aes-ctr-ikev2-02.txt. Please read the draft and comment on the list whether or not you think it is ready for standardization. We are particularly interested in hearing from implementers who have carefully read the details to be sure they are implementable and seem correct. Of course, we want to hear from everyone as well.

This Last Call should end around October 1.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Sep 2009 14:23:55 +0300

Paul Hoffman writes:
> Greetings again. This message starts the WG Last Call on
> draft-ietf-ipsecme-aes-ctr-ikev2-02.txt. Please read the draft and
> comment on the list whether or not you think it is ready for
> standardization. We are particularly interested in hearing from
> implementers who have carefully read the details to be sure they are
> implementable and seem correct. Of course, we want to hear from
> everyone as well. 

When reading the roadmap I noticed that camellia-ctr is also not
defined for IKEv2 SAs, so I was wondering if the text in this document
could be made generic enough so any counter mode cipher could be used.

There is not really anything that much different between different
counter mode ciphers, they take IV, which must not be repeated for
same key, I think almost all of them also take nonce which is
generated when key is generated but not transmitted on the wire and
they do not have padding requirements.

To be able to use counter mode in IKEv2 SA the implementation needs to
know the IV format, transmitted IV length and padding requirements.
Usually the RFC specifying the counter mode cipher defines IV format
already and also specifies the transmitted IV length, so the required
information is there but as the RFC4306 talks only about CBC mode
ciphers and says things like the IV is same size as block length of
cipher we could not use CTR ciphers in IKEv2.

Making part of the draft bit more generic so it can be used to combine
any counter mode cipher document and IKEv2 document in a such way that
counter mode cipher can also be used to protect IKEv2, would make
things easier for the future (i.e. there is no need to create separate
RFC for each counter mode cipher).

Mostly the information is already there in section 3, but some text
might need to talk generic case first and the add text specifically
for AES_CTR. For example:

Changing:
----------------------------------------------------------------------
3.1.  Initialization Vector(IV)

   The IV field MUST be eight octets when AES_CTR algorithm is used for
   encryption.  The IV MUST be chosen by the encryptor in a manner that
   ensures that the same IV value is NOT used more than once with a
   given encryption key.  The encryptor can generate the IV in any
   manner that ensures uniqueness.  Common approaches to IV generation
   include incrementing a counter for each packet and linear feedback
   shift registers (LFSRs).
----------------------------------------------------------------------
to
----------------------------------------------------------------------
3.1.  Initialization Vector(IV)

   The IV field length used for encryption depends on the counter mode
   algorithm. The IV MUST be chosen by the encryptor in a manner that
   ensures that the same IV value is NOT used more than once with a
   given encryption key. The encryptor can generate the IV in any
   manner that ensures uniqueness. Common approaches to IV generation
   include incrementing a counter for each packet and linear feedback
   shift registers (LFSRs).

   For AES_CTR algorithm IV field MUST be eight octects.
----------------------------------------------------------------------

Other option is of course to include text to ikev2bis which specifies
how to use counter mode ciphers when protecting IKEv2 SAs.

Currently draft-ietf-ipsecme-ikev2bis-04.txt says:

     ...   Future
   documents may specify the processing of Encrypted payloads for other
   types of transforms, such as counter mode encryption and
   authenticated encryption algorithms.

so instead of saying that we could say that 

   [RFC5282] specifies how to use authenticated encryption algorithms
   with the Encrypted Payload, and [draft-ietf-ipsecme-aes-ctr-ikev2]
   specifies how to use counter mode encryption algorithms with
   Encrypted Payload. Future documents may specify the processing of
   Encrypted payloads for other types of transforms.
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Sep 2009 07:44:11 -0700

>could be made generic enough so any counter mode cipher could be used.

It is not clear to me that future counter modes will fit today's generic definition. I don't think it is bad to require a specific definition for each application of counter mode.

>how to use counter mode ciphers when protecting IKEv2 SAs.

This seems like overkill and possibly limiting to future applications of counter mode.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 18 Sep 2009 11:51:14 +0300

Paul Hoffman writes:
> It is not clear to me that future counter modes will fit today's
> generic definition. I don't think it is bad to require a specific
> definition for each application of counter mode. 

The generic description would say that for counter mode there is IV
that length is specified by the counter mode algorithm, and whose
format and generation is specified by the counter mode algorithm, and
that there usually is no padding requirements for counter mode
algorithms unless otherwise specified by the counter mode algorithm.

There is not really anything else that needs to be done for counter
mode ciphers. 

> applications of counter mode. 

We already do that for CBC, and that text is the only text which does
not fit the counter mode case (i.e. the text saying the IV length is
same as the block length of the cipher and text about IV generation).

Actually the current ikev2bis already says: "For modes other than CBC,
the IV format and processing is specified in the document specifying
the encryption algorithm and mode." which is already enough for
counter mode ciphers.
-- 
[email-masked]