RFC 4763, "Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)", November 2006

Errata ID: 1415
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-02-12
Rejected by: Bob Braden
Date Rejected: 2008-04-24

(3)  Section 3.2.8.2 -- clarification needed

Within Section 3.2.8.2, the second paragraph on page 20 says:

   The default encryption algorithm, as described in Section 3.2.8.3,
   requires the length of the plaintext to be a multiple of 16 bytes.
   The sender MAY need to include the AT_PADDING attribute as the last
|  attribute within the value field of the AT_ENCR_DATA attribute.  The
   length of the padding is chosen so that the length of the value field
   of the AT_ENCR_DATA attribute becomes a multiple of 16 bytes.  The
   AT_PADDING attribute SHOULD NOT be included if the total length of
   other attributes present within the AT_ENCR_DATA attribute is a
   multiple of 16 bytes.  The length of the AT_PADDING attribute
   includes the Attribute Type and Attribute Length fields.  The actual
   pad bytes in the value field are set to zero (0x00) on sending.  The
   recipient of the message MUST verify that the pad bytes are zero
   after decryption and MUST silently discard the message otherwise.

It should say:

   The default encryption algorithm, as described in Section 3.2.8.3,
   requires the length of the plaintext to be a multiple of 16 bytes.
   The sender MAY need to include the AT_PADDING attribute as the last
|  attribute within the plaintext of the value field of the AT_ENCR_DATA
   attribute.  The length of the padding is chosen so that the length of
   the value field of the AT_ENCR_DATA attribute becomes a multiple of
   16 bytes.  The AT_PADDING attribute SHOULD NOT be included if the
   total length of other attributes present within the AT_ENCR_DATA
   attribute is a multiple of 16 bytes.  The length of the AT_PADDING
   attribute includes the Attribute Type and Attribute Length fields.
   The actual pad bytes in the value field are set to zero (0x00) on
   sending.  The recipient of the message MUST verify that the pad bytes
   are zero after decryption and MUST silently discard the message
   otherwise.

Note:
The proper distinction between the plaintext and the ciphertext
version of fields that are encrypted in its on-the-wire form should be
heavily emphasized; neglecting this distinction can lead to significant
interoperability problems and catastrophic cryptographic failures!

(7)  Section 3.3.5 -- lack of specification, and artwork improvement

As above ...

The figure in Section 3.3.5, on page 28, contains the initial part:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=1   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_RAND_P    | Length = 18  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |  ...

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Code=2     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type=EAP-SAKE |   Version=2   |  Session ID   |   Subtype=1   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_RAND_P   |   Length=18   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |  ...

On page 29, the explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE=48

And the subsequent explanation headlines:

|  AT_RAND_P

|  AT_PEERID

|  AT_SPI_P

|  AT_MIC_P

should be amended to say, respectively:

|  AT_RAND_P (=2)

|  AT_PEERID (=6)

|  AT_SPI_P (=8)

|  AT_MIC_P (=4)


(13)  Section 4 -- lack of specification

The first paragraph of Section 4 (on page 37) says:

|  IANA allocated a new EAP Type for EAP-SAKE.
                                ^
It should say:

|  IANA allocated a new EAP Type, 48, for EAP-SAKE.
                                ^^^^^^

(14)  Section 5.5 -- spelling and terminology

'Server' and 'Peer' are distinguished roles of EAP entities.
Therefore, when talking about both participants in an EAP session,
the term 'Peer' (in headline case) should not be used to avoid
confusion.

Therefore, the last paragraph of Section 5.5, on page 40,
that says,

     [...]  Thus, the recipient of an EAP message can be assured that
|  the message it just received is the one just sent by the other Peer
   and not a replay, since it contains a valid MIC of the recipient's
|  nonce and the other Peer nonce.  As before, the extent of replay
   protection is commensurate with the security of the KDF used to
   derive the MIC, the length and entropy of the shared secret used by
   the KDF, and the length of the MIC.

should better say:

     [...]  Thus, the recipient of an EAP message can be assured that
|  the message it just received is the one just sent by the other party
   and not a replay, since it contains a valid MIC of the recipient's
|  nonce and the other party's nonce.  As before, the extent of replay
   protection is commensurate with the security of the KDF used to
   derive the MIC, the length and entropy of the shared secret used by
   the KDF, and the length of the MIC.


(15)  Section 8.1 -- outdated Normative Reference

On page 45, the ref. [SHA1] should better point to the current
version, "FIPS 180-2 (with Change Notice)", February 2004.

It should say:

[not submitted]

Notes:

from pending
--VERIFIER NOTES--
Repeticious and unnecessary reports.

Report New Errata