On Mon, Mar 05, 2007 at 06:03:18PM -0800, Narayanan, Vidya wrote: > 1. Overall, I'm looking for a compelling reason to have another EAP > method and I found none in the document. For instance, all the design > goals listed seem to be satisfied by EAP-TLS-PSK (inclusion of protected > payloads can be done as an extension to TLS as well). And, given that > EAP-TLS-PSK is an incremental change to EAP-TLS, it would be much more > compelling to use EAP-TLS-PSK than EAP-GPSK. So, is there at least one > design goal of GPSK that cannot be met by other methods?
As far as I can tell, EAP-TLS-PSK would be yet another EAP method in the same sense as EAP-GPSK, so I don't see EAP-TLS-PSK in any way a better solution from the view point of not adding a new method. As far as comparison of EAP-GPSK vs. EAP-TLS-PSK is concerned, one major part is in EAP-GPSK being much simpler and smaller from implementation view point. In most cases, extending TLS seems to bring in a major extra cost of having to modify a TLS library which is not desirable in many cases. It may mean that the TLS implementation included in the system would not be suitable and the EAP implementation would need to bring in another TLS implementation with maintenance and memory/flash footprint concerns. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
