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

From: Sean Turner <[email-masked]>
Date: Tue, 16 Nov 2010 09:24:05 -0500

Did this ever get resolved?

spt

On 9/7/10 5:45 PM, Pae, Min wrote:
> 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.
>
> On Sep 7, 2010, at 12:05 AM, Jouni Malinen<[email-masked]>  wrote:
>
>> On Fri, Sep 3, 2010 at 11:51 PM, RFC Errata System
>> <[email-masked]>  wrote:
>>> http://www.rfc-editor.org/errata_search.php?rfc=5216&eid=2510
>>
>>> 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
>>> -------------
>>> 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.
>>
>> 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: Bernard Aboba <[email-masked]>
Date: Fri, 19 Nov 2010 03:36:02 +0000

I agree with Jouni that this is not an editorial change. 

In practice, TLS-based EAP methods are often built on the same code base.  That means that an EAP-TTLS implementation that also supports EAP-TLS will typically behave as specified in RFC 5281, disallowing use of the 'L' flag in fragments other than the first one. 

As a result, setting the 'L' flag in fragments other than the first one is probably not something that should be encouraged. 
 
-----Original Message-----
From: Sean Turner [mailto:[email-masked]] 
Sent: Tuesday, November 16, 2010 9:24 AM
To: Pae, Min
Cc: Jouni Malinen; Dan Simon; Bernard Aboba; Ryan Hurst; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Emu] [Editorial Errata Reported] RFC5216 (2510)

spt