So that answers the questions from my last email. It sounds like PKI vs PSK is a reasonable split, but for reasons somewhat unrelated to EAP vs TLS credential negotiation, which I don't see as a big problem, personally.
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 ... EAP-TLS-v1 EAP-TLS-v2-PSK EAP-TLS-v2-PKI ... might be appropriate. -- t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy On Mon, October 23, 2006 12:17 pm, Bernard Aboba wrote: > During the EMU BOF we talked about the high cost that would be imposed on > customers by introducing new non-certificate ciphersuites during EAP-TLS. > > EAP-TLS is now ten years old, and has a very large installed base. > Virtually all of these installations only support certificate-based > authentication, since that is a requirement of RFC 2716, which states: > > If the EAP server is not resuming a previously established > session, then it MUST include a TLS server_certificate handshake > message, and a server_hello_done handshake message MUST be the last > handshake message encapsulated in this EAP-Request packet.... > > If the EAP server sent a certificate_request message in the preceding > EAP-Request packet, then > the peer MUST send, in addition, certificate and certificate_verify > handshake messages. > > As a result of these and other specification requirements, an > implementation > that does not support certificate authentication is non-compliant with RFC > 2716. > > During the BOF we also talked about the drawbacks of attempting to support > both certificate and non-certificate modes in a single EAP method. Such > an > approach would require embedded systems to take on the footprint of > certificate handling even when all they really needed to do was to support > pre-shared keys. It would also add new potential security vulnerabilities > to one of the few EAP methods that has provable security properties. > > In addition adding new non-certificate modes would impose large costs on > customers. Today there are interoperability and conformance test suites > for > EAP-TLS that assume that only certificate-based authentication is > supported. > In addition, EAP-TLS has been approved for use within FIPS 140-2 > installations, based on support for certificate-base ciphersuites. > Introducing new non-certificate modes would introduce confusion, and would > force existing test suites to be re-written. > > For customers, deployment of EAP is difficult enough without introducing > confusion, interoperability problems and new security vulnerabilities into > the one EAP method that today is synonmous with high security. > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
