idnits 2.17.1 draft-sheffer-cfrg-pake-review-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2019) is 1639 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-sullivan-tls-opaque-00 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Crypto Forum Research Group Y. Sheffer 3 Internet-Draft Intuit 4 Intended status: Informational October 31, 2019 5 Expires: May 3, 2020 7 Review of the CFRG PAKE Proposals 8 draft-sheffer-cfrg-pake-review-00 10 Abstract 12 This draft consists of the author's review of the password- 13 authenticated key exchange (PAKE) protocols, as submitted to the 14 IRTF's CFRG. All opinions here are the author's alone. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 3, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.2. Conventions used in this document . . . . . . . . . . . . 3 53 2. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Protocol Completeness and Clarity . . . . . . . . . . . . 3 55 2.2. Integration into Existing Protocols . . . . . . . . . . . 4 56 3. Detailed Review . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Balanced Algorithms . . . . . . . . . . . . . . . . . . . 4 58 3.1.1. SPAKE2 . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1.2. J-PAKE . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1.3. SPEKE . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1.4. CPace . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. Augmented Algorithms . . . . . . . . . . . . . . . . . . 5 63 3.2.1. OPAQUE . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2.2. AuCPace . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2.3. VTBPEKE . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2.4. BSPAKE . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Informative References . . . . . . . . . . . . . . . . . . . 6 69 Appendix A. Document History . . . . . . . . . . . . . . . . . . 8 70 A.1. draft-sheffer-cfrg-pake-review-00 . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The CFRG took upon itself to review multiple proposed PAKE algorithms 76 and select zero or more of them as suitable for general use in IETF 77 protocols. Eight protocols were submitted for consideration, and 78 they are listed on the CFRG GitHub repository: 79 https://github.com/cfrg/pake-selection. 81 Over the last few months multiple reviews were submitted to the CFRG, 82 evaluating the protocols' cryptographic quality as well as their 83 engineering properties. As the last stage of this process, members 84 of the CFRG Crypto Review Panel were asked to provide summary 85 reviews, and this document is the author's contribution as a Panel 86 member. 88 1.1. Disclaimer 90 The author is not a cryptographer. Specifically, I do not have the 91 skills to prove security of such protocols, nor even to evaluate the 92 quality of such proofs. I do, however, possess a reasonable amount 93 of experience in integrating cryptography into protocols, including 94 PAKE-based algorithms [RFC6124] [RFC6631]. 96 1.2. Conventions used in this document 98 This is essentially an opinion piece and does not employ any 99 normative language. 101 2. Preliminaries 103 Before diving into the individual protocols, I would like to get two 104 important points out of the way. 106 2.1. Protocol Completeness and Clarity 108 CFRG has published in the past some protocols in enough detail that 109 they can be implemented by a non-expert developer. A good example is 110 [RFC7748]. Of the eight PAKE submissions, in my opinion only one 111 comes close to this level of rigor. Whatever protocols are selected, 112 CFRG must make it clear that such selection is conditional on the 113 algorithms being republished in a detailed format. CFRG must not 114 leave this task to the IETF working groups, because that would both 115 duplicate work and introduce a major risk of inadvertent errors that 116 invariably manifest themselves as vulnerabilities. 118 Ironically, I can quote the abstract of one of the submissions to 119 support this position: "We observe that the original SPEKE 120 specification is subtly different from those defined in the ISO/IEC 121 11770-4 and IEEE 1363.2 standards. We show that those differences 122 have critical security implications by presenting two new attacks on 123 SPEKE: an impersonation attack and a key-malleability attack." In 124 other words, an under-specified protocol resulted in two different 125 standards, both of them vulnerable. This is ironic because the paper 126 from which this is quoted is not itself a rigorous description of the 127 protocol that it attempts to fix. 129 I would propose that each of the selected protocols be published as 130 an RFC, containing: 132 o A detailed description of the protocol, to a level that can be 133 implemented by developers who are not security experts. 134 o Test vectors to ensure interoperability. 135 o Recommendations on integrating with higher-level protocols: 136 supported identity fields and recommendations on how they should 137 be protected, session ID and "exporter" integration, secure 138 capability and parameter negotiation, conditions on whether and 139 how "optional" protocol exchanges can be eliminated. 140 o Mandated auxiliary primitives, such as hash-to-curve and memory- 141 hard iterated hashing. 143 2.2. Integration into Existing Protocols 145 The IPsec/IKE community has always been interested in PAKE as a 146 component, both for remote access and for peer-to-peer VPN 147 deployments. This to me justifies the selection of both a balanced 148 and an augmented PAKE, assuming good candidates exist. It also means 149 that the integration of such protocols into IKEv2 is relatively 150 straightforward. 152 On the other hand, the TLS community has been less receptive to PAKE 153 solutions, and as a result, the properties required from the protocol 154 for proper integration are not as clear. It is possible that the 155 most common deployment will be a combination of TLS, PAKE and OAuth. 156 Arguably we should take the combination into account when defining 157 the PAKE portion of the protocol, and resist the temptation to only 158 consider the narrow integration of a PAKE protocol into TLS 1.3. 160 3. Detailed Review 162 As mentioned above, I believe we should select one balanced and one 163 augmented PAKE protocol. 165 3.1. Balanced Algorithms 167 3.1.1. SPAKE2 169 This protocol is the best documented of all the candidates. On the 170 down side, it relies on a set of parameters that present a high value 171 target for factorization once a quantum computer is available to an 172 adversary, and that would break all instances of this protocol. 174 3.1.2. J-PAKE 176 This algorithm is an outlier in its complexity, which also implies a 177 significant performance penalty. For this reason I don't think it 178 would be a realistic selection. 180 3.1.3. SPEKE 182 SPEKE has been around for a long time, which is an advantage. But 183 the quoted paper describes several attacks on concrete 184 specifications/implementations, and Karthik's review casts doubts 185 about the validity of the security proof presented for this protocol. 186 As far as I can tell, the mailing list discussion has not fully 187 clarified which exact version of the protocol is proposed and which 188 published security proof applies to it. Specifically, does [Hao2018] 189 apply? 191 3.1.4. CPace 193 CPace is not specified as a stand-alone protocol, but rather needs to 194 be extracted out of the AuCPace specification. Moreover, it adds a 195 mandatory (though trivial) message round to establish a session ID. 196 This extra round may or may not be subsumed by the higher-level 197 protocol. Having said that, it comes with an actual security proof 198 and no magic parameters. 200 3.2. Augmented Algorithms 202 3.2.1. OPAQUE 204 OPAQUE is described as a generic framework, with two instantiations, 205 and will have to be narrowed down when standardized. The protocol is 206 secure against pre-computation attacks. This is a good thing of 207 course, however I am not sure how serious this attack is in practice: 208 while servers are often breached with attackers gaining bulk access 209 to hashed passwords, I don't think it is common for attackers to 210 record multiple salt exchanges and use them in a follow-on attack. 211 OPAQUE comes with a security proof. OPAQUE is well documented, with 212 a separate draft [I-D.sullivan-tls-opaque] on its integration into 213 TLS. 215 3.2.2. AuCPace 217 The protocol has two versions, the main paper and Appendix C ("Strong 218 AuCPace"), which is resistant to pre-computation attacks. It is 219 unclear which one is nominated. 221 3.2.3. VTBPEKE 223 This 2017 paper extends SPEKE into a balanced PEKE that can be proven 224 even for elliptic curves, and then again into a verifier-based (i.e., 225 augmented) PAKE named VTBPEKE. It has a few "magic" constants which 226 are potentially of concern - I didn't see any mention of how they 227 should be generated. 229 3.2.4. BSPAKE 231 This protocol is somewhat loosely specified, with no security proof 232 (or even security justification/intuition) provided. So it is hard 233 to be convinced of its fit for purpose. 235 4. Conclusions 237 As noted, I think the Research Group should recommend one balanced 238 and one augmented algorithm. 240 Before presenting my conclusions, I would like to clarify my view 241 about quantum resistance in this context. Steve Thomas defines 242 "quantum annoying" as: an attacker with a quantum computer needs to 243 solve a DLP per password guess. IMO this is too high of a bar, and 244 once we get to the point where this is a real risk we will need to 245 migrate to PQC for these protocols. However I think that even now, a 246 protocol where a single DLP solve would break _all_ instances of the 247 protocol, is too risky to adopt. 249 Of the balanced algorithms, I would recommend CPace. I think the 250 extra round trip is a reasonable price to pay for a formally proven 251 protocol. To me the potential quantum vulnerability of the SPAKE2 252 parameters is a showstopper. 254 Of the augmented algorithms, I will follow the Mozilla report and 255 recommend OPAQUE, which appears to be the best fit into TLS, and is 256 also a good fit into IKEv2. 258 5. Informative References 260 [Hao2018] Hao, F., Metere, R., Shahandashti, S., and C. Dong, 261 "Analyzing and Patching SPEKE in ISO/IEC", IEEE 262 Transactions on Information Forensics and Security Vol. 263 13, pp. 2844-2855, DOI 10.1109/tifs.2018.2832984, November 264 2018. 266 [I-D.sullivan-tls-opaque] 267 Sullivan, N., Krawczyk, H., Friel, O., and R. Barnes, 268 "Usage of OPAQUE with TLS 1.3", draft-sullivan-tls- 269 opaque-00 (work in progress), March 2019. 271 [RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An 272 EAP Authentication Method Based on the Encrypted Key 273 Exchange (EKE) Protocol", RFC 6124, DOI 10.17487/RFC6124, 274 February 2011, . 276 [RFC6631] Kuegler, D. and Y. Sheffer, "Password Authenticated 277 Connection Establishment with the Internet Key Exchange 278 Protocol version 2 (IKEv2)", RFC 6631, 279 DOI 10.17487/RFC6631, June 2012, 280 . 282 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 283 for Security", RFC 7748, DOI 10.17487/RFC7748, January 284 2016, . 286 Appendix A. Document History 288 A.1. draft-sheffer-cfrg-pake-review-00 290 o Initial version. 292 Author's Address 294 Yaron Sheffer 295 Intuit 297 EMail: yaronf.ietf@gmail.com