1 / 33

IEEE 802 Response to 6N15523

IEEE 802 Response to 6N15523. Authors:. Date: 2013-03-18. Abstract. A submission for ISO/IEC JTC1/SC6 in 802 format is presented. IEEE 802 Response to 6N15523– “A Comparative Analysis of TePA /KA4 and IEEE 802.1X Security”. ISO/IEC JTC1 SC6 Seoul, Republic of Korea June, 2013. Agenda.

gaia
Télécharger la présentation

IEEE 802 Response to 6N15523

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IEEE 802 Response to 6N15523 Authors: • Date:2013-03-18 IEEE 802 Working Group, IEEE 802

  2. Abstract • A submission for ISO/IEC JTC1/SC6 in 802 format is presented. IEEE 802 Working Group, IEEE 802

  3. IEEE 802 Liason to ISO/IEC JTC1 SC6 IEEE 802 Response to 6N15523– “A Comparative Analysis of TePA/KA4 and IEEE 802.1X Security” ISO/IEC JTC1 SC6 Seoul, Republic of Korea June, 2013

  4. Agenda • Overview of 6N15523 • Justification of TePA per 6N15523’s criteria • 6N15523’s analysis • Remote Configuration • AS in TePA versus AS in 802.1X • Significant Misunderstandings • Summary

  5. Overview of 6N15523 • Purpose is the promotion of TePA-based technologies and justification for their standardization • Attempts to demonstrate advantages and innovation when compared to existing technologies, namely 802.1X • Criteria used for comparison: • New security services • Higher security • Better performance • Significant difference of solution

  6. Overview of 6N11523 • Makes a series of false assertions and incorrect claims • Suffers from critical misunderstandings of technology • Misrepresentation of OCSP • Misstatements about peer authentication • Erroneous statements on protocol risks • Incorrectly equates the “AS” in 802.1X to the “AS” in TePA • Actually argues against standardization of TePA!

  7. Overview of 6N15523 • Incorrect “entity model” • “TLS is a two-entity security protocol, TePA a three-entity authentication protocol….The remote configuration of IEEE 802.1X and EAP-TLS extends to three entities.” • The number of entities is irrelevant, it is the functionality of entities in the deployment that matter • Misguided comparison • “In order to obtain useful results configurations with the same security claims should be compared” • To obtain useful results the security of similar configurations of the same deployment should be compared! • Analysis is from a misguided comparison using an incorrect model

  8. Overview of 6N15523 • Invalid assumptions, misguided comparison, and an incorrect model produce flawed conclusions: • “The co-located 802.1X configuration is less secure than TePA and has an important disadvantage in roaming situations due to the lack of a centralized authentication server.” • “TePAand the remote 802.1X configuration both are characterized by a centralized authentication server giving them the same trust requirements and roaming suitability.” • Summary does not evaluate the protocols according to criteria for evaluation listed in introduction.

  9. Agenda • Overview of 6N15523 • Justification of TePA per 6N15523’s criteria • 6N15523’s analysis • Remote Configuration • AS in TePA versus AS in 802.1X • Significant Misunderstandings • Summary

  10. New Security Services Beyond Existing Technology • TePA only supports certified public keys for both the client and server. • 802.1X supports numerous configurations • Client and server have certified public keys • Server has certified public key, client has password • Server has certified public key, client has biometric or smart card • Client and server use a pre-shared word, phrase, code or key • 802.1X supports optional deployments that allow all supported configurations to scale to large networks. • TePA provides a subset of services provided by existing technology, nothing new beyond what 802.1X offers

  11. Higher Security Than Existing Technology • TePA: • Performs an ISO 11770-3-like exchange using asymmetric key agreement that is authenticated with certified public keys • Uses on-line server for certificate status check • Provable security • 802.1X/EAP (in only configuration TePA supports): • Performs an ISO 11770-3-like exchange using asymmetric key agreement that is authenticated with certified public keys • Can use an on-line server for certificate status check • Provable security • TePA provides equivalent security and, given the cryptographic flexibility of 802.1X/EAP, arguably less security.

  12. Better Performance or Quality Than Existing Technology • The high pole in the tent of performance is the Diffie-Hellman and (EC)DSA calculations • In TePA, client and server perform 1 Diffie-Hellman, 1 signature, 2 verifications • In 802.1X/EAP-TLS with OCSP, client and server perform 1 Diffie-Hellman, 1 signature, 2 verifications • Quality is difficult to analyze since TePA is not fully-defined • What domain parameter sets are supported? • Can multiple security levels be supported? • TePA provides either comparable performance and quality versus existing technology, or it provides worse, depending on its complete specification.

  13. Significant Difference of Solution Than Existing Technology • TePA is significantly different in its rigidity– credentials must be certificates • The manner in which TePA performs an authenticated Diffie-Hellman, with on-line certificate status check is quite different • This difference has no practical effect on the protocol and how it addresses the problem • This is a highly subjective criterion of dubious benefit to protocol analysis.

  14. TePA Fails Justification • TePA fails to be justified by any of the four differentiators • TePA provides a subset of functionality provided by 802.1X • TePA provides similar security when deployed similarly, and arguably less since it cannot be deployed differently • Performance of TePA is comparable to 802.1X/EAP, quality is probably less due to TePA’s rigidity. • Differences between TePA and 802.1X, when similar deployments are compared similarly, are without distinction

  15. TePA Fails Justification • The flexibility in deployment of 802.1X/EAP is a significant advantage for 802.1X to the detriment of TePA • The experience in deployment of 802.1X over the past decade+ has not shown any problem solved by TePA • There is no reason to to consider unjustifiable alternatives to existing technology which works fine in practice

  16. Agenda • Overview of 6N15523 • Justification of TePA per 6N15523’s criteria • 6N15523’s analysis • Remote Configuration • AS in TePA versus AS in 802.1X • Significant Misunderstandings • Summary

  17. Analysis in 6N15523 • Comparative analysis is quite detailed • Pointless analysis of “remote configuration” in 802.1X • This sort of deployment is not possible with TePA • If “remote configuration” is required then TePA is inadequate, therefore end of analysis: TePA is not justified • If “remote configuration” is not required then why waste time on something that cannot be compared when the whole point is to compare the two technologies? • Some misunderstandings produce erroneous results • “AS” in TePA is not analogous to the “AS” in 802.1X • A certificate verified by an on-line notary does not provide authentication • Authentication in both TePA and EAP-TLS is through digital signatures by entities A and B • OCSP provides an on-line certificate status check

  18. Agenda • Overview of 6N15523 • Justification of TePA per 6N15523’s criteria • 6N15523’s analysis • Remote Configuration • AS in TePA versus AS in 802.1X • Significant Misunderstandings • Summary

  19. Remote Configuration • 6N15523 states, “the remote configuration [supported by 802.1X/EAP] has significant functional and management advantages in networks with multiple authenticators.” • Given: • Support for large networks is crucial • Large networks have multiple authenticators • TePA does not support “remote configuration” • Conclusion: • 802.1X/EAP has significant functional and management advantages over TePA • TePA is unable to support a crucial deployment model

  20. Agenda • Overview of 6N15523 • Justification of TePA per 6N15523’s criteria • 6N15523’s analysis • Remote Configuration • AS in TePA versus AS in 802.1X • Significant Misunderstandings • Summary

  21. Authentication Server in TePA • The TePA “Authentication Server” (AS) is not used for authentication of entities R (requestor) and C (controller) • Certificates are public data and are not secret • Anyone can present to the AS a valid certificate for which it does not possess the private key analog • The AS merely asserts the current status of the certificate • Authentication of R to C (C to R) is by way of a digital signature of R (C), verified using the public key from a trusted certificate

  22. AS in TePA does not perform Authentication Requester Controller AS Controller sends another entity’s certificate Message1, Cert-C Message 2, Cert-R, Sig-R Message 3, Cert-R, Cert-C Message 4, Cert-R, Cert-C, Res-R, Res-C, Sig-AS Message 5, Acc-R, RES, Sig-C Controller does not have the private analog to Cert-C, so signature verification fails! It’s a valid certificate so Res-C has status True

  23. Authentication Server in TePA • The AS does not, and cannot, discover the attack • The AS correctly noted that the certificate is valid • Authentication of C by R fails and the attack fails, no thanks the AS • The “AS” in 802.1X is analogous to the Controller in TePA • In TePA, Controller does DH, and generates and verifies a digital signature to authenticate the exchange • When used with 802.1X/EAP, the AS does DH, and generates and verifies digital signatures that authenticate the exchange • The “AS” in 802.1X, when used, terminates EAP • The “AS” in TePA is not functionally equivalent to the “AS” in 802.1x! • The AS in TePAdoes not provide the service of authentication • Any analysis that is based on an assertion to the contrary is therefore incorrect

  24. Agenda • Overview of 6N15523 • Justification of TePA per 6N15523’s criteria • 6N15523’s analysis • Remote Configuration • AS in TePA versus AS in 802.1X • Significant Misunderstandings • Summary

  25. Erroneous Claims • When using EAP-TLS “entity A [client] will not detect if entity B’s [server] certificate is invalid.” (section 4.5.1) • RFC 3546 states, “Constrained clients may wish to use a certificate-status protocol such as OCSP to check the validity of server certificates….” • Using the OCSP extension to TLS allows the client (“entity A”) to detect whether the server’s (“entity B’s”) certificate is valid or invalid; that is the whole point!

  26. Erroneous Claims (continued) • “The 802.1X configurations fail to prevent the use of invalid (expired or withdrawn) certificates by rogue entities.” (section6.1.2) • Expired certificates will fail normal certificate verification • The whole point of OCSP, and the OCSP extension to EAP-TLS, is to determine whether a certificate is withdrawn, i.e. revoked.

  27. Erroneous Claims (continued) • “In TePA entities A and B need only capability to verify C’s certificates and role, while in the 802.1X-based configurations entity A and B must be capable to verify each other’s certificates and role.” (section 6.1.2) • In both TePA and EAP-TLS the parties to the exchange must produce a digital signature and verify the other party’s digital signature– more than just trusting C. • In EAP-TLS the trust placed in a 3rd party (the CA) can be used to gain trust in the other entity’s certificate • A’s and B’s certificates must be verified otherwise the protocol is insecure, this is true for EAP-TLS and TePA

  28. Erroneous Claims (continued) • “A MITM can be mounted between entities A (client) and B (server) by an attacker holding verifying PKI certificates.” (section 4.5.2) • This is only possible if the certificate is not verified • This is possible when using TEPA-AC/KA4 too • This is not an attack against EAP-TLS, TEPA-AC/KA4, or any other authenticated key exchange, it’s sign of a poor implementation • EAP-TLS “cannot prevent this attack unless entity A (client) and B (server) know their identities in advance.” • The entities learn the identities to authenticate in-line. • The client knows to whom it is trying to connect, analogous to a browser issuing a warning on different server • Proper certificate verification prevents this • If A and B do not verify certificates in TePA (as is claimed) then it is susceptible to this attack, EAP-TLS is not.

  29. Erroneous Claims (continued) • “A rogue entity A (client) may gain unauthorized access to entity B (server) if…entity B does not request validation of entity A’s (client) certificate….” • If the server does not do a certificate status check then a revoked certificate can be used • The client’s certificate is still verified though, no rogue entity access is possible • The client still produces a CertificateVerify message which proves possession of the private analog to the public key in the (possibly revoked) certificate • Entity B may possess a current CRL: no validation request is necessary but rogue entity still does not gain access

  30. Erroneous Risks • It’s not a protocol risk if you must violate the protocol to be at risk! • “If B1 and B2 do not authenticate each other…” • “If entity A does not verify entity B’s certificate…” • “If validation requests are not authenticated…”

  31. Agenda • Overview of 6N15523 • Justification of TePA per 6N15523’s criteria • 6N15523’s analysis • Remote Configuration • AS in TePA versus AS in 802.1X • Significant Misunderstandings • Summary

  32. Summary • TePA fails to be justified by the criteria listed in 6N15523 • Security analysis in 6N15523, while quite good and very detailed, produces erroneous results based on misunderstandings of technology • 802.1X/EAP has world-wide deployment from small office to enterprise to multi-campus corporate environments to cross-continental, multi-service provider situations • There are no problems with 802.1X/EAP that are solved by switching to TePA • TePA severely constrains deployment options to the detriment of industry

  33. IEEE 802 Liason to ISO/IEC JTC1 SC6 Thanks!

More Related