RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

RFC 5282, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", August 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 3605
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wan-Teh Chang
Date Reported: 2013-04-25
Verifier Name: Sean Turner
Date Verified: 2013-05-01

Section 10.1.3 says: 

   This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of
   [RFC5116]), except that the tag length, t, is 12, and an
   authentication tag with a length of 12 octets (64 bits) is used.

It should say:

   This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of
   [RFC5116]), except that the tag length, t, is 12, and an
   authentication tag with a length of 12 octets (96 bits) is used.

Notes:

"(64 bits)" should be changed to "(96 bits)".

Errata ID: 3606
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wan-Teh Chang
Date Reported: 2013-04-25
Verifier Name: Sean Turner
Date Verified: 2013-05-01

Section 10.1.4 says: 

   This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of
   [RFC5116], except that the tag length, t, is 12 and an authentication
   tag with a length of 12 octets (64 bits) is used.

It should say:

   This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of
   [RFC5116], except that the tag length, t, is 12 and an authentication
   tag with a length of 12 octets (96 bits) is used.

Notes:

"(64 bits)" should be changed to "(96 bits)".

Status: Reported (1)

RFC 5282, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", August 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5109
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Cagney
Date Reported: 2017-09-08

Section 8. says: 

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.

It should say:

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

Report New Errata



Advanced Search