2009/10/20 Tero Kivinen
<kivinen at iki.fi>
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
library.
[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.
