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
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
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
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
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
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
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
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.
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
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,
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
11 matches
Mail list logo
