|Main Archive Page > Month Archives > ipsec archives|
2009/10/23 Alfred HÎnes <email@example.com>
> Sean Shen wrote:
> >> ...
> > [Sean] The IKEv2 requirement in the draft is only about key lengths.
> > I never pretended that the AES standard allows arbitary conbinations
> > of key lengths and rounds.
> > I checked the document again and noticed that in the second paragraph
> > of section 2:
> > "... The choices of Key Size, Rounds and Block Size are defined as
> > following which are compatible with [RFC3686]."
> That was one of my initial complaints ...
> > If this sentense misleads readers to think that users can choose all
> > conbinations, I will rewrite it as:
> > "... The choices of Key Size are defined as following which are
> > compatible with [RFC3686]."
> ... and that's essentially what I had proposed for that paragraph.
> And yes, since that's written in the overview of Section 2, which
> lays out the skeleton of the remainder of the section, the immediate
> consequence of this change should be to drop sections 2.2 and 2.3
> as well, as explained in my original review.
> (To recall: The argument presented there was that, after dropping
> inappropriate text, the remaining text in 2.2 & 2.3 would be a
> simple -- yet verbose -- restatement of the first paragraph of
> Section 2, and hence redundant anyway.)
[Sean] Section 2.2 introduces key length of AES, the associated rounds,
IKEv2's MUST/MAY requirements of key length. Section 2.3 introduces block
size. These are all basic intro of algorithm.
The overview of section 2 can be:
" The use of AES algorithm operations in IKEv2 is the same as what defined in [AES]. The use of Counter Mode is defined the same as how AES_CTR is used to encrypt ESP payload [RFC3686]. Basic descriptions of AES and CTR mode are given in this section. Also the requirement of Key Size of IKEv2 are discussed as following which are compatible with [RFC3686]."