idnits 2.17.1 draft-irtf-cfrg-pake-reqs-08.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 : ---------------------------------------------------------------------------- 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 (February 8, 2017) is 2605 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force J. Schmidt 3 Internet-Draft secunet Security Networks 4 Intended status: Informational February 8, 2017 5 Expires: August 12, 2017 7 Requirements for PAKE schemes 8 draft-irtf-cfrg-pake-reqs-08 10 Abstract 12 Password-Authenticated Key Agreement (PAKE) schemes are interactive 13 protocols that allow the participants to authenticate each other and 14 derive shared cryptographic keys using a (weaker) shared password. 15 This document reviews different types of PAKE schemes. Furthermore, 16 it presents requirements and gives recommendations to designers of 17 new schemes. It is a product of the Crypto Forum Research Group 18 (CFRG). 20 Status of This Memo 22 This Internet-Draft is submitted 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). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on August 12, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. PAKE Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Storage of the Password . . . . . . . . . . . . . . . . . 3 58 3.2. Transmission of Public Keys . . . . . . . . . . . . . . . 4 59 3.3. Two Party versus Multiparty . . . . . . . . . . . . . . . 4 60 4. Security of PAKEs . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Implementation Aspects . . . . . . . . . . . . . . . . . 6 62 4.2. Special case: Elliptic Curves . . . . . . . . . . . . . . 6 63 5. Protocol Considerations and Applications . . . . . . . . . . 6 64 6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 11.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Requirements notation 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. Introduction 82 Passwords are the predominant method of accessing the Internet today 83 due, in large part, to their intuitiveness and ease of use. Since a 84 user needs to enter passwords repeatedly in many connections and 85 applications, these passwords tend to be easy to remember and be able 86 to be entered repeatedly with a low probability of error. They tend 87 to be low-grade and not-so-random secrets that are susceptible to 88 brute-force guessing attacks. 90 A Password-Authenticated Key Exchange (PAKE) attempts to address this 91 issue by constructing a cryptographic key exchange that does not 92 result in the password, or password-derived data, being transmitted 93 across an unsecured channel. Two parties in the exchange prove 94 possession of the shared password without revealing it. Such 95 exchanges are therefore resistant to off-line, brute-force dictionary 96 attacks. The idea was initially described by Bellovin and Merritt in 98 [BM92] and has received considerable cryptographic attention since 99 then. PAKEs are especially interesting due to the fact that they can 100 achieve mutual authentication without requiring any Public Key 101 Infrastructure (PKI). 103 Different types of PAKE schemes are reviewed in this document. It 104 defines requirements for new schemes and gives additional 105 recommendations for designers of PAKE schemes. The specific 106 recommendations are discussed throughout Section 3 till Section 7. 107 Section 8 summarizes the requirements. 109 This document represents the consensus of the Crypto Forum Research 110 Group (CFRG). 112 3. PAKE Taxonomy 114 Broadly speaking, different PAKEs satisfy their goals in a number of 115 common ways. This leads to various design choices: how public keys 116 are transmitted (encrypted or not), whether both parties possess the 117 same representation of the password (balanced versus augmented) and 118 the number of parties (two party versus multiparty). 120 3.1. Storage of the Password 122 When both sides of a PAKE store the same representation of the 123 password, the PAKE is said to be "balanced". In a balanced PAKE the 124 password can be stored directly, in a salted state by hashing it with 125 a random salt, or by representing the credential as an element in a 126 finite field (by, for instance, multiplying a generator from a finite 127 field and the password represented as a number to produce a "password 128 element"). The benefits of such PAKEs are that they are applicable 129 to situations where either party can initiate the exchange or both 130 parties can initiate simultaneously, i.e. where they both believe 131 themselves to be the "initiator". This sort of PAKE can be useful 132 for mesh networking (see, for example, [DOT11]) or Internet-of-Things 133 applications. 135 When one side maintains a transform of the password and the other 136 maintains the raw password, the PAKE is said to be "augmented". 137 Typically, a client will maintain the raw password (or some 138 representation of it as in the balanced case), and a server will 139 maintain a transformed element generated with a one-way function. 140 The benefit of an augmented PAKE is that it provides some protection 141 for the server's password in a way that is not possible with a 142 balanced PAKE. In particular, an adversary that has successfully 143 obtained the server's PAKE credentials cannot directly use them to 144 impersonate the users to other servers. The adversary has to learn 145 the individual passwords first, e.g. by performing an (offline) 146 dictionary attack. This sort of PAKE is useful for strict client- 147 server protocols such as the one discussed in [RFC5246]. 149 3.2. Transmission of Public Keys 151 All known PAKEs use public key cryptography. A fundamental 152 difference in PAKEs is how the public key is communicated in the 153 exchange. 155 One class of PAKEs uses symmetric key cryptography, with a key 156 derived from the password, to encrypt an ephemeral public key. The 157 ability of the peer to demonstrate it has successfully decrypted the 158 public key proves knowledge of the shared password. Examples of this 159 exchange include the first PAKE called the Encrypted Key Exchange 160 (EKE) which was introduced in [BM92]. 162 Another class of PAKEs transmits unencrypted public keys, like the 163 J-PAKE protocol [JPAKE]. During key agreement, ephemeral public keys 164 and values derived using the shared password are exchanged. In the 165 case that the passwords match both parties can compute a common 166 secret by combining password, public keys and private keys. The 167 SPEKE [SPEKE] scheme also exchanges public keys, namely Diffie- 168 Hellman values. Here, the generator for the public keys is derived 169 from the shared secret. Afterwards, only the public Diffie-Hellman 170 values are exchanged, the generator is kept secret. In both cases, 171 the values that are transmitted across the unsecured medium is an 172 element in a finite field and not a random blob. 174 A combination of the EKE and SPEKE is used in PACE as described in 175 [BFK09], which is e.g. used in international travel documents. In 176 this method a nonce is encrypted rather than a key. This nonce is 177 used to generate a common base for the key agreement. Without 178 knowing the password, the nonce cannot be determined and hence, the 179 subsequent key agreement will fail. 181 3.3. Two Party versus Multiparty 183 The majority of PAKE protocols allow two parties to agree on a shared 184 key based on a shared password. Nevertheless, there exist proposals 185 that allow key agreement for more than two parties. Those protocols 186 allow key establishment for a group of parties and are hence called 187 Group PAKEs or GPAKEs. Examples of such protocols can be found in 188 [ABCP06], while [ACGP11] and [HYCS15] propose a generic construction 189 that allows the transformation of any two-party PAKE into a GPAKE 190 protocol. Another possibility of defining a multi-party PAKE 191 protocol is to assume the existence of a trusted server with which 192 each party shares a password. This server enables different parties 193 to agree on a common secret key without the need to share a password 194 among each other. Each party has only a shared secret with the 195 trusted server. For example, Abdalla et al. designed such a protocol 196 as discussed in [AFP05]. 198 4. Security of PAKEs 200 PAKE schemes are modelled on the scenario of two parties, typically 201 Alice and Bob, who share a password (or perhaps Bob shares a function 202 of the password) and would like to use it to establish a secure 203 session key over an untrusted link. There is a powerful adversary, 204 typically Eve, who would like to subvert the exchange. Eve has 205 access to a dictionary that is likely to contain Alice and Bob's 206 password, and Eve is capable of enumerating through the dictionary in 207 a brute-force manner to try and discover Alice and Bob's password. 209 All PAKEs have a limitation. If Eve guesses the password, she can 210 subvert the exchange. It is therefore necessary to model likelihood 211 that Eve will guess the password to access the security of a PAKE. 212 If the probability of her discovering the password is a function of 213 interaction with the protocol participants and not a function of 214 computation, then the PAKE is secure. That is, if Eve is unable to 215 take information from a passive attack or from a single active 216 attack. Thus, she cannot enumerate through her dictionary without 217 interacting with Alice or Bob for each password guess, i.e. the only 218 attack left is repeated guessing. Eve learns one thing from a single 219 active attack: whether her single guess is correct or not. 221 In other words, the security of a PAKE scheme is based on the idea 222 that Eve, who is trying to impersonate Alice, cannot efficiently 223 verify a password guess without interacting with Bob (or Alice). If 224 she were to interact with either, she would thereby be detected. 225 Thus, it is to balance restricting the number of allowed 226 authentication attempts with the potential of a denial-of-service 227 vulnerability. In order to judge and compare the security of PAKE 228 schemes, security proofs in commonly accepted models SHOULD be used. 229 Each proof and model, however, is based on assumptions. Often 230 security proofs show that if an adversary is able to break the 231 scheme, the adversary is also able to solve a problem that is assumed 232 to be hard such as computing a discrete logarithm. By conversion, 233 breaking the scheme is considered to be a hard problem as well. 235 A PAKE scheme SHOULD be accompanied with a security proof with 236 clearly stated assumptions and models used. In particular, the proof 237 MUST show that the probability is negligible that an active adversary 238 would be able to pass authentication, learn additional information 239 about the password or learn anything about the established key. 240 Moreover, the authors MAY specify which underlying primitives are to 241 be used with the scheme or MAY consider specific use cases or 242 assumptions like resistance to quantum computers. A clear and 243 comprehensive proof is the foundation for users to trust in the 244 security of the scheme. 246 4.1. Implementation Aspects 248 Aside from the theoretical security of a scheme, practical 249 implementation pitfalls have to be considered as well. If not 250 carefully implemented, even a scheme that is secure in a well-defined 251 mathematical model can leak information via side-channels. The 252 design of the scheme might allow or prevent easy protection against 253 information leakage. In a network scenario, an adversary can measure 254 the time the computation of an answer takes and derive information 255 about secret parameters of the scheme. If a device operates in a 256 potentially hostile environment, such as a smart card, other side- 257 channels like power consumption and electromagnetic emanations or 258 even active implementation attacks have to be taken into account as 259 well. 261 The developers of a scheme SHOULD keep the implementation aspects in 262 mind and show how to implement the protocol in constant time. 263 Furthermore, adding a discussion about how to protect implementations 264 of the scheme in potential hostile environments is encouraged. 266 4.2. Special case: Elliptic Curves 268 Since Elliptic Curve Cryptography (ECC) allows for a smaller key- 269 length compared to traditional schemes based on the discrete 270 logarithm problem in finite fields at similar security levels, using 271 ECC for PAKE schemes is also of interest. In contrast to schemes 272 that can use the finite field element directly, an additional 273 challenge has to be considered for some schemes based on ECC, namely 274 the mapping of a random string to an element that can be computed 275 with, i.e. a point on the curve. In some cases, also the opposite is 276 needed, i.e. the mapping of a curve point to a string that is not 277 distinguishable from a random one. When choosing a mapping, it is 278 crucial to consider the implementation aspects as well. 280 In the case that the PAKE scheme is intended to be used with ECC, the 281 authors SHOULD state whether there is a mapping function needed, and 282 if so, discuss its requirements. Alternatively, the authors MAY 283 define a mapping to be used with the scheme. 285 5. Protocol Considerations and Applications 287 In most cases, the PAKE scheme is a building block in a more complex 288 protocol like IPsec or TLS. This can influence the choice of a 289 suitable PAKE scheme. For example, an augmented scheme can be 290 beneficial for protocols that have a strict server-client 291 relationship. In the case that both parties can initiate a 292 connection of a protocol, a balanced PAKE might be more appropriate. 294 A special variation of the network password problem, called Password 295 Authenticated Key Distribution, is defined in [P1363] as password 296 authenticated key retrieval: "The retrieval of a key from a secure 297 key repository or escrow requiring authentication derived in part 298 from a password." 300 In addition to key retrieval from escrow, there is also the variant 301 of two parties exchanging public keys using a PAKE in lieu of 302 certificates. In this variant, public keys can be encrypted using a 303 password. Authentication key distribution can be performed because 304 each side knows the private key associated with its unencrypted 305 public key and can also decrypt the peer's public key. This 306 technique can be used to transform a short, one-time code into a 307 long-term public key. 309 Another possible variant of a PAKE scheme allows combining 310 authentication with certificates and the use of passwords. In this 311 variant, the private key of the certificate is used to blind the 312 password key agreement. For verification, the message is unblinded 313 with the public key. A correct key establishment therefore implies 314 the possession of the private key belonging to the certificate. This 315 method enables one-sided authentication as well as mutual 316 authentication when the password is used. 318 The authors of a PAKE scheme MAY discuss variations of their scheme 319 and explain application scenarios where these variations are 320 beneficial. In particular, techniques that allow long-term (public) 321 key agreement are encouraged. 323 6. Privacy 325 In order to establish a connection, each party of the PAKE protocol 326 needs to know the identity of its communication partner to identify 327 the right password for the agreement. In cases where a user wants to 328 establish a secure channel with a server, the user first has to let 329 the server know which password to use by sending some kind of 330 identifier to the server. If this identifier is not protected, 331 everyone who is able to eavesdrop on the connection can identify the 332 user. In order to prevent this and protect the privacy of the user, 333 the scheme might provide a way to protect the transmission of the 334 user's identity. A simple way to achieve privacy of a user that 335 communicates with a server is to use a public key provided by the 336 server to encrypt the user's identity. 338 The PAKE scheme MAY discuss special ideas and solutions how to 339 protect the privacy of the users of the scheme. 341 7. Performance 343 The performance of a scheme can be judged along different lines 344 depending on the optimization goals of the target application. 345 Potential metrics include latency, code-size/area, power consumption, 346 or exchanged messages. In addition, there might be application 347 scenarios in which a constrained client communicates with a powerful 348 server. In such a case, the scheme has to require minimal efforts on 349 the client side. Note that for some clients the computations might 350 even be carried out in a hardware implementation, which require 351 different optimizations compared to software. 353 Furthermore, the design of the scheme can influence the cost of 354 protecting the implementation from adversaries exploiting its 355 physical properties (see Section 4.1). 357 The authors of a PAKE scheme MAY discuss their design choices and the 358 influence of these choices on the performance. In particular, the 359 optimization goals could be stated. 361 8. Requirements 363 This section summarizes the requirements for PAKE schemes to be 364 compliant with this document based on the previous discussed 365 properties. 367 R1: A PAKE scheme MUST clearly state its features regarding 368 balanced/augmented versions. 370 R2: A PAKE scheme SHOULD come with a security proof and clearly 371 state its assumptions and models. 373 R3: The authors SHOULD show how to protect their PAKE scheme 374 implementation in hostile environments, particularly, how to 375 implement their scheme in constant time to prevent timing attacks. 377 R4: In the case that the PAKE scheme is intended to be used with 378 ECC, the authors SHOULD discuss their requirements for a potential 379 mapping or define a mapping to be used with the scheme. 381 R5: The authors of a PAKE scheme MAY discuss its design choice 382 with regard to performance, i.e., its optimization goals. 384 R6: The authors of a scheme MAY discuss variations of their scheme 385 that allows the use in special application scenarios. In 386 particular, techniques that facilitate long-term (public) key 387 agreement are encouraged. 389 R7: Authors of a scheme MAY discuss special ideas and solutions on 390 privacy protection of its users. 392 R8: The authors MUST follow the IRTF IPR policy . 395 9. IANA Considerations 397 This document makes no request of IANA. 399 10. Security Considerations 401 This document analyses requirements for a cryptographic scheme. 402 Security considerations are discussed throughout the document. 404 11. References 406 11.1. Normative References 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, 410 DOI 10.17487/RFC2119, March 1997, 411 . 413 11.2. Informative References 415 [ABCP06] Abdalla, M., Bresson, E., Chevassut, O., and D. 416 Pointcheval, "Password-Based Group Key Exchange in a 417 Constant Number of Rounds", PKC 2006, LNCS 3958, 2006. 419 [ACGP11] Abdalla, M., Chevalier, C., Granboulan, L., and D. 420 Pointcheval, "Contributory Password-Authenticated Group 421 Key Exchange with Join Capability", CT-RSA 2011, 422 LNCS 6558, 2011. 424 [AFP05] Abdalla, M., Fouque, P., and D. Pointcheval, "Password- 425 based authenticated key exchange in the three-party 426 setting", PKC 2005, LNCS 3386, 2005. 428 [BFK09] Bender, J., Fischlin, M., and D. Kuegler, "Security 429 Analysis of the PACE Key-Agreement Protocol", ISC 2009, 430 LNCS 5735, 2009. 432 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 433 Password-Based Protocols Secure Against Dictionary 434 Attacks", Proc. of the Symposium on Security and 435 Privacy Oakland, 1992. 437 [DOT11] IEEE Computer Society, "Telecommunications and information 438 exchange between systems Local and metropolitan area 439 networks", Part 11: Wireless LAN Medium Access Control 440 (MAC) and Physical Layer (PHY) Specifications IEEE Std 441 802.11-2012, 2012. 443 [HYCS15] Hao, F., Yi, X., Chen, L., and S. Shahandashti, "The 444 Fairy-Ring Dance: Password Authenticated Key Exchange in a 445 Group", IoTPTS 2015, ACM , 2015. 447 [JPAKE] Hao, F. and P. Ryan, "Password Authenticated Key Exchange 448 by Juggling", SP 2008, LNCS 6615, 2008. 450 [P1363] IEEE Microprocessor Standards Committee, "Draft Standard 451 for Specifications for Password-based Public Key 452 Cryptographic Techniques", IEEE P1363.2, 2006. 454 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 455 (TLS) Protocol Version 1.2", RFC 5246, 456 DOI 10.17487/RFC5246, August 2008, 457 . 459 [SPEKE] Jablon, D., "Strong Password-Only Authenticated Key 460 Exchange", ACM Computer Communications Review October 461 1996, 1996. 463 Author's Address 465 Joern-Marc Schmidt 466 secunet Security Networks 467 Mergenthaler Allee 77 468 65760 Eschborn 469 Germany 471 Email: joern-marc.schmidt@secunet.com