idnits 2.17.00 (12 Aug 2021) /tmp/idnits35635/draft-sheffer-ipsecme-pake-criteria-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 24, 2010) is 4434 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.harkins-ipsecme-spsk-auth' is defined on line 371, but no explicit reference was found in the text == Outdated reference: draft-harkins-emu-eap-pwd has been published as RFC 5931 == Outdated reference: draft-harkins-ipsecme-spsk-auth has been published as RFC 6617 == Outdated reference: draft-sheffer-emu-eap-eke has been published as RFC 6124 == Outdated reference: A later version (-02) exists of draft-sheffer-ipsecme-hush-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Check Point 4 Intended status: Informational March 24, 2010 5 Expires: September 25, 2010 7 Password-Based Authentication in IKEv2: Selection Criteria and 8 Comparison 9 draft-sheffer-ipsecme-pake-criteria-02.txt 11 Abstract 13 The IPsecME working group has been chartered with specifying a new 14 password-based authentication method for IKEv2. This document 15 presents a few solution alternatives, and lists potential criteria 16 for choosing among them. It is not the author's intention to publish 17 this document as an RFC. Moreover, it is more subjective than most 18 IETF documents. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 25, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Selection Criteria . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Security Criteria . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Intellectual Property . . . . . . . . . . . . . . . . . . 5 65 3.3. Other Considerations and Engineering Criteria . . . . . . 6 66 4. Some Possible Candidates . . . . . . . . . . . . . . . . . . . 7 67 5. Comparison Table . . . . . . . . . . . . . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 The new IPsecME WG charter defines a new work item on password-based 79 authentication for IKEv2. This is a somewhat contentious issue, so 80 the charter is very particular about the requirements. Quoting in 81 full: 83 IKEv2 supports mutual authentication with a shared secret, but 84 this mechanism is intended for "strong" shared secrets. User- 85 chosen passwords are typically of low entropy and subject to off- 86 line dictionary attacks when used with this mechanism. Thus, RFC 87 4306 recommends using EAP with public-key based authentication of 88 the responder instead. This approach would be typically used in 89 enterprise remote access VPN scenarios where the VPN gateway does 90 not usually even have the actual passwords for all users, but 91 instead typically communicates with a back-end RADIUS server. 92 However, user-configured shared secrets are still useful for many 93 other IPsec scenarios, such as authentication between two servers 94 or routers. These scenarios are usually symmetric: both peers 95 know the shared secret, no back-end authentication servers are 96 involved, and either peer can initiate an IKEv2 SA. While it 97 would be possible to use EAP in such situations (by having both 98 peers implement both the EAP peer and the EAP server roles of an 99 EAP method intended for "weak" shared secrets) with the mutual 100 EAP-based authentication work item (above), a simpler solution may 101 be desirable in many situations. 102 The WG will develop a standards-track extension to IKEv2 to allow 103 mutual authentication based on "weak" (low-entropy) shared 104 secrets. The goal is to avoid off-line dictionary attacks without 105 requiring the use of certificates or EAP. There are many already- 106 developed algorithms that can be used, and the WG would need to 107 pick one that both is believed to be secure and is believed to 108 have acceptable intellectual property features. The WG would also 109 need to develop the protocol to use the chosen algorithm in IKEv2 110 in a secure fashion. It is noted up front that this work item 111 poses a higher chance of failing to be completed than other WG 112 work items; this is balanced by the very high expected value of 113 the extension if it is standardized and deployed. 115 The charter defines some properties that a good solution is required 116 to have. For example, despite the fact that EAP is an integral part 117 of IKEv2, there are good reasons to avoid it in this case. But the 118 charter does not name a specific cryptographic protocol on which to 119 base this solution, nor does it mention a specific IETF document as a 120 starting point. This document asserts that several such choices are 121 possible, and attempts to provide the group with some selection 122 criteria, in order to enable a reasoned discussion of these (and 123 possibly other) alternatives. 125 2. Terminology 127 This document is entirely non-normative. None of the IETF- 128 capitalized words SHOULD be used, and if perchance they are, they 129 MUST be ignored. 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. Selection Criteria 137 IKEv2 is targeted at applications that require a very high level of 138 security. Therefore, adding a new mode of operation to the protocol 139 can only be done after careful consideration. In this section, I 140 describe some of the criteria we can use to choose between solution 141 candidates. Unfortunately, I am not aware of any potential solution 142 that score a "perfect 10" under these criteria. If this paper 143 encourages the development of new solutions that better fit the 144 criteria, so much the better. 146 3.1. Security Criteria 148 The primary requirement from a good solution is to have a high level 149 of security. Unfortunately, we all know this property is extremely 150 hard to gauge. But some data might enhance our confidence in a 151 solution's security. 153 SEC1: The protocol has good security "best practices", such as 154 crypto agility. 155 SEC2: The solution is based on a cryptographic protocol that has 156 been (openly) published some time ago, giving the 157 cryptographic community enough time to have reviewed it. 158 Preferably, it was published in a location where it is more 159 likely to be reviewed, e.g. a peer-reviewed crypto journal. 160 SEC3: The protocol has undergone thorough professional analysis. 161 It's best if protocol analyses by prominent cryptographers 162 have been published. If issued were uncovered, we would 163 prefer repeat analysis to have been undertaken on the fixed 164 protocol. 165 SEC4: Some modern protocols have been mathematically proven secure 166 under various models. This is an attractive feature of such 167 protocols. 169 SEC5: When integrated with IKEv2, the solution should preserve IKE's 170 existing security properties. These include forward secrecy 171 (disclosure of long term credentials, in this case the 172 password, does not expose past sessions), and identity 173 protection in the presence of passive attackers 174 (eavesdroppers). 175 SEC6: The solution should be able of generating of a cryptographic- 176 strength credential (either a long key or a certificate) so 177 that the weak credential needs to be used rarely or even only 178 once. 180 It is noted that some features (such as support for password expiry) 181 and some security criteria (such as resistance to server compromise) 182 are very important for the "teleworker" use case. This document is 183 limited to the use of password-based authentication to achieve trust 184 between gateways, and for this use case, these features and criteria 185 are of questionable value. 187 The author considers security assurance to be by far the most 188 important criterion. The impact of a security vulnerability 189 discovered late in the process would be extremely severe to the 190 protocol and to deployed implementations. 192 3.2. Intellectual Property 194 "Intellectual property", a common euphemism for patents, is a complex 195 issue. The existence of patents covering a specific technology is 196 often an important consideration for vendors, and critical for open 197 source implementers. Despite this fact, the IETF does not provide 198 its constituency with any legal guidance or assistance in this 199 matter. 201 Unfortunately, the specific area of password-based authentication is 202 riddled with patents. This has hampered the IETF adoption of this 203 technology for years, and caused at least one working group to fail. 204 As a result, we (as individual implementers and as a working group) 205 need to understand as best we can the IPR status of each proposal. 207 Disclaimer: I am not a lawyer, and this document should not be 208 construed as legal advice. 210 IETF rules require that any participant who's aware of a patent 211 relevant to an IETF work item should disclose the patent's existence. 212 In practice, such disclosures are often submitted very late in the 213 process, resulting in a long period when a document's IPR status 214 remains unclear. Even more worryingly, filing an IPR statement 215 against another person's technology carries no cost: in at least one 216 case I am aware of, a company filed an IPR statement for a 217 competitive technology asserting their own patent, even though the 218 technology is in fact covered by another patent, making it very 219 likely that the company's patent does not apply to the technology. 220 Given this background, I propose the following as selection criteria: 222 IPR1: Ideally, the proposal should be unencumbered. This property 223 is very difficult to prove, and each WG participant should 224 attempt to review the applicable patents and determine whether 225 in fact they do not apply to the proposal. Remember that 226 independently invented technology might still infringe a 227 patent. 228 IPR2: In some cases the IPR situation is clear: if the protocol 229 relies on a specific patent, and believed to not require the 230 use of any other. This is mostly useful if the patent's 231 licensing terms (whether free or not) are known, and/or the 232 patent's expiration date is near. 233 IPR3: Many IETF participants, and the IETF as an organization, quite 234 naturally prefer freely licensed technology to non-free 235 licensing terms. 237 Given the number and quality of encumbered protocols in this space, 238 IPR is one area where the group might have to compromise. 240 3.3. Other Considerations and Engineering Criteria 242 Several additional criteria may be just as important: 244 MISC1: Protocols that have been specified within standards documents 245 should be preferred over protocols that are only described in 246 scientific papers. Such description is typically 247 insufficient to provide interoperability, and may not be 248 sufficient for a thorough security analysis. 249 MISC2: Likewise, cryptographic protocols that have been integrated 250 into the IKE framework have an advantage over those described 251 only within other security protocols. 252 MISC3: The protocol should make a good fit into the minimal IPsec/ 253 IKE architecture, e.g. it should not assume a trusted third 254 party or tight clock synchronization. 255 MISC4: It is advantageous if the same algorithms and where 256 applicable, the same Diffie-Hellman groups can be used for 257 IKE itself and for the authentication protocol. This can 258 simplify the implementation and eliminate spurious 259 negotiation. 260 MISC5: Performance, measured primarily by the number of round trips 261 and number of exponentiations. Performance should remain 262 reasonable even if the "password" is a long octet string. 264 MISC6: The solution should accommodate algorithm agility relative to 265 IKE cryptographic algorithms, e.g., transition to elliptic 266 curve key agreement. 267 MISC7: The solution must support localization of identities and 268 passwords. In general, the scheme must support arbitrary 269 octet strings as the input, so that any current and future 270 character encoding can be supported. 271 MISC8: Similarly, the scheme must support arbitrary octet strings as 272 input, so that it can be used to "boost" shared secrets that 273 have been generated using weak methods, e.g. not-quite-random 274 RNGs. 275 MISC9: The always valid, but always vague "ease of implementation". 277 4. Some Possible Candidates 279 This section provides background regarding some of the candidate 280 protocols. Some pertinent properties are mentioned, but this is by 281 no means an analysis against the criteria defined above. 283 1. EKE is the oldest password-authenticated key exchange (PAKE) 284 protocol still considered secure, although some of its variants 285 have been broken. It is covered by a patent, due to expire in 286 late 2011. 287 2. SPSK (a.k.a. EAP-PWD) is a relatively new mechanism. It has 288 been standardized within IEEE 802.11s. 289 3. PAK is the earliest provably-secure mechanism. A protocol 290 description has been standardized within the IETF, but no other 291 IETF PAK-based protocol exists. PAK is patented (IPR statement 292 #1179). 293 4. SRP has been deployed in multiple products. It is described by 294 several IETF documents, including a TLS-SRP variant. SRP is 295 patented, and can be used under a royalty-free license (IPR 296 statement #31, as well as additional IPR statements filed by 297 other parties). 299 In addition, applicable standards to be consulted for these and 300 additional protocols include: 302 o IEEE P1363.2, Specifications for Password based Public Key 303 Cryptographic Techniques. 304 o ISO/IEC 11770-4:2006 Information technology - Security techniques 305 - Key management - Part 4: Mechanisms based on weak secrets. 307 5. Comparison Table 309 This is a very rough attempt at a comparative analysis. Many of the 310 details are incomplete, and/or controversial. 312 +------+-----------------------------+---------------+--------------+ 313 | Name | Security Standards | Security | IPR | 314 | | | Analysis | | 315 +------+-----------------------------+---------------+--------------+ 316 | EKE | [I-D.sheffer-emu-eap-eke], | Well analyzed | Patent filed | 317 | | [I-D.sheffer-ipsecme-hush] | security, | 1992 (now | 318 | | | since 1992, | owned by | 319 | | | several | Lucent), due | 320 | | | analysis | to expire | 321 | | | papers | Oct. 2011. | 322 | | | published. | | 323 | SRP | SRP published as [RFC2945], | Published and | Patent held | 324 | | TLS-SRP is [RFC5054]. IEEE | unpublished | by Stanford | 325 | | 1363.2, ISO IEC 11770-4. | analysis by | University, | 326 | | | Bleichenbache | with a free | 327 | | | r. | license. | 328 | | | | Phoenix | 329 | | | | posted an | 330 | | | | IPR | 331 | | | | statement, | 332 | | | | but no | 333 | | | | request for | 334 | | | | reexaminatio | 335 | | | | n. | 336 | SPSK | [I-D.harkins-emu-eap-pwd], | Security | Explicitly | 337 | | [I-D.harkins-ipsecme-spsk-a | analysis by | not | 338 | | uth]. | NIST | patented. | 339 | | | cryptographer | | 340 | | | s. | | 341 | SPEK | IEEE 1363.2 and ISO IEC | [To be | Patents held | 342 | E | 11770-4. | completed] | by Phoenix. | 343 | PAK | Published as [RFC5683]. | See [RFC5683] | Patents held | 344 | | IEEE 1363.2. | | by Lucent. | 345 +------+-----------------------------+---------------+--------------+ 347 6. IANA Considerations 349 This document does not require any action by IANA. 351 7. Security Considerations 353 This document does not define any new protocol, and has no inherent 354 security considerations. It does discuss criteria for the selection 355 of a security protocol, chief among them being security. 357 8. References 359 8.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 8.2. Informative References 366 [I-D.harkins-emu-eap-pwd] 367 Harkins, D. and G. Zorn, "EAP Authentication Using Only A 368 Password", draft-harkins-emu-eap-pwd-13 (work in 369 progress), February 2010. 371 [I-D.harkins-ipsecme-spsk-auth] 372 Harkins, D., "Secure PSK Authentication for IKE", 373 draft-harkins-ipsecme-spsk-auth-01 (work in progress), 374 March 2010. 376 [I-D.sheffer-emu-eap-eke] 377 Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An 378 EAP Authentication Method Based on the EKE Protocol", 379 draft-sheffer-emu-eap-eke-05 (work in progress), 380 March 2010. 382 [I-D.sheffer-ipsecme-hush] 383 Sheffer, Y. and S. Fluhrer, "HUSH: Using HUmanly memorable 384 SHared secrets with IKEv2", draft-sheffer-ipsecme-hush-00 385 (work in progress), March 2010. 387 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 388 RFC 2945, September 2000. 390 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 391 "Using the Secure Remote Password (SRP) Protocol for TLS 392 Authentication", RFC 5054, November 2007. 394 [RFC5683] Brusilovsky, A., Faynberg, I., Zeltsan, Z., and S. Patel, 395 "Password-Authenticated Key (PAK) Diffie-Hellman 396 Exchange", RFC 5683, February 2010. 398 Appendix A. Change Log 400 A.1. -02 402 Yet more criteria after the discussion in Anaheim and on the list. 404 A.2. -01 406 Added some criteria after mailing list review. 408 A.3. draft-sheffer-ipsecme-pake-criteria-00 410 Initial version. 412 Author's Address 414 Yaron Sheffer 415 Check Point Software Technologies Ltd. 416 5 Hasolelim St. 417 Tel Aviv 67897 418 Israel 420 Email: yaronf.ietf@gmail.com