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 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.
~Oleg
On Thu, Feb 14, 2019 at 1:54 PM Mohit Sethi M
wrote:
> 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 me to my first question:* is there a de-facto "standard" way
> to add Fragmentation support we can just use (without having to re-invent
> the wheel all the time) ? If we had such a mechanism, then we could just
> say "implement the mechanism as defined in ... ". This would definitely
> help developers that could safely re-use code/libraries. The other approach
> would be to modify EAP to add Fragmentation support there. The main reason
> to have a standard behavior is to have also better management for ack and
> nak packets. As far as the solution goes, the main ones I looked at are the
> ones mentioned in EAP-TTLS and EAP-TEAP. They are both practically the
> same, active ACK-based - are there other methods that have been implemented
> ? Has anybody ever looked at how fragmentation is handled in practice and
> if there are better solutions than others ?
>
> No hat: I think having a standard mechanism for supporting large messages
> and fragmentation independently of any particular EAP method would
> definitely be something useful. As you said, it would allow developers to
> safely re-use code. If you have a draft proposal, I would be happy to
> review it. Perhaps we could start by looking at existing mechanisms used by
> EAP-Pwd/EAP-TTLS.
>
> --Mohit
>
> *Further thinking let me to my second question:* the method we are going
> to propose requires some form of authentication for the server, therefore I
> can see its use mainly as a tunneled method where the communication with
> the server is assumed to be already secure. If we go down the route of
> requiring the use of an outer method that provides authenticity and,
> optionally, confidentiality we would also not need to provide support for
> Fragmentation control, since the records would be encapsulated within the
> outer-method messages that already provide fragmentation support. Would
> this be acceptable ? Or should the method not have such assumptions and
> provide support for explicit fragmentation control ? What would be the
> preferred path here ? I personally would like to have a method that could
> be used independently, but I would also like to focus on simplicity of
> implementation so that if you already have EAP-TTLS/EAP-TEAP support,
> adding support for EAP-CREDS would be very simple.
>
> Looking forward to some great guidance and advice :D Also, if you would
> like to collaborate/contribute, please let me know!
> --
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> [image: OpenCA Logo]
>
> ___
> Emu mailing listEmu@ietf.orghttps://www.ietf.org/mailman/listinfo/emu
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
