ipsec October 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] review of draft-ietf-ipsecme-aes-ctr-ikev2-02

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

From: Tero Kivinen <kivinen_at_nospam>
Date: Tue Oct 20 2009 - 09:07:14 GMT
To: Shen Sean <sean.s.shen@gmail.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 library.

> (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. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec