Subject: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Sep 2008 16:42:28 +0300

> >  3.14.  Encrypted Payload
> >
> >     The Encrypted Payload, denoted SK{...} or E in this memo, contains
> >     other payloads in encrypted form.  The Encrypted Payload, if present
> >     in a message, MUST be the last payload in the message.  Often, it is
> >     the only payload in the message.
> >
> >     The algorithms for encryption and integrity protection are negotiated
> >     during IKE_SA setup, and the keys are computed as specified in
> >     Section 2.14 and Section 2.18.
> >
> >     This document specifies the cryptographic processing of Encrypted
> >     payloads using a block cipher in CBC mode and an integrity check
> >     algorithm that computes a fixed-length checksum over a variable size
> >     message.  The design is modeled after the ESP algorithms described in
> 
> As we already has document which describes how to use other ciphers in
> the IKE, we at least put the reference to there, or even incorporate
> the changes specified in there to this document. Especially as the
> RFCF 4307 specifies ENCR_AES_CTR as SHOULD for the IKEv2...
> 
> ===Done. Well, not the way that you wanted. I will send in an errata to
> RFC 4307 saying that AES_CTR should not have been listed.

I think the AES_CTR can be used to protect the IKEv2 SA without any
problems. The RFC3686 already describes evertything that is needed to
use it. The only difference to the CBC mode is, is the way how IV for
the AES_CTR is generated. The RFC4306 only points to "Recommendation
for Block Cipher Modes of Operation" document for advises for IV
generation. Only think that would not really be needed for IV
selection is the text in the RFC4306 which says that IV must be
unpredictable. The counter mode ciphers do not require
unpredictability but they do require uniqueness.

Anyways RFC3686 already describes the way how the IV should be
generated for AES_CTR, and I do not see any reason why the the text
which previously allowed CTR now needs to forbid CTR modes and only
allow CBC modes. This is again protocol change that will change bits
on the wire (i.e making CTR mode in IKEv2 SA to be unspecified even
when it was previously specified).

Note, that RFC5282 "Using Authenticated Encryption Algorithms with the
Encrypted Payload of the Internet Key Exchange version 2 (IKEv2)
Protocol" do NOT include AES-CTR description there. It only includes
combined modes, which were unspecified in IKEv2 SAs before.

Couldn't find issue number for this from the tracker, so could not put
reference to it.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Sep 2008 16:02:41 -0700

At 4:42 PM +0300 9/23/08, Tero Kivinen wrote:
>use it.

...except how to do so in IKEv2. RFC 3686 is, obviously, for IKEv1 only.

>The only difference to the CBC mode is, is the way how IV for

And this will help bits-on-the-wire interoperability in what way? :-)

>allow CBC modes.

That's not what I am saying: I'm saying that it was a mistake to list 
ENCR_AES_CTR as RFC3686 unless that RFC describes how to use it in 
IKEv2, which it doesn't. There is nothing stopping someone from 
writing a revision to RFC 3686 to describe this.

>This is again protocol change that will change bits

Unless I am missing something, it is not specified: it is unspecified 
but you could try to guess from RFC 3686.

>combined modes, which were unspecified in IKEv2 SAs before.

...but are fully specified there.

>Couldn't find issue number for this from the tracker, so could not put

I don't see it either. Yaron, can you add this one as "open"?

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Sep 2008 14:03:34 +0300

> ...except how to do so in IKEv2. RFC 3686 is, obviously, for IKEv1 only.

So is RFC2451 and RFC3602 (AES_CBC). So we cannot use AES_CBC or 3DES
either if using the same logic. 

> And this will help bits-on-the-wire interoperability in what way? :-)

Responder takes IV field from the packet a generates the real IV given
to the AES CTR by concatenating nonce (which is from keying material
generated by IKEv2), IV field, and block number (0). Responder does
not care how the IV was generated, and it does not need to care.
Responder will be interoperable with the other end regardless how the
initiator generates IVs. 

> writing a revision to RFC 3686 to describe this.

Same applies to the RFC3602 (AES_CBC), and RFC 2451 (3DES, RC5, IDEA,
Cast, Blowfish, 3IDEA). None of those describe anything how those
ciphers are used in the IKEv2, they only describe how they are used in
the ESP (or IKEv1).

3DES, AES-CBC, AES-CTR are all in exactly same situation here.

> but you could try to guess from RFC 3686.

And same applies to the AES-CBC. It is unspecified, but you can try to
guess from RFC 3602 and try to apply that ESP and IKEv1 processing to
IKEv2.

When the RFC 3686 was being specified, I required it to be changed so
it does not use IKEv2 ONLY way of describing how to generate keying
material, but uses words that can be use for BOTH IKEv1 and IKEv2:

http://www.sandelman.ottawa.on.ca/ipsec/2003/06/msg00197.html

BTW Could not use the www.ietf.org ipsec-list mail archive as it only
starts from 2004.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec