Sean Shen writes: > Hi, IPSECME WG, > The 01 version of draft-ietf-ipsecme-aes-ctr-ike was uploaded. The > modification addressed comments we received so far and also include some > other editing. > Major changes are as following: > #4 > Section 3.2 > Added clear reference to rfc4302 and rfc4307 for integrity requirement and > algorithm choice.
I do not think it is good idea to copy the table from RFC4307 as it is likely to change in the future, so better would be just to give reference to the document. On the other hand RFC4306 already says that "... implementations MUST NOT negotiate NONE as the IKE integrity protection algorithm ..." (section 5. Security Considerations of RFC4306), thus AES-CTR cannot be used without integrity algorithm in this context anyways. One thing that is not 100% clear from the draft is that whether there is any padding in the encrypted payload. RFC4306 says that encrypted part is padded up to the block size of the cipher. In AES-CTR the block size is 1, thus that does not require any padding. Normal ESP requires padding for at least up to 4-byte boundary, regardless of the block size of the cipher, thus even AES-CTR uses padding up to 4-byte boundary. The IKEv2 SA does not require thus. I think it would be better to add text explictly saying this. I.e. add text like this to the end of 2.3: ... For this reason, AES-CTR does not require the plaintext to be padded to a multiple of the block size. For Encrypted Payload this means that Padding field is always empty, and Pad Length field will always be 0. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
