RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

RFC 5106, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", February 2008

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

Errata ID: 1342
Status: Held for Document Update
Type: Technical
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.

Notes:

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.

Please clarify!

Report New Errata



Advanced Search