I'll defer to Tero's expertise on this - if he's ok with the revised text, then so am I.
Thanks, --David > -----Original Message----- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Tuesday, September 12, 2017 6:07 PM > To: Black, David <david.bl...@emc.com> > Cc: Yoav Nir <ynir.i...@gmail.com>; mcg...@cisco.com; > andrew.cag...@gmail.com; ipsec@ietf.org; i...@ietf.org; RFC Errata > System <rfc-edi...@rfc-editor.org> > Subject: Re: [IPsec] [Technical Errata Reported] RFC5282 (5109) > > 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... > > > On 12 Sep 2017, at 1:19, Black, David <david.bl...@dell.com> wrote: > > > > [Adding the IPsec mailing list.] > > > > Notes > > ----- > > RFC-7296 and RFC-5282 contradict each other (yet RFC-7296 cites > > 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 > > does not. > > 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 > > -------------- > > 8. IKEv2 Algorithm Selection > > > > IKEv2 [rfc7296], section 3.3. Security Association Payload, > > specifies > > AEAD algorithm selection. > > 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. > -- > kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
