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
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

Reply via email to