Subject: [Emu] [Editorial Errata Reported] RFC5216 (2510)

From: RFC Errata System <[email-masked]>
Date: Fri, 3 Sep 2010 13:51:55 -0700 (PDT)

The following errata report has been submitted for RFC5216,
"The EAP-TLS Authentication Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5216&eid=2510

--------------------------------------
Type: Editorial
Reported by: Min Pae <[email-masked]>

Section: 3.1

Original Text
-------------
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.

Corrected Text
--------------
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.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5216 (draft-simon-emu-rfc2716bis-13)
--------------------------------------
Title               : The EAP-TLS Authentication Protocol
Publication Date    : March 2008
Author(s)           : D. Simon, B. Aboba, R. Hurst
Category            : PROPOSED STANDARD
Source              : EAP Method Update
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Jouni Malinen <[email-masked]>
Date: Tue, 7 Sep 2010 10:05:07 +0300

> Section: 3.1

Please note that similar language exists in other places of the
document, too (2.1.5 and 3.2) and the same comments should apply to
them.

> Original Text

This would still leave some potential uses of the L bit undefined.
These two sentences cover only fragmented TLS messages. What about TLS
messages that are not fragmented?

It should also be noted that the proposed text would make RFC 5216
(EAP-TLS) inconsistent with RFC 5281 (EAP-TTLS) as far as
fragmentation is concerned. I do not think that that would be a good
idea since it is possible to share same implementation for handling
fragmentation/reassembly of various TLS-based EAP methods (EAP-TLS,
EAP-TTLS, EAP-PEAP, EAP-FAST).

RFC 5281 disallows use of the L bit in the fragments other than the
first one. In addition, it does actually cover the not fragmented
message case, too:

   If there are multiple fragments, the first fragment MUST have the L
   bit set and include the length of the entire raw message prior to
   fragmentation.  Fragments other than the first MUST NOT have the L
   bit set.  Unfragmented messages MAY have the L bit set and include
   the length of the message (though this information is redundant).

My preference would be for RFC 5216 to follow this design, but I don't
think I would be willing to call this change "editorial".. Are there
any known EAP-TLS implementations that actually use the L bit in
fragments other than the first one? Would that interoperate with other
EAP-TLS implementations?

- Jouni

---

From: "Pae, Min" <[email-masked]>
Date: Tue, 7 Sep 2010 14:45:16 -0700

I agree that the text I proposed does not take other TLS based methods into account. The AAA vendor that we are working with does include the length in fragments other than the first, but we are working with them to get this addressed.

I classified the errata as editorial because I didn't think the proposed text redefines anything about the protocol. If your comment about restricting the inclusion of the length field in fragments other than the first is included, you are probably correct that this shouldn't be classified as editorial.