Subject: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt

From: Sean Shen <[email-masked]>
Date: Tue, 18 Aug 2009 12:00:26 +0800

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 18 Aug 2009 12:09:30 +0300

> Added clear reference to rfc4302 and rfc4307 for integrity requirement and

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. 
-- 
[email-masked]

---

From: Sean Shen <[email-masked]>
Date: Wed, 19 Aug 2009 09:46:10 +0800

Hi, Tero,
Thanks for the comments. Please check in lines:

> > modification addressed comments we received so far and also include 
> > some other editing.
> > 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 
> 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
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

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 19 Aug 2009 12:23:18 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sean Shen
> Sent: Wednesday, August 19, 2009 4:46
> To: 'Tero Kivinen'
> Cc: [email-masked]
> Subject: Re: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-
> 01.txt
> 
> Hi, Tero,
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 19 Aug 2009 13:59:18 +0300

> update, the following listed algorithm is just showing current 4307's

I think it is better to remove the table, and just refer to RFC4307
directly. 

> 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.
-- 
[email-masked]

---

From: Sean Shen <[email-masked]>
Date: Fri, 21 Aug 2009 15:40:53 +0800

> > 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. 
Ok, we will remove he talbe and only keep reference.
 
> > > 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 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.
So, we will add sentences in section 3 (encrypted payload) to enphasize
again that: sender is not required to pad plaintext; pad SHOULD be zero
following the "SHOULD be minimun" in rfc4306; also the difference of pad
requirement between ikev2 and esp will be helpful here. 

Thanks,

Sean