|Main Archive Page > Month Archives > ipsec archives|
Paul Hoffman writes:
> At 2:23 PM +0300 9/17/09, Tero Kivinen wrote:
> >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.
> 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.
> >Other option is of course to include text to ikev2bis which specifies
> >how to use counter mode ciphers when protecting IKEv2 SAs.
> This seems like overkill and possibly limiting to future
> 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@example.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec