RFC Errata
Found 9 records.
Status: Verified (2)
RFC 5216, "The EAP-TLS Authentication Protocol", March 2008
Note: This RFC has been updated by RFC 8996, RFC 9190
Source of RFC: emu (sec)
Errata ID: 1389
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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]
Errata ID: 6357
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Benjamin Kaduk
Date Reported: 2020-12-16
Verifier Name: Roman Danyliw
Date Verified: 2022-01-19
Section 5.1 says:
[3] Section 5 of BCP 86 [RFC3766] offers advice on the required RSA or Diffie-Hellman (DH) module and Digital Signature Algorithm (DSA) subgroup size in bits, for a given level of attack resistance in bits. For example, a 2048-bit RSA key is recommended to provide 128-bit equivalent key strength. The National Institute of Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
It should say:
[3] Section 5 of BCP 86 [RFC3766] offers advice on the required RSA or Diffie-Hellman (DH) modulus and Digital Signature Algorithm (DSA) subgroup size in bits, for a given level of attack resistance in bits. For example, a 2048-bit RSA key is recommended to provide 128-bit equivalent key strength. The National Institute of Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
Notes:
RSA and DH computations are parameterized by their moduli, with singular "modulus" (not "module").
Status: Held for Document Update (6)
RFC 5216, "The EAP-TLS Authentication Protocol", March 2008
Note: This RFC has been updated by RFC 8996, RFC 9190
Source of RFC: emu (sec)
Errata ID: 1388
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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)
RFC 5216, "The EAP-TLS Authentication Protocol", March 2008
Note: This RFC has been updated by RFC 8996, RFC 9190
Source of RFC: emu (sec)
Errata ID: 1392
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
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.