|Main Archive Page > Month Archives > ipsec archives|
2009/10/20 Tero Kivinen <email@example.com>
> Shen Sean writes:
> > (3) Section 2 (and ff.)
> > The number of (internal) rounds is totally irrelevant for the
> > application of the AES. Any attempt to mangle with this 'parameter'
> > would raise significant security concerns and conformance issues.
> > I strongly request to elide all mention of "rounds" from the draft.
> I agree on that. In most cases the AES is implemented as part of
> cryptographic library or hardware, and for those you usually just
> indicate the key length to be used and that automatically selects the
> number of rounds.
> > [Sean] The intention of such a document is to give what a IKEv2 product
> > MUST/SHOULD/MAY provide. A user may not have "choices" of rounds or size,
> > but a vendor need to know what to provide.
> Usually even the vendor does not have choice, or even possibility to
> change the number of rounds, as that is hidden inside cryptographic
[Sean] I have no doubt that most users or vendors won't bother to choose or change what's already in crypto lib. But, a standard related document is responsible to clearly state what are necessary for a product, in this case, the basic characteristics of AES-CTR, even though some of these seems obvious. I remmeber the very early version of this document does not include rounds stuff, but eventually we added it based on reviewers' comments and requests.
> > (15) Section 7
> > I suggest to more clearly indicate what this draft is expecting IANA
> > to do: adding a reference to this memo for an existing registration.
> > | IANA has assigned 13 as the transform ID for ENCR_AES_CTR encryption
> > | with an explicit IV. This ID is to be used during IKE_SA
> > | negotiation.
> > ---
> > | Per [RFC3686], IANA has assigned 13 as the "IKEv2 Encryption
> > | Transform ID" to the name "ENCR_AES_CTR" for AES-CTR encryption with
> > | an explicit IV, in the IANA "Internet Key Exchange Version 2 (IKEv2)
> > | Parameters" registry. This document specifies how to use this
> > | transform during IKE_SA negotiations. Hence IANA should add to that
> > | entry a reference to this RFC.
> > [Sean] It's a good point, but for IANA's reference to this document, I
> > assume iana will updated their reference (following some rocedure?) when
> > this document is processed. Let me know if we have to request it in the
> > draft.
> I would not count on that. For example IANA didn't update the
> ENCR_AES-CCM_* or AES_GCM with a * octect ICV references for the
> RFC5282 automatically, so better add text there.
[Sean] The last time I check iana's ikev2 parameters, the parameters was "last updated 2009-09-21". Seems they missed what you mentioned above. So I will add a request for reference.