RFC 5216, "The EAP-TLS Authentication Protocol", March 2008

Note: This RFC has been updated by RFC 8996, RFC 9190

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.

Report New Errata