Re: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt
Hi Sean, I agree with Tero that including the table in the document is redundant and confusing. Removing it would add clarity, more than your proposed text IMO. Regarding padding, you are right that the recipient should accept anything, but you can still repeat the sentence AES-CTR does not require the plaintext to be padded to a multiple of the block size (or better still: the sender is not required to pad the plaintext) in the section that specifies the Encrypted Payload. Thanks, Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Sean Shen Sent: Wednesday, August 19, 2009 4:46 To: 'Tero Kivinen' Cc: ipsec@ietf.org Subject: Re: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2- 01.txt Hi, Tero, Thanks for the comments. Please check in lines: 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. The point here is to say that integrity protection is needed with aes-ctr, not trying to specify which integrity algorithm to choose. rfc4306 already required integrity for ikev2 and we refered to 4306 here. The choice of integrity algorithm is up to rfc4307 or some update document, we just listed what rfc4307 chooses to make this document more rich of information. If you think the table gives misleading impression of only requiring these particular algorithms, we may add another sentence to hint that integrity algorithm requirement may change over time, please check 4307 and 4307's update, the following listed algorithm is just showing current 4307's requirement. 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. I don't agree with this. Specifying Padding field to be empty and Pad Length to be zero here is not proper, because rfc4306 requires that recipient MUST accept any lenght that results in proper alignment (section 3.14). Best, Sean ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt
Sean Shen writes: The point here is to say that integrity protection is needed with aes-ctr, not trying to specify which integrity algorithm to choose. rfc4306 already required integrity for ikev2 and we refered to 4306 here. The choice of integrity algorithm is up to rfc4307 or some update document, we just listed what rfc4307 chooses to make this document more rich of information. If you think the table gives misleading impression of only requiring these particular algorithms, we may add another sentence to hint that integrity algorithm requirement may change over time, please check 4307 and 4307's update, the following listed algorithm is just showing current 4307's requirement. I think it is better to remove the table, and just refer to RFC4307 directly. 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. I don't agree with this. Specifying Padding field to be empty and Pad Length to be zero here is not proper, because rfc4306 requires that recipient MUST accept any lenght that results in proper alignment (section 3.14). Yes, it MUST accept, and it says SHOULD set Pad Length to minimum value, which in this case is zero. I think it is important to note that no padding is required, thus Pad Length field can be zero, and if the SHOULD in the RFC4306 is followed it will be zero. As this is different from the ESP, I think it is important to note this difference. In ESP the padding length MUST be selected so that provides 4-byte alignment for the encrypted data, but for IKEv2 there is no such requirement, and this should be even more explictly mentioned in the draft. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt
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
[IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt
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. Your comments will be appreciated. Regard, Sean A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 Author(s) : S. Shen, et al. Filename: draft-ietf-ipsecme-aes-ctr-ikev2-01.txt Pages : 17 Date: 2009-08-17 This document describes the usage of Advanced Encryption Standard Counter Mode (AES_CTR), with an explicit initialization vector, by IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr -ikev2-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Major changes are as following: #1. Section 2 Rearranged sentences at the beginning of section 2 to simplify and clarify AES and AES_CTR. #2 Section 2.1 Detailed description of counter mode was cited from corresponding section of rfc3686 #3 Section 2.2: old: All IKEv2 implementations MUST support the 128 key size. new: All IKEv2 implementations that implement AES-CTR MUST support the 128 key size. Because AES-CTR is a SHOULD requirement for IKEv2. #4 Section 3.2 Added clear reference to rfc4302 and rfc4307 for integrity requirement and algorithm choice. #5 Section 4 Rewrote second paragraph in section 4 to clarify the role of Counter Block. The Counter Block is same as that defined by rfc3686. #6 Section 4 Keep the Counter Block description in the same style as in rfc3686 Message/External-body; name=draft-ietf-ipsecme-aes-ctr-ikev2-01.txt: Unrecognized ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
