errata logo graphic

Found 8 records.

Status: Verified (1)

RFC5216, "The EAP-TLS Authentication Protocol", March 2008

Source of RFC: emu (sec)

Errata ID: 1389

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Verifier Name: Pasi Eronen
Date Verified: 2009-01-05

Section 2.1.3 says:

   If the peer's authentication is unsuccessful, the EAP server SHOULD
   send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS
   record containing the appropriate TLS alert message.  The EAP server
|  SHOULD send a TLS alert message immediately terminating the
   conversation so as to allow the peer to inform the user or log the
   cause of the failure and possibly allow for a restart of the
   conversation.

It should say:

   If the peer's authentication is unsuccessful, the EAP server SHOULD
   send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS
   record containing the appropriate TLS alert message.  The EAP server
|  SHOULD send a TLS alert message rather than immediately terminating
                                   ^^^^^^^^^^^^
   the conversation so as to allow the peer to inform the user or log
   the cause of the failure and possibly allow for a restart of the
   conversation.

Notes:

The double word omission totally distorts the proper sense
of the sentence. The 4th paragraph of this section describes
the converse scenarion, and it does it properly; the wording
from there has been adopted above.

Note that RFC 2716 already had dropped the word "than" making it
difficult to understand. Additionally dropping "rather" as well in
RFC 5216 fully distorts the intended sense and leads to confusion.

[Confirmed by Bernard Aboba and Ryan Hurst]


Status: Held for Document Update (6)

RFC5216, "The EAP-TLS Authentication Protocol", March 2008

Source of RFC: emu (sec)

Errata ID: 1388

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Held for Document Update by: Pasi Eronen

Section 2.1.1,pg.5 says:

   The certificate message contains a public key certificate chain for
   either a key exchange public key (such as an RSA or Diffie-Hellman
   key exchange public key) or a signature public key (such as an RSA or
|  Digital Signature Standard (DSS) signature public key).  In the
   latter case, a TLS server_key_exchange handshake message MUST also be
   included to allow the key exchange to take place.

It should say:

   The certificate message contains a public key certificate chain for
   either a key exchange public key (such as an RSA or Diffie-Hellman
   key exchange public key) or a signature public key (such as an RSA or
|  Digital Signature Algorithm (DSA) signature public key).  In the
                     ^^^^^^^^^    ^
   latter case, a TLS server_key_exchange handshake message MUST also be
   included to allow the key exchange to take place.

Notes:

Location is the 6th paragraph of Section 2.1.1.
(Please note that the first paragraph of that section is
inadvertently split into two parts by a spurious blank line
that has been ignored for the purpose of paragraph numbering.)

Rationale:
There's no such thing like a DSS signature public key.
Keys have to match the mathematical algorithms, and only
indirectly the standrds documents.
The Digital Signature Standard (DSS) supports three different
kinds of signature algorithms: (classical) DSA, ECDSA (the DSA
variant based on Elliptic Curve Cryptography), and RSA.
All three algorithms require different keys, based on the
mathematical properties and the related presentation forms.

Other parts of the document, in particular Section 5.1 already
use the proper terminology to distinguish between algorithm and
standards document.


Errata ID: 1393

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Held for Document Update by: Pasi Eronen

Section 3.1,pg.20 says:

|  0                   1                   2                   3
|  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |   Identifier  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Type      |     Flags     |      TLS Message Length
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     TLS Message Length        |       TLS Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

|   0                   1                   2                   3
|   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |   Identifier  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |     Type      |     Flags     |      TLS Message Length       :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  :     TLS Message Length        |       TLS Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

There are two issues:
- misalignment of ruler lines above the diagram;
- misleading representation of the TLS Message Length field
that is continued from the 2nd to the 3rd data line;
the above proposal makes use of ':' to denote continuation
of a folded field -- this notational detail has been widely
adopted in many contemporary RFCs.

This very same issue recurs in Section 3.2, on page 22, and
identical changes should be applied there.


Note:
Unfortunately, the affiliation of the authors apparently
maintains packet filters (since almost 9 months) that preclude
DNS lookups for the MX records, and hence sending email to the
authors, for any site operating a DNS resolver behind a NAT/NAPT,
by blackholing DNS queries from sorce ports other than 53 --
contrary to all applicable RFCs.
This effective denial of service has prohibited me from direct
communication with the authors, to make them aware of the issues
now reported in this series of Errata Reports.


Errata ID: 1390

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Held for Document Update by: Pasi Eronen

Section 2.1.3,pg.10 says:

                           <- EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS server_hello,
                             TLS certificate,
                    [TLS server_key_exchange,]
               TLS certificate_request,
                 TLS server_hello_done)

   EAP-Response/
   EAP-Type=EAP-TLS
   (TLS certificate,
    TLS client_key_exchange,
    TLS certificate_verify,
    TLS change_cipher_spec,
    TLS finished) ->

It should say:

                           <- EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS server_hello,
|                           TLS certificate,
|                           [TLS server_key_exchange,]
|                           TLS certificate_request,
|                           TLS server_hello_done)

   EAP-Response/
   EAP-Type=EAP-TLS
   (TLS certificate,
    TLS client_key_exchange,
    TLS certificate_verify,
    TLS change_cipher_spec,
    TLS finished) ->

Notes:

Rationale:

The columnar alignment of many parts of the examples
presented in Section 2.1.3 - 2.1.5 is distorted, for
multiple messages sent by the Authenticator
(denoted A-msg below, for brevity).

The example above is the 3rd A-msg on page 10.

Additional occurrences of this issue are:

- Section 2.1.3, last part, mid-page 11, third A-msg,
- Section 2.1.4, first, second and third A-msg on page 13,
- Section 2.1.5, second and third A-msg on page 15,
and second A-msg on page 16.


Errata ID: 1391

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Held for Document Update by: Pasi Eronen

Section 2.3,pg.17 says:

   master_secret = TLS-PRF-48(pre_master_secret, "master secret",
|                   client.random || server.random) key_block     =
|  TLS-PRF-X(master_secret, "key expansion",
                    server.random || client.random)

It should say:

   master_secret = TLS-PRF-48(pre_master_secret, "master secret",
|                   client.random || server.random)
|  key_block     = TLS-PRF-X(master_secret, "key expansion",
                    server.random || client.random)

Notes:

Wrong line break makes formula presentation confusing.

(This flaw has been introduced in a last-minute change
before publication!)


Errata ID: 1394

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Held for Document Update by: Pasi Eronen
Date Held: 2008-12-04

Section 5.3,pg.26 says:

   In contrast to the EAP-TLS server, the EAP-TLS peer may not have
|  Internet connectivity.  Therefore, the EAP-TLS server SHOULD provide
   its entire certificate chain minus the root to facilitate certificate
   validation by the peer.  The EAP-TLS peer SHOULD support validating
   the server certificate using RFC 3280 [RFC3280] compliant path
   validation.

It should say:

   In contrast to the EAP-TLS server, the EAP-TLS peer may not have
|  Internet connectivity (at the time of the EAP-TLS exchange).
   Therefore, the EAP-TLS server SHOULD provide its entire certificate
   chain minus the root to facilitate certificate validation by the
   peer.  The EAP-TLS peer SHOULD support validating the server
   certificate using RFC 3280 [RFC3280] compliant path validation.

Notes:

Rationale: Clarification


Errata ID: 2510

Status: Held for Document Update
Type: Editorial

Reported By: Min Pae
Date Reported: 2010-09-03
Held for Document Update by: Sean Turner

Section 3.1 says:

The L bit (length included) is set to indicate the presence of the
four-octet TLS Message Length field, and MUST be set for the first
fragment of a fragmented TLS message or set of messages.

It should say:

The L bit (length included) is set to indicate the presence of the
four-octet TLS Message Length field, and MUST be set for the first
fragment of a fragmented TLS message.  The L bit MAY be included
in all fragments of a fragmented TLS message, but if included the
TLS Length MUST represent the entire length of the TLS message.

Notes:

The lack of definition for what to do with the L bit and the TLS length field for TLS fragments other than the first fragment is leaving the door open to divergent behavior for whether the L bit and length field are included, what the length contains if they're included, and how to interpret it.


Status: Rejected (1)

RFC5216, "The EAP-TLS Authentication Protocol", March 2008

Source of RFC: emu (sec)

Errata ID: 1392

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-03-26
Rejected by: Pasi Eronen
Date Rejected: 2008-12-04

Section 2.3,pg.19 says:

[lower part of Figure 2]

         |                       |                         |
         V                       V                         V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                         |
   |                        MSK, EMSK                        |
   |               label == "client EAP encryption"          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             |             |
     | MSK(0,31)   | MSK(32,63)  | EMSK(0,63)
     |             |             |
     |             |             |
     V             V             V

                     Figure 2 - EAP-TLS Key Hierarchy

It should say:

         |                       |                         |
         V                       V                         V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                         |
   |                        MSK, EMSK                        |
   |               label == "client EAP encryption"          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              |              |            |
|    | Enc-RECV-Key | Enc-SEND-Key | RECV-IV    | SEND-IV
|    |  =           |  =           |  =         |  =
|    | MSK(0,31)    | MSK(32,63)   | EMSK(0,31) | EMSK(32,63)
     |              |              |            |
     V              V              V            V

                     Figure 2 - EAP-TLS Key Hierarchy

Notes:

Rationale:

Figure 2 should be comparable to Figure 1, but it does not
show the final deliverables with their names as they appear
in the referenced documents.
Also, the figure is surprisingly unbalanced; it shows the split
of MSK, but it does not show the split of EMSK; I cannot detect
any reason for this difference.
The proposal above includes both these names and the technical
details of how these variables are derived from MSK and EMSK,
according to the formulae given near the bottom of page 18.

To avoid these technical details and better align the abstraction
level in the presentation with Figure 1, alternatively the second
and the third tagged line above (those with "=" and MSK/EMSK)
could be left off.
--VERIFIER NOTES--

The updated figure is wrong -- RECV-IV/SEND-IV are not derived from EMSK.


Report New Errata