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
