RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 5116, "An Interface and Algorithms for Authenticated Encryption", January 2008

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

Errata ID: 4338

Status: Reported
Type: Technical

Reported By: Maarten Bodewes
Date Reported: 2015-04-19

Section 3.2.1 says:

      +-------------------+--------------------+---------------+
      |    Fixed-Common   |   Fixed-Distinct   |    Counter    |
      +-------------------+--------------------+---------------+
       <---- implicit ---> <------------ explicit ------------>

                 Figure 2: Partially implicit nonce format

      The rationale for the partially implicit nonce format is as
      follows.  This method of nonce construction incorporates the best
      known practice; it is used by both GCM Encapuslating Security
      Payload (ESP) [RFC4106] and CCM ESP [RFC4309], in which the Fixed
      field contains the Salt value and the lowest eight octets of the
      nonce are explicitly carried in the ESP packet.  In GCM ESP, the
      Fixed field must be at least four octets long, so that it can
      contain the Salt value.  In CCM ESP, the Fixed field must be at
      least three octets long for the same reason.  This nonce
      generation method is also used by several counter mode variants
      including CTR ESP.

It should say:

      +-------------------+------------------------------------+
      |    Fixed-Common   |           Fixed-Distinct           |
      +-------------------+------------------------------------+
       <---- implicit ---> <------------ explicit ------------->

                 Figure 2: Partially implicit nonce format

      The rationale for the partially implicit nonce format is as
      follows.  This method of nonce construction incorporates the best
      known practice; it is used by both GCM Encapuslating Security
      Payload (ESP) [RFC4106] and CCM ESP [RFC4309], in which the
      Fixed-Common field contains the Salt value and the lowest eight
      octets of the nonce are explicitly carried in the ESP packet. In
      GCM ESP, the Fixed-Common field must be at least four octets
      long, so that it can contain the Salt value.  In CCM ESP, the
      Fixed-Common field must be at least three octets long for the
      same reason.  This nonce generation method is also used by
      several counter mode variants including CTR ESP.

Notes:

The counter is generally not considered part of the nonce.

The counter itself is not /send/ as part of the nonce, so the figure doesn't comply with the sentence in the text above: "We call the portion of the nonce that is stored or sent with the ciphertext the explicit part." Furthermore the text above also reads: "lowest eight octets of the nonce are explicitly carried in the ESP packet"

The referred to documents (e.g. RFC 4106) also explicitly specify a 12 byte nonce.

The GCM documentation recommends using a nonce of 96 bits (12 bytes) and then proceeds to build a counter (specified as J0) out of that. If the nonce is considered 128 bits instead then J0 is created using a GMAC invocation, which is probably not what was meant by this specification.

Finally, the text about GCM ESP and CCM ESP didn't distinguish between Fixed-Common and Fixed Distinct. It seems clear to me that Fixed-Common was meant the text below Figure 2. (If this should be in a separate Report, please let me know - the text between these parentheses may be removed of course)

Report New Errata