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
