Re: [Emu] EAP and Fragmentation

[Mohit Sethi M <[e-mail]>]

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.  Flags include the Length included
   (L) and More fragments (M) bits.  The L flag is set to indicate the
   presence of the two-octet Total-Length field, and MUST be set for the
   first fragment of a fragmented EAP-pwd message or set of messages.
   The M flag is set on all but the last fragment.  The Total-Length
   field is two octets, and provides the total length of the EAP-pwd
   message or set of messages that is being fragmented; this simplifies
   buffer allocation.

As I said, having a method independent mechanism that could be re-used safely would make sense.

And thanks for pointing out L bit ambiguity in EAP-TLS. We should indeed fix this.

--Mohit

On 2/14/19 3:27 PM, slon v sobstvennom palto wrote:
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 <[e-mail]<mailto:[e-mail]>> 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
[OpenCA Logo]



_______________________________________________
Emu mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/emu


_______________________________________________
Emu mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/emu