Subject: RFC 4763 ERRATA

From: Alfred Hönes <[email-masked]>
Date: Mon, 12 Feb 2007 23:55:48 +0100 (MEZ)

Hello,
after studying the recently published RFC 4763 (EAP-SAKE)
authored by you, I would like to submit a few comments, pointing
out the issues I found with the RFC text, and supplying material
for an appropriate RFC Errata Note.

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(1)  Section 3.1 -- word omission

The first bullet in Section 3.1, on mid-page 4, says:
                   v
|  o It is based on well-established Bellare-Rogaway mutual
     authentication protocol.

It should say:
                   vvvvv
|  o It is based on the well-established Bellare-Rogaway mutual
     authentication protocol.

BTW: Wouldn't that have deserved a proper reference ???

(2)  Section 3.2.6.1 -- URGENT algorithmic correction

Unfortunately, Section 3.2.6.1 contains a bad legacy mistake.
Like a couple of related documents, it does not properly set
the repetition count needed for the partitioning of a message
into fixed-size blocks, by substituting the 'FLOOR' function
where the 'CEILING' or 'CEIL' function would be needed.

To most easily see what's wrong, try substituting  Length := 16
(hence, a single 20-octet HMAC-SHA1 result is needed to cover
the requested size), and observe the controlling loop:

           for i := 0 to FLOOR(Length/20)-1 do
becomes:
           for i := 0 to FLOOR(16/20)-1 do
which is:
           for i := 0 to 0-1 do
or:
           for i := 0 to -1 do

and hence no H-SHA1 calls are ever performed.

The simple rule-of-thumb is:
  - you need FLOOR if you want to fit fixed-size pieces into a bag;
  - you need CEIL[ING] if you want to cover a bag with fixed-size pieces.

These are the changes to make the algorithm in Section 3.2.6.1 work
as intended:

In the first paragraph on page 16, where the RFC says:

   The KDF is a keyed hash function with key "Key" and operating on
   input "Label | Msg".  The convention followed herein is that
|  concatenation is denoted by |, FLOOR denotes the floor function, and
   [x...y] denotes bytes x through y.

it should say:

   The KDF is a keyed hash function with key "Key" and operating on
   input "Label | Msg".  The convention followed herein is that
|  concatenation is denoted by |, CEIL denotes the ceiling function,
   and [x...y] denotes bytes x through y.

The code block at the end of Section 3.2.6.1 :

   KDF(Key, Label, Msg, Length)
   R := []  ;; null string
|  for i := 0 to FLOOR(Length/20)-1 do
|  R := R | H-SHA1(Key, Label, Msg, i)
   return R[0...(Length-1)]

should properly state:

   KDF(Key, Label, Msg, Length)
   R := []  ;; null string
|  for i := 0 to CEIL(Length/20)-1 do
|    R := R | H-SHA1(Key, Label, Msg, i)
   return R[0...(Length-1)]

[ Note: I also have indented the statement making up the body
        of the loop to cleraly identify this property. ]

(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!

(4)  Section 3.3.1 -- lack of specification, and a word omission

Unfortunately, the RFC has not been cleaned up after IANA allocation
and remains unspecific und indeterminate on the protocol constant
(EAP method type)  EAP-SAKE (=48).

In Section 3.3.1, the explanation:

   Type

      To be assigned.

should say:

   Type

|     EAP-SAKE (=48)

At the end of Section 3.3.1, the explanation:

   Subtype

      EAP-SAKE subtype: SAKE/Challenge, SAKE/Confirm, SAKE/Auth-Reject,
      and SAKE/Identity.  All messages of type "EAP-SAKE" that are not
|     of these subtypes MUST silently discarded.
      [...]                          ^

should say:

   Subtype

      EAP-SAKE subtype: SAKE/Challenge, SAKE/Confirm, SAKE/Auth-Reject,
      and SAKE/Identity.  All messages of type "EAP-SAKE" that are not
|     of these subtypes MUST silently be discarded.
      [...]                          ^^^^

(5)  Section 3.3.2 -- format, and incomplete specification

The inadvertent blank line near the end of the table on page 24
has no functional meaning and hence should be deleted.

At the end of the section, below the table, add the sentence:

   The attribute type values assigned by this specification (and
   registered by the IANA) are listed in section 4.

Note:
  Below, I have chosen to supply the missing values explicitely,
  rather than proposinf to repeatedly add similar pointers to Sct. 4.
  This seems to better serve the needs of the reader and hopefully
  will aid the implementer as well.

(6)  Section 3.3.3 -- lack of specification, and artwork improvement

For uniformity, *all* constant values should be made visible in
the message format diagrams.
The rationale of item (4) above applies as well.

The figure in Section 3.3.4, on page 26, contains the initial part:

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

It should say:

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

The explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE (=48)

At the end of the section, on page 27, the explanations:

|  AT_RAND_S

      The value field of this attribute contains the Server nonce RAND_S
      parameter.  The RAND_S attribute MUST be present in
      EAP.Request/SAKE/Challenge.

|  AT_SERVERID

      The value field of this attribute contains the Server identifier
      (e.g., a non-null terminated string).  The AT_SERVERID attribute
      SHOULD be present in EAP.Request/SAKE Challenge.

should say:

|  AT_RAND_S (=1)

      The value field of this attribute contains the Server nonce RAND_S
      parameter.  The RAND_S attribute MUST be present in
      EAP.Request/SAKE/Challenge.

|  AT_SERVERID (=5)

      The value field of this attribute contains the Server identifier
      (e.g., a non-null terminated string).  The AT_SERVERID attribute
      SHOULD be present in EAP.Request/SAKE Challenge.

(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)

(8)  Section 3.3.6 -- lack of specification, and artwork improvement

As above ...
Also, a spurious separator line in the diagram should be deleted.

The figure in Section 3.3.6, on page 30, contains the initial part:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=2   |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_SPI_S    | Length        |        SPI_S                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_IV       | Length        |   Initialization Vector ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               :
   |   ...

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |    Code=1     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  | Type=EAP-SAKE |   Version=2   |  Session ID   |   Subtype=2   |
|  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_SPI_S    | Length        |        SPI_S                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT_IV       | Length        |   Initialization Vector ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               :
   |   ...

On page 31, the explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE=48

The subsequent explanation headlines:

|  AT_SPI_S

|  AT_IV

|  AT_MSK_LIFE

|  AT_MIC_S

should be amended to say, respectively:

|  AT_SPI_S (=7)

|  AT_IV (=129)

|  AT_MSK_LIFE (=132)

|  AT_MIC_S (=3)

Finally, the explanation,

   AT_ENCR_DATA

      This attribute is optional to use in this message.  The encrypted
      data, if present, may contain an attribute AT_NEXT_TMPID,
      containing the NAI the Peer should use in the next EAP
      authentication.

should say:

|  AT_ENCR_DATA (=128)

|     This attribute is optional to use in this message.  The cleartext
|     form of the encrypted data, if present, may contain an attribute
      AT_NEXT_TMPID, containing the NAI the Peer should use in the next
      EAP authentication.

(9)  Section 3.3.7 -- lack of specification, and artwork improvement

As above ...

The figure in Section 3.3.7, on page 32, contains the initial part:

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

It should say:

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

The explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE (=48)

And on page 33, the explanation headlines:

|  AT_MIC_P

|  AT_PADDING

should be amended to say, respectively:

|  AT_MIC_P (=4)

|  AT_PADDING (=130)

(10)  Section 3.3.8 -- lack of specification, and artwork improvement

As above ...

The figure in Section 3.3.8, on page 33, says:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=3   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |    Code=2     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  | Type=EAP-SAKE |   Version=2   |  Session ID   |   Subtype=3   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE (=48)

(11)  Section 3.3.9 -- lack of specification, and artwork improvement

As above ...

The figure in Section 3.3.9, on page 34, contains the initial part:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=4   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

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

On page 35, the explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE=48

The subsequent explanation headlines:

|  AT_PERM_ID_REQ

|  AT_ANY_ID_REQ

|  AT_SERVERID

should be amended to say, respectively:

|  AT_PERM_ID_REQ (=10)

|  AT_ANY_ID_REQ (=9)

|  AT_SERVERID (=5)

(12)  Section 3.3.10 -- lack of specification, and artwork improvement

As above ...

The figure in Section 3.3.10, on page 36, contains the initial part:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |Type=EAP-SAKE  |    Version=2  | Session ID    |   Subtype=4   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |    Code=2     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  | Type=EAP-SAKE |   Version=2   |  Session ID   |   Subtype=4   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The explanation:

   Type

|     EAP-SAKE

should say:

   Type

|     EAP-SAKE (=48)

And on page 37, the explanation headline:

   AT_PEERID

should be amended to say:

   AT_PEERID (=6)

(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.

Please comment.

All items above seem to be appropriate for an Errata Note.

Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above, or even just direct the RFC Editor
to make use of this message.  But if you like, I can formally
submit an Errata Note on my own, with your consent.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+