RFC 5106, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", February 2008Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec
Errata ID: 1342
Status: Held for Document Update
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner
Section 8.1 says:
Last paragraph on page 17: [...]. The Message Length field is four octets long and contains the length of the entire message (i.e., the length of the EAP Data field.). Note that, in contrast, the Length field shown in ^^^^^^^^^^^^^^ Figure 4 contains the length of only the current fragment. [...] Second-to-last paragraph on page 18: The Integrity Checksum Data field contains a cryptographic checksum that covers the entire EAP message, starting with the Code field, and | ending at the end of the EAP Data field. This field, shown in Figure ^^^^^^^^^^^^^^^^^^ 4, is present only if the I bit is set in the Flags field. The Integrity Checksum Data field immediately follows the EAP Data field without padding.
The above text is ambiguous and confusing, because the
"EAP Data field" is neither shown in Figure 4 nor
introduced in the text of Sections 8 / 8.1.
From the text snippits above, it remains unclear in particular
whether or not the "Integrity Checksum Data" field is considered
part of the "EAP Data field".
According to the EAP base specification, the former should be
expected, but the text contains no provisions for presetting
that field when calculating the ICV; thus it might be concluded
that the latter was intended.