On Mar 15, 2019, at 12:51 PM, slon v sobstvennom palto
wrote:
>
> >That is probably the correct behavior to standardize, i.e., something like
> >"Implementations MUST NOT set the L bit in unfragmented messages, but MUST
> >accept unfragmented messages with and without the L bit set."
>
> I'm f
John wrote:
>That is probably the correct behavior to standardize, i.e., something like
>"Implementations MUST NOT set the L bit in unfragmented messages, but MUST
accept unfragmented messages with and without the L bit set."
I'm for the strict approach. Anyway some implementations don't adhere i
Alan wrote:
>I've done a quick check. On reception, FreeRADIUS accepts the L bit for any
>type of message. It doesn't care >about fragments, just that the length is
>correct.
>
>For sending packets, FreeRADIUS sets the L bit only if it is sending
>fragments.
That is probably the correct be
On Mar 15, 2019, at 6:13 AM, John Mattsson wrote:
> I think we need to choose one and ensure that implementations following
> draft-ietf-emu-eap-tls13 can talk to each other. Do anybody have any data on
> how many implementations out there set the L bit for unfragmented messages
> and how many
Hi Oleg,
>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
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 sa
Welcome and thanks for your comments Oleg!
slon v sobstvennom palto ; 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
Hi Mohit, all,
somehow I skipped this message... :( Sorry ... anyhow - I do not have a
draft on that, and I am not even sure how this could be structured -
maybe this could be a BCP ? I actually came across another building
block that might be useful: an easy way to negotiate a key and an
enc
Hi Alan,
thanks for the answers... aligned with what I thought and they do make
sense... :D Further considerations inline...
On 2/12/19 11:26 AM, Alan DeKok wrote:
On Feb 12, 2019, at 12:36 PM, Dr. Pala wrote:
[...]
This, led me to my first question: is there a de-facto "standard" way to ad
Hi Oleg,
You are warmly welcome.
Not all methods use a TLS outer tunnel. For example: EAP-pwd has the following
text:
EAP-pwd fragmentation support is provided through the addition of
flags within the EAP-Response and EAP-Request packets, as well as a
Total-Length field of two octets. Fl
Hi all,
These are my first steps in this group so please correct me if I don't
follow the rules.
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 ambiguit
Dear Dr. Pala,
On 2/12/19 7:36 PM, Dr. Pala wrote:
Hi all,
I am working on a draft for credentials management via EAP. When looking at the
different specifications, it seems a bit weird that EAP does not provide
Fragmentation control and requires each method to define their own way.
This, led
On Feb 12, 2019, at 12:36 PM, Dr. Pala wrote:
> I am working on a draft for credentials management via EAP. When looking at
> the different specifications, it seems a bit weird that EAP does not provide
> Fragmentation control and requires each method to define their own way.
IIRC, EAP was d
13 matches
Mail list logo
