idnits 2.17.1 draft-kwon-yoon-kim-ipake-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 lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 3, 2013) is 4012 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T.Kwon, Sejong University 3 INTERNET-DRAFT H. Yoon, Samsung SDS 4 Intended Status: Standards Track S. Kim, Samsung SDS 5 Expires: November 4, 2013 May 3, 2013 7 I-PAKE: Identity-Based Password Authenticated Key Exchange 8 draft-kwon-yoon-kim-ipake-01 10 Abstract 12 Although password authentication is the most widespread user 13 authentication method today, cryptographic protocols for mutual 14 authentication and key agreement, i.e., password authenticated key 15 exchange (PAKE), in particular authenticated key exchange (AKE) based 16 on a password only, are not actively used in the real world. This 17 document introduces a quite novel form of PAKE protocols that employ 18 a particular concept of ID-based encryption (IBE). The resulting 19 cryptographic protocol is the ID-based password authenticated key 20 exchange (I-PAKE) protocol which is a secure and efficient PAKE 21 protocol in both soft- and hard-augmented models. I-PAKE achieves the 22 security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also 23 achieves the great efficiency by allowing the whole pre-computation 24 of the ephemeral Diffie-Hellman public keys by both server and 25 client. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2012 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 68 2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.3 Underlying Group . . . . . . . . . . . . . . . . . . . . . . 6 71 2.4 Notations . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3 Identity-Based Password Authenticated Key Exchange . . . . . . . 9 73 3.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.1.1 System Initialization . . . . . . . . . . . . . . . . . 9 75 3.1.2 Registration . . . . . . . . . . . . . . . . . . . . . . 9 76 3.2 Protocol Execution . . . . . . . . . . . . . . . . . . . . . 9 77 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 78 4.1 General - Completeness . . . . . . . . . . . . . . . . . . . 13 79 4.1.1 Mutual Authentication . . . . . . . . . . . . . . . . . 13 80 4.1.2 Key Agreement . . . . . . . . . . . . . . . . . . . . . 13 81 4.2 I-PAKE - AKE Security . . . . . . . . . . . . . . . . . . . 13 82 4.2.1 Passive Attacks . . . . . . . . . . . . . . . . . . . . 13 83 4.2.2 Active Attacks . . . . . . . . . . . . . . . . . . . . . 14 84 4.2.3 Forward Secrecy . . . . . . . . . . . . . . . . . . . . 15 85 4.2.4 Known Session Key . . . . . . . . . . . . . . . . . . . 15 86 4.2.5 Key Control . . . . . . . . . . . . . . . . . . . . . . 16 87 4.3 I-PAKE - Dictionary Attack . . . . . . . . . . . . . . . . . 16 88 4.3.1 On-line Dictionary Attack . . . . . . . . . . . . . . . 16 89 4.3.2 Off-line Dictionary Attack . . . . . . . . . . . . . . . 17 90 4.4 I-PAKE - Server Compromise . . . . . . . . . . . . . . . . . 17 91 4.4.1 Soft-Augmented Model . . . . . . . . . . . . . . . . . . 17 92 4.4.2 Hard-Augmented Model . . . . . . . . . . . . . . . . . . 18 93 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 94 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 6.1 Normative References . . . . . . . . . . . . . . . . . . . 18 96 6.2 Informative References . . . . . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 99 1 Introduction 101 The most widespread user authentication method today is obviously 102 password-based authentication; a user memorizes a textual and/or 103 numerical password and makes its direct entry for authentication. 105 There have been various attempts to enhance security of password- 106 based authentication. Password authenticated key exchange (PAKE) is a 107 cryptographic protocol to achieve both mutual authentication and 108 secure key agreement based on a password only, i.e., without 109 requiring a public key certificate [IEEE P1363.2]. That is, PAKE is 110 an authenticated key exchange (AKE) protocol based on the user- 111 memorable low-entropy password, so that both authenticated entities 112 can only agree on a fresh session key. Augmented PAKE protocols allow 113 a server to store a one-way function of password instead of the plain 114 text, so as to mitigate the server compromise [RFC2945]. 116 PAKE protocols, however, have not been deployed actively despite of 117 their merits. Instead, for example, Web applications employ the 118 SSL/TLS suite for secure transport of password information at the 119 cost of manipulating and relying on server's public key certificates 120 with regard to long-term security. This is in part due to that the 121 password transport over SSL/TLS is easier for migration of existing 122 password-based systems on the Web and also that PAKE protocols 123 require a large amount of computation for security enhancement, e.g., 124 for encrypting ephemeral Diffie-Hellman public keys under the low- 125 entropy password. There still remains a security concern as for the 126 augmented PAKE protocols. The protocols which said to resist a server 127 compromise are prone to off-line guessing attacks if the server is 128 really compromised. The password information stored in the server's 129 storage for verification purposes can be exploited by adversaries to 130 derive real passwords. Consequently, users are still in great 131 danger. 133 This document raises the fundamental questions as above to the 134 existing form of PAKE protocols and attempts to provide a novel 135 design to resolve these problems. We depart from the previous way of 136 encrypting the ephemeral Diffie-Hellman public keys under the low- 137 entropy password. Instead we map to 138 for authentication. To the protocol, the former pair is the user 139 input derived from the user's memory, while the latter is the server 140 input fetched from the server's storage. We also introduce the hard- 141 augmented model which enhances the previous, soft-augmented model for 142 sever compromise security, based on the hardware security module 143 (HSM). For the purposes, a particular concept of identity-based 144 encryption (IBE) is employed. At the cost of pre-computation of the 145 salt alphabet as for the ID alphabet, we can reduce the amount of 146 computation in real time, i.e., at registration and authentication. 148 The resulting cryptographic protocol is the ID-based password 149 authenticated key exchange (IPAKE) protocol which is a secure and 150 efficient PAKE protocol in both soft- and hard-augmented models. 151 IPAKE achieves the security goals of AKE, PAKE, and hard-augmented 152 PAKE. IPAKE also achieves the great efficiency by allowing the whole 153 pre-computation of the ephemeral Diffie-Hellman public keys by both 154 server and client. 156 1.1 Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 2. Requirements Notation 164 2.1 Definitions 166 Identity Based Encryption (IBE): Identity-based encryption (IBE) is a 167 public-key encryption technology that allows a public key to be 168 calculated from an identity and a set of public mathematical 169 parameters and that allows for the corresponding private key to be 170 calculated from an identity, a set of public mathematical parameters, 171 and a domain-wide secret value [RFC5408]. The IBE framework is 172 defined in [RFC5091], [RFC5408], and [RFC5409]. 174 Password Authenticated Key Exchange (PAKE): Password authenticated 175 key exchange (PAKE) is a cryptographic protocol to achieve both 176 mutual authentication and key agreement securely based on a password 177 only, i.e., without requiring a public key certificate. That is, PAKE 178 is a form of authenticated key exchange (AKE) which is in particular 179 based on the password for authentication. The PAKE framework is 180 defined in [IEEE P1363.2], [ISO/IEC 11770-4], and [RFC2945]. 182 2.2 Abbreviations 184 TDL Trapdoor Discrete Logarithm 186 IBE Identity Based Encryption 188 I-PAKE Identity-Based Password Authenticated Key Exchange 190 AKE Authenticated Key Exchange 191 PKG Private Key Generator 193 HSM Hardware Security Module 195 MAC Message Authentication Code 197 SSL/TLS Secure Socket Layer/Transport Layer Security 199 CDH problem Computational Diffie-Hellman problem 201 2.3 Underlying Group 203 The I-PAKE protocol can be implemented over the following group. 205 Let N =p*q where p and q are sufficiently large B-smooth prime such 206 that p = 3 (mod 4), q = 3 (mod 4), gcd(p - 1, q - 1) = 2. Let G be a 207 multiplicative cyclic subgroup of Z_N^* with a generator g = g_m^2 208 where g_m is a generator of a maximal cyclic subgroup of Z_N^* of 209 order phi(N)/2. The order of g is phi(N)/4. 211 2.4 Notations 213 a||b 214 A concatenation of a and b. 216 A 217 The alphabet of ID. An alphanumeric set is commonly used. 219 T 220 The alphabet of salt. A set of discrete logarithms of the A's 221 elements in G. This set is maintained privately by the server's 222 HSM_s. 224 P 225 The alphabet of password. An alphanumeric set with special 226 characters is commonly used. 228 User 229 A human user who actually remembers a pair of ID and password for 230 authentication. 232 ID 233 User's identity which is represented ID = ID_1||ID_2|| ... || 234 ID_alpha where the ID_i is an element of Set A for all i in {1,2, 235 ..., alpha}. 237 Client or C 238 A protocol entity providing a user interface to User for ID and 239 password entry, and a system interface to a remote server for 240 running the protocol. Client represents User in the protocol. 242 Server or S 243 A protocol entity providing a system interface to Client for 244 running the protocol, and storing a 3-tuple of ID, salt, and 245 password-verifier for authentication. 247 HSM_t and HSM_v 248 Private hardware attached to Server. HSM_t stores Set T and is 249 used for deriving salt given ID. HSM_v is only used in the hard- 250 augmented model for computing a password-verifier. 252 h 253 A known random hash function which takes an arbitrary finite bit 254 string and assigns it to an element of Z_N^*, where Z_N^* is a set 255 of positive integers modulo N which are not zero divisors. In 256 practice, a cryptographically secure one-way hash function is 257 used. 259 H 260 It is defined as H(ID) = (h(ID))^2 for an ID. By definition, H 261 takes an ID and assigns it to an elements of G. That is H(ID) = I 262 is in G. In fact, ID = ID_1||ID_2|| ... || ID_alpha, H(ID) is 263 calculated as H(ID_1) * H(ID_2) * ... * H(ID_alpha). 265 h_i (i = 0, 1, 2, 3, 4, 5, 6) 266 Known random hash functions. In practice, a cryptographically 267 secure one-way hash function is used with distinct indices i. Each 268 h_i takes an arbitrary finite bit string and assigns it to a 269 finite string. The bit size of output of each h_i can be different 270 from each other. 272 t_ID 273 The secret key of the client whose identity is ID. t_ID is a 274 discrete logarithm of I = H(ID) based on g. That is, t_ID = log_g 275 H(ID) = log_g H(ID_1) * H(ID_2) * ... * H(ID_alpha) = log_g 276 H(ID_1) + log_g H(ID_2) + ... + log_g H(ID_alpha) = t_ID_1 + 277 t_ID_2 + ... + t_ID_alpha. 279 pw and PW 280 "pw" is the password maintained by Client. Importantly, pw can be 281 a plaintext of password, exactly remembered by User, or a one-way 282 hash function of it, depending on the protocol and Server 283 implementation. "PW" is the password maintained by Server. 284 Importantly, PW can be equal to pw, exactly maintained by Client, 285 or a one-way hash function of it, or a MAC of it, depending on the 286 protocol and Server implementation. 288 V_PW 289 A password-verifier maintained by Server, such that V_PW = 290 h(ID,t_ID,PW). This value is derived from PW by hashing in the 291 soft-augmented model or MAC in the hard-augmented model. That is 292 PW = h'(pw) or PW = MAC_hk(pw), where h' is a cryptographically 293 secure one-way hash function, MAC_hk is a message authentication 294 code that takes an element in P and assigns it to a finite bit 295 string where hk is a secret key of HSM_v. 297 X and Y 298 Ephemeral Diffie-Hellman public keys. X=g^x mod N and Y=g^y mod N, 299 respectively, for randomly chosen x and y in Z_N^*. 301 E_K(pw) 302 Encryption of pw under the ephemeral high-entropy key K. The 303 encryption function E is a secure symmetric key encryption 304 function, for example, AES. 306 C_1 and C_2 307 Confirmation messages in the protocol. 309 ' 310 An indicator that discriminates the values computed by the server 311 from the same values computed by the client. For instance, sk and 312 sk' might be the same values but computed by respective parties. 314 3 Identity-Based Password Authenticated Key Exchange 316 I-PAKE is a two-party protocol where Client and Server authenticate 317 each other and generate a session key together, based on a human- 318 memorable password and ID information. For the purpose, the client 319 and the server exchange messages involving ephemeral keying 320 information and agree on a fresh session key. 322 3.1 Initialization 324 The initialization SHOULD be finished before the I-PAKE protocol 325 execution. 327 3.1.1 System Initialization 329 Server MAY negotiate with PKG or play the role of PKG by itself, so 330 as to generate system parameters including underlying group 331 parameters, ID and salt alphabets, and required functions. 333 Server MUST keep the salt alphabet, T, secure, e.g., in HSM_t, after 334 the initialization. 336 In the hard-augmented model, Server MUST initialize HSM_v as well. 338 3.1.2 Registration 340 User SHOULD select ID and a memorable password, and register them to 341 Server through a secure channel. The secure channel at registration 342 is out of scope in this document. 344 Client MAY receive the User's input and set the password as pw, so as 345 to submit ID and pw to Server. 347 Server MUST fetch the discrete logarithms of H(ID_i) from T for ID, 348 and set their sum as User's salt, t_ID. Server MAY set the received 349 pw as PW, so as to compute a password-verifier. 351 In the hard-augmented model, Server MUST negotiate with HSM_v for 352 obtaining PW such that PW = MAC_hk(pw). In the soft-augmented model, 353 Server MAY set PW as a function of pw. 355 Server SHOULD store ID, t_ID, and V_PW in its storage after computing 356 the password-verifier such that V_PW = h(ID,t_ID,PW) 358 User MAY update the memorable password with a new one, and register 359 it to Server again. 361 3.2 Protocol Execution 362 User MUST input ID and password at the user interface provided by 363 Client. The protocol SHOULD be executed between Server and Client. 365 +------------+ +-------------+ 366 | | | | 367 | Client | MESSAGE_1 | Server | 368 | | -------------> | | 369 | | MESSAGE_2 | | 370 | | <------------ | | 371 | | MESSAGE_3 | | 372 | | -------------> | | +-------+ 373 | | MESSAGE_4 | | --- | HSM_v | 374 | | <------------- | | +-------+ 375 | | | | 376 +------------+ +-------------+ 378 Client ----> Server 380 Client SHALL choose a random x from Z_N^* and computes its 381 ephemeral Diffie-Hellman public key X = g^x mod N. It is an 382 OPTION that this computation MAY be done as pre-computation. 384 MESSAGE_1 = ID, X 386 Server ----> Client 388 If the received value X is 1, 0, or -1, then Server MUST 389 terminate this protocol execution. Upon receiving MESSAGE_1, 390 Server SHALL select a random y from Z_N^* and compute Y=g^y mod 391 N. It is an OPTION that this computation MAY be done as pre- 392 computation. 394 MESSAGE_2 = Y 396 Client ----> Server 398 If the received value Y is 1, 0, or -1, then Client MUST 399 terminate this protocol execution. Upon receiving MESSAGE_2, 400 Client SHALL perform the following: 402 o Action 1: Calculate I = H(ID). 404 o Action 2: Calculate e = h_0(ID,C,S,X,Y,I). 406 o Action 3: Calculate Z = (YI^e)^x mod N. 408 o Action 4: Calculate the secret key K = h_1(ID,C,S,X,Y,I,Z). 410 o Action 5: Calculate the session key sk = h_2(ID,C,S,X,Y,I,Z). 412 o Action 6: Encrypt the password pw using the secret key K, 413 E_K(pw). 415 o Action 7: Calculate C_1 = h_3(ID,C,S,X,Y,I,sk). 417 MESSAGE_3 = E_K(pw), C_1 419 Server ----> Client 421 Upon receiving MESSAGE_3, Server SHALL perform the following: 423 o Action 1: Calculate I = H(ID). 425 o Action 2: Calculate e = h_0(ID,C,S,X,Y,I). 427 o Action 3: Calculate Z' = X^(y+t_ID*e) mod N. 429 o Action 4: Calculate the secret key K' = h_1(ID,C,S,X, Y, I, 430 Z'). 432 o Action 5: Calculate the session key sk' = h_2(ID,C,S,X, Y, I, 433 Z'). 435 o Action 6: Decrypt the received E_K(pw) using the secret key 436 K'. 438 o Action 7: Calculate the password verifier V_PW = 439 h(ID,t_ID,PW), where PW is MAC_hk(pw) in the hard-augmented 440 model or h(pw) in the soft-augmented model. 442 If the calculated V_PW is not equal to the saved V_PW then 443 Server MUST terminate this protocol execution. Otherwise, Server 444 SHALL perform the following: 446 o Action 8: Calculate C_1' = h_3(ID,C,S,X,Y,I,sk). 448 If the received C_1 in MESSAGE_3 is not equal to C_1' then 449 Server MUST terminate this protocol execution. Otherwise, Server 450 shall perform the following: 452 o Action 9: Calculate C_2 = h_4(ID,C,S,X,Y,I,sk'). 454 MESSAGE_4 = C_2 456 Since (YI^e)^x = (g^y * (g^sID)^e)^x = g^xy * g^((s_ID)ex) = X^y 457 * X^(s_ID * e) = X^(y + s_ID*e), K = K' and sk = sk'. That is, 458 Server calculates the same secret key with Client and can 459 decrypt the MESSAGE_3 and obtain the same password pw. Server 460 can confirm that Client is now operated by authenticated User 461 and agree on the session key sk to be shared with Client. 463 Client 465 Upon receiving MESSAGE_4, Client SHALL perform the following: 467 o Action 1: Calculate C_2' = h_4(ID,C,S,X,Y,I,sk'). 469 If the received C_2 does not equal to C_2' then Client MUST 470 terminate this protocol execution. Otherwise, Client can confirm 471 that Server is authenticated and agree on the session key sk to 472 be shared with Server. 474 4 Security Considerations 476 4.1 General - Completeness 478 The I-PAKE protocol is a cryptographic protocol that achieves 479 mutual authentication and key agreement, based on a human- 480 memorable password and ID information, between two entities. 482 4.1.1 Mutual Authentication 484 A user is authenticated by a server through a pair of ID and 485 memorable password pw in the I-PAKE protocol. For the purpose, a 486 client of the user should submit the encryption of pw under a 487 correct fresh encryption key K, along with the user's ID, in the 488 protocol. Note that pw can be a secure one-way hash function of 489 real memorable password. 491 The server is authenticated by the client through the salt, that 492 is, the user's ID information based on IBE, in the I-PAKE 493 protocol. For the purpose, the server must show the confirmation 494 that the same session key has been derived based on the salt. 496 4.1.2 Key Agreement 498 A client and a server both exchange ephemeral Diffie-Hellman 499 public keys, X and Y, and agree on the same key incorporating 500 the correct Diffie-Hellman key based on them. 502 4.2 I-PAKE - AKE Security 504 The I-PAKE protocol is an AKE protocol based on a memorable 505 password and ID information. Thus, it fulfills the requirements 506 of AKE security. 508 4.2.1 Passive Attacks 510 We say that an AKE protocol is secure against passive attacks if 511 an adversary who merely observes honest entities carrying out 512 the protocol, fails to derive a session key, which was 513 authenticated and agreed by the honest entities. 515 IPAKE is a secure AKE protocol because the messages, (U, X), (S, 516 Y), C1, and C2, eavesdropped by a passive attacker, do not 517 reveal the corresponding session key, sk, due to the CDH problem 518 and the secure one-way hash function. 520 More specifically, sk and K are secure one-way hash functions of 521 protocol messages involving the seed key, zk, denoted as 522 follows. 524 zk=Z*Z'^e mod N 526 Note that Z is a Diffie-Hellman key of X and Y, i.e., Z=g^(xy) 527 mod N; Z' can be seen as another form of the Diffie-Hellman key 528 of X and I, i.e., Z=g^(xt) mod N; and e is a secure one-way hash 529 function of protocol messages involving X, Y, and I, i.e., 530 e=h0(U,S,X,Y,I). 532 The confirmation messages, C1 and C2, are secure one-way hash 533 functions of protocol messages involving sk. 535 The I-PAKE protocol is secure against the passive attacks. 537 4.2.2 Active Attacks 539 We say that an AKE protocol is secure against active attacks if 540 an adversary who controls the protocol messages, e.g., by 541 injection, interception, replay, and/or modification, fails to 542 subvert the communications of the honest entities. 544 o Impersonation of client: In order to impersonate a client of a 545 target user, an adversary should obtain the encryption of pw 546 under a fresh encryption key K and its confirmation message C1. 547 (1) Although the adversary can inject a new message X to the 548 protocol and derive K from x and Y, the probability of 549 constructing the correct encryption of pw is bounded by the 550 password space. (2) Although the adversary can replay the old 551 message X' generated previously by the honest client, the new 552 encryption key K must be different from the old encryption key 553 K' due to the server's new ephemeral key Y that is different 554 from the old ephemeral key Y'. In both cases, the adversary 555 cannot construct the correct encryption of pw and its 556 confirmation message C1, and thus fails to impersonate the 557 client. 559 o Impersonation of server: In order to impersonate a server, an 560 adversary should obtain a correct encryption key K and its 561 confirmation message C2. (1) Although the adversary can inject a 562 new message Y to the protocol, the probability of computing K is 563 bounded by the salt space. (2) Although the adversary can replay 564 the old message Y' generated previously by the honest server, 565 the new decryption key K must be different from the old 566 encryption key K' due to the client's new ephemeral key X that 567 is also distinct from the old ephemeral key X'. (3) Although the 568 adversary can modify a new message Y, e.g., Y=g^y*I^(1/e') mod 569 N, for the purpose of canceling out I and so the slat s when 570 computing a fresh key K from X, Y, and the secure one-way hash 571 function e, the probability of obtaining e' such that e'=e must 572 be bounded by the collision resistance of the hash function. In 573 all cases, the adversary cannot obtain a correct encryption key 574 K and its confirmation message C2, and thus fails to impersonate 575 the server. 577 o Man-in-the-middle attack: In order to reside as a middle man 578 in the protocol, an adversary should enforce a fresh encryption 579 key K, encryption of pw, and confirmation messages C1 and C2, 580 according to her own key X' and Y', respectively. Although the 581 adversary can intercept X and Y, and inject her own key X' and 582 Y' to replace them, respectively, into the protocol, the 583 probability of computing K against a client is bounded by the 584 salt space while that of constructing the encryption of pw 585 against the server is bounded by the password space. The 586 adversary fails to reside as a middle man in the protocol. 588 The I-PAKE protocol is secure against the active attacks. 590 4.2.3 Forward Secrecy 592 We say AKE provides forward secrecy when the secrecy of previous 593 session keys is not affected even if long-term secrets, such as 594 passwords and salt in the I-PAKE protocol, of one or more 595 entities are compromised. 597 If the password is compromised, an adversary should inspect the 598 protocol messages of the previous sessions that incorporate the 599 password but only is the encryption of pw from a conventional 600 block cipher system. Due to the security assumption of the block 601 cipher, the ephemeral encryption key K is not derivable. Even if 602 K is also compromised, the previous session key is not derivable 603 due to the security assumption of one-way hash function. 605 If the salt is compromised, the adversary should inspect the 606 protocol messages of the previous sessions that incorporate the 607 salt but only is the ID information. Due to the hardness 608 assumption of the Diffie-Hellman problem, the previous session 609 key is not derivable from X and Y. 611 The I-PAKE protocol provides the forward secrecy. 613 4.2.4 Known Session Key 615 We say AKE is secure against known session key attacks if the 616 protocol achieves its goal even if an adversary learned some 617 previous session keys. 619 If the previous session key sk is compromised, an adversary 620 should inspect the protocol messages of the previous and/or 621 future sessions but only is the confirmation message. Due to the 622 hardness assumption of the Diffie-Hellman problem and the 623 security assumption of one-way hash function, the old session 624 keys neither reveal the password and salt information nor 625 enforce forged key agreement. 627 The I-PAKE protocol is secure against the known session key 628 attacks. 630 4.2.5 Key Control 632 We say AKE is secure against key control attacks if neither 633 entity is able to force the session key to be a function of a 634 pre-selected value, such as either X or Y. 636 Due to the the hardness assumption of the Diffie-Hellman 637 problem, neither entity can enforce the key agreement on a pre- 638 selected value. 640 The I-PAKE protocol is secure against the key control attacks. 642 4.3 I-PAKE - Dictionary Attack 644 The I-PAKE protocol is a PAKE protocol that incorporates IBE. 645 Thus, it fulfills the requirements of PAKE security against 646 dictionary attacks. 648 4.3.1 On-line Dictionary Attack 650 We say PAKE is secure against on-line dictionary attacks if an 651 active adversary in the client side is only able to test a 652 single guess from a password dictionary per on-line attempt 653 while a server is able to count the number of failed attempts 654 consistently, and also in the server side cannot test any guess 655 from the password dictionary per on-line attempt. Note that the 656 second requirement is very important in practical settings. 658 In order to test a guessed password on-line in the client side, 659 the adversary should send the honest server the encryption of 660 guessed password and its confirmation C1 after exchanging X and 661 Y. The adversary can verify the guess according to the response 662 of the server, while the server can also verify it and count its 663 failure due to the decryption result. If the failure count gets 664 to the limit, the server can lock the corresponding account. 666 In order to test a guessed password on-line in the server side, 667 the adversary should decrypt out the password which was 668 encrypted by the honest client after exchanging X and Y. The 669 adversary cannot verify the guess because the corresponding 670 decryption key K is not derivable. 672 The I-PAKE protocol is secure against the on-line dictionary 673 attacks. 675 4.3.2 Off-line Dictionary Attack 677 We say PAKE is secure against off-line dictionary attacks if an 678 active adversary is only able to remove at most a single guess 679 from a password dictionary per session, and a passive adversary 680 cannot remove any guess from the dictionary. 682 As described in the on-line dictionary attack, the active 683 adversary can only remove a single guess from the dictionary in 684 the client side, and no guess in the server side per session. 686 As described in the passive attack, the passive adversary cannot 687 derive a decryption key K, and thus cannot remove any guess from 688 the dictionary per session. 690 The I-PAKE protocol is secure against the off-line dictionary 691 attacks. 693 4.4 I-PAKE - Server Compromise 695 The I-PAKE protocol is an augmented PAKE protocol that fulfills 696 the requirements of PAKE security against server compromise, not 697 only in the previous (soft-) augmented model but also in the new 698 hard-augmented model. 700 4.4.1 Soft-Augmented Model 702 We say PAKE is secure against the server compromise in the soft- 703 augmented model if an adversary who obtained a password 704 verification directory stored by the server cannot impersonate 705 the client of the target user directly, i.e., without launching 706 the off-line dictionary attack. Note that the off-line 707 dictionary attack is possible for the server compromise in the 708 soft-augmented model. 710 Since the server stores only ID, salt, and verifier in the 711 password verification directory, the adversary who obtained the 712 directory cannot construct the encryption of password. 714 The I-PAKE protocol is secure against the server compromise in 715 the soft-augmented model. 717 4.4.2 Hard-Augmented Model 719 We say PAKE is secure against the server compromise in the hard- 720 augmented model if an adversary who obtained a password 721 verification directory stored by the server cannot impersonate 722 the client of the target user and launch the off-line dictionary 723 attack. The basic assumption is that the HSM module is never 724 compromised. 726 Since the server stores only ID, salt, and verifier in the 727 password verification directory, the adversary who obtained the 728 directory cannot construct the encryption of password. 730 Since the verifier is the MAC of password information under the 731 MAC key which is only stored in the HSM module, the adversary 732 who obtained the directory cannot launch the off-line dictionary 733 attack. 735 The I-PAKE protocol is secure against the server compromise in 736 the hard-augmented model. 738 5 IANA Considerations 740 This document includes no request to IANA. 742 6 References 744 6.1 Normative References 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", BCP 14, RFC 2119, March 1997. 749 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 750 RFC 2945, September 2000. 752 6.2 Informative References 754 [RFC5408] Appenzeller, G., Martin, L., and M. Schertler, "Identity- 755 Based Encryption Architecture and Supporting Data 756 Structures", RFC 5408, January 2009. 758 [RFC5409] Martin, L. and M. Schertler, "Using the Boneh-Franklin and 759 Boneh-Boyen Identity-Based Encryption Algorithms with the 760 Cryptographic Message Syntax (CMS)", RFC 5409, January 761 2009. 763 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 764 Standard (IBCS) #1: Supersingular Curve Implementations of 765 the BF and BB1 Cryptosystems", RFC 5091, December 2007. 767 [IEEE P1363.2] 768 IEEE P1363.2, "Password-Based Public-Key Cryptography", 769 Submissions to IEEE P1363.2, . 772 [ISO/IEC 11770-4] 773 ISO/IEC JTC 1/SC 27 11770-4, "Information technology - 774 Security techniques - Key management - Part 4: Mechanisms 775 based on weak secrets", May 2006, . 779 Authors' Addresses 781 Taekyoung Kwon 782 Sejong University 783 98 Kunja-dong, Kwangjin-gu 784 Seoul 143-747, Korea 786 EMail: tkwon@sejong.edu 788 Hyojin Yoon 789 Samsung SDS 790 5th Fl., Medison Bldg., 791 Daechi-dong, Gangnam-gu, 792 Seoul 135-280, Korea 794 EMail: hj1230.yoon@samsung.com 796 Sangyoub Kim 797 Samsung SDS 798 4th Fl., Medison Bldg., 799 Daechi-dong, Gangnam-gu, 800 Seoul 135-280, Korea 801 EMail: sy9.kim@samsung.com