On Fri, Mar 09, 2007 at 11:56:07AM -0800, Lakshminath Dondeti wrote: > I have a question. I have some experience with code reuse, but I was > hacking, err... prototyping. What is the general sense on using a piece > of TLS code to do things like EAP-TLS or EAP-TLS and EAP-TLS-PSK? I ask > because elsewhere people make the argument that TLS is already there on > a certain device and so DTLS is an incremental implementation etc.
I think the answer is "it depends".. In many (most?) embedded client designs I've been involved with in one way or another, TLS library has been one of the key issues due to the possible overhead (e.g., OpenSSL can add almost 1 MB to the binary). It would be ideal, to be able to share the same TLS implementation for all uses on the device to save in size (both flash and RAM). In addition to size concerns, it would also be quite helpful if the native TLS implementation with the target platform could be used (if one is available) to benefit from existing integration with certificate store and private key access, including UI components. Providing a nice user experience with another TLS library can get difficult, if not impossible, in many cases. That said, it is not always possible to use the native TLS implementation. For example, one of the most difficult aspects of EAP-FAST from implementation view point is its requirement for TLS extensions (ClientHello extension and session ticket). Most existing TLS libraries do not support this, so whoever is implementing EAP-FAST may need to modify TLS implementation and this is something, that is often not feasible for OS/SDK provided implementation. Consequently, EAP-FAST (or EAP-TLS-PSK for that matter) may end up requiring the EAP server/peer implementation to include another TLS library. If whoever is working with EAP method implementation is also in control of the system TLS library, adding support for TLS extensions is less likely to be an issue (though, often the person working on EAP method is not the same as the one working on TLS library, so this adds some extra overhead, but anyway, still manageable). If EAP method is being implemented by someone who does not have any control on the system TLS library, things can get quite difficult. Convinsing TLS vendors to add some extensions may take time and effort; especially so, when they may not see much need for the requested extension as far as the "main uses" of the TLS from their and most of their customers view points are concerned (HTTPS? IMAPS?, etc.). I would say that reusing TLS implementations with functionality specified in TLSv1 (i.e., without any extensions) is fine in many cases since most TLS libraries include all the needed functionality. However, anything new (as in anything brought in during last few years) is going to make such reuse difficult at this point. Sure, in the future this can get easier should the TLS vendors like the new extensions enough to implement them, but until that, there is a risk of causing extra issues to vendors who work with EAP implementation and just rely on external TLS libraries.. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
