RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 9 records.

Status: Verified (1)

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: 1338

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Verifier Name: Sean Turner
Date Verified: 2010-07-30

Section 7, pg. 14/15 says:

                                                                  Only
   after receiving message 6, the server SHOULD respond with an
<< page break >>
   authentication failure notification, i.e., a message conforming to
|  message 6 in Figure 10.  The purpose of this behaviour is to prevent
   an adversary from probing the EAP-IKEv2 peer identifier space.

It should say:

                                                                   Only
   after receiving message 6, the server SHOULD respond with an
   authentication failure notification, i.e., a message conforming to
|  message 7 in Figure 10.  The purpose of this behaviour is to prevent
   an adversary from probing the EAP-IKEv2 peer identifier space.

Notes:

Rationale: See Figure 10 in Appendix A (on page 30).

Note: The RFC contains Figure 1..6, 10, and 11, but no Figure 7..9 !

Status: Held for Document Update (7)

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

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!

Errata ID: 1336

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner

Section 4.,4th para says:

   ... by other severs ...

It should say:

   ... by other servers ...
                  ^

Errata ID: 1337

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner
Date Held: 2010-07-30

Section 6.,2nd para says:

   o  The Session-ID is constructed and exported as the concatenation of
|     the following three elements, in this order: (a) the EAP Code Type
|     for EAP-IKEv2 (to be defined by IANA), (b) the contents of the
      Nonce Data field of the Nonce Payload Ni from message 3, (c) the
      contents of the Nonce Data field of the Nonce Payload Nr from
      message 4.

It should say:

   o  The Session-ID is constructed and exported as the concatenation of
|     the following three elements, in this order: (a) the EAP Method 
|     Type for EAP-IKEv2 (49, as assigned by IANA), (b) the contents of
      the Nonce Data field of the Nonce Payload Ni from message 3, (c)
      the contents of the Nonce Data field of the Nonce Payload Nr from
      message 4.

Notes:

Rationale:
a) "EAP Code Type" is confusing; the correct term is
"EAP Methode Type".
b) The code point indeed had been allocated by IANA on publication
of the RFC; the text should be explicit, for the ease of its readers.

Errata ID: 1340

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner

Section 7, pg.15 says:

|  o  The packet contains an Integrity Checksum Data field (see *Figure
      4) that is incorrect.
                                                                ^

It should say:

|  o  The packet contains an Integrity Checksum Data field (see Figure
      4) that is incorrect.

Notes:

Location is third bullet on page 15.

Errata ID: 1341

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner

Section 8, last para says:

    ...  processed in way ...

It should say:

    ...  processed in a way ...

Errata ID: 1343

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner

Section 8.10,last pa says:

   ... in the context EAP-IKEv2 ...

It should say:

   ... in the context of EAP-IKEv2 ...

Notes:

Location is 3rd-to-last line of last paragraph of the section.

Errata ID: 1344

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Held for Document Update by: Sean Turner

Section A.,last para says:

   The difference in the full successful exchange ...

It should say:

   The difference from the full successful exchange ...

Status: Rejected (1)

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: 1339

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Rejected by: Sean Turner
Date Rejected: 2010-07-30

Section 7, pg.15 says:

   o  The packet contains an Encrypted payload that, when decrypted with
|     the appropriate key, yields an invalid decryption.

It should say:

   o  The packet contains an Encrypted payload that, when decrypted with
|     the appropriate key, yields an invalid plaintext.
                                             ^^^^^^^^^

Notes:

Location 1 first bullet on page 15.
--VERIFIER NOTES--
Document editor's choice.

Report New Errata