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
