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 <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): >> >> - 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 > david.bl...@dell.com > ---------------------------------------------------------------- > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-edi...@rfc-editor.org] >> Sent: Friday, September 8, 2017 11:13 AM >> To: Black, David <david.bl...@emc.com>; mcg...@cisco.com; i...@ietf.org >> Cc: andrew.cag...@gmail.com; rfc-edi...@rfc-editor.org >> 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 <andrew.cag...@gmail.com> >> >> 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 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
