Re: [Emu] EAP and Fragmentation

slon v sobstvennom palto <slonvpalto@gmail.com> Thu, 14 March 2019 15:12 UTC

MIME-Version: 1.0
References: <E842F2F1-CA25-4F07-B00B-FDB1D4B1B313@ericsson.com>
In-Reply-To: <E842F2F1-CA25-4F07-B00B-FDB1D4B1B313@ericsson.com>
From: slon v sobstvennom palto <slonvpalto@gmail.com>
Date: Thu, 14 Mar 2019 17:11:54 +0200
Message-ID: <CABe6AHhJgDe6q=PP_rP0NN1grnH6SqaLwibTayZNqgC8p9x0vA@mail.gmail.com>
To: John Mattsson <john.mattsson@ericsson.com>
Cc: Mohit Sethi M <mohit.m.sethi@ericsson.com>, "Dr. Pala" <director@openca.org>, Alan DeKok <aland@deployingradius.com>, "emu@ietf.org" <emu@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005c4ded05840f589e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/ZexFr7GROnvNOjN6gGESoO9H0dk>
Subject: Re: [Emu] EAP and Fragmentation
Precedence: list

Hi John,

>Should draft-ietf-emu-eap-tls13-04 just copy the sentence from RFC 5281 or
do the group want something different?

I remember that some EAP-TLS/PEAP clients rejected not fragmented messages
without L bit set, probably due to their wrong interpretation of EAP-TLS
RFC. Would it worth to say something like "Implementation SHOULD accept
unfragmented messages with and without L bit set" in addition to copying
the sentence above from RFC 5281?

Cheers,
Oleg


On Sun, Mar 10, 2019 at 2:39 PM John Mattsson <john.mattsson@ericsson.com>
wrote:

> Welcome and thanks for your comments Oleg!
>
> slon v sobstvennom palto <slonvpalto@gmail.com>; wrote:
>
> >Per my experience the existing fragmentation method described in EAP-TLS
> >RFC 5216 serves good for all fragmentation needs. The method is reused by
> >PEAP, EAP-FAST, TEAP and EAP-TTLS. There's an ambiguity in EAP-TLS RFC
> that
> >doesn't specify whether a not-fragmented message should have the L bit and
> >the 4 octets length field so different peers treat it differently.
> However,
> >for example, EAP-TTLS RFC closed it tightly saying that even a
> >single-fragment message should have it nevertheless on its redundancy.
>
> I cannot find anything in EAP-TTLS (RFC 5281) saying that the L bit should
> be set. As you have noticed, EAP-TLS (RFC 5216) does not say anything about
> the L bit in unfragmented messages and my understanding is that the
> ambiguity is if unfragmented messages can (not should) have the L bit set.
> As far as I can see, EAP-TTLS (RFC 5281) states that unfragmented messages
> MAY set the L bit.
>
> RFC 5281 Section 9.2.2:
>
>    “Unfragmented messages MAY have the L bit set and include the
>     length of the message (though this information is redundant).”
>
> I looked through the other TLS-based EAP methods (both RFCs and drafts)
> and none of them seems to say anything new about the L bit.
> draft-ietf-emu-eap-tls13 should clarify any ambiguity.
>
> Should draft-ietf-emu-eap-tls13-04 just copy the sentence from RFC 5281 or
> do the group want something different?
>
> Cheers,
> John
>
>

[Emu] EAP and Fragmentation Dr. Pala
Re: [Emu] EAP and Fragmentation Alan DeKok
Re: [Emu] EAP and Fragmentation Mohit Sethi M
Re: [Emu] EAP and Fragmentation slon v sobstvennom palto
Re: [Emu] EAP and Fragmentation Mohit Sethi M
Re: [Emu] EAP and Fragmentation Dr. Pala
Re: [Emu] EAP and Fragmentation Dr. Pala
Re: [Emu] EAP and Fragmentation John Mattsson
Re: [Emu] EAP and Fragmentation slon v sobstvennom palto
Re: [Emu] EAP and Fragmentation John Mattsson
Re: [Emu] EAP and Fragmentation Alan DeKok
Re: [Emu] EAP and Fragmentation John Mattsson
Re: [Emu] EAP and Fragmentation slon v sobstvennom palto
Re: [Emu] EAP and Fragmentation Alan DeKok