On Feb 12, 2019, at 12:36 PM, Dr. Pala <direc...@openca.org> 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 designed to be a protocol to carry other protocols, and nothing more than that. Hence then 5 octet header, followed by (to be non-technical) data composed of "Uh... we're not sure... whatever..." :) > 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) ? No. > 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. I suspect that it's difficult to "modify EAP". However, adding a standard fragmentation method would be definitely useful. > 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 - The TLS-based EAP methods do pretty much the same thing: EAP header EAP type (TTLS, PEAP, TEAP, FAST) TLS The rest is largely window-dressing. Since TLS provides it's own fragmentation layer, the above methods just use that. There is very little method-specific code involved. > 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 ? EAP-PWD does multi-round authentication, and adds it's own fragmentation layer: https://tools.ietf.org/html/rfc5931#section-4 The method used is somewhat similar to TLS. > 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 > ? I think so, yes. Once you have a TLS tunnel set up, TLS largely takes care of fragmenting the application data. So from the point of view of the application, it just sends and receives blocks of data, irrespective of the outer fragment size. > Or should the method not have such assumptions and provide support for > explicit fragmentation control ? I have no idea how that would work. The inner application data has no real way of knowing about the external fragment size, or even how much data is being added by the TLS layer. > 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. If it's an EAP type that only appears inside of a TLS tunnel, then don't worry too much about fragmentation. If the data you're sending will be larger than 64K, you *will* need to provide your own fragmentation support. But that's only because the EAP header has a 16-bit "Length" field. > Looking forward to some great guidance and advice :D Also, if you would like > to collaborate/contribute, please let me know! I've been known to have opinions. :) Plus, it's useful to have credential provisioning methods. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
