Subject: Re: [IPsec] [Technical Errata Reported] RFC5282 (5109)

From: "Black, David" <[email-masked]>
Date: Mon, 11 Sep 2017 22:19:20 +0000

[Adding the IPsec mailing list.]

> Notes
> -----
> RFC-7296 and RFC-5282 contradict each other (yet RFC-7296 cites RFC-5282 without any clarification):
> 
> - RFC-7296 explicitly disallows mixing AEAD and non-AEAD algorithms in a single
>   proposal; RFC-5282 does not (and strongly implies it is allowed)
> 
> - RFC-7296 allows 'none' integrity in an AEAD-only proposal; RFC-5282 does not.

Please provide pointers to the RFC 7296 text that supports each of these assertions.

Thanks, --David
----------------------------------------------------------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953    Mobile: +1 (978) 394-7754
[email-masked]
----------------------------------------------------------------

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]]
> Sent: Friday, September 8, 2017 11:13 AM
> To: Black, David <[email-masked]>; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Technical Errata Reported] RFC5282 (5109)
> 
> The following errata report has been submitted for RFC5282,
> "Using Authenticated Encryption Algorithms with the Encrypted Payload of
> the Internet Key Exchange version 2 (IKEv2) Protocol".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5109
> 
> --------------------------------------
> Type: Technical
> Reported by: Andrew Cagney <[email-masked]>
> 
> Section: 8.
> 
> Original Text
> -------------
> 8.  IKEv2 Algorithm Selection
> 
>    This section applies to the use of any authenticated encryption
>    algorithm with the IKEv2 Encrypted Payload and is unique to that
>    usage.
> 
>    IKEv2 (Section 3.3.3 of [RFC4306]) specifies that both an encryption
>    algorithm and an integrity checking algorithm are required for an IKE
>    SA (Security Association).  This document updates [RFC4306] to
>    require that when an authenticated encryption algorithm is selected
>    as the encryption algorithm for any SA (IKE or ESP), an integrity
>    algorithm MUST NOT be selected for that SA.  This document further
>    updates [RFC4306] to require that if all of the encryption algorithms
>    in any proposal are authenticated encryption algorithms, then the
>    proposal MUST NOT propose any integrity transforms.
> 
> Corrected Text
> --------------
> 8.  IKEv2 Algorithm Selection
> 
> IKEv2 [rfc7296], section 3.3. Security Association Payload, specifies
> AEAD algorithm selection.
> 
> 
> Notes
> -----
> RFC-7296 and RFC-5282 contradict each other (yet RFC-7296 cites RFC-5282
> without any
> clarification):
> 
> - RFC-7296 explicitly disallows mixing AEAD and non-AEAD algorithms in a
> single
>   proposal; RFC-5282 does not (and strongly implies it is allowed)
> 
> - RFC-7296 allows 'none' integrity in an AEAD-only proposal; RFC-5282 does
> not
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC5282 (draft-black-ipsec-ikev2-aead-modes-01)
> --------------------------------------
> Title               : Using Authenticated Encryption Algorithms with the Encrypted
> Payload of the Internet Key Exchange version 2 (IKEv2) Protocol
> Publication Date    : August 2008
> Author(s)           : D. Black, D. McGrew
> Category            : PROPOSED STANDARD
> Source              : IETF - NON WORKING GROUP
> Area                : N/A
> Stream              : IETF
> Verifying Party     : IESG

---

From: Yoav Nir <[email-masked]>
Date: Tue, 12 Sep 2017 07:20:47 +0300

Hi, David.

Section 2.7 last paragraph:

   If an initiator proposes both normal ciphers with integrity
   protection as well as combined-mode ciphers, then two proposals are
   needed.  One of the proposals includes the normal ciphers with the
   integrity algorithms for them, and the other proposal includes all
   the combined-mode ciphers without the integrity algorithms (because
   combined-mode ciphers are not allowed to have any integrity algorithm
   other than "NONE").

if you allow one proposal to specify (ENCR-AES-CBC,ENCR-AES-GCM,AUTH-None,AUTH-HMAC-SHA1) then the responder can validly select (ENCR-AES-GCM,AUTH-HMAC-SHA1) and that’s not a valid combination.

Yoav

> On 12 Sep 2017, at 1:19, Black, David <[email-masked]> wrote:
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Black, David" <[email-masked]>
Date: Tue, 12 Sep 2017 13:14:30 +0000

Hi Yoav,

Well, RFC 5282 actually prohibits the responder from selecting that combination, but requiring separate proposals for combined-mode and normal ciphers is a cleaner and simpler approach.

It looks like RFC 7296 should have updated RFC 5282, but didn’t.  I need to look at the relevant text in both RFCs more carefully, and plan to respond to Andrew’s email later today with my 0.02 on what should be done.

Thanks, --David

From: Yoav Nir [mailto:[email-masked]]
Sent: Tuesday, September 12, 2017 12:21 AM
To: Black, David <[email-masked]>
Cc: RFC Errata System <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [IPsec] [Technical Errata Reported] RFC5282 (5109)

Hi, David.

   other than "NONE").

Yoav

On 12 Sep 2017, at 1:19, Black, David <[email-masked]<mailto:[email-masked]>> wrote:

Notes
-----

Thanks, --David
[email-masked]<mailto:[email-masked]>

-----Original Message-----
From: RFC Errata System [mailto:[email-masked]]
Sent: Friday, September 8, 2017 11:13 AM
To: Black, David <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Technical Errata Reported] RFC5282 (5109)

--------------------------------------
Type: Technical
Reported by: Andrew Cagney <[email-masked]<mailto:[email-masked]>>

Section: 8.

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------

[email-masked]<mailto:[email-masked]>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Sep 2017 01:06:55 +0300

Black, David writes:
> Well, RFC 5282 actually prohibits the responder from selecting that
> combination, but requiring separate proposals for combined-mode and normal
> ciphers is a cleaner and simpler approach.

Yes, and RFC5996 restricted that even more, saying that you need to
use separate proposals to do that, which will make it clear that you
cannot select such combination and still following the generic IKEv2
rules how to select algorithms.

I.e., RFC 5282 changed the generic rules in IKEv2, and when the we did
do update on the IKEv2, i.e., from RFC4306 -> RFC5996, it decided that
changing generic rules is bad idea, and we can get the same effect by
forcing implementations to do two proposals, while also specifying how
to negotiate the AEAD ciphers for the ESP.

Note, that using two proposals is completely ok for the RFC5282 point
of view, i.e., nothing in the RFC5282 forbid using multiple proposals,
so in sense the RFC5996 did not change RFC5282 text, it just
restricted some of the options allowed by the RFC5282. 

This was discussed in the IPsec list during the 5996 rewrite, and
there was ticket #20 assigned for this:

https://trac.ietf.org/trac/ipsecme/ticket/20

Of course the RFC5282 only talks when negotiating AEAD algorithm for
IKEv2 use, not at all when using AEAD algorithm for ESP, i.e., when
negotiating AEAD algorithm to be used for ESP, which is the much more
common case. How to negotiate them in ESP was unclear before RFC5996,
as RFC4106 did not specify anything for IKEv2, and RFC4306 did not
really specify how they are negotiated. 

> It looks like RFC 7296 should have updated RFC 5282, but didn’t. I
> need to look at the relevant text in both RFCs more carefully, and
> plan to respond to Andrew’s email later today with my 0.02 on what
> should be done.

I am not sure if RFC5996 should have updated RFC5282, as it only
restricted some of the options allowed by RFC5282, but what is
specified in the RFC5996 is still completely inside the what RFC5282
implementation will accept.

RFC5996 did restrict some options from the RFC4306 also, i.e., things
that were allowed in RFC4306, were no longer allowed in RFC5996.

If someone would have pointed that out during the RFC5996 cycle, we
would most likely had done something to it... 

>         RFC-5282 without any clarification):

They do not really contradict, the RFC5996 and RFC7296 restrict the
options which were allowed in the RFC5282, but RFC5996 initiator will
still talk to the RFC5282 responder. If RFC5282 initiator tries to
talk to the RFC5996 responder, and does not use multiple proposals,
then the RFC5996 specification is silent what to do for that. Some
implementations will most likely accept it, and some will return
error. 

>         - RFC-7296 explicitly disallows mixing AEAD and non-AEAD
>         algorithms in a single proposal; RFC-5282 does not (and
>         strongly implies it is allowed)

RFC582 might imply so, but does not require or even suggest such
behavior, and using two proposals solves the issue in a way which is
acceptable for the RFC5282 too.

Btw, note, that RFC5996 and 7296 does not use upper case MUST, it just
states the facts, i.e. "two proposals are needed" (section 2.7), and
that if proposing both AEAD and non-AEAD ciphers, then "it must
include two proposals".

I.e. those are not new requirements, they are just facts based on the
requirements derived from the requirements elsewhere in the
specification. 

>         - RFC-7296 allows 'none' integrity in an AEAD-only proposal; RFC-5282

Yes. We had discussion about this when RFC5996 was being made, and I
think the reason why we do allow it was that there were some
implementations doing that (for ESP), and we did not want to make them
non-compilent by saying MUST NOT. Note, that RFC5996/7296 text covers
both cases when negotiating the AEAD for IKEv2 and ESP. The RFC5282
case only really covers IKEv2 case.

>         Corrected Text

This corrected text is good, and I think we can safely mark this as
errata ok, as the text specifying how to negotiate the AEAD ciphers
has in fact been incorporated in to the base IKEv2 specification.
-- 
[email-masked]

---

From: "Black, David" <[email-masked]>
Date: Tue, 12 Sep 2017 22:28:51 +0000

I'll defer to Tero's expertise on this - if he's ok with the revised text, then so am I.

Thanks, --David

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Tuesday, September 12, 2017 6:07 PM
> Cc: Yoav Nir <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; RFC Errata
> System <[email-masked]>