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.

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.

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.

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.

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.

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.