RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (4)

RFC 4543, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", May 2006

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

Errata ID: 1821
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pasi Eronen
Date Reported: 2009-07-30
Verifier Name: Pasi Eronen
Date Verified: 2009-10-08

Section 9 says: 

(nothing)

It should say:

The following text should have been included in Section 9:

For the negotiation of AES-GMAC in AH with IKEv1, the following
values have been assigned in the IPsec AH Transform Identifiers
registry (in isakmp-registry). Note that IKEv1 and IKEv2 use
different transform identifiers.

   "11" for AH_AES-128-GMAC

   "12" for AH_AES-192-GMAC

   "13" for AH_AES-256-GMAC

In addition, the following values have been assigned in the
Authentication Algorithms registry (in isakmp-registry):

   "11" for AES-128-GMAC

   "12" for AES-192-GMAC

   "13" for AES-256-GMAC

For the negotiation of AES-GMAC in ESP with IKEv1, the following
value has been assigned from the IPsec ESP Transform Identifiers
registry (in isakmp-registry). Note that IKEv1 and IKEv2 use a
different transform identifier.

   "23" for ESP_NULL_AUTH_AES-GMAC

Notes:

Found by Soo-Fei Chew (ipsec@ietf.org list, 2009-04-09);
approved by IESG in 2009-06-04 telechat.

Errata ID: 3643
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Bowler
Date Reported: 2013-06-06
Verifier Name: Sean Turner
Date Verified: 2013-08-14

Section 4 says: 

   In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV
   and the Authentication Tag, as shown in Figure 5.  Unlike the usual
   AH case, the Authentication Data field contains both an input to the
   authentication algorithm (the IV) and the output of the
   authentication algorithm (the tag).  No padding is required in the
   Authentication Data field, because its length is a multiple of 64
   bits.

It should say:

   In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV
   and the Authentication Tag, as shown in Figure 5.  Unlike the usual
   AH case, the Authentication Data field contains both an input to the
   authentication algorithm (the IV) and the output of the
   authentication algorithm (the tag).  In IPv6, padding of 4 octets is
   required to bring the AH header to a multiple of 64-bits.  No padding
   is required for IPv4.

Notes:

The original text fails to consider the rest of the AH header which is 12 octets plus the authentication data field.

Errata ID: 62
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: David McGrew
Date Reported: 2006-07-06
Verifier Name: Russ Housley
Date Verified: 2010-03-11

Section 7 says: 

In ENCR_NULL_AUTH_AES_GMAC, the IV is not included in either the  
plaintext or the additional authenticated data.

It should say:

In AES-GCM-ESP, the IV is not included in either the plaintext or  
the additional authenticated data.

Notes:

This error might confuse the reader because it makes the text
contradict Figure 4.

Errata ID: 1921
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Paul Hoffman
Date Reported: 2009-10-20
Verifier Name: Russ Housley
Date Verified: 2010-03-11

Section 11 says: 

   [GCM]      McGrew, D. and J. Viega, "The Galois/Counter Mode of
              Operation (GCM)", Submission to NIST. http://
              csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/
              gcm-spec.pdf, January 2004.

It should say:

[GCM]      Dworkin, M. "Recommendation for Block Cipher Modes
of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special
Publication 800-38D, November 2007.

Notes:

The original link is dead.

Report New Errata



Advanced Search