With implementations shipping on virtually every major platform (e.g. Android, iOS, Mac OS X, Windows, Linux ,etc.) EAP-TLS (RFC 5216) is now supported on 2+ billion devices worldwide. This includes numerous open source implementations for both the EAP client and server.
In particular, EAP-TLS, due to its focus on certificate-authentication, has been deployed widely in environments requiring the highest levels of security, such as critical infrastructure, and military/national security installations. In these environments, EAP-TLS's provable security properties are considered critical, as is backward compatibility with the hardware ecosystem that has grown up around EAP-TLS, providing addons such as employee smartcard badges, or hardware-based certificate storage. Given the enormous number of deployed devices, the widespread implementation in open source, and the potential impact on national security and critical infrastructure, it is very important that updates to EAP-TLS consider backwards compatibility, retain the provable security, and avoid introduction of royalty-bearing IPR and the introduction of security vulnerabilities. To provide backwards as well as forwards compatibility, EAP-TLS was designed to to support new versions of TLS, including versions introducing new ciphersuites. So while RFC 5216 mandates support for TLS 1.0 to preserve backwards compatibility, it does not mandate the use of TLS 1.0 or any other version in a given installation. This allows organizations to manage their deployments (and required ciphersuites) as they see fit. For example, an organization wiling to take on the costs of migrating all of their devices and servers to TLS 1.3 and requiring the use of TLS 1.3 mandated ciphersuites is fully able to do so within the framework laid out by RFC 5216. However, what RFC 5216 does NOT attempt to do is to mandate a world-wide non-backward compatible "forklift" upgrade for TLS versions of ciphersuites. Such a non-backward compatible "forklift" update would be extra-ordinarily costly, requiring the upgrading of every device implementing EAP-TLS, including devices that do not use the protocol regularly, if ever. Despite this lack of "central management" imposed by the IETF, the record of EAP-TLS forward compatibility appears to be pretty good. At this point support for TLS 1.1 and 1.2 in EAP-TLS has widely deployed and I am aware of several implementations of EAP-TLS now testing support for TLS 1.3, without any changes to the protocol. I was therefore surprised to come across draft-mattsson-eap-tls13 which: 1. Mandates support for TLS 1.3 in all implementations of EAP-TLS. As noted earlier, organizations requiring support for TLS 1.3 can easily impose such a requirement on their EAP-TLS devices, if the cost and security benefits justify it. However, since RFC 5216 is referenced in many RFPs, obsoleting it merely to impose a TLS 1.3 requirement without extraordinary justification (such as discovery of a critical security flaw that cannot be patched in previous versions) would impose enormous costs. 2. Invalidates the existing security proofs of EAP-TLS by introducing new authentication modes (such as EAP PSK) that were specifically rejected by the EMU WG so to ensure that high-security installations could ensure that certificate-based authentication, and only cert-based authentication was provided by their EAP-TLS implementations. This reversal of an EMU WG decision is very unwise since it has the potential to introduce new security vulnerabilities into the systems protecting some of the world's most sensitive data. 3. Removes much of the security guidance of RFC 5216 addressing known interoperability and security issues. 4. Does not discuss the potential IPR implications of introducing a TLS 1.3 requirement into a protocol that is widely implemented in open source. -------------------------------------- Although I see that the EMU WG concluded earlier this year, I’d like to ask those on this mail list to consider whether an update to RFC 5216 may be worth pursuing. Wireless LAN deployments commonly leverage the EAP-TLS standard. The IEEE took steps earlier this year to raise the bar for wireless security through publishing the new 802.11ac standard. RFC 5216 currently requires TLS 1.0, and the only mandatory cipher suite specified is TLS_RSA_WITH_3DES_EDE_CBC_SHA. I’d like to suggest updating the standard in a manner that also requires mandatory support for TLS 1.2 and ECDHE_ECDSA AEAD cipher suites. Best regards, Clint Clint McKay NSA Information Assurance
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
