Subject: Re: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt

From: "Dan Harkins" <[email-masked]>
Date: Tue, 4 Mar 2008 00:02:55 -0800 (PST)

Hi David,

  What value is there in enabling CCM? Like GCM, it is fragile
in the sense that if an IV is ever reused all security is lost.
But unlike GCM it cannot support high-speed data rates because
of it's two-pass nature. If you're going to enable a two-pass
AEAD scheme why not consider SIV which is resistant to IV
misuse? That way if you need robustness and can sacrifice
speed you use SIV, if you are assured that the cipher mode
cannot be misused and want to take advantage of the speed
gain you use GCM.

  It doesn't make sense to add a cipher which is both slower
and fragile.

  regards,

  Dan.

On Fri, February 29, 2008 11:55 am, [email-masked] wrote:
> David McGrew and I would appreciate comments on this
> draft. Its primary purpose is to enable use of AES GCM
> and AES CCM for the IKEv2 encrypted payload - currently,
> these algorithms can be used with ESP, but not with
> IKEv2 proper (i.e., IKEv2 can negotiate ESP usage of
> GCM and CCM, but the IKEv2 encrypted payload can't
> currently be encrypted with GCM or CCM).
>
> This draft does so by applying the Authenticated
> Encryption framework from RFC 5116 to IKEv2's encrypted
> payload, as AES GCM, AES CCM and other combined modes
> are examples of authenticated encryption algorithms.
> The draft also supplies the remaining details needed
> for use of AES GCM and AES CCM with IKEv2.  This
> approach should make things easier for future
> authenticated encryption algorithms because the
> IKEv2-generic aspects (e.g., data that receives
> integrity coverage but is not encrypted) won't have
> to be respecified.
>
> While this draft has already received some good review
> (and we thank the reviewers), like any -00 version, it's
> not complete.  The only major technical content that's
> missing is completing the connection to RFC 5116, mostly
> explaining how this draft relates to the specific AEAD
> algorithms defined in RFC 5116.  As part of doing this,
> additional AEAD algorithm identifiers for AES CCM will be
> defined to the version of AES CCM specified in RFC 4309,
> as the AEAD CCM algorithms in RFC 5116 differ from
> those in RFC 4309.
>
> There are a few technical issues that we are looking
> for input on:
>
> 1) Key size.  IPsec in general allows 192 bit AES
> 	keys, but RFC 5116 currently does not.  Is it
> 	ok to not allow 192 bit AES keys when AES GCM
> 	and AES CCM are used for the IKEv2 encrypted
> 	payload.
> 2) ICV size.  Both RFC 4106 (GCM) and 4309 (CCM) are
> 	fairly permissive about 8-octet and 12-octet
> 	ICVs.  David McGrew would like to generally
> 	prohibit ICV sizes other than 16-octets and hence
> 	only specify and allow support of 16-octet ICVs
> 	in this draft.  That would place tighter
> 	restrictions on AES GCM and AES CCM usage with
> 	IKEv2 than with ESP unless something else is done.
> 3) Padding.  Both AES GCM and AES CCM only require
> 	padding only to a 32-bit alignment (this is
> 	done here for commonality with ESP).  Is that
> 	a general characteristic of authenticated
> 	encryption algorithms, or are there algorithms
> 	that may need more padding (e.g., to the AES
> 	encryption block size)?
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of [email-masked]
>> Sent: Wednesday, February 20, 2008 1:10 PM
>> To: IPsec WG
>> Subject: [IPsec] I-D ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> 	Title		: Using Authenticated Encryption Algorithms
>> with the Encrypted Payload of the Internet Key Exchange version 2
>> (IKEv2) Protocol
>> 	Author(s)	: D. Black, D. McGrew
>> 	Filename	: draft-black-ipsec-ikev2-aead-modes-00.txt
>> 	Pages		: 14
>> 	Date		: 2008-2-15
>>
>> An authenticated encryption algorithm combines encryption and
>>     integrity into a single operation; such algorithms may also be
>>     referred to as combined modes of an encryption cipher or
>> as combined
>>     mode algorithms.  This document describes the use of authenticated
>>     encryption algorithms with the Encrypted Payload of the
>> Internet Key
>>     Exchange version 2 (IKEv2) protocol.
>>
>>     The use of two specific authenticated encryption
>> algorithms with the
>>     IKEv2 Encrypted Payload is also described; these two
>> algorithms are
>>     the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES
>>     GCM) and AES in Counter with CBC-MAC Mode (AES CCM).  Additional
>>     documents may describe use of other authenticated encryption
>>     algorithms with the IKEv2 Encrypted Payload.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-black-ipsec-ikev2-ae
> ad-modes-00.txt
>>
>> _______________________________________________
>> IPsec mailing list
>> [email-masked]
>> http://www.ietf.org/mailman/listinfo/ipsec
>>
>>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked]
Date: Wed, 5 Mar 2008 12:56:52 -0500

Dan,

> of it's two-pass nature.

The short answer is consistency.  GCM and CCM are specified for
ESP, so this draft specifies them for the IKEv2 Encrypted Payload.
Unless we want to move RFC 4309 to Historic status, this seems
like a reasonable thing to do.  I believe that there's much
more implementation interest in GCM than CCM.

> If you're going to enable a two-pass

I have no objection in principle to specifying SIV for IKEv2.
Where is SIV specified for ESP?
 
>   It doesn't make sense to add a cipher which is both slower

IMHO, this should be done consistently for ESP and IKEv2.  If
you believe that CCM should no longer be used, I suggest
writing an Internet-Draft that explains why as a justification
for moving RFC 4309 (CCM for ESP) to Historic status.

Thanks,
--David

---

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Mar 2008 13:15:48 -0500

David,

One observation about crypto modes for IPsec and IKE:

	- IKE has very low bandwidth requirements, so the motivation 
to adopt crypto modes that offer higher performance is pretty low 
here.  The notion of having the same mode for both ESP and IKE has 
some attraction, but is it that critical?  Crypto chip vendors 
support protocols other than IPsec and IKE with the same chips.  if 
we use a mode for IKE that is also used by other protocols, then that 
mode will likely be there anyway.

Steve

---

From: [email-masked]
Date: Wed, 5 Mar 2008 18:15:16 -0500

Steve, 

> mode will likely be there anyway.

I appreciate the observation and believe it's correct, but I
also believe that there are additional considerations.

This draft has been motivated in part by the adaptation of IKEv2
and ESP to SCSI, and clear interest has been expressed by the
SCSI standards organization (T10) in using authenticated encryption
with the SCSI version of IKEv2, mostly on the grounds of being
able to use the same encryption mode for both IKEv2 and ESP.  A
major contributing factor is that for simplicity, the concept
of CHILD SAs and the associated IKEv2 negotiation pass that
enables use of different algorithms for the IKE SA and CHILD SA
were both removed as part of the SCSI work.

Some of these SCSI implementations of IKE and ESP may be in
software, as the use cases do not involve encryption of all
transmitted data (e.g., an important initial motivating use
case has been inband keying of a tape drive that has onboard
encryption), hence the functional footprint may matter.

In addition, GCM in particular has such compelling hardware
implementation advantages over a separate integrity computation
that I'm not sure that all crypto hardware is always going to
support something like CBC plus an integrity hash when one
considers what's involved in fast hardware support for the
SHA2 hashes.

Also, one argument for authenticated encryption is that it is
authenticated (ok, that's obvious), hence its use removes any
possibility of an "encryption without data integrity
authentication" security weakness, and for that that reason,
I think we should be enabling and encouraging its use.

I don't know that any of these are "critical" reasons, but I
also don't think "critical" is the right decision level.  This
is a clear functional gap in IKEv2, and closing it not only
supports use of a variant of IKEv2 in another standards body,
but also adds flexibility to implementations and encourages
use of technology that eliminates a potential security weakness.

Thanks,
--David

---

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Mar 2008 18:26:26 -0500

David,

Thanks for articulating some additional motivations for defining use 
of GCM in IKEv2.

I think that adding this as an optional, additional crypto capability 
is OK.  Makig it the default or mandatory to implement for IPsec in 
general would be a harder argument.  However, you noted that the SCSI 
context is a major focus, and their profile is not the general case, 
so ...

Steve

---

From: [email-masked]
Date: Wed, 5 Mar 2008 19:04:57 -0500

Steve,

> is OK.  Making it the default or mandatory to implement for IPsec in 

I agree, and I'm deliberately not making the "harder argument" - the
goal of this draft is only to make authenticated encryption algorithms
such as GCM available as an "optional, additional crypto capability"
for IKEv2.  I have no intention of making authenticated encryption
(e.g., GCM) "the default or mandatory to implement" for IKEv2.

Thanks,
--David

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 6 Mar 2008 13:35:43 +0200

> (e.g., GCM) "the default or mandatory to implement" for IKEv2.

For me the most important issue is that IKEv2 shares same encryption
algoritm numbers for both ESP and IKEv2 payloads, and there has not
been description how to use those combined modes with IKEv2. Some
people have argued that it is "obvious" how they are used and claimed
they can be used. I do not think it is obvious, thus I think we either
need document saying they are not to be used, or we define how to use
them. I think defining how they are used is better option from those
two.

Some comments about the draft:

> 1. Introduction
> ...
>   with IKEv1, thus limiting initial specifications of AES combined mode 
>   usage for IPsec to the Encapsulating Security Payload (ESP) 
>   [RFC2406].  The current version of ESP is version 2, ESPv2 [RFC4303]. 

There is no versions on the ESP, and I think the current RFC4303 was
mostly referenced as ESPv3, not version 2. I think it would be better
to change that to just say:

   The curren version of ESP is specified in RFC4303.

or something like that.

> 3. IKEv2 Encrypted Payload Data
> ...
>   The length of the Padding field MUST be chosen so that the number of 
>   octets in the Encrypted Payload is a multiple of four, in order to 
>   satisfy IKEv2 data alignment needs.   

IKEv2 does not have any data alignment needs, and the data fields in
the IKEv2 might have any alignment. For example certficiate payloads
etc can have any length and payloads after that will be unaligned.

We might want to still limit the alignment to 4 bytes even when IKEV2
do not require so, but we should not claim it is because of IKEv2 data
alignment needs. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked]
Date: Thu, 6 Mar 2008 17:00:16 -0500

Tero,

Thanks for looking at the draft.

The ESP change sounds fine.  Regarding alignment:

> the IKEv2 might have any alignment. For example certificate payloads
> We might want to still limit the alignment to 4 bytes even when
> IKEV2 do not require so, but we should not claim it is because
> of IKEv2 data alignment needs.

The heritage of that text is that it was copied from text specifying
use of the algorithms with ESP.  On this basis, I think we can just
drop this alignment text for IKEv2, as neither GCM nor CCM has any
inherent alignment requirements.

Thanks,
--David

> From: Tero Kivinen [mailto:[email-masked]] 
> Sent: Thursday, March 06, 2008 6:36 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Subject: Re: [IPsec] I-D 
> ACTION:draft-black-ipsec-ikev2-aead-modes-00.txt
>