I don't think we would go down the route of making other types of ciphersuites mandatory to implement.
> -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Monday, October 23, 2006 9:17 AM > To: [email protected] > Subject: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites > > 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 > [email protected] > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
