idnits 2.17.1 draft-harkins-ipsecme-spsk-auth-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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 26, 2012) is 4408 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Harkins 3 Internet-Draft Aruba Networks 4 Intended status: Experimental March 26, 2012 5 Expires: September 27, 2012 7 Secure PSK Authentication for IKE 8 draft-harkins-ipsecme-spsk-auth-08 10 Abstract 12 This memo describes a secure pre-shared key authentication method for 13 IKE. It is resistant to dictionary attack and retains security even 14 when used with weak pre-shared keys. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 27, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Keyword Definitions . . . . . . . . . . . . . . . . . . . 3 52 2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Terms and Notation . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Discrete Logarithm Cryptography . . . . . . . . . . . . . . . 5 55 4.1. Elliptic Curve Cryptography (ECP) Groups . . . . . . . . . 5 56 4.2. Finite Field Cryptography (MODP) Groups . . . . . . . . . 7 57 5. Random Numbers . . . . . . . . . . . . . . . . . . . . . . . . 7 58 6. Using Passwords and Raw Keys For Authentication . . . . . . . 8 59 7. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 8. Secure PSK Authentication Message Exchange . . . . . . . . . . 9 61 8.1. Negotiation of Secure PSK Authentication . . . . . . . . . 10 62 8.2. Fixing the Secret Element, SKE . . . . . . . . . . . . . . 10 63 8.2.1. ECP Operation to Select SKE . . . . . . . . . . . . . 11 64 8.2.2. MODP Operation to Select SKE . . . . . . . . . . . . . 13 65 8.3. Encoding and Decoding of Group Elements and Scalars . . . 14 66 8.3.1. Encoding and Decoding of Scalars . . . . . . . . . . . 14 67 8.3.2. Encoding and Decoding of ECP Elements . . . . . . . . 15 68 8.3.3. Encoding and Decoding of MODP Elements . . . . . . . . 15 69 8.4. Message Generation and Processing . . . . . . . . . . . . 15 70 8.4.1. Generation of a Commit . . . . . . . . . . . . . . . . 15 71 8.4.2. Processing of a Commit . . . . . . . . . . . . . . . . 16 72 8.4.2.1. Validation of an ECP Element . . . . . . . . . . . 16 73 8.4.2.2. Validation of a MODP Element . . . . . . . . . . . 16 74 8.4.2.3. Commit Processing Steps . . . . . . . . . . . . . 16 75 8.4.3. Authentication of the Exchange . . . . . . . . . . . . 17 76 8.5. Payload Format . . . . . . . . . . . . . . . . . . . . . . 18 77 8.5.1. Commit Payload . . . . . . . . . . . . . . . . . . . . 18 78 8.6. IKEv2 Messaging . . . . . . . . . . . . . . . . . . . . . 18 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 84 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 1. Introduction 89 [RFC5996] allows for authentication of the IKE peers using a pre- 90 shared key. This exchange, though, is susceptible to dictionary 91 attack and is therefore insecure when used with weak pre-shared keys, 92 such as human-memorizable passwords. To address the security issue, 93 [RFC5996] recommends that the pre-shared key used for authentication 94 "contain as much unpredictability as the strongest key being 95 negotiated". That means any non-hexidecimal key would require over 96 100 characters to provide enough strength to generate a 128-bit key 97 suitable for AES. This is an unrealistic requirement because humans 98 have a hard time entering a string over 20 characters without error. 99 Consequently, pre-shared key authentication in [RFC5996] is used 100 insecurely today. 102 A pre-shared key authentication method built on top of a zero- 103 knowledge proof will provide resistance to dictionary attack and 104 still allow for security when used with weak pre-shared keys, such as 105 user-chosen passwords. Such an authentication method is described in 106 this memo. 108 Resistance to dictionary attack is achieved when an adversary gets 109 one, and only one, guess at the secret per active attack (see for 110 example, [BM92], [BMP00] and [BPR00]). Another way of putting this 111 is that any advantage the adversary can realize is through 112 interaction and not through computation. This is demonstrably 113 different than the technique from [RFC5996] of using a large, random 114 number as the pre-shared key. That can only make a dictionary attack 115 less likely to succeed, it does not prevent a dictionary attack. 116 And, as [RFC5996] notes, it is completely insecure when used with 117 weak keys like user-generated passwords. 119 1.1. Keyword Definitions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 2. Usage Scenarios 127 [RFC5996] describes usage scenarios for IKEv2. These are: 129 1. "Security Gateway to Security Gateway Tunnel": the endpoints of 130 the IKE (and IPsec) communication are network nodes that protect 131 traffic on behalf of connected networks. Protected traffic is 132 between devices on the respective protected networks. 134 2. "Endpoint-to-Endpoint Transport": the endpoints of the IKE (and 135 IPsec) communication are hosts according to [RFC4301]. Protected 136 traffic is between the two endpoints. 138 3. "Endpoint to Security Gateway Tunnel": one endpoint connects to a 139 protected network through a network node. The endpoints of the 140 IKE (and IPsec) communication are the endpoint and network node, 141 but the protected traffic is between the endpoint and another 142 device on the protected network behind the node. 144 The authentication and key exchange described in this memo is 145 suitable for all the usage scenarios described in [RFC5996]. In the 146 "Security Gateway to Security Gateway Tunnel" scenario and the 147 "Endpoint-to-Endpoint Transport" scenario it provides a secure method 148 of authentication without requiring a certificate. For the "Endpoint 149 to Security Gateway Tunnel" scenario it provides for secure username+ 150 password authentication that is popular in remote access VPN 151 situations. 153 3. Terms and Notation 155 The following terms and notation are used in this memo: 157 PSK 158 A shared, secret and potentially low-entropy word, phrase, code 159 or key used as a credential to mutually authenticate the peers. 161 a = prf(b, c) 162 The string "b" and "c" are given to a pseudo-random function to 163 produce a fixed-length output "a". 165 a | b 166 denotes concatenation of string "a" with string "b". 168 [a]b 169 indicates a string consisting of the single bit "a" repeated "b" 170 times. 172 len(a) 173 indicates the length in bits of the string "a". 175 LSB(a) 176 returns the least-significant bit of the bitstring "a". 178 element 179 one member of a finite cyclic group. 181 scalar 182 a quantity that can multiply an element. 184 The convention for this memo to represent an element in a finite 185 cyclic group is to use an upper-case letter or acronym, while a 186 scalar is indicated with a lower-case letter or acronym. 188 4. Discrete Logarithm Cryptography 190 This protocol uses Discrete Logarithm Cryptography to achieve 191 authentication. Each party to the exchange derives ephemeral public 192 and private keys with respect to a particular set of domain 193 parameters (referred to here as a "group"). Groups can be either 194 based on finite field cryptography (MODP groups) or elliptic curve 195 cryptography (ECP groups). 197 This protocol uses the same group as the IKE exchange in which it is 198 being used for authentication, with the exception of characteristic- 199 two elliptic curve groups (EC2N). Use of such groups is undefined 200 for this authentication method and an IKE exchange that negotiates 201 one of these groups MUST NOT use this method of authentication. 203 For each group the following operations are defined: 205 o "scalar operation"-- takes a scalar and an element in the group 206 to produce another element-- Z = scalar-op(x, Y). 208 o "element operation"-- takes two elements in the group to produce 209 a third-- Z = element-op(X, Y). 211 o "inverse operation"-- takes an element and returns another 212 element such that the element operation on the two produces the 213 identity element of the group-- Y = inverse(X). 215 4.1. Elliptic Curve Cryptography (ECP) Groups 217 The key exchange defined in this memo uses fundamental algorithms of 218 ECP groups as described in [RFC6090]. 220 Domain parameters for ECP elliptic curves used for secure pre-shared 221 key-based authentication include: 223 o A prime, p, determining a prime field GF(p). The cryptographic 224 group will be a subgroup of the full elliptic curve group which 225 consists of points on an elliptic curve-- elements from GF(p) that 226 satisfy the curve's equation-- together with the "point at 227 infinity" (denoted here as "0") that serves as the identity 228 element. 230 o Elements a and b from GF(p) that define the curve's equation. The 231 point (x,y) is on the elliptic curve if and only if y^2 = x^3 + 232 a*x + b. 234 o A prime, r, which is the order of G, and thus is also the size of 235 the cryptographic subgroup that is generated by G. 237 The scalar operation is multiplication of a point on the curve by 238 itself a number of times. The point Y is multiplied x-times to 239 produce another point Z: 241 Z = scalar-op(x, Y) = x*Y 243 The element operation is addition of two points on the curve. Points 244 X and Y are summed to produce another point Z: 246 Z = element-op(X, Y) = X + Y 248 The inverse function is defined such that the sum of an element and 249 its inverse is "0", the point-at-infinity of an elliptic curve group: 251 Q + inverse(Q) = "0" 253 Elliptic curve groups require a mapping function, q = F(Q), to 254 convert a group element to an integer. The mapping function used in 255 this memo returns the x-coordinate of the point it is passed. 257 scalar-op(x, Y) can be viewed as x iterations of element-op() by 258 defining: 260 Y = scalar-op(1, Y) 262 Y = scalar-op(x, Y) = element-op(Y, scalar-op(x-1, Y)), for x > 1 264 A definition of how to add two points on an elliptic curve (i.e. 265 element-op(X, Y)) can be found in [RFC6090]. 267 Note: There is another ECP domain parameter, a co-factor, h, that is 268 defined by the requirement that the size of the full elliptic curve 269 group (including "0") be the product of h and r. ECP groups used for 270 secure pre-shared key-based authentication MUST have a co-factor of 271 one (1). At the time of publication of this memo, all ECP groups in 272 [IKEV2-IANA] had a co-factor of one (1). 274 4.2. Finite Field Cryptography (MODP) Groups 276 Domain parameters for MODP groups used for secure pre-shared key- 277 based authentication include: 279 o A prime, p, determining a prime field GF(p), the integers modulo 280 p. 282 o A prime, r, which is the multiplicative order of G, and thus also 283 the size of the cryptographic subgroup of GF(p)* that is generated 284 by G. 286 The scalar operation is exponentiation of a generator modulo a prime. 287 An element Y is taken to the x-th power modulo the prime returning 288 another element, Z: 290 Z = scalar-op(x, Y) = Y^x mod p 292 The element operation is modular multiplication. Two elements, X and 293 Y, are multiplied modulo the prime returning another element, Z: 295 Z = element-op(X, Y) = (X * Y) mod p 297 The inverse function for a MODP group is defined such that the 298 product of an element and its inverse modulo the group prime equals 299 one (1). In other words, 301 (Q * inverse(Q)) mod p = 1 303 Unlike ECP groups, MODP groups do not require a mapping function to 304 convert an element into an integer. But for the purposes of notation 305 in protocol definition, the function F, when used below, shall just 306 return the value that was passed to it-- i.e. F(i) = i. 308 Some MODP groups in [IKEV2-IANA] are based on safe primes and the 309 order is not included in the group's domain parameter set. In this 310 case only, the order, r, MUST be computed as the prime minus one 311 divided by two-- (p-1)/2. If an order is included in the group's 312 domain parameter set that value MUST be used in this exchange when an 313 order is called for. If a MODP group does not include an order in 314 its domain parameter set and is not based on a safe prime it MUST NOT 315 be used with this exchange. 317 5. Random Numbers 319 As with IKE itself, the security of the secure pre-shared key 320 authentication method relies upon each participant in the protocol 321 producing quality secret random numbers. A poor random number chosen 322 by either side in a single exchange can compromise the shared secret 323 from that exchange and open up the possibility of dictionary attack. 325 Producing quality random numbers without specialized hardware entails 326 using a cryptographic mixing function (like a strong hash function) 327 to mix entropy from multiple, uncorrelated sources of information and 328 events. A very good discussion of this can be found in [RFC4086]. 330 6. Using Passwords and Raw Keys For Authentication 332 The PSK used as an authentication credential with this protocol can 333 be either a character-based password or passphrase, or it could be a 334 binary or hexidecimal string. Regardless though, this protocol 335 requires both the Initiator and Responder to have identical binary 336 representations of the shared credential. 338 If the PSK is a character-based password or passphrase, there are two 339 types of pre-preprocessing that SHALL be employed to convert the 340 password or passphrase into a hexidecimal string suitable for use 341 with Secure PSK authentication. If a PSK is already a hexidecimal or 342 binary string it can be used directly as the shared credential 343 without any pre-processing. 345 The first step of pre-processing is to remove ambiguities that may 346 arise due to internationalization. Each character-based password or 347 passphrase MUST be pre-processed to remove that ambiguity by 348 processing the character-based password or passphrase according to 349 the rules of the [RFC4013] profile of [RFC3454]. The password or 350 passphrase SHALL be considered a "stored string" per [RFC3454] and 351 unassigned code points are therefore prohibited. The output SHALL be 352 the binary representation of the processed UTF-8 character string. 353 Prohibited output and unassigned codepoints encountered in SASLprep 354 pre-processing SHALL cause a failure of pre-processing and the output 355 SHALL NOT be used with Secure Password Authentication. 357 The next pre-processing step for character-based passwords or 358 passphrases is to effectively obfuscate the string. This is done in 359 an attempt to reduce exposure of stored passwords in the event of 360 server compromise, or compromise of a server's database of stored 361 passwords. The step involves taking the output of the [RFC4013] 362 profile of [RFC3454] and passing it, as the key, with the ASCII 363 string "IKE Secure PSK Authentication", as the data, to HMAC- 364 SHA256(). The output of this obfuscation step SHALL become the 365 shared credential used with Secure PSK Authentication. 367 Note: Passwords tend to be shared for multiple purposes and 368 compromise of a server or database of stored plaintext passwords can 369 be used, in that event, to mount multiple attacks. The obfuscation 370 step is merely to hide the password in the event of server compromise 371 or compromise of the database of stored passwords. Advances in 372 distributed computing power have diminished the effectiveness of 373 performing multiple prf iterations as a technique to prevent 374 dictionary attacks, so no such behavior is proscribed here. Mutually 375 consenting implementations can agree to use a different password 376 obfuscation method, the one described here is for interoperability 377 purposes only. 379 If a device stores passwords for use at a later time it SHOULD pre- 380 process the password prior to storage. If a user enters a password 381 into a device at authentication time it MUST be pre-processed upon 382 entry and prior to use with Secure PSK Authentication. 384 7. Assumptions 386 The security of the protocol relies on certain assumptions. They 387 are: 389 1. The pseudo-random function, prf, defined in [RFC5996], acts as an 390 "extractor" (see [RFC5869]) by distilling the entropy from a 391 secret input into a short, fixed, string. The output of prf is 392 indistinguishable from a random source. 394 2. The discrete logarithm problem for the chosen finite cyclic group 395 is hard. That is, given G, p and Y = G^x mod p it is 396 computationally infeasible to determine x. Similarly for an 397 elliptic curve group given the curve definition, a generator G, 398 and Y = x * G it is computationally infeasible to determine x. 400 3. The pre-shared key is drawn from a finite pool of potential keys. 401 Each possible key in the pool has equal probability of being the 402 shared key. All potential adversaries have access to this pool 403 of keys. 405 8. Secure PSK Authentication Message Exchange 407 The key exchange described in this memo is based on the "Dragonfly" 408 key exchange which has also been proposed in 802.11 wireless networks 409 (see [SAE]) and as an EAP method (see [RFC5931]). "Dragonfly" is 410 patent-free and royalty-free. It SHALL use of the same pseudo-random 411 function (prf) and the same Diffie-Hellman group that are negotiated 412 for use in the IKE exchange that "dragonfly" is authenticating. 414 A pseudo-random function which uses a block cipher is NOT RECOMMENDED 415 for use with Secure PSK Authentication due to its poor job operating 416 as an "extractor" (see Section 7). Pseudo-random functions based on 417 hash functions using the HMAC construct from [RFC2104] SHOULD be 418 used. 420 To perform secure pre-shared key authentication each side must 421 generate a shared and secret element in the chosen group based on the 422 pre-shared key. This element, called the Secret Key Element, or SKE, 423 is then used in the "Dragonfly" authentication and key exchange 424 protocol. "Dragonfly" consists of each side exchanging a "Commit" 425 payload and then proving knowledge of the resulting shared secret. 427 The "Commit" payload contributes ephemeral information to the 428 exchange and binds the sender to a single value of the pre-shared key 429 from the pool of potential pre-shared keys. An authentication 430 payload (AUTH) proves that the pre-shared key is known and completes 431 the zero-knowledge proof. 433 8.1. Negotiation of Secure PSK Authentication 435 The Initiator indicates its desire to use Secure PSK Authentication, 436 by adding a Notify payload of type SECURE_PASSWORD_METHODS (see 437 [RFC6467]) to the first message of the IKE_SA_INIT exchange and by 438 including TBD in the notification data field of the Notify payload, 439 indicating SPSK Authentication. 441 The Responder indicates its acceptance to perform Secure PSK 442 Authentication, by adding a Notify payload of type 443 SECURE_PASSWORD_METHODS to its response in the IKE_SA_INIT exchange 444 and by adding the sole value of TBD to the notification data field of 445 the Notify payload. 447 If the Responder does not include a Notify payload of type 448 SECURE_PASSWORD_METHODS in its IKE_SA_INIT response the Initiator 449 MUST terminate the exchange, it MUST NOT fall back to the PSK 450 authentication method of [RFC5996]. If the Initiator only indicated 451 its support for Secure PSK Authentication (i.e. if the Notify data 452 field only contained TBD) and the Responder replies with a Notify 453 payload of type SECURE_PASSWORD_METHODS and a different value in the 454 Notify data field, the Initiator MUST terminate the exchange. 456 8.2. Fixing the Secret Element, SKE 458 The method of fixing SKE depends on the type of group, either MODP or 459 ECP. The function "prf+" from [RFC5996] is used as a key derivation 460 function. 462 Fixing SKE involves an iterative hunting-and-pecking technique using 463 the prime from the negotiated group's domain parameter set and an 464 ECP- or MODP-specific operation depending on the negotiated group. 465 This technique requires the pre-shared key to be a binary string, 466 therefore any pre-processing transformation (see Section 6) MUST be 467 performed on the pre-shared key prior to fixing SKE. 469 To thwart side channel attacks which attempt to determine the number 470 of iterations of the "hunting-and-pecking" loop that are used to find 471 SKE for a given password, a security parameter, k, is used to ensure 472 that at least k iterations are always performed. 474 Prior to beginning the hunting-and-pecking loop, an 8-bit counter is 475 set to the value one (1). Then the loop begins. First, the pseudo- 476 random function is used to generate a secret seed using the counter, 477 the pre-shared key, and two nonces (without the fixed headers) 478 exchanged by the Initiator and the Responder (see Section 8.6): 480 ske-seed = prf(Ni | Nr, psk | counter) 482 Then, the ske-seed is expanded using prf+ to create an ske-value: 484 ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking") 486 where len(ske-value) is the same as len(p), the length of the prime 487 from the domain parameter set of the negotiated group. 489 If the ske-seed is greater than or equal to the prime, p, the counter 490 is incremented and a new ske-seed is generated and the hunting-and- 491 pecking continues. If ske-seed is less than the prime, p, it is 492 passed to the group-specific operation to select the SKE or fail. If 493 the group-specific operation fails, the counter is incremented, a new 494 ske-seed is generated and the hunting-and-pecking continues. This 495 process continues until the group-specific operation returns the 496 password element. After the password element has been chosen, a 497 random number is used in place of the password in the ske-seed 498 calculation and the hunting-and-pecking continues until the counter 499 is greater than the security parameter, k. 501 8.2.1. ECP Operation to Select SKE 503 The group-specific operation for ECP groups uses ske-value, ske-seed 504 and the equation of the curve to produce SKE. First ske-value is 505 used directly as the x-coordinate, x, with the equation of the 506 elliptic curve, with parameters a and b from the domain parameter set 507 of the curve, to solve for a y-coordinate, y. 509 Note: A method of checking whether a solution to the equation of the 510 elliptic curve is to see whether the legendre symbol of (x^3 + ax + 511 b) equals one (1). If it does then a solution exists, if it does not 512 then there is no solution. 514 If there is no solution to the equation of the elliptic curve then 515 the operation fails, the counter is incremented, a new ske-value and 516 ske-seed is selected and the hunting-and-pecking continues. If there 517 is a solution then, y is calculated as the square root of (x^3 + ax + 518 b) using the equation of the elliptic curve. In this case an 519 ambiguity exists as there are technically two solutions to the 520 equation, and ske-seed is used to unambiguously select one of them. 521 If the low-order bit of ske-seed is equal to the low-order bit of y 522 then a candidate SKE is defined as the point (x,y); if the low-order 523 bit of ske-seed differs from the low-order bit of y then a candidate 524 SKE is defined as the point (x, p-y) where p is the prime from the 525 negotiated group's domain parameter set. The candidate SKE becomes 526 the SKE and the ECP-specific operation completes successfully. 528 Algorithmically, the process looks like this: 530 found = 0 531 counter = 1 532 v = psk 533 do { 534 ske-seed = prf(Ni | Nr, v | counter) 535 ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking") 536 if (ske-value < p) 537 then 538 x = ske-value 539 if ( (y = sqrt(x^3 + ax + b)) != FAIL) 540 then 541 if (found == 0) 542 then 543 if (LSB(y) == LSB(ske-seed)) 544 then 545 SKE = (x,y) 546 else 547 SKE = (x, p-y) 548 fi 549 found = 1 550 v = random() 551 fi 552 fi 553 fi 554 counter = counter + 1 555 } while ((found == 0) || (counter <= k)) 557 where FAIL indicates that there is no solution to sqrt(x^3 + ax + b). 559 Figure 1: Fixing SKE for ECP Groups 561 Note: For ECP groups, the probability that more than "n" iterations 562 of the "hunting-and-pecking" loop are required to find SKE is roughly 563 (1-(r/2p))^n which rapidly approaches zero (0) as "n" increases. 565 8.2.2. MODP Operation to Select SKE 567 The group-specific operation for MODP groups takes ske-value, and the 568 prime, p, and order, r, from the group's domain parameter set to 569 directly produce a candidate SKE by exponentiating the ske-value to 570 the value ((p-1)/r) modulo the prime. If the candidate SKE is 571 greater than one (1) the candidate SKE becomes the SKE and the MODP- 572 specific operation completes successfully. Otherwise, the MODP- 573 specific operation fails (and the hunting-and-pecking continues). 575 Algorithmically, the process looks like this: 577 found = 0 578 counter = 1 579 v = psk 580 do { 581 ske-seed = prf(Ni | Nr, v | counter) 582 ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking") 583 if (ske-value < p) 584 then 585 ELE = ske-value ^ ((p-1)/r) mod p 586 if (ELE > 1) 587 then 588 if (found == 0) 589 SKE = ELE 590 found = 1 591 v = random() 592 fi 593 fi 594 fi 595 counter = counter + 1 596 } while ((found == 0) || (counter <= k)) 598 Figure 2: Fixing SKE for MODP Groups 600 Note: For MODP groups, the probability that more than "n" iterations 601 of the "hunting-and-pecking" loop are required to find SKE is roughly 602 ((m-p/p)^n, where m is the largest unsigned number that can be 603 expressed in len(p) bits, which rapidly approaches zero (0) as "n" 604 increases. 606 8.3. Encoding and Decoding of Group Elements and Scalars 608 The payloads used in the secure pre-shared key authentication method 609 contain elements from the negotiated group and scalar values. To 610 ensure interoperability, scalars and field elements MUST be 611 represented in payloads in accordance with the requirements in this 612 section. 614 8.3.1. Encoding and Decoding of Scalars 616 Scalars MUST be represented (in binary form) as unsigned integers 617 that are strictly less than r, the order of the generator of the 618 agreed-upon cryptographic group. The binary representation of each 619 scalar MUST have a bit length equal to the bit length of the binary 620 representation of r. This requirement is enforced, if necessary, by 621 prepending the binary representation of the integer with zeros until 622 the required length is achieved. 624 Scalars in the form of unsigned integers are converted into octet- 625 strings and back again using the technique described in [RFC6090]. 627 8.3.2. Encoding and Decoding of ECP Elements 629 Elements in ECP groups are points on the negotiated elliptic curve. 630 Each such element MUST be represented by the concatenation of two 631 components, an x-coordinate and a y-coordinate. 633 Each of the two components, the x-coordinate and the y-coordinate, 634 MUST be represented (in binary form) as an unsigned integer that is 635 strictly less than the prime, p, from the group's domain parameter 636 set. The binary representation of each component MUST have a bit 637 length equal to the bit length of the binary representation of p. 638 This length requirement is enforced, if necessary, by prepending the 639 binary representation of the integer with zeros until the required 640 length is achieved. 642 The unsigned integers that represent the coordinates of the point are 643 converted into octet-strings and back again using the technique 644 described in [RFC6090]. 646 Since the field element is represented in a payload by the 647 x-coordinate followed by the y-coordinate it follows, then, that the 648 length of the element in the payload MUST be twice the bit length of 649 p. 651 8.3.3. Encoding and Decoding of MODP Elements 653 Elements in MODP groups MUST be represented (in binary form) as 654 unsigned integers that are strictly less than the prime, p, from the 655 group's domain parameter set. The binary representation of each 656 group element MUST have a bit length equal to the bit length of the 657 binary representation of p. This length requirement is enforced, if 658 necessary, by prepending the binary representation of the interger 659 with zeros until the required length is achieved. 661 The unsigned integer that represents a MODP element is converted into 662 an octet-string and back using the technique described in [RFC6090]. 664 8.4. Message Generation and Processing 666 8.4.1. Generation of a Commit 668 Before a Commit can be generated, the SKE must be fixed using the 669 process described in Section 8.2. 671 A Commit has two components, a scalar and an Element. To generate a 672 Commit, two random numbers, a "private" value and a "mask" value, are 673 generated (see Section 5). Their sum modulo the order of the group, 674 r, becomes the scalar component: 676 scalar = (private + mask) mod r 678 If the scalar is not greater than one (1), the private and mask 679 values MUST be thrown away and new values randomly generated. If the 680 scalar is greater than one (1), the inverse of the scalar operation 681 with the mask and SKE becomes the Element component. 683 Element = inverse(scalar-op(mask, SKE)) 685 The Commit payload consists of the scalar followed by the Element and 686 the scalar and Element are encoded in the Commit payload according to 687 Section 8.3. 689 8.4.2. Processing of a Commit 691 Upon receipt of a peer's Commit the scalar and element MUST be 692 validated. The processing of an element depends on the type, either 693 an ECP element or a MODP element. 695 8.4.2.1. Validation of an ECP Element 697 Validating a received ECP Element involves: 1) checking whether the 698 two coordinates, x and y, are both greater than zero (0) and less 699 than the prime defining the underlying field; and 2) checking whether 700 the x- and y-coordinates satisfy the equation of the curve (that is, 701 that they produce a valid point on the curve that is not "0"). If 702 either of these conditions are not met the received Element is 703 invalid, otherwise the received Element is valid. 705 8.4.2.2. Validation of a MODP Element 707 A received MODP Element is valid if: 1) it is between one (1) and the 708 prime, p, exclusive; and 2) if modular exponentiation of the Element 709 by the group order, r, equals one (1). If either of these conditions 710 are not true the received Element is invalid, otherwise the received 711 Element is valid.. 713 8.4.2.3. Commit Processing Steps 715 Commit validation is accomplished by the following steps: 717 1. The length of the Commit payload is checked against its 718 anticipated length (the anticipated length of the scalar plus the 719 anticipated length of the element, for the negotiated group). If 720 it is incorrect, the Commit is invalidated, otherwise processing 721 continues. 723 2. The peer's scalar is extracted from the Commit payload according 724 to Section 8.3.1 and checked to ensure it is between one (1) and 725 r, the order of the negotiated group, exclusive. If it is not, 726 the Commit is invalidated, otherwise processing continues. 728 3. The peer's Element is extracted from the Commit payload according 729 to Section 8.3.2 and checked in a manner that depends on the type 730 of group negotiated. If the group is ECP the element is 731 validated according to Section 8.4.2.1, if the group is MODP the 732 element is validated according to Section 8.4.2.2. If the 733 Element is not valid then the Commit is invalidated, otherwise 734 the Commit is validated. 736 4. The Initiator of the IKE exchange has an added requirement to 737 verify that the received element and scalar from the Commit 738 payload differ from the element and scalar sent to the Responder. 739 If they are identical, it signifies a reflection attack and the 740 Commit is invalidated. 742 If the Commit is invalidated the payload MUST be discarded and the 743 IKE exchange aborted. 745 8.4.3. Authentication of the Exchange 747 After a Commit has been generated and a peer's Commit has been 748 processed a shared secret used to authenticate the peer is derived. 749 Using SKE, the "private" value generated as part of Commit 750 generation, and the peer's scalar and Element from its Commit, named 751 here peer-scalar and peer-element, respectively, a preliminary shared 752 secret, skey, is generated as: 754 skey = F(scalar-op(private, 755 element-op(peer-element, 756 scalar-op(peer-scalar, SKE)))) 758 For the purposes of subsequent computation, the bit length of skey 759 SHALL be equal to the bit length of the prime, p, used in either a 760 MODP or ECP group. This bit length SHALL be enforced, if necessary, 761 by prepending zeros to the value until the required length is 762 achieved. 764 A shared secret, ss, is then computed from skey and the nonces 765 exchanged by the Initiator (Ni) and Responder (Nr) (without the fixed 766 headers) using prf(): 768 ss = prf(Ni | Nr, skey | "Secure PSK Authentication in IKE") 770 The shared secret, ss, is used in an AUTH authentication payload to 771 prove possession of the shared secret, and therefore knowledge of the 772 pre-shared key. 774 8.5. Payload Format 776 8.5.1. Commit Payload 778 [RFC6467] defines a Generic Secure Password Method (GSPM) payload 779 which is used to convey information that is specific to a particular 780 secure password method. This memo uses the GSPM payload as a "Commit 781 Payload" to contain the Scalar and Element used in the SPSK exchange: 783 The Commit Payload is defined as follows: 785 1 2 3 786 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 ! Next Payload !C! RESERVED ! Payload Length ! 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | | 791 + Scalar ~ 792 | | 793 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | | | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 796 | | 797 ~ Element ~ 798 | | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 The Scalar and Element SHALL be encoded in the Commit payload 802 according to Section 8.3. 804 8.6. IKEv2 Messaging 806 SPSK authentication modifies the IKE_AUTH exchange by adding one 807 additional round trip to exchange Commit payloads to perform the 808 Secure PSK Authentication exchange, and by changing the calculation 809 of the AUTH payload data to bind the IKEv2 exchange to the outcome of 810 the Secure PSK Authentication exchange (see Figure 3). 812 Initiator Responder 813 ----------- ----------- 815 IKE_SA_INIT: 817 HDR, SAi1, KEi, Ni, 818 N(SPM-SPSK) --> 820 <-- HDR, SAr1, KEr, Nr, 821 N(SPM-SPSK) 823 IKE_AUTH: 825 HDR, SK {IDi, COMi, [IDr,] 826 SAi2, TSi, TSr} --> 827 <-- HDR, SK {IDr, COMr} 828 HDR, SK {AUTHi} --> 829 <-- HDR, SK {AUTHr, SAr2, TSi, TSr} 831 where N(SPM-SPSK) indicates the Secure Password Methods Notify 832 payloads used to negotiate the use of SPSK authentication (see 833 Section 8.1), COMi and AUTHi are the Commit payload and AUTH payload, 834 respectively, sent by the Initiator and COMr and AUTHr are the Commit 835 payload and AUTH payload, respectively, sent by the Responder. 837 Figure 3: Secure PSK in IKEv2 839 The AUTH payloads when doing SPSK authentication SHALL be computed as 841 AUTHi = prf(ss, | COMi | COMr) 843 AUTHr = prf(ss, | COMr | COMi) 845 Where "ss" is the shared secret derived in Section 8.4.3, COMi and 846 COMr are the entire Commit payloads (including the fixed headers) 847 sent by the Initiator and Responder, respectively, and 848 and are defined in 849 [RFC5996]. The Authentication Method indicated in both AUTH payloads 850 SHALL be "Generic Secure Password Authentication Method", value 12, 851 from [IKEV2-IANA]. 853 9. IANA Considerations 855 IANA SHALL assign a value for "Secure PSK Authentication", replacing 856 TBD above, from the Secure Password Authentication Method registry in 857 [IKEV2-IANA] with the method name of "Secure PSK Authentication". 859 10. Security Considerations 861 Both the Initiator and Responder obtain a shared secret, "ss" (see 862 Section 8.4.3) based on a secret group element and their own private 863 values contributed to the exchange. If they do not share the same 864 pre-shared key they will be unable to derive the same secret group 865 element and if they do not share the same secret group element they 866 will be unable to derive the same shared secret. 868 Resistance to dictionary attack means that the adversary must launch 869 an active attack to make a single guess at the pre-shared key. If 870 the size of the pool from which the key was extracted was D, and each 871 key in the pool has an equal probability of being chosen, then the 872 probability of success after a single guess is 1/D. After X guesses, 873 and removal of failed guesses from the pool of possible keys, the 874 probability becomes 1/(D-X). As X grows so does the probability of 875 success. Therefore it is possible for an adversary to determine the 876 pre-shared key through repeated brute-force, active, guessing 877 attacks. This authentication method does not presume to be secure 878 against this and implementations SHOULD ensure the size of D is 879 sufficiently large to prevent this attack. Implementations SHOULD 880 also take countermeasures, for instance refusing authentication 881 attempts for a certain amount of time, after the number of failed 882 authentication attempts reaches a certain threshold. No such 883 threshold or amount of time is recommended in this memo. 885 An active attacker can impersonate the Responder of the exchange and 886 send a forged Commit payload after receiving the Initiator's Commit. 887 The attacker then waits until it receives the authentication payload 888 from the Responder. Now the attacker can attempt to run through all 889 possible values of the pre-shared key, computing SKE (see 890 Section 8.2), computing "ss" (see Section 8.4.3), and attempting to 891 recreate the Confirm payload from the Responder. 893 But the attacker committed to a single guess of the pre-shared key 894 with her forged Commit. That value was used by the Responder in his 895 computation of "ss" which was used in the authentication payload. 896 Any guess of the pre-shared key which differs from the one used in 897 the forged Commit would result in each side using a different secret 898 element in the computation of "ss" and therefore the authentication 899 payload could not be verified as correct, even if a subsequent guess, 900 while running through all possible values, was correct. The attacker 901 gets one guess, and one guess only, per active attack. 903 An attacker, acting as either the Initiator or Responder, can take 904 the Element from the Commit message received from the other party, 905 reconstruct the random "mask" value used in its construction and then 906 recover the other party's "private" value from the Scalar in the 907 Commit message. But this requires the attacker to solve the discrete 908 logarithm problem which we assumed was intractable above (Section 7). 910 Instead of attempting to guess at pre-shared keys an attacker can 911 attempt to determine SKE and then launch an attack. But SKE is 912 determined by the output of the pseudo-random function, prf, which is 913 assumed to be indistinguishable from a random source (Section 7). 914 Therefore, each element of the finite cyclic group will have an equal 915 probability of being the SKE. The probability of guessing SKE will 916 be 1/r, where r is the order of the group. This is the same 917 probability of guessing the solution to the discrete logarithm which 918 is assumed to be intractable (Section 7). The attacker would have a 919 better chance of success at guessing the input to prf, i.e. the pre- 920 shared key, since the order of the group will be many orders of 921 magnitude greater than the size of the pool of pre-shared keys. 923 The implications of resistance to dictionary attack are significant. 924 An implementation can provision a pre-shared key in a practical and 925 realistic manner-- i.e. it MAY be a character string and it MAY be 926 relatively short-- and still maintain security. The nature of the 927 pre-shared key determines the size of the pool, D, and 928 countermeasures can prevent an adversary from determining the secret 929 in the only possible way: repeated, active, guessing attacks. For 930 example, a simple four character string using lower-case English 931 characters, and assuming random selection of those characters, will 932 result in D of over four hundred thousand. An adversary would need 933 to mount over one hundred thousand active, guessing attacks (which 934 will easily be detected) before gaining any significant advantage in 935 determining the pre-shared key. 937 If an attacker knows the number of hunting-and-pecking loops that 938 were required to determine SKE, it is possible to eliminate passwords 939 from the pool of potential passwords and increase the probability of 940 successfully guessing the real password. MODP groups will require 941 more than "n" loops with a probability based on the value of the 942 prime-- if m is the largest unsigned number that can be expressed in 943 len(p) bits then the probability is ((m-p)/p)^n-- which will 944 typically be very small for the groups defined in [IKEV2-IANA]. ECP 945 groups will require more than one "n" loops with a probability of 946 roughly (1-(r/2p))^n. Therefore, a security parameter, k, is defined 947 that will ensure that at least k loops will always be executed 948 regardless of whether SKE is found in less than k loops. There is 949 still a probability that a password would require more than k loops, 950 and a side-channel attacker could use that information to his 951 advantage, so selection of the value of k should be based on a trade- 952 off between the additional work load to always perform k iterations 953 and the potential of providing information to a side-channel 954 attacker. It is important to note that the possibility of a 955 successful side channel attack is greater against ECP groups than 956 MODP groups and it might be appropriate to have separate values of k 957 for the two. 959 For a more detailed discussion of the security of the key exchange 960 underlying this authentication method see [SAE] and [RFC5931]. 962 11. Acknowledgements 964 The author would like to thank Scott Fluhrer and Hideyuki Suzuki for 965 their insight in discovering flaws in earlier versions of the key 966 exchange that underlies this authentication method and for their 967 helpful suggestions in improving it. Thanks to Lily Chen for useful 968 advice on the hunting-and-pecking technique to "hash into" an element 969 in a group and to Jin-Meng Ho for a discussion on countering a small 970 sub-group attack. Rich Davis suggested several checks on received 971 messages that greatly increase the security of the underlying key 972 exchange. Hugo Krawczyk suggested using the prf as an extractor. 974 12. References 976 12.1. Normative References 978 [IKEV2-IANA] 979 "Internet Assigned Numbers Authority, IKEv2 Parameters", 980 . 982 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 983 Hashing for Message Authentication", RFC 2104, 984 February 1997. 986 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 987 Requirement Levels", BCP 14, RFC 2119, March 1997. 989 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 990 Internationalized Strings ("stringprep")", RFC 3454, 991 December 2002. 993 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 994 and Passwords", RFC 4013, February 2005. 996 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 997 "Internet Key Exchange Protocol Version 2 (IKEv2)", 998 RFC 5996, September 2010. 1000 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1001 Curve Cryptography Algorithms", RFC 6090, February 2011. 1003 [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key 1004 Exchange Version 2 (IKEv2)", RFC 6467, December 2011. 1006 12.2. Informative References 1008 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 1009 Password-Based Protocols Secure Against Dictionary 1010 Attack", Proceedings of the IEEE Symposium on Security and 1011 Privacy, Oakland, 1992. 1013 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 1014 Password Authenticated Key Exchange Using Diffie-Hellman", 1015 Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag, 1016 2000. 1018 [BPR00] Bellare, M., Pointcheval, D., and P. Rogaway, 1019 "Authenticated Key Exchange Secure Against Dictionary 1020 Attacks", Advances in Cryptology -- Eurocrypt '00, Lecture 1021 Notes in Computer Science Springer-Verlag, 2000. 1023 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1024 Requirements for Security", BCP 106, RFC 4086, June 2005. 1026 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1027 Internet Protocol", RFC 4301, December 2005. 1029 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1030 Key Derivation Function (HKDF)", RFC 5869, May 2010. 1032 [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication 1033 Protocol (EAP) Authentication Using Only a Password", 1034 RFC 5931, August 2010. 1036 [SAE] Harkins, D., "Simultaneous Authentication of Equals: A 1037 Secure, Password-Based Key Exchange for Mesh Networks", 1038 Proceedings of the 2008 Second International Conference on 1039 Sensor Technologies and Applications Volume 00, 2008. 1041 Author's Address 1043 Dan Harkins 1044 Aruba Networks 1045 1322 Crossman Avenue 1046 Sunnyvale, CA 94089-1113 1047 United States of America 1049 Email: dharkins@arubanetworks.com