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

[Shen Sean <[e-mail]>]

2009/10/20 Tero Kivinen <[e-mail]>

> 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.

Best,

Sean