So, it sounds like defining an EAP type code for EAP-TLS with non-PKI ciphersuites sounds like the best way to go. Would it be appropriate to have IANA allocate a new EAP type code with 2716bis, or have a seperate document discussing EAP-TLS with TLS-PSK ciphersuites?
-- t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy On Mon, October 23, 2006 9:07 pm, Bernard Aboba wrote: >>Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 (PKI and PSK)? >> Or >>EAP-TLS-PKI and EAP-TLS-PSK? If we have both legacy issues AND footprint >>issues, perhaps something like ... > > So far, we've talked about handling PSK support by creating a new EAP > method > with a distinct name: "EAP-TLS-PSK". That approach enables embedded > devices to implement only PSK ciphersuites, reducing footprint. It also > avoids impacting the interoperability and security of existing EAP-TLS > implementations. > > Given that EAP-TLS already supports PKI, I'm not sure why a distinct EAP > method called "EAP-TLS-PKI" would be needed. > > Creating "versions" of EAP-TLS would potentially confuse customers and > cause > problems with existing test suites and certification programs. Witness > the > confusion that was created by PEAP versioning, where PEAPv0 and PEAPv1 did > not interoperate. So I'd stay away from versioning if at all possible. > > > > _______________________________________________ > Emu mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
