idnits 2.17.1 draft-harkins-ipsecme-pake-criteria-01.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (October 18, 2010) is 4931 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Harkins 3 Internet-Draft Aruba Networks 4 Intended status: Informational October 18, 2010 5 Expires: April 21, 2011 7 Password-Based Authentication in IKEv2: Selection Criteria and 8 Considerations 9 draft-harkins-ipsecme-pake-criteria-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 21, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 41 in effect on the date of publication of this document. Please review 42 these documents carefully, as they describe your rights and restrictions 43 with respect to this document. 45 Abstract 47 The IPsecME working group has been re-chartered. One of the new 48 charter items is to specify a new password-based authentication 49 method for IKEv2. This document describes some selection criteria 50 and selection considerations for the WG to use. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Selection Considerations . . . . . . . . . . . . . . . . . . . 3 57 3.1. Security . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Intellectual Property . . . . . . . . . . . . . . . . . . . 4 59 3.3. Protocol Co-Existance . . . . . . . . . . . . . . . . . . . 7 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. Informative References . . . . . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 The new IPsecME WG charter defines a new work item on password-based 69 authentication for IKEv2. It says, in part: 71 The WG will develop a standards-track extension to IKEv2 to allow 72 mutual authentication based on "weak" (low-entropy) shared 73 secrets. The goal is to avoid off-line dictionary attacks without 74 requiring the use of certificates or EAP. There are many already- 75 developed algorithms that can be used, and the WG would need to 76 pick one that both is believed to be secure and is believed to 77 have acceptable intellectual property features. The WG would also 78 need to develop the protocol to use the chosen algorithm in IKEv2 79 in a secure fashion. It is noted up front that this work item 80 poses a higher chance of failing to be completed than other WG 81 work items; this is balanced by the very high expected value of 82 the extension if it is standardized and deployed. 84 As noted, there are many algorithms that can satisfy this work item 85 and the WG needs to pick one. This memo describes a set of selection 86 critera to consider when making the choice and suggests some 87 techniques to use to prevent the process from degenerating. It is an 88 informational memo for the edification of the WG only. It does not 89 presume to be the only way for the WG to arrive at decision. 91 This Internet-Draft is not intended to be advanced. It exists solely 92 for easy reference of the criteria on which the WG should base its 93 selection decision. Once that decision has been made this Internet- 94 Draft should quietly expire. 96 2. Terminology 98 This document is entirely non-normative. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document hold no special significance, certainly not those described 103 in [RFC2119]. 105 3. Selection Considerations 107 IKEv2 provides a very high level of security, has no or a very 108 negligible cost for licensing, and has a protocol structure that is 109 well-understood. Therefore a new mode to support authentication with 110 a possibly low-entropy password/passphrase must be added with great 111 care, so as to not unduely affect any of these features. 113 Candidate protocols must be evaluated against each of these: security 114 of the candidate, intellectual property considerations that would 115 require licensing of any kind, and how well the candidate fits into 116 the existing protocol structure of IKEv2. 118 3.1. Security 120 Because the charter work item deals with authentication using a low- 121 entropy shared secret any candidate protocol has to address the 122 security issues of the existing pre-shared key mode in IKE today when 123 using a low-entropy secret, and must not introduce any new avenues of 124 attack. 126 SEC1: The protocol must be based on a zero-knowledge proof. It must 127 be resistant to passive attack, active attack, and off-line 128 dictionary attack. The only information leaked about the 129 secret from a single run of the protocol is a single bit: 130 whether the single guess was correct or not. Another way to 131 put this is that the advantage an attacker gets is based on 132 interation and not computation. 133 SEC2: The protocol supports perfect forward secrecy and protection 134 against the Denning-Sacco attack. 135 SEC3: The protocol does not require the loss of identity protection 136 afforded by IKEv2 today. 137 SEC4: The protocol does not constrain the "crypto agility" of IKEv2. 138 It must not require fixed and unchangable cryptographic 139 primitives or Diffie-Hellman groups. 140 SEC5: The protocol should have received review by the cryptographic 141 community, and the more review the better. The protocol 142 should be proven secure under a commonly understood 143 cryptographic model. 144 SEC6: The protocol should support the ability to parlay the low- 145 entropy secret into a cryptographic-strength credential (such 146 as a strong symmetric key or a certificate and private key) 147 such that the low-entropy secret need only be used once, or 148 very rarely. 149 SEC7: The protocol should be able to store, and use, a transform of 150 a password to provide resistance to exposure of the password 151 in case of compromise. 152 SEC8: The protocol is secure regardless of the tranforms negotiated 153 by IKEv2. The security properties of the exchange must not 154 change depending on the negotiated transforms. 156 3.2. Intellectual Property 158 Password-authenticated key exchange is an interesting and difficult 159 problem. When a solution is found, there is a natural desire to 160 protect the intellectual property unique to the solution and apply 161 for a patent. The issue of intellectual property rights (IPR) is a 162 large consideration for a solution to this work item due to the 163 potential added cost to implementation due to licensing issues. 165 [RFC3669] provides some case studies on how IPR has been handled in 166 other IETF WGs and has a good section on using IPR as a technology 167 evaluation factor. It can be a useful guide to IPR discussions in 168 IPsecME in deciding which protocol to use to satisfy the charter work 169 item. 171 Patent holders have a financial interest in licensing their 172 technology. This results in claims and counter-claims on whether a 173 particular piece of IPR applies or does not apply to a particular 174 protocol. Many of these claims are subjective. Given that the 175 claimant has an obvious motivation for opining a certain way (either 176 "yes it does apply" or "no it does not apply") the opinion can be 177 suspect. Discussions can easily reach the point of being pointless 178 back-and-forth exchanges because these claimants are not providing 179 legal advice on what is, fundamentally, a legal question. 181 There are a few things to keep in mind when considering the IPR 182 implications of adopting a particular candidate protocol: 184 o Every protocol, even protocols that are already patented, may 185 infringe on other patents that are known or unknown. 186 o Licensing of a patent does not provide protection against 187 incidential infringment of another patent. 188 o The claims of a patent are what define the IPR. Descriptive text 189 or problem statements that are part of a patent but not part of a 190 claim do not describe IPR, but may be used to interpret the 191 claims. 192 o Whether a protocol does or does not infringe on a particular 193 patent can only be determined by a court, not by cryptographers, 194 patent holders, lawyers, or other so-called "experts". 195 o Nothing can prevent you from receiving a threatenting letter from 196 a patent holder accusing you of infringing on a some patent. 197 o Patents are time-limited. 198 o Information made public before a given date (so called "prior 199 art") may be useful in invalidating claims of a patent. 201 A WG reaching some consensus on whether a technology infringes on a 202 particular patent, or whether some patent is invalid, is 203 inappropriate. The decision must be arrived at individually by each 204 WG member, although each decision will influence support for 205 selecting a particular protocol and collectively an impression can be 206 made. Unfortunately, that individual decision may involve resolution 207 of competing and fuzzy claims and counter-claims. As [RFC3669] 208 mentions, each WG member should use all legal resources (including 209 legal counsel) to arrive at a decision whether a particular protocol 210 infringes or does not infringe on a particular patent. The opinion 211 of "experts" may be interesting and potentially insightful but is not 212 the type of opinion required to make a decision. 214 It is important to avoid pointless "yes it does"/"no it doesn't" 215 exchanges when evaluating IPR and candidate protocols. This can be 216 done by framing the disussion. This framing takes two parts. 218 First by stating uncontentous facts about the known IPR status of a 219 candidate protocol. These are suggested to be: 221 IPR1: A public description of the protocol was made on . This 222 allows one to determine when applicable patents may expire or 223 to determine whether some public information could be 224 considered "prior art". 225 IPR2: A patent or patent application on the protocol has been made. 226 Or, conversely, no patent or patent application on the 227 protocol has been made as of this time. If the protocol is 228 patented this allows one to find out when it will expire. 229 IPR3: An IPR disclosure on this protocol, or a particular 230 instantiation of this protocol, has been made to the IETF. 231 Or, conversely, no IPR disclosure on this protocol was made 232 because, for instance, it is believed to be free of IPR. This 233 is useful in determining a baseline for licensing costs. 235 Second, by focusing the discussion of known IPR to address the 236 questions that really matter: 238 1. does the claim cover the protocol in question? 239 2. is the claim valid? 241 Such discussions are focused and useful if they point out which claim 242 from which patent a protocol seems to infringe and, importantly, why. 243 Each such statement can become a separate issue around which an 244 informative discussion can be had. 246 Some kinds of statements should be discouraged. For example: 248 o Statements which assume one must prove a negative ("show that this 249 protocol is patent-free") should be discouraged because such a 250 thing is very difficult, if not impossible, to prove. 251 o Broad accusations that a protocol infringes on IPR without listing 252 the specific claims from a patent on which it supposedly infringes 253 should be discouraged because they can tend to be inflammatory, 254 and more importantly, because they do not specifically address the 255 important questions. 257 o Opinions masquerading as facts ("that claim will never stand up in 258 court") should be discouraged or restated ("that claim will be 259 very difficult to uphold"). 261 3.3. Protocol Co-Existance 263 IKE is a request/response protocol with role enforcement (there is an 264 "initiator" and a "responder"). It negotiates a slew of parameters 265 that govern how it will complete. It provides mutual authentication 266 and derivation of a secret known only to the authenticated peers. It 267 can trade off the strength of the derived key for computation and 268 time costs. It creates and manages security associations that define 269 how to communicate between peers. These are all well understood and 270 well-analyzed features of IKE. Addition of new modes of 271 authentication must be done harmoniously, keeping in mind the 272 existing structure and nature of IKE. 274 Co-existance considerations must be taken into account when 275 discussing candidate protocols. These include: 277 MISC1: How many additional round trips does the protocol add to the 278 existing exchange? 279 MISC2: How much additional computation (e.g. exponentiation) must 280 be performed for each exchange because of the protocol? 281 MISC3: Does performance differ depending on whether the secret is a 282 large, random octet string or a character string? 283 MISC4: Can internationalization of character-based passwords be 284 supported? 285 MISC5: Can the protocol use the same finite cyclic groups (MODP, 286 EC2N, ECP) used in IKEv2 or does it require a new IANA 287 registry or additions of special groups to the existing IANA 288 registry? 289 MISC6: Does the protocol fit into the request/response nature of 290 IKE or are additional messages required to "sync" the two 291 peers back up? 292 MISC7: What additional negotiation, if any, is required to use this 293 protocol? 294 MISC8: Does the the protocol require a trusted third party or clock 295 synchronization to successfully complete? 296 MISC9: Does the protocol require the use of certain cryptographic 297 primitives-- hash functions, ciphers, finite cyclic groups-- 298 or is it "crypto-agile"? 299 MISC10: Does the protocol support the use of elliptic curve 300 cryptography or only finite field cryptography? 302 MISC11: Can the protocol be easily implemented? 304 4. IANA Considerations 306 This document does not require any action by IANA. 308 5. Security Considerations 310 This document does not define any new protocol, and has no inherent 311 security considerations. It does discuss criteria for the selection 312 of a security protocol, chief among them being security. 314 6. Acknowledgments 316 The author would like to thank Yaron Sheffer and Paul Hoffman for the 317 email exchanges the caused this document to be written. It was 318 motivated by Yaron's draft of a similar name. 320 7. Informative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 [RFC3669] Brim, S., "Guidelines for Working Groups on Intellectual 326 Property Issues", RFC 3669, February 2004. 328 Author's Address 330 Dan Harkins 331 Aruba Networks 332 1322 Crossman Avenue 333 Sunnyvale, CA 94089-1113 334 United States of America 336 Email: dharkins@arubanetworks.com