|Main Archive Page > Month Archives > ipsec archives|
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:
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).
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:
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@example.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec