idnits 2.17.1 draft-haase-aucpace-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (January 13, 2020) is 1564 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 ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Haase 3 Internet-Draft Endress + Hauser Liquid Analysis 4 Intended status: Informational January 13, 2020 5 Expires: July 16, 2020 7 (strong) AuCPace, an augmented composable PAKE 8 draft-haase-aucpace-00 10 Abstract 12 This document describes AuCPace which is an augmented PAKE protocol 13 for two parties. The protocol was tailored for constrained devices 14 and smooth migration for compatibility with legacy user credential 15 databases. It is designed to be compatible with any group of both 16 prime- and non-prime order and comes with a security proof providing 17 composability guarantees. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 16, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 49 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 58 3. Definitions for AuCPace . . . . . . . . . . . . . . . . . . . 3 59 3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Access to server-side password verifiers databases . . . . . 6 61 4.1. User credential database and password verifier types . . 7 62 4.2. Encoding of passwords and user names . . . . . . . . . . 7 63 4.3. AuCPace database interface for retrieving password 64 verifiers . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.4. Derivation of the salt value for strong AuCPace . . . . . 9 66 4.5. Specification of the workload parameter sigma . . . . . . 10 67 4.6. Result of the database parameter lookup . . . . . . . . . 10 68 5. Authentication session . . . . . . . . . . . . . . . . . . . 11 69 5.1. Authentication Protocol Flow . . . . . . . . . . . . . . 11 70 5.2. AuCPace . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 14 72 6.1. CPACE-X25519-ELLIGATOR2_SHA512-SHA512 . . . . . . . . . . 15 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 78 10.2. Informative References . . . . . . . . . . . . . . . . . 21 79 Appendix A. AuCPace25519 Test Vectors . . . . . . . . . . . . . 21 80 A.1. Inverse X25519 test vectors . . . . . . . . . . . . . . . 21 81 A.2. Strong AuCPace25519 salt test vectors . . . . . . . . . . 22 82 A.3. Test vectors for AuCPace password verifier . . . . . . . 23 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 85 1. Introduction 87 This document describes AuCPace which is an augmented password- 88 authenticated key-establishment (PAKE) protocol for two parties. 89 Both sides the client B and the server A establish a high-entropy 90 session key SK, based on a secret (password) which may be of low 91 entropy for the client B and a password-verifier stored on the 92 server. The protocol is designed such that disclosing the secret to 93 offline dictionary attacks is prevented. Upon server compromise 94 (stealing A's database), the adversary must first succeed with a 95 dictionary search for the clear-text password before being able to 96 impersonate the client. 98 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 100 The protocol was tailored for constrained server devices. 101 Specifically, the computationally complex password hash operation is 102 refered to the clients. AuCPace is also designed for enabling a 103 smooth migration of legacy user credential databases. 105 AuCPace is designed to be compatible with any group of both prime- 106 and non-prime order and comes with a security proof providing 107 composability guarantees. AuCPace uses CPace as a building block 108 which is described in a separate internet draft document. 110 2. Requirements Notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 3. Definitions for AuCPace 120 3.1. Setup 122 Let C be a group in which there exists a subgroup of prime order p 123 where the computational Diffie-Hellman (CDH) problem is hard. C has 124 order p*c where p is a large prime; c will be called the cofactor. 125 Let I be the unit element in C, e.g., the point at infinity in if C 126 is an elliptic curve group. We denote the operations in the group 127 using addition and multiplication operators, e.g. P + (P + P) = P + 128 2 * P = 3 * P. We refer to a sequence of n additions of an element 129 in P as scalar multiplication by n. With B we denote a generator of 130 the prime-order subgroup in C that we call the base point. 132 With F we denote a field that may be associated with C, e.g. the 133 prime base field used for representing the coordinates of points on 134 an elliptic curve. 136 We assume that for any element P in C there is a representation 137 modulo negation, encode_group_element_mod_neg(P) as a byte string 138 such that for any Q in C with Q != P and Q != -P, 139 encode_group_element_mod_neg(P) != encode_group_element_mod_neg(Q). 140 It is recommended that encodings of the elements P and -P share the 141 same result string. Common choices would be a fixed (per-group) 142 length encoding of the x-coordinate of points on an elliptic curve C 143 or its twist C' in Weierstrass form, e.g. according to [IEEE1363] in 144 case of short Weierstrass form curves. For curves in Montgomery form 145 correspondingly the u-coordinate would be encoded, as specified, 146 e.g., by the encodeUCoordinate function from [RFC7748]. 148 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 150 With J we denote the group modulo negation associated to C. Note 151 that in J the scalar multiplication operation is well defined since 152 scalar_multiply(P,s) == -scalar_multiply(-P,s) while arbitrary 153 additions of group elements are no longer available. 155 With J' be denote a second group modulo negation that might share the 156 byte-string encoding function encode_group_element_mod_neg with J 157 such for a given byte string either an element in J or J' is encoded. 158 If the x-coordinate of an elliptic curve point group is used for the 159 encoding, J' would commonly be corresponding to the group of points 160 on the elliptic curve's quadratic twist. Correspondingly, with p' we 161 denote the largest prime factor of the order of J' and its cofactor 162 with c'. 164 Let scalar_cofactor_clearing(s) be a cofactor clearing function 165 taking an integer input argument and returning an integer as result. 166 For any s, scalar_cofactor_clearing(s) is REQUIRED to be of the form 167 c * s1. I.e. it MUST return a multiple of the cofactor. An example 168 of such a function may be the cofactor clearing and clamping 169 functions decodeScalar25519 and decodeScalar448 as used in the X25519 170 and X448 protocols definitions of [RFC7748]. In case of prime-order 171 groups with c == 1, it is RECOMMENDED to use the identity function 172 with scalar_cofactor_clearing(s) = s. 174 Let scalar_mult_cc(P,s) be a joint "scalar multiplication and 175 cofactor clearing" function of an integer s and an string-encoded 176 value P, where P could represent an element either on J or J'. If P 177 is an element in J or J', the scalar_mult_cc function returns a 178 string encoding of an element in J or J' respectively, such that the 179 result of scalar_mult_cc(P,s) encodes (scalar_cofactor_clearing(s) * 180 P). 182 Let si = invert_scalar_mult_cc(P,s) be a function such that for any 183 point Z in the prime-order subgroup of J, 184 invert_scalar_mult_cc(scalar_mult_cc(Q,s),s) == Q. A typical 185 implemention will involve calculating the inverse in the prime field 186 mod p on the scalar generated by scalar_cofactor_clearing(s). 188 Let scalar_mult_ccv(P,s) be a "scalar multiplication cofactor 189 clearing and verify" function of an integer s and an encoding of a 190 group element P. Unlike scalar_mult_cc, scalar_mult_ccv additionally 191 carries out a verification that checks that the computational Diffie- 192 Hellman problem (CDH) is hard in the subgroup (in J or J') generated 193 by the encoded element SP = scalar_mult_cc(P,s). In case that the 194 verification fails (SP might be of low order or on the wrong curve), 195 scalar_mult_ccv is REQUIRED to return the encoding of the identity 196 element I. Otherwise scalar_mult_ccv(P,S) is REQUIRED to return the 197 result of scalar_mult_cc(P,s). A common choice for scalar_mult_ccv 199 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 201 for Montgomery curves with twist security would be the X25519 and 202 X448 Diffie-Hellman functions as specified in [RFC7748]. For curves 203 in short Weierstrass form, scalar_mult_ccv could be implemented by 204 the combination of a point verification of the input point with a 205 scalar multiplication. Here scalar_mult_ccv SHALL return the 206 encoding of the neutral element I if the input point P was not on the 207 curve C. 209 Let P=map_to_group_mod_neg(r) be a mapping operation that maps a 210 string r to an encoding of an element P in J. Common choices would 211 be the combination of map_to_base and map_to_curve methods as defined 212 in the hash2curve draft [HASH2CURVE]. Note that we don't require and 213 RECOMMEND cofactor clearing here since this complexity is already 214 included in the definition of the scalar multiplication operation 215 calar_mult_cc above. Additionally requiring cofactor clearing also 216 in map_to_group_mod_neg() would result in efficiency loss. 218 || denotes concatenation of strings. We also let len(S) denote the 219 length of a string in bytes. Finally, let nil represent an empty 220 string, i.e., len(nil) = 0. 222 [f,g,h] denotes alternatives where exactly one of the comma-separated 223 options is to be chosen. 225 Let H(m) be a hash function from arbitrary strings m to bit strings 226 of a fixed length. Common choices for H are SHA256 or SHA512 227 [RFC6234]. H is assumed to segment messages m into blocks m_i of 228 byte length H_block. E.g. the blocks used in SHA512 have a size of 229 128 bytes. 231 Let strip_sign_information(P) be function that takes a string 232 encoding of an element P in J and strips any information regarding 233 the sign of P, such that strip_sign_information(P) = 234 strip_sign_information(-P). For short Weierstrass (Montgomery) 235 curves this function will return a string encoding the x-coordinate. 236 The purpose of defining this function is for allowing for 237 x-coordinate only scalar multiplication algorithms. The sign is to 238 be stripped before generating the intermediate session key ISK. 240 With ISK we denote the intermediate session key output string 241 provided by CPace that is generated by a hash operation on the 242 Diffie-Hellman result. 244 MAC(msg,key) is a message authentication code. A common examples 245 would be HMAC_SHA512, a block cipher based MAC or a hash-function 246 based tag. 248 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 250 KDF(Q) is a key-derivation function that takes a string and derives 251 key of length L. Common choices for KDF are HMAC_SHA512. 253 With DSI we denote domain-separation identifier strings that may be 254 prepended to the inputs of Hash and KDF functions. 256 Let IHF(salt, username, pw, sigma) be an iterated hash function that 257 takes a salt value, a user name and a password as input. IHF is 258 designed to slow down brute-force attackers as controlled by a 259 workload parameter set sigma. State of the art iterated hash 260 functions are designed for requiring a large amount of memory for its 261 operation and will be referred to as memory-hard hash functions 262 (MHF). Scrypt [RFC7914] or Argon2 are common examples of a MHF 263 primitive. 265 With PRS we denote a string that is a required input of the CPace 266 subprotocol and generated by the AuCPace protocol. 268 Let A and B be two parties. A and B may also have digital 269 representations of the parties' identities such as Media Access 270 Control addresses or other names (hostnames, usernames, etc). We 271 denote the parties' representation and the parties themselves both by 272 using the identifiers A and B. 274 With CI we denote a string that is a required input of the CPace 275 subprotocol. CI is generated together with PRS by the AuCPace 276 augmentation layer. CI SHALL be formed by the concatenation of the 277 identifiers A and B and an associated data string AD, CI = A || B || 278 AD; 280 With uad we denote an optional string that is specifying user- 281 associated data in a password file entry, such as authorization 282 rights or permissions or account expiration dates. Specification of 283 this string is outside of the scope of the AuCPace protocol. 285 Let sid be a session id byte string chosen for each protocol session 286 before protocol execution; The length len(sid) SHOULD be larger or 287 equal to 16 bytes. 289 4. Access to server-side password verifiers databases 291 AuCPace is an asymmetric PAKE protocol. I.e. while one party, the 292 client B, is in possession of a clear-text password pw, the other 293 party, the server A, is not given access to the cleartext password 294 but only to a password verifier. The way how such a password 295 verifier is maintained by a server party is essential for the AuCPace 296 protocol construction. 298 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 300 4.1. User credential database and password verifier types 302 With respect to the use of user credantial databases, AuCPace is 303 flexible and supports three different database types. 305 Firstly, the conventional approach as used for logins without a PAKE 306 protocol is supported (as used e.g. for the password over https:/ 307 approach). Here the server stores a tuple of four elements in his 308 password database file, (username, uad, salt, w) with w = 309 IHF(username,pw,salt)). With uad, we denote user-accociated data 310 such as permissions. The salt value is a nonce used for the IHF 311 function. Upon a login request, the user transmits the username and 312 the clear-text password pw to the server. The server looks up the 313 database, retrieves the salt value, calculates the IHF function with 314 the given inputs and compares the result with the registered password 315 verifier w. We refer to this setting as "legacy password verifier 316 database" (LPVD) setting. 318 Secondly, AuCPace supports an AuCPace password verifier database 319 setting (APVD) setting. Here the database is already adapted for use 320 in conjunction with AuCPace. This setting differs from LPVD by the 321 fact that instead of the direct output of the IHF, w = 322 IHF(username,pw,salt), an AuCPace password verifier W is maintained 323 in the database. W is calculated from the legacy-style value w by W 324 = scalar_mult_cc(B,w). It is possible to calculate W from a LPVD 325 entry on the fly and without knowledge of the clear-text password 326 upon a remote login request. It is also easily possible to migrate 327 the format of a LPVD database to an APVD database by calling the 328 scalar multiplication function for each entry. 330 Thirdly, AuCPace supports the *strong* AuCPace password verifier 331 database setting (sAPVD) setting, which differs from APVD and LPVD by 332 the fact that the salt entry in the database, as used for the IHF, is 333 replaced by a salt-derivation parameter q, as will be detailed below. 334 With this strong AuCPace verifier type, the AuCPace protocol provides 335 the additional security guarantee of pre-computation attack 336 resistance. Note that migrating LPVD or APVD database records to 337 sAPVD entries is *not* possible, because calculating the strong sAPVD 338 password verifiers requires the clear-text passwords. 340 4.2. Encoding of passwords and user names 342 For AuCPace usernames and passwords are encoded as strings according 343 to the definitions of [RFC8265], i.e. case-preserving unicode 344 encoding SHALL be employed. 346 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 348 4.3. AuCPace database interface for retrieving password verifiers 350 In the course of the authentication protocoll, the AuCPace server 351 implementation will need to interface to an user credential database 352 for retrieving password verifiers. 354 Database lookup is implemented by use of string-encoded user names. 355 AuCPace needs an interface equivalent to a function pvr = 356 lookup_pw_verifier_record(username). I.e. a lookup returns a 357 password verfier record pvr, based on a username string. It is 358 REQUIRED that for the purpose of pvr record lookup in databases and 359 for the database contents, the "case preservation" according to 360 [RFC8265] is employed, both for the string encoding of the username 361 and the password. 363 The content in the pvr records will depend on the application 364 scenarios, LPVD, APVD and sAPVD as defined above. Password verifier 365 records pvr as returned from the database are REQUIRED to be composed 366 of the following components. 368 A password verifier from either one of the following two options 369 (w or W). 371 LPVD case: A binary encoding of the actual password verifier 372 that has been calculated as a function of the username, the 373 password, a salt value by use of an iterated hash function pv = 374 w = IHF(username,password,salt, sigma). 376 APVD and sAPVD cases: An encoding of an element in J, W = 377 scalarmult_cc(B,w), which has been calculated by a scalar 378 multiplication using the base point B. The secret scalar, w, 379 has been calculated by an iterated hash function just as in the 380 case above, w = IHF(username,password,salt, sigma). 382 sigma, a binary encoding specifying the type and the workload 383 parametrization of the iterated hash function IHF that has been 384 used for calculating w or W. 386 A salt derivation entry which is either 388 LPVD and APVD cases: a binary string encoding of the salt value 389 itself or, 391 sAPVD case: an encoding of a secret scalar q for a group scalar 392 multiplication such that the salt value used for calculating w 393 or W could be calculated from the tuple salt = 394 strong_AuCPace_salt_derivation(q,username,password). 396 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 398 In case that a database lookup on a server yields a legacy password 399 database record (LPVD case that includes an entry w), the AuCPace 400 implementation SHALL convert this record into a AuCPace database 401 record (APVD case) by replacing w with W=scalarmult_cc(B,w). 403 The AuCPace application protocol, thus, only needs to consider the 404 two different APVD and sAPVD scenarios. In case of the APVD 405 scenario, the salt value used for the IHF execution is returned by 406 the database lookup, while in the sAPVD case the salt value is 407 replaced by the secret scalar. 409 4.4. Derivation of the salt value for strong AuCPace 411 For strong AuCPace the salt value used for the IHF is not explicitly 412 included in the password verifier record pvr. Instead only the 413 parameter q is stored. q serves for deriving the salt value. In 414 order to determine the salt value, strong AuCPace uses a function 415 salt = strong_AuCPace_salt_derivation(q,username,password). This 416 function implements the following sequence of operations. 418 First Z, an element in J, is calculated by use of a Z = 419 map_username_password_to_J(username || password). function, e.g. 420 by use of a hash function such as SHA512 and a mapping such as 421 Elligator2. 423 The salt value is then determined by applying the scalar q and the 424 group element Z to the scalar multiplication function, salt = 425 strip_sign_information(scalarmult_cc(Z,q)). 427 Deriving the salt value, thus, requires access to all of, username, 428 clear text password and secret key q. If the database is stolen, an 429 adversary is not able to derive the salt value without having access 430 to the clear-text password. 432 Note that the method above which derives the salt directly from Z and 433 q will typically only be used when creating a new password database 434 entry. The AuCPace protocol uses a secret scalar r for, masking the 435 value of Z. The approach exploits the relation q * Z == ((Z * r) * 436 q) * (1/r). More explicitly the sequence is as follows: 438 The client, B, having access to the username and the clear-text 439 password calculates Z. It aims at deriving the salt value. 441 B samples a fresh scalar r and calculates U = scalarmult_cc(Z,r). 442 B sends U to A. 444 A fetches q from the database and calculates UQ = 445 scalarmult_cc(U,q). A sends UQ back to A. 447 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 449 B retrieves the salt by inverting the blinding with the scalar r 450 using salt = 451 strip_sign_information(invert_cofactor_cleared_scalar(UQ,r)). 453 4.5. Specification of the workload parameter sigma 455 AuCPace does not require the use of a specific iterated hash function 456 IHF. Still it is strongly RECOMMENDED to use AuCPace in conjunction 457 with state-of-the art memory-hard hash functions MHF with a secure 458 workload parametrization. The workload parameter sigma shall encode 459 all of the following. 461 The algorithm family, such as Argon2i, scrypt or PBKDF2-HMAC- 462 SHA256. 464 The workload parameter specification, e.g. the iteration count for 465 PBKDF2 or the parameters N,r and p of the scrypt algorithm. 467 4.6. Result of the database parameter lookup 469 Summing up, the lookup process for user credential data for AuCPace 470 SHALL provide all of the following information in the course of the 471 session establishment protocol. 473 The iterated hash function specification sigma. 475 A salt-derivation parameter and its type. The salt derivationn 476 parameter is either a salt scalar q or the salt value itself. 477 Correspondingly the type of the salt-derivation parameter is 478 either "AuCPace" or "strong AuCPace". 480 An AuCPace password verifier W = 481 scalarmult_cc(B,IHF(pwd,username,salt)). 483 For handling the case of failed lookups, if a given user name does 484 not have an entry, the database shall define a default parameter set 485 sigma_default and a default salt-derivation parameter for password 486 hashing. Moreover and a secret string database_seed shall be chosen 487 specifically for each distinct server A. In case of failed lookups 488 the following procedure SHALL be used. A random value w shall be 489 sampled. The password verifier W shall be calculated as W = 490 map_to_group(w). The parameters q or salt shall be respectively 491 calculated as [q,salt] = H(name || database_seed). 493 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 495 5. Authentication session 497 5.1. Authentication Protocol Flow 499 AuCPace is a protocol run between two parties, A and B, for 500 establishing a shared secret key with explicit mutual authentication. 501 AuCPace is implemented by four messages as indicated by the numbers 502 in the figure below. The roles of the two parties are different. 503 Party B, the client, is provided a user name and a password as input. 504 Party A, the server, has access to a user credentials database that 505 stores password verifiers. Both parties share a channel identifier 506 string CI characterizing the communication channel (e.g. information 507 on IP addresses and port numbers of both sides). 509 The channel identifier, CI, SHOULD include an encoding of the 510 identities of both parties A and B if these are available prior to 511 starting the communication protocol. 513 Both sides also share a common subsession ID (ssid) string. ssid 514 could be pre-established by a higher-level protocol invocing AuCPace. 515 If no such ssid is available from a higher-level protocol, a suitable 516 approach is including ssid in the first message from B to A as shown 517 in the figure below. 519 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 521 A B 522 | ssid | 523 |<1----------------| (sample ssid) 525 ---------- AuCPace protocol ----------- 526 In: ssid | | In: name, passw. 527 | name,U | ssid 528 |<1----------------| 529 DB lookup | | 530 | sid2 | 531 |[UQ,salt],X,sigma | 532 det. CI,PRS |----------------2>| det. CI,PRS 533 sid_cpace | | sid_cpace 534 --------------------------------------- 535 In: CI, PRS, || (CPace substep) || In: CI, PRS, 536 sid_cpace || || sid_cpace 537 || Ya || 538 ||----------------2>|| 539 || Yb || 540 Output: ISK ||<3----------------|| Output: ISK 541 --------------------------------------- 542 expl.auth. | Tb | expl.auth. 543 |<3----------------| 544 | Ta | 545 |----------------4>| 546 Output: SK | | Output: SK 548 5.2. AuCPace 550 Both parties start with agreed values on the ssid string. The server 551 side has access to a user credentials database. The client side 552 holds a user name, a clear-text password to be used for the 553 authentication session. Both sides share an encoding CI specifying 554 the communication channel, such as IP addresses and port numbers. 556 To begin, B calculates an element Z = 557 map_username_password_to_J(username || password) in J. 559 B then picks r randomly and uniformly according to the requirements 560 for group J scalars and calculates U = scalar_mult_cc(Z,r). 562 B then sends (name,U) to A. 564 A then queries its database for the user name and retrieves the 565 information as specified in section Section 4.6 , i.e. the set 566 (W,sigma,salt-derivation parameter [q,salt]). (Note that according 568 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 570 to the specification of the database lookup, such a set is provided, 571 even if there is no database entry for the given user name.) 573 A picks x randomly and uniformly according to the requirements for 574 group J scalaras and calculates X = scalarmult_cc(B,x) and WX = 575 scalarmult_ccv(W,x). A MUST abort if WX is the neutral element (this 576 indicates an error in the database contents). A then calculates 577 sid_cpace = (ssid || X). 579 A strips the sign information from WX to obtain WXs. A picks ya 580 randomly and uniformly. A then calculates G = 581 map_to_group_mod_neg(DSI1 || WXs || ZPAD || sid_cpace || CI) and Ya = 582 scalar_mult_cc(G,ya). I.e. WXs takes over the role of CPace's PRS 583 string. 585 The following operations will variate, depending on the type of salt- 586 derivation entry in the database. 588 If the salt derivation parameter is for strong AuCPace, A 589 calculates UQ = scalarmult_cc(U,q) and sends (UQ,X,sigma,Ya) to B. 590 B then calculates salt as salt = 591 strip_sign_information(inverse_scalarmult_cc(UQ,r)). 593 If the salt derivation parameter is for AuCPace, A sends 594 (salt,X,sigma,Ya) to B. 596 B then calculates w = IHF(sigma,username,password, salt) and XW = 597 scalarmult_ccv(X,w). B MUST abort, if XW is the neutral element I. 599 B strips the sign information from XW to obtain XWs. B picks yb 600 randomly and uniformly. B calculates sid_cpace=(ssid || X). B then 601 calculates G = map_to_group_mod_neg(DSI1 || XWs || ZPAD || 602 sid_cpace || CI) and Yb = scalar_mult_cc(G,yb). B then calculates K 603 = scalar_mult_ccv(Ya,yb). B MUST abort if K is the encoding of the 604 neutral element I. Otherwise B sends Yb to A and proceeds as 605 follows. B strips the sign information from K, Ya and Yb to obtain 606 the strings Ks, Yas and Ybs by using the strip_sign_information() 607 function. B calculates ISK = H(DSI2 || sid_cpace || Ks || Yas || 608 Ybs). 610 B calculates Tb = MAC(ISK,DSI4) and Ta_v = MAC(ISK,DSI3) and sends 611 (Yb,Tb) to A. 613 Upon reception of Yb, A calculates K = scalar_mult_ccv(Yb,ya). A 614 MUST abort if K is the neutral element I. If K is different from I, 615 A strips the sign information from K, Ya and Yb and calculates ISK = 616 H(DSI2 || sid_cpace || Ks || Yas || Ybs). 618 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 620 A calculates Tb_v = MAC(ISK,DSI4) and Ta = MAC(ISK,DSI3). If the 621 received authentication tag Tb did not match the verification value 622 Tb_v A MUST abort. Otherwise A sends Ta to B and returns the session 623 key SK = KDF(DSI5 || ISK || ssid). 625 When B receives T_a it compares this to the verification value Ta_v. 626 B MUST abort if Ta != Ta_v. Otherwise B returns the session key SK = 627 KDF(DSI5 || ISK || ssid). 629 Upon completion of this protocol, the session key SK returned by A 630 and B will be identical by both parties if and only if the supplied 631 input parameters ssid and CI match on both sides and the password 632 verifier in the server database for the user was calculated from the 633 clear-text password used by B. 635 6. Ciphersuites 637 This section documents AuCPace ciphersuite configurations. A 638 ciphersuite is REQUIRED to specify all of, 640 o a group modulo negation J with an associated 641 encode_group_element_mod_neg function 643 o scalar_mult_cc(P,s) and scalar_mult_ccv(P,s) functions operating 644 on encodings of elements P in J 646 o a mapping function map_to_group_mod_neg(r) converting byte strings 647 r into elements in J 649 o a strip_sign_information(Q) function operating on string 650 representations of elements Q 652 o a hash function H for generating the intermediate session key ISK 654 o A message authentication code MAC for authentication tag 655 generation. 657 o A key derivation function KDF for generating the final session key 658 SK 660 o and domain separation strings DSI1, DSI2, DSI3, DSI4, DSI5 662 Currently, detailed specifications are available for CPACE- 663 X25519-ELLIGATOR2_SHA512-SHA512. 665 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 667 +--------+----------------------+------------------+ 668 | J | map_to_group_mod_neg | KDF | 669 +--------+----------------------+------------------+ 670 | X25519 | ELLIGATOR2_SHA512 | SHA512 [RFC6234] | 671 +--------+----------------------+------------------+ 673 Table 1: CPace Ciphersuites 675 6.1. CPACE-X25519-ELLIGATOR2_SHA512-SHA512 677 This cipher suite targets particularly constrained targets and 678 implements specific optimizations. It uses the group of points on 679 the Montgomery curve Curve25519 for constructing J. The base field F 680 is the prime field built upon the prime p = 2^255 - 19. The Diffie- 681 Hellmann protocol X25519 and the group are specified in [RFC7748]. 682 The encode_group_element_mod_neg(P) is implemented by the 683 encodeUCoordinate(P) function defined in [RFC7748]. The neutral 684 element I is encoded as a 32 byte zero-filled string. 686 The domain separation strings are defined as DSI1 = "CPace25519-1", 687 DSI2 = "CPace25519-2", DSI3 = "AuCPace25-Ta", DSI4 = "AuCPace25-Tb", 688 DSI5 = "AuCPace25519". (ASCII encoding without ANSI-C style trailing 689 zeros). 691 Both, scalar_mult_cc and scalar_mult_ccv, are implemented by the 692 X25519 function specified in [RFC7748]. 694 The secret scalars ya and yb used for X25519 shall be sampled as 695 uniformly distributed 32 byte strings. 697 The QI = inverse_scalarmult_cc(Q,s) function is implemented as 698 follows. 700 cs = scalar_cofactor_clearing(s) 702 csi = 1 / (8 * cs) % p. 704 QI = UNCLAMPED_X25519(Q, 8 * si). 706 Where the unclamped X25519 function ommits the setting of bit #254 in 707 the scalar from [RFC7748]. 709 The map_to_group_mod_neg function for the CPace substep is 710 implemented as follows. First the byte length of the ZPAD zero- 711 padding string is determined such that len(ZPAD) = max(0, 712 H_block_SHA512 - len(DSI1 || PRS)), with H_block_SHA512 = 128 bytes. 713 Then a byte string u is calculated by use of u = 714 SHA512(DSI1||PRS||ZPAD||sid||CI). The resulting string is 716 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 718 interpreted as 512-bit integer in little-endian format according to 719 the definition of decodeLittleEndian() from [RFC7748]. The resulting 720 integer is then reduced to the base field as input to the Elligator2 721 map specified in [HASH2CURVE] to yield the secret generator G = 722 Elligator2(u). 724 The map_to_group_mod_neg function used for the strong AuCPace substep 725 for calculating the field element Z is implemented accordingly. 726 First the byte length of the ZPAD zero-padding string is determined 727 such that len(ZPAD) = max(0, H_block_SHA512 - len(DSI5 || password)), 728 with H_block_SHA512 = 128 bytes. Then a byte string u is calculated 729 by use of u = SHA512(DSI5||password||ZPAD||username). The resulting 730 string is interpreted as 512-bit integer in little-endian format 731 according to the definition of decodeLittleEndian() from [RFC7748]. 732 The resulting integer is then reduced to the base field as input to 733 the Elligator2 map specified in [HASH2CURVE] to yield the secret 734 generator Z = Elligator2(u). 736 AuCPace25519 calculates an intermediate session key ISK of 64 bytes 737 length by a single invocation of SHA512(DSI2||ISK). Since the 738 encoding does not incorporate the sign from the very beginning Qs = 739 strip_sign_information(Q) == Q for this cipher suite. 741 AuCPace25519 calculates authentication tags and session key SK from 742 ISK of 64 bytes length by a single invocation of Ta = 743 SHA512(DSI3||ISK), Tb = SHA512(DSI4||ISK) and SK = SHA512(DSI5||ISK). 745 The following sage code could be used as reference implementation for 746 the mapping and key derivation functions. 748 750 def littleEndianStringToInteger(k): 751 bytes = [ord(b) for b in k] 752 return sum((bytes[i] << (8 * i)) for i in range(len(bytes))) 754 def map_to_group_mod_neg_CPace25519(sid, PRS, CI): 755 m = hashlib.sha512() 756 p = 2^255 - 19 758 H_block_SHA512 = 128 759 DSI1 = b"CPace25519-1" 760 ZPAD_len = max(0,H_block_SHA512 - len(CI) - len(PRS)) 761 ZPAD = ZPAD_len * "\0" 763 m.update(DSI1) 764 m.update(PRS) 765 m.update(ZPAD) 767 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 769 m.update(sid) 770 m.update(CI) 771 u = littleEndianStringToInteger(m.digest()) 772 return map_to_curve_elligator2_curve25519(u % p) 774 def map_to_group_mod_neg_StrongAuCPace25519(username, password): 775 # Map username and password to field element Z 776 DSI = b"AuCPace25519" 777 F = GF(2^255 - 19) 778 m = hashlib.sha512() 779 H_block_SHA512 = 128 780 ZPAD_len = max(0,H_block_SHA512 - len(DSI) - len(password)) 781 ZPAD = ZPAD_len * "\0" 782 m.update(DSI) 783 m.update(password) 784 m.update(ZPAD) 785 m.update(username) 786 u = littleEndianStringToInteger(m.digest()) 787 u = F(u) 788 Z = map_to_curve_elligator2_curve25519(u) 789 return Z 791 def Inverse_X25519(u_string,scalar_string): 792 OrderSubgroup = 2^252 + 27742317777372353535851937790883648493 793 SF = GF(OrderSubgroup) 794 coFactor = SF(8) 795 scalar = clampScalar25519(scalar_string) 796 inverse_scalar = 1 / (SF(scalar) * coFactor) 797 inverse_scalar_shifted = Integer(inverse_scalar) * 8 798 return X25519(u_string,inverse_scalar_shifted,withClamping=0) 800 def generate_ISK_CPace25519(sid,K,Ya,Yb): 801 m = hashlib.sha512(b"CPace25519-2") 802 m.update(sid) 803 m.update(K) 804 m.update(Ya) 805 m.update(Yb) 806 return m.digest() 808 def MAC_SK_AuCPace25519(ISK): 809 DSI3 = b"AuCPace25-Ta" 810 DSI4 = b"AuCPace25-Tb" 811 DSI5 = b"AuCPace25519" 812 m = hashlib.sha512(DSI3) 813 m.update(ISK) 814 Ta = m.digest() 815 Ta = Ta[:16] 817 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 819 m = hashlib.sha512(DSI4) 820 m.update(ISK) 821 Tb = m.digest() 822 Tb = Tb[:16] 824 m = hashlib.sha512(DSI5) 825 m.update(ISK) 826 SK = m.digest() 828 return (Ta,Tb,SK) 830 832 Due to its use in Ed25519 [RFC8032], SHA512 is considered to be the 833 natural hash choice for Curve25519. The 512 bit output of SHA512 834 moreover allows for removing any statistical bias stemming from the 835 non-canonical base field representations, such that the overhead of 836 the HKDF_extract/HKDF_expand sequences from [HASH2CURVE] are 837 considered not necessary (in line with the assessments regarding 838 Curve25519 in [HASH2CURVE]). 840 7. Security Considerations 842 A security proof covering AuCPace is found in [HL18]. 844 Elements received from a peer MUST be checked by a proper 845 implementation of the scalar_mult_ccv method. Failure to properly 846 validate group elements can lead to attacks. The Curve25519-based 847 cipher suite employs the twist security feature of the curve for 848 point validation. As such, it is mandatory to check that all low- 849 order points on both the curve and the twist are mapped on the 850 neutral element by the X25519 function. Corresponding test vectors 851 are provided in the appendix. 853 The choices of random numbers MUST be uniform. Randomly generated 854 values (e.g., ya, r, q and yb) MUST NOT be reused. 856 User credential database lookups for AuCPace might not be executed in 857 non-constant time. In this case, AuCPace does not provide full 858 confidentiality with respect to hiding the presence or abscence of a 859 given user's entry in the database. The fact that in case of 860 abscence of a record random values are provided instead should be 861 considered only a mitigation regarding user-enumeration attacks. 863 If AuCPace is used as a building block of higher-level protocols, it 864 is RECOMMENDED that ssid is generated by the higher-level protocol 865 and passed to AuCPace. It is RECOMMENDED that ssid, is generated by 866 sampling ephemeral random strings. 868 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 870 AuCPace generates the session key SK by a hash function operation on 871 the intermediate session key ISK. If SK is possibly to be used for 872 many different sub-protocols and purposes, such as e.g. in TLS1.3, it 873 is RECOMMENDED to apply SK to a stronger KDF function, such as HKDF 874 from [RFC5869]. 876 In case that side-channel attacks are to be considered practical for 877 a given application, it is RECOMMENDED to focus side-channel 878 protections such as masking and redundant execution (faults) on the 879 process of calculating the secret generator G. The most critical 880 aspect to consider is the processing of the first block of the hash 881 that includes the PRS string. The CPace protocol construction 882 considers the fact that side-channel protections of hash functions 883 might be particularly resource hungry. For this reason, AuCPace aims 884 at minimizing the number of hash functions invocations in the 885 specified mapping method. 887 AuCPace is designed also for compatibility with legacy-style user- 888 credential databases which directly store the output of iterated hash 889 functions w = IHF(salt, username, password). If AuCPace is used in 890 this configuration, AuCPace provides only the security guarantees of 891 a balanced PAKE. I.e. in this case, user impersonation attacks 892 become feasible if the user credential database is stolen. It is 893 RECOMMENDED to migrate legacy-style databases to an AuCPace format, 894 by replacing w with W = scalarmult_cc(B,w). 896 It is RECOMMENDED to use password verifiers for "strong AuCPace" on 897 such a migrated database upon user password changes in order to 898 obtain pre-computation attack resistance. 900 AuCPace is proven secure under the hardness of the computational 901 Diffie-Hellmann (CDH) and the computational Double-Diffie-Hellmann 902 assumptions in the group J. Still, even for the event that large- 903 scale quantum computers (LSQC) will become available, AuCPace forces 904 an active adversary to solve one CDH per password guess. Using the 905 wording suggested by Steve Tobtu on the CFRG mailing list, AuCPace is 906 "quantum-annoying". For the event that LSQC become ubiquitous, it is 907 suggested to consider the replacement of the group operations used in 908 AuCPace with a corresponding commutative group actions on isogenies, 909 such as suggested in [IsogenyPAKE]. The fact that CPace does not 910 require arbitrary group operations but only the operation set 911 available in a group modulo negation allows for commutative isogeny- 912 based group actions cryptography as a drop-in replacement. 914 Strong AuCPace is pre-computation attack resistant under the CDH and 915 One-More-DH assumption setp. While the rest of the AuCPace protocol 916 is quantum-annoying, solving a single discrete logarithm problem will 917 reveal the salt-derivation parameter q to the adversary and allow him 919 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 921 for pre-computing a rainbow table for a given user name. In order to 922 provide resistance with respect to LSQC-based attacks, a post-quantum 923 instance of an olibvious pseudo-random function (OPRF) would have to 924 be used as replacement of the Diffie-Hellman OPRF construction as 925 used by strong AuCPace. 927 8. IANA Considerations 929 No IANA action is required. 931 9. Acknowledgments 933 Thanks to the members of the CFRG for comments and advice. 935 10. References 937 10.1. Normative References 939 [HASH2CURVE] 940 Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and 941 C. Wood, "draft-irtf-cfrg-hash-to-curve-05", 2019. 943 IRTF draft standard 945 [IEEE1363] 946 IEEE, ""Standard Specifications for Public Key 947 Cryptography", IEEE 1363", 2000. 949 IEEE 1363 951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 952 Requirement Levels", BCP 14, RFC 2119, 953 DOI 10.17487/RFC2119, March 1997, 954 . 956 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 957 Key Derivation Function (HKDF)", RFC 5869, 958 DOI 10.17487/RFC5869, May 2010, 959 . 961 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 962 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 963 DOI 10.17487/RFC6234, May 2011, 964 . 966 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 967 for Security", RFC 7748, DOI 10.17487/RFC7748, January 968 2016, . 970 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 972 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 973 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 974 August 2016, . 976 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 977 Signature Algorithm (EdDSA)", RFC 8032, 978 DOI 10.17487/RFC8032, January 2017, 979 . 981 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 982 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 983 May 2017, . 985 10.2. Informative References 987 [HL18] Haase, B. and B. Labrique, "AuCPace. PAKE protocol 988 tailored for the use in the internet of things.", Feb 989 2018. 991 eprint.iacr.org/2018/286 993 [IsogenyPAKE] 994 Taraskin, O., Soukharev, V., Jao, D., and J. LeGrow, "An 995 Isogeny-Based Password-Authenticated Key Establishment 996 Protocol.", Sep. 2018. 998 eprint.iacr.org/2018/886 1000 [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, 1001 Enforcement, and Comparison of Internationalized Strings 1002 Representing Usernames and Passwords", RFC 8265, 1003 DOI 10.17487/RFC8265, October 2017, 1004 . 1006 Appendix A. AuCPace25519 Test Vectors 1008 A.1. Inverse X25519 test vectors 1009 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 1011 ######################## /inverse X25519 ########################## 1013 Z : 1014 0x5d7189be6192ffccdb80902ac26c5d38592822a761c7268007200a232a4cd841 1015 r (random scalar input for X25519): 1016 0xe8a70b556490ecdbd52c2927464d4eff557807496af234fc496c9f4221bd4423 1017 U = X25519(Z,r): 1018 0x3e6377b3410a60d0ca65190963ad6dce3aeae178aafad369dc2a59c59acc3ceb 1019 IU = inverse_X25519(U) 1020 0x5d7189be6192ffccdb80902ac26c5d38592822a761c7268007200a232a4cd841 1022 Z : 1023 0x73583bc520f4b9e1245e29b92e6b12dc1c8bc0d9b018a1e2626875db2774974 1024 r (random scalar input for X25519): 1025 0xe22cb510bd45fc6cbcb929353777925d152c2a9a5b924715d7480aad8b64d447 1026 U = X25519(Z,r): 1027 0x545040a9ac1cc13a627dddc0ab4ef0b9128d54476aa98727bd45a86ea2d6de24 1028 IU = inverse_X25519(U) 1029 0x73583bc520f4b9e1245e29b92e6b12dc1c8bc0d9b018a1e2626875db2774974 1031 ######################## inverse X25519/ ########################## 1033 A.2. Strong AuCPace25519 salt test vectors 1034 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 1036 ############ /salt derivation for strong AuCPace ################## 1038 DSI5 = 417543506163653235353139 string ('AuCPace25519') of len(12) 1039 pw = 70617373776f7264 ('password') string of len(8) 1040 ZPAD = 108 zero bytes 1041 name = 757365726e616d65 ('username') string of len(8) 1042 u = SHA512(DSI||password||ZPAD||username) as 512 bit int: 1043 0xfec497749d249426e4895e05d0bb4f565aa4423f33d19e6b20aa3837eb77d16e 1044 <<256 1045 + 0xb8f5b1b51c1557c088356d7ca09bd78f259f1d5f4041d466f4edd40f041a0bb3 1047 u as reduced base field element coordinate: 1048 0xa242d046f835586749962599c699e609a00f2c0f15f584dce322c5bf7e327be 1050 Z = Elligator2(u) as base field element coordinate: 1051 0x3c01681e4c6d4a43b527c789bcf6046b53ac14c516dfbbbb0f8916826b537f4b 1053 salt-derivation parameter q: 1054 0xf40546b4544bae5fcc564dc917407ee02300312c8fd558a0b37f48322277962e 1056 ZQ = X25519(Z,q): 1057 0x77412819cad958e14d4a4c09c129456b90733fd13f337ffed6c0a30f7c3a9a50 1059 Blinding scalar r: 1060 0x1698d57693a684a957ae0492bade0dfd6a261dfa2bb4a74c6b0b8b84acf082a8 1061 U = X25519(Z,r): 1062 0xaf2a058fbd974a6122f8316323060d808705701971666121477eba97386a977 1063 UQ = X25519(U,q): 1064 0x610270daff540b5b7adec057e0f8fa1bfe7687649d95f65560a77a2be70e6cb5 1065 ZQ = inverse_X25519(Z,r) 1066 0x77412819cad958e14d4a4c09c129456b90733fd13f337ffed6c0a30f7c3a9a50 1068 ############ salt derivation for strong AuCPace/ ################## 1070 A.3. Test vectors for AuCPace password verifier 1071 Internet-Draf(strong) AuCPace, an augmented composable PAKE January 2020 1073 ###################### /Password verifier ######################### 1074 Inputs: 1076 Password: 'password', length 8 1077 User Name: 'username', length 8 1079 Z for username, password: 1080 0x3c01681e4c6d4a43b527c789bcf6046b53ac14c516dfbbbb0f8916826b537f4b 1081 q: 1082 0xf40546b4544bae5fcc564dc917407ee02300312c8fd558a0b37f48322277962e 1084 Salt value salt = X25519(Z,q): 1085 0x77412819cad958e14d4a4c09c129456b90733fd13f337ffed6c0a30f7c3a9a50 1087 #################################################################### 1089 Concatenated input to scrypt as password parameter: 1090 'passwordusername', length 16 1092 Password hash w from scrypt with N=1<<15, r=8, p=1 1093 f2b54e7325a1a4fdc88a7899cfe68aee41ebda4145ba93480bc295c84a0832d8 1095 Password verifier W = X25519(w) 1096 0x12511fcfc70fe9c3a8e72b347d7de52927fc253b83edc8271a5e90ecdf958f57 1098 ###################### Password verifier/ ######################### 1100 Author's Address 1102 Bjoern Haase 1103 Endress + Hauser Liquid Analysis 1105 Email: bjoern.m.haase@web.de