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 <mohit.m.se...@ericsson.com> 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
