[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
