RFC Errata
RFC 5116, "An Interface and Algorithms for Authenticated Encryption", January 2008
Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec
Errata ID: 4338
Status: Reported
Type: Technical
Publication Format(s) : TEXT
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)