Subject: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Mar 2010 09:51:37 -0800

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.
>
>	Title		: Using Advanced Encryption Standard (AES) Counter Mode with IKEv2
>	Author(s)	: S. Shen, Y. Mao, S. murthy
>	Filename	: draft-ietf-ipsecme-aes-ctr-ikev2-05.txt
>	Pages		: 10
>	Date		: 2010-3-2
>	
>This document describes the usage of Advanced Encryption Standard
>   Counter Mode (AES-CTR), with an explicit initialization vector, by
>   IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT
>   exchange.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-05.txt

Based on Pasi's AD review, the authors significantly shortened the document. It seems prudent to have the WG review the new, shorter version. In particular, it would be good for developers to look at the new short document and see if it is complete enough to implement from.

This review cycle will end in a week, but please do the review early in case problems are found.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Thu, 4 Mar 2010 07:16:55 +0200

Paragraph 5 of section #2:
   MUST accept any length that results in proper alignment.  It should
   be noticed that the ESP [RFC4303] Encrypted Payload requires

Please change "noticed" to "noted".

Other than that, the document looks good enough for implementation.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Wednesday, March 03, 2010 7:52 PM
To: IPsecme WG
Subject: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 4 Mar 2010 13:47:17 +0200

Paul Hoffman writes:
> Based on Pasi's AD review, the authors significantly shortened the
> document. It seems prudent to have the WG review the new, shorter
> version. In particular, it would be good for developers to look at
> the new short document and see if it is complete enough to implement
> from. 
> 

The draft looks good, but I would clarify the security considerations
section a bit. Now it says:

   Security considerations explained in section 7 of [RFC3686] are
   entirely relevant for this draft also.  The security considerations
   on fresh keys and integrity protection in section 7 of [RFC3686] are
   totally applicable on using AES-CTR in IKEv2; see [RFC3686] for
   details.  Due to this reasons, static keys are never used for the IKE
   SA and the IKE_SA always uses integrity protection.

The last paragraph is bit misleading, as there is no way static keys
can be used in IKE SA at all, and this is not because of the issues of
AES-CTR. Also integrity protection is already mandatory for IKEv2 IKE
SA regardless whether AES-CTR is used or not. It would be better to
replace the last sentence with:

   As static keys are never used in IKEv2 for IKE_SA and integrity
   protection is mandatory for IKE_SA, these issues are not applicable
   for AES-CTR in IKEv2 when protecting IKE_SA.
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 4 Mar 2010 15:20:32 -0500

Caveat: I have not reviewed in detail.

But I noticed a typo below line 3020 -- "may hve".

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Paul Hoffman <[email-masked]>                                                                                                              |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |IPsecme WG <[email-masked]>                                                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |03/03/2010 12:51 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |[IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt                                                                                     |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|

Based on Pasi's AD review, the authors significantly shortened the
document. It seems prudent to have the WG review the new, shorter version.
In particular, it would be good for developers to look at the new short
document and see if it is complete enough to implement from.

This review cycle will end in a week, but please do the review early in
case problems are found.

--Paul Hoffman, Director
--VPN Consortium

---

From: Sean Shen 沈烁 <[email-masked]>
Date: Mon, 8 Mar 2010 15:39:49 +0800

>   for AES-CTR in IKEv2 when protecting IKE_SA.

Agree, I will reword this part. 

Sean

---

From: David McGrew <[email-masked]>
Date: Mon, 8 Mar 2010 08:33:23 -0800

The statement that "Although the [RFC4307] specifies that the AES-CTR  
encryption algorithm feature SHOULD be supported by IKEv2, no existing  
document specifies how IKEv2 can support the feature"  is not  
completely correct.  RFC 5282 specifies how to use AES in the Galois  
Counter Mode (GCM) and Counter and CBC-MAC (CCM) modes of operation.

Neither this draft nor RFC 4307 provides any rationale for why or when  
AES-CTR should be used.  If it is  considered useful because CTR can  
be pipelined or implemented in parallel, then the considerations of http://tools.ietf.org/html/draft-mcgrew-esp-ah-algo-update-00#section-3 
  would apply.  What value is there is promoting the use of AES-CTR  
when better technical alternatives exist and are on standards track?   
If the sole motivation for this standard is to correct the  
inconsistency between RFC 4307 and RFC 3686, then the draft should  
include a statement to that effect, and mention the IKEv2 transforms  
that have all of the advantages of AES-CTR already exist.

The draft is not very clear on how AES-CTR is supposed to be  
implemented.  What is the counter format and what is the increment  
function?   If the intent is to copy RFC 3686 then this needs to be  
made more explicit.

David

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Mar 2010 10:31:16 -0800

At 8:33 AM -0800 3/8/10, David McGrew wrote:
>The statement that "Although the [RFC4307] specifies that the AES-CTR encryption algorithm feature SHOULD be supported by IKEv2, no existing document specifies how IKEv2 can support the feature"  is not completely correct.  RFC 5282 specifies how to use AES in the Galois Counter Mode (GCM) and Counter and CBC-MAC (CCM) modes of operation.

David, that sounds like you are saying that GCM and CCM modes are the same at the CTR mode, which we all know is not true. The statement in the current draft is true, and I would not want to muddy it by saying ", but other RFCs specify how IKEv2 can support other modes".

>Neither this draft nor RFC 4307 provides any rationale for why or when AES-CTR should be used.  If it is  considered useful because CTR can be pipelined or implemented in parallel, then the considerations of http://tools.ietf.org/html/draft-mcgrew-esp-ah-algo-update-00#section-3 would apply.  What value is there is promoting the use of AES-CTR when better technical alternatives exist and are on standards track?

Because implementers might do it anyway, regardless of whether there might be better alternatives. We have already heard that some have.

>If the sole motivation for this standard is to correct the inconsistency between RFC 4307 and RFC 3686, then the draft should include a statement to that effect,

Agree, but...

> and mention the IKEv2 transforms that have all of the advantages of AES-CTR already exist.

Disagree. GCM and CCM have the disadvantage of being more complex than CTR, and that complexity brings more safety. Instead, this draft can point to RFC 5282 as another way to do *similar* things.

>The draft is not very clear on how AES-CTR is supposed to be implemented.  What is the counter format and what is the increment function?   If the intent is to copy RFC 3686 then this needs to be made more explicit.

A sentence on each of those would be good additions to section 2.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 8 Mar 2010 11:17:00 -0800 (PST)

Hi,

  Let me take this opportunity to point out that RFC 5297 describes
an AES-CTR variant that does not have the performance benefits that
GCM has but provides nonce misuse/abuse resistance. It is a much more
robust alternative than CCM because security is not voided if the
nonce/counter happens to get reused. The robustness properties would
work well for SA failover because you don't need to worry about the
counter being reused.

  If you're not already using CCM there's really no reason to start.
It's slow and fragile and alternatives exist to address both of those
shortcomings, GCM and SIV respectively.

  regards,

  Dan.

On Mon, March 8, 2010 8:33 am, David McGrew wrote:
> be pipelined or implemented in parallel, then the considerations of
> http://tools.ietf.org/html/draft-mcgrew-esp-ah-algo-update-00#section-3

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Mar 2010 11:47:32 -0800

At 11:17 AM -0800 3/8/10, Dan Harkins wrote:
>GCM has but provides nonce misuse/abuse resistance.

It feels like your comment is unrelated to this thread, unless you are proposing that draft-ietf-ipsecme-aes-ctr-ikev2 needs to reference every single variant, even those that are not on standards track. If that is what you are saying, please propose wording for the WG to look at.

--Paul Hoffman, Director
--VPN Consortium