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

[Tero Kivinen <[e-mail]>]

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.
-- 
[e-mail]