1. Submission doc.: IEEE 11-13/0338r0 March 2013 IEEE 802 Working Group, IEEE 802Slide 1 IEEE 802 Response to 6N15523 Date: 2013-03-18 Authors:

2. Submission doc.: IEEE 11-13/0338r0 March 2013 IEEE 802 Working Group, IEEE 802Slide 2 Abstract A submission for ISO/IEC JTC1/SC6 in 802 format is presented.

3. Submission doc.: IEEE 11-13/0338r0 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 12/2/13 IEEE 802 Liason to ISO/IEC JTC1 SC63

4. Submission doc.: IEEE 11-13/0338r0 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 4

5. Submission doc.: IEEE 11-13/0338r0 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 5

6. Submission doc.: IEEE 11-13/0338r0 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! 6

7. Submission doc.: IEEE 11-13/0338r0 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 7

8. Submission doc.: IEEE 11-13/0338r0 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.” “TePA and 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. 8

9. Submission doc.: IEEE 11-13/0338r0 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 9

10. Submission doc.: IEEE 11-13/0338r0 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 10

11. Submission doc.: IEEE 11-13/0338r0 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. 11

12. Submission doc.: IEEE 11-13/0338r0 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. 12

13. Submission doc.: IEEE 11-13/0338r0 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. 13

14. Submission doc.: IEEE 11-13/0338r0 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 14

15. Submission doc.: IEEE 11-13/0338r0 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 15

16. Submission doc.: IEEE 11-13/0338r0 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 16

17. Submission doc.: IEEE 11-13/0338r0 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 17

18. Submission doc.: IEEE 11-13/0338r0 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 18

19. Submission doc.: IEEE 11-13/0338r0 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 19

20. Submission doc.: IEEE 11-13/0338r0 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 20

21. Submission doc.: IEEE 11-13/0338r0 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 21

22. Submission doc.: IEEE 11-13/0338r0 AS in TePA does not perform Authentication 22 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 RequesterControllerAS Controller sends another entity’s certificate It’s a valid certificate so Res-C has status True Controller does not have the private analog to Cert-C, so signature verification fails!

23. Submission doc.: IEEE 11-13/0338r0 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 TePA does not provide the service of authentication Any analysis that is based on an assertion to the contrary is therefore incorrect 23

24. Submission doc.: IEEE 11-13/0338r0 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 24

25. Submission doc.: IEEE 11-13/0338r0 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! 25

26. Submission doc.: IEEE 11-13/0338r0 Erroneous Claims (continued) “The 802.1X configurations fail to prevent the use of invalid (expired or withdrawn) certificates by rogue entities.” (section 6.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. 26

27. Submission doc.: IEEE 11-13/0338r0 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 3 rd 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 27

28. Submission doc.: IEEE 11-13/0338r0 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. 28

29. Submission doc.: IEEE 11-13/0338r0 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 29

30. Submission doc.: IEEE 11-13/0338r0 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…” 30

31. Submission doc.: IEEE 11-13/0338r0 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 31

32. Submission doc.: IEEE 11-13/0338r0 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 32

33. Submission doc.: IEEE 11-13/0338r0 Thanks! 12/2/13 IEEE 802 Liason to ISO/IEC JTC1 SC6 33