Found 2 records.

Status: Held for Document Update (1)

RFC 5926, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", June 2010

Errata ID: 6413
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ananth Rajadurai
Date Reported: 2021-01-28
Held for Document Update by: Martin Duke
Date Held: 2021-02-02

Section 3.1.1.2 says:

In section 3.1.1.2 Page 8, figure 1,

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                        KDF-AES-128-CMAC                           +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                                                                   +
+ Input  : MK (Master_Key, the variable-length shared secret)       +
+        : I (Input, i.e., the input data of the PRF)               +
+        : MKlen (length of MK in octets)                           +
+        : len (length of M in octets)                              +
+ Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable)         +
+                                                                   +
+-------------------------------------------------------------------+

It should say:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                        KDF-AES-128-CMAC                           +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                                                                   +
+ Input  : MK (Master_Key, the variable-length shared secret)       +
+        : I (Input, i.e., the input data of the PRF)               +
+        : MKlen (length of MK in octets)                           +
+        : len (length of I in octets)                              +
+ Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable)         +
+                                                                   +
+-------------------------------------------------------------------+

Notes:

In Input, "len" is described as (length of "M' in octets), but there is no "M" in the input, but it is supposed to mention the length of the Input Data "I", so it should be (length of "I" in octets)

Status: Rejected (1)

RFC 5926, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", June 2010

Errata ID: 5267
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Weis
Date Reported: 2018-02-26
Rejected by: Mirja Kühlewind
Date Rejected: 2018-03-28

Section 3.1.1 says:

- Label:     A binary string that clearly identifies the purpose
                   of this KDF's derived keying material.  For TCP-AO,
                   we use the ASCII string "TCP-AO", where the last
                   character is the capital letter "O", not to be
                   confused with a zero.  While this may seem like
                   overkill in this specification since TCP-AO only
                   describes one call to the KDF, it is included in
                   order to comply with FIPS 140 certifications.

It should say:

- Label:     A binary string that clearly identifies the purpose
                   of this KDF's derived keying material.  For TCP-AO,
                   we use the ASCII string "TCP-AO", where the last
                   character is the capital letter "O", not to be
                   confused with a zero. The ASCII string is terminated
                   with a null octet (0x00). While this may seem like
                   overkill in this specification since TCP-AO only
                   describes one call to the KDF, it is included in
                   order to comply with FIPS 140 certifications.

Notes:

This section states that "Both of these KDFs are based on the iteration-mode KDFs specified in [NIST-SP800-108].", which is later clarified to be the "counter mode" KDF defined in that document. The definition of the "Label" input to the KDF in the original text is not clear.

[NIST-SP800-108] specifies that a 0x00 octet should follow the Label. This 0x00 octet is important when the KDF does not have control over the Context given it, which is the case here -- RFC 5926 depends on the definition in RFC 5925. RFC 5925 currently declares two fixed-size inputs for the Context (See Figures 7 & 8 of RFC 5925), so the Context length differs. Also, RFC 5925 RFC could be updated over over time to include other Contexts that are variable sized. The risk of excluding 0x00 is enabling an attacker to choose a specially-crafted Context that violates the clean separation between the Label and Context arguments. Therefore, it is important to include the 0x00 octet for TCP-AO.

I believe this 0x00 is implied in the specification of the string "TCP-AO", since conventionally many string definitions include a trailing 0x00 octet, The text should state that the 0x00 octet is present as part of the string.

If this errata does not result in adding the 0x00 octet, then its omission needs to be justified.
--VERIFIER NOTES--
NIST-SP800-108 does not require the use of 0x00. It only requires that the length and order of each field be defined unambiguously. The method of providing that length unambiguously to the KDF algorithm is an implementation issue.

Report New Errata