Main Archive Page > Month Archives  > ipsec archives

Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02

From: Sean Shen <sean.s.shen_at_nospam>
Date: Fri Oct 23 2009 - 12:38:45 GMT
To: Alfred HÎnes <ah@tr-sys.de>

2009/10/23 Alfred HÎnes <ah@tr-sys.de>

> Sean Shen wrote:
>
> > Section 2.2 says that "AES MUST use different rounds for each of the
> > key sizes: ...".
> > The draft is not trying to say that IKEv2 requires 10/12/14 rounds for
> > 128/192/256 key lengths. The draft is not trying to say that AES-CTR
> > requires 10/12/14 rounds for 128/192/256 key lengths.
> >
> > Sean
> >
> > ...
>
> The "MUST" still makes the difference! That is normative and does
> NOT belong into this draft. Although that would still be regarded
> out of scope of your draft, I would be more willing to accept an
> _informative_ statement like:
>
> "Note: AES uses different rounds for each of the key sizes: ...".
> ^^^^^^ ^^^^

[Sean] Correct, "MUST" is defined in key words conventions and should not be used here. I will dropt it.

> But the most important topic remains: The draft is ill-advised in
> pretending that the interface of AES -- or, btw, *any* currently
> sensibly used block cipher primitive of reasonable strength --
> had an _external_ parameter "number of rounds" that upper protocol
> (sub-)layers would need to have to deal with.
> Otherwise, the "IKEv2 Transform Attribute Types" would have to
> include an entry for "number of rounds", which it doesn't, and
> you also do not aim at establishing such entry.
>

[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]."
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]."

Best Regards,

Sean

---

IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec