idnits 2.17.1 draft-harkins-ipsecme-spsk-auth-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (June 30, 2010) is 5046 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-mcgrew-fundamental-ecc-01 ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-14) exists of draft-harkins-emu-eap-pwd-12 Summary: 6 errors (**), 0 flaws (~~), 4 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 June 30, 2010 5 Expires: January 1, 2011 7 Secure PSK Authentication for IKE 8 draft-harkins-ipsecme-spsk-auth-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 1, 2011. 33 Copyright Notice 35 Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) 40 in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This memo describes a secure pre-shared key authentication method for 47 IKE. It is resistant to dictionary attack and retains security even 48 when used with weak pre-shared keys. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Keyword Definitions . . . . . . . . . . . . . . . . . . . 3 54 2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Discrete Logarithm Cryptography . . . . . . . . . . . . . . . 5 57 4.1. Elliptic Curve Cryptography (ECP) Groups . . . . . . . . . 6 58 4.2. Finite Field Cryptography (MODP) Groups . . . . . . . . . 7 59 5. Random Numbers . . . . . . . . . . . . . . . . . . . . . . . . 8 60 6. Using Passwords as a Pre-Shared Key . . . . . . . . . . . . . 8 61 7. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 8. Secure PSK Authentication Message Exchange . . . . . . . . . . 9 63 8.1. Fixing the Secret Element, SKE . . . . . . . . . . . . . . 10 64 8.1.1. ECP Operation to Select SKE . . . . . . . . . . . . . 11 65 8.1.2. MODP Operation to Select SKE . . . . . . . . . . . . . 12 66 8.2. Encoding and Decoding of Group Elements and Scalars . . . 13 67 8.2.1. Encoding and Decoding of Scalars . . . . . . . . . . . 13 68 8.2.2. Encoding and Decoding of ECP Elements . . . . . . . . 13 69 8.2.3. Encoding and Decoding of MODP Elements . . . . . . . . 14 70 8.3. Message Generation and Processing . . . . . . . . . . . . 14 71 8.3.1. Generation of a Commit . . . . . . . . . . . . . . . . 14 72 8.3.2. Processing of a Commit . . . . . . . . . . . . . . . . 15 73 8.3.2.1. Validation of an ECP Element . . . . . . . . . . . 15 74 8.3.2.2. Validation of a MODP Element . . . . . . . . . . . 15 75 8.3.2.3. Commit Processing Steps . . . . . . . . . . . . . 15 76 8.3.3. Authentication of the Exchange . . . . . . . . . . . . 16 77 8.4. Payload Format . . . . . . . . . . . . . . . . . . . . . . 16 78 8.4.1. Commit Payload . . . . . . . . . . . . . . . . . . . . 17 79 8.5. IKEv1 Messaging . . . . . . . . . . . . . . . . . . . . . 17 80 8.6. IKEv2 Messaging . . . . . . . . . . . . . . . . . . . . . 19 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 1. Introduction 91 Both [RFC2409] and [RFC4306] allow for authentication of the IKE 92 peers using a pre-shared key. The exchanges, though, are susceptible 93 to dictionary attack and are therefore insecure. In addition, 94 [RFC2409] requires that a pre-shared key be identified by IP address 95 and this severely constrains its usefulness. These are obvious 96 drawbacks to using pre-shared key authentication in IKEv1 and IKEv2. 98 To address the security issue, [RFC4306] recommends that the pre- 99 shared key used for authentication "contain as much unpredictability 100 as the strongest key being negotiated". That means any non- 101 hexidecimal key would require over 100 characters to provide enough 102 strength to generate a 128-bit key for AES. This is an unrealistic 103 requirement because humans have a hard time entering a string over 20 104 characters without error. Consequently, pre-shared key 105 authentication in [RFC2409] and [RFC4306] are used insecurely today. 107 A pre-shared key authentication method built on top of a zero- 108 knowledge proof will provide resistance to dictionary attack and 109 still allow for security when used with weak pre-shared keys, such as 110 user-chosen passwords. Such an authentication method is described in 111 this memo. 113 Resistance to dictionary attack is achieved when an attacker gets 114 one, and only one, guess at the secret per active attack (see for 115 example, [BM92], [BMP00] and [BPR00]). Another way of putting this 116 is that any advantage the attacker can realize is through interaction 117 and not through computation. This is demonstrably different than the 118 technique from [RFC4306] of using a large, random number as the pre- 119 shared key. That can only make a dictionary attack less likely to 120 suceed, it does not prevent a dictionary attack. And, as [RFC4306] 121 notes, it is completely insecure when used with weak keys like user- 122 generated passwords. 124 1.1. Keyword Definitions 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 2. Usage Scenarios 132 [RFC4306] describes usage scenarios for IKEv2. These are: 134 1. "Security Gateway to Security Gateway Tunnel": the endpoints of 135 the IKE (and IPsec) communication are network nodes that protect 136 traffic on behalf of connected networks. Protected traffic is 137 between devices on the respective protected networks. 139 2. "Endpoint-to-Endpoint Transport": the endpoints of the IKE (and 140 IPsec) communication are hosts according to [RFC4301]. Protected 141 traffic is between the two endpoints. 143 3. "Endpoint to Securty Gateway Tunnel": one endpoint connects to a 144 protected network through a network node. The endpoints of the 145 IKE (and IPsec) communication are the endpoint and network node, 146 but the protected traffic is between the endpoint and another 147 device on the protected network behind the node. 149 The authentication and key exchange described in this memo is 150 suitable for all the usage scenarios described in [RFC4306]. In the 151 "Security Gateway to Security Gateway Tunnel" scenario and the 152 "Endpoint-to-Endpoint Transport" scenario it provides a secure method 153 of authentication without requiring a certificate. For the "Endpoint 154 to Security Gateway Tunnel" scenario it provides for secure username+ 155 password authentication that is popular in remote access VPN 156 situations. 158 [RFC2409] does not describe usage scenarios for IKEv1 but IKEv1 has, 159 traditionally, been used in the same "Security Gateway to Security 160 Gateway Tunnel" scenario and the "Endpoint-to-Endpoint Transport" 161 scenario. Its pre-shared key-based authentication method is 162 constrained to only allow keys identified by IP address and therefore 163 it lacks a robust way to do user authentication using a password, 164 prompting the definition of different insecure ways to do password 165 authentication. Therefore, a secure pre-shared key-based 166 authentication method in IKEv1 will obviate the need to do insecure 167 password-based authentication, such as [XAUTH], and remove the 168 requirement that a pre-shared key in IKEv1 needs to be based on IP 169 address. 171 3. Notation 173 The following notation is used in this memo: 175 psk 176 A shared, secret and potentially low-entropy word, phrase, code 177 or key used as a credential to mutually authenticate the peers. 179 a = prf(b, c) 180 The string "b" and "c" are given to a pseudo-random function to 181 produce a fixed-length output "a". 183 a | b 184 denotes concatenation of string "a" with string "b". 186 [a]b 187 indicates a string consisting of the single bit "a" repeated "b" 188 times. 190 len(x) 191 indicates the length in bits of the string x. 193 LSB(x) 194 returns the least-significant bit of the bitstring "x". 196 The convention for this memo to represent an element in a finite 197 cyclic group is to use an upper-case letter or acronym, while a 198 scalar is indicated with a lower-case letter or acronym. 200 4. Discrete Logarithm Cryptography 202 This protocol uses Discrete Logarithm Cryptography to achieve 203 authentication. Each party to the exchange derives ephemeral public 204 and private keys with respect to a particular set of domain 205 parameters (referred to here as a "group"). Groups can be either 206 based on finite field cryptography (MODP groups) or elliptic curve 207 cryptography (ECP groups). 209 This protocol uses the same group as the IKE exchange in which it is 210 being used for authentication, with the exception of characteristic- 211 two elliptic curve groups (EC2N). Use of such groups is undefined 212 for this authentication method and an IKE exchange that negotiates 213 one of these groups MUST NOT use this method of authentication. 215 For each group the following operations are defined: 217 o "scalar operation"-- taking a scalar and an element in the group 218 producing another element-- Z = scalar-op(x, Y). 220 o "element operation"-- taking two elements in the group to produce 221 a third-- Z = element-op(X, Y). 223 o "inverse operation"-- take an element an return another element 224 such that the element operation on the two produces the identity 225 element of the group-- Y = inverse(X). 227 4.1. Elliptic Curve Cryptography (ECP) Groups 229 The key exchange defined in this memo uses fundamental algorithms of 230 ECP groups as described in [FUN-ECC]. 232 Domain parameters for ECP elliptic curves used for secure pre-shared 233 key-based authentication include: 235 o A prime, p, determining a prime field GF(p). The cryptographic 236 group will be a subgroup of the full elliptic curve group which 237 consists points on an elliptic curve-- elements from GF(p) that 238 satisfy the curve's equation-- together with the "point at 239 infinity" (denoted here as "O") that serves as the identity 240 element. 242 o Elements a and b from GF(p) that define the curve's equation. The 243 point (x,y) is on the elliptic curve if and only if (y^2 - x^3 - 244 a*x - b) mod p equals zero (0). 246 o A prime, r, which is the order of G, and thus is also the size of 247 the cryptographic subgroup that is generated by G. 249 The scalar operation is multiplication of a point on the curve by 250 itself a number of times. The point Y is multiplied x-times to 251 produce another point Z: 253 Z = scalar-op(x, Y) = x*Y 255 The element operation is addition of two points on the curve. Points 256 X and Y are summed to produce another point Z: 258 Z = element-op(X, Y) = X + Y 260 The inverse function is defined such that the sum of an element and 261 its inverse is "0": 263 Q + inverse(Q) = "O" 265 Elliptic curve groups require a mapping function, q = F(Q), to 266 convert a group element to an integer. The mapping function used in 267 this memo returns the x-coordinate of the point it is passed. 269 scalar-op(x, Y) can be viewed as x iterations of element-op(Y, Y) by 270 defining: 272 Y = scalar-op(x, Y), for x = 1 273 Y = scalar-op(x, Y) = element-op(scalar-op(x-1, Y), for x > 1 275 A definition of how to add two points on an elliptic curve (i.e. 276 element-op(X, Y)) can be found in [FUN-ECC]. 278 Note: There is another ECP domain parameter, a co-factor, h, that is 279 defined by the requirement that the size of the full elliptic curve 280 group (including "O") be the product of h and r. ECP groups used for 281 secure pre-shared key-based authentication MUST have a co-factor of 282 one (1). At the time of publication of this memo, all ECP groups in 283 the IANA registry used by IKE had a co-factor of one (1). 285 4.2. Finite Field Cryptography (MODP) Groups 287 Domain parameters for MODP groups used for secure pre-shared key- 288 based authentication include: 290 o A prime, p, determining a prime field GF(p), the integers modulo 291 p. 293 o A prime, r, which is the multiplicative order of G, and thus also 294 the size of the cryptographic subgroup of GF(p)* that is generated 295 by G. 297 The scalar operation is exponentiation of a generator modulus a 298 prime. An element Y is taken to the x-th power modulo the prime 299 returning another element, Z: 301 Z = scalar-op(x, Y) = Y^x mod p 303 The element operation is modular multiplication. Two elementx, X and 304 Y, are multiplied modulo the prime returning another element, Z: 306 Z = element-op(X, Y) = (X * Y) mod p 308 The inverse function for a MODP group is defined such that the 309 product of an element and its inverse modulo the group prime equals 310 one (1). In other words, 312 (Q * inverse(Q)) mod p = 1 314 Unlike ECP groups, MODP groups do not require a mapping function to 315 convert an element into a scalar. But for the purposes of notation 316 in protocol definition, the function F, when used below, shall just 317 return the integer that was passed to it-- i.e. F(i) = i. 319 Some MODP groups in the IANA registry for use by IKE (and the secure 320 pre-shared key authentication method) are based on safe primes and 321 the order is not included in the group's domain parameter set. In 322 this case only, the order, r, MUST be computed as the prime minus one 323 divided by two-- (p-1)/2. If an order is included in the group's 324 domain parameter set that value MUST be used in this exchange when an 325 order is called for. If a MODP group does not include an order in 326 its domain parameter set and is not based on a safe prime it MUST NOT 327 be used with this exchange. 329 5. Random Numbers 331 As with IKE itself, the security of the secure pre-shared key 332 authenticaiton method relies upon each participant in the protocol 333 producing quality secret random numbers. A poor random number chosen 334 by either side in a single exchange can compromise the shared secret 335 from that exchange and open up the possibility of dictionary attack. 337 Producing quality random numbers without specialized hardware entails 338 using a cryptographic mixing function (like a strong hash function) 339 to distill entropy from multiple, uncorrelated sources of information 340 and events. A very good discussion of this can be found in 341 [RFC4086]. 343 6. Using Passwords as a Pre-Shared Key 345 This protocol requires the pre-shared key to be represented as a 346 binary string. When passwords are used it is necessary to transform 347 the password into a binary string in a manner that will produce 348 identitcal binary strings on the Initiator and the Responder. This 349 imposes processing requirements on a password prior to its use. 351 Three techniques for password pre-processing exist for Secure PSK 352 Authentication: 354 o None: The input password string SHALL be treated as an ASCII 355 string or a hexadecimal string with no treatment or normalization 356 performed. The output SHALL be the binary representation of the 357 input string. 359 o RFC2759: The input password string SHALL be processed to produce 360 the output PasswordHashHash, as defined in [RFC2759], including 361 any approved errata to [RFC2759]. This technique is useful when 362 at least one side does not have access to the plaintext password. 364 o SASLprep: The input password string is processed according to the 365 rules of the [RFC4013] profile of [RFC3454]. A password SHALL be 366 considered a "stored string" per [RFC3454] and unassigned code 367 points are therefore prohibited. The output SHALL be the binary 368 representation of the processed UTF-8 character string. 369 Prohibited output and unassigned codepoints encountered in 370 SASLprep pre-processing SHALL cause a failure of pre-processing 371 and the output SHALL NOT be used with Secure Password 372 Authentication. 374 For the purposes of interoperability, a password pre-processing 375 technique of "None" MUST be supported. "RFC2759" and "SASLprep" 376 SHOULD be supported. 378 Changing a password is out-of-scope of this memo but due to the 379 ambiguities in the way internationalized character strings are 380 handled it SHOULD be done using SASLprep ensure a canonical 381 representation of the new password is stored and subsequent 382 invocations of Secure PSK Authentication SHOULD use SASLprep to 383 ensure that both sides generate an identical binary string from the 384 input password. 386 7. Assumptions 388 The security of the protocol relies on certain assumptions. They 389 are: 391 1. The pseudo-random function, prf, defined in IKE (either [RFC2409] 392 or [RFC4306]) acts as an "extractor" by concentrating the entropy 393 from a secret input into a short, fixed, string. The output of 394 prf is indistinguishable from a random source. 396 2. The discrete logarithm problem for the chosen finite cyclic group 397 is hard. That is, given G, p and Y = G^x mod p it is 398 computationally infeasible to determine x. Similarly for an 399 elliptic curve group given the curve definition, a generator G, 400 and Y = x * G it is computationally infeasible to determine x. 402 3. The pre-shared key is drawn from a finite pool of potential keys. 403 Each possible key in the pool has equal probability of being the 404 shared key. All potential attackers have access to this pool of 405 keys. 407 8. Secure PSK Authentication Message Exchange 409 The key exchange described in this memo is based on the "Dragonfly" 410 key exchange which has also been proposed in 802.11 wireless networks 411 (see [SAE]) and as an EAP method (see [EAPPWD]). "Dragonfly" is 412 patent-free and royalty-free. It has been defined here for use in 413 both IKEv1 ([RFC2409]) and IKEv2 ([RFC4306]). It makes use of the 414 same pseudo-random function (prf) and the same Diffie-Hellman group 415 that are negotiated for use in the IKE exchange that "dragonfly" is 416 authenticating. 418 A pseudo-random function which uses a block cipher is NOT RECOMMENDED 419 for use with Secure PSK Authentication due to its poor job operating 420 as an "extractor" (see Section 7). Pseudo-random functions based on 421 hash functions using the HMAC construct from [RFC2104] SHOULD be 422 used. 424 To perform secure pre-shared key authentication each side must 425 generate a shared and secret element in the chosen group based on the 426 pre-shared key. This element, called the Secret Key Element, or SKE, 427 is then used in an authentication and key exchange protocol. The key 428 exchange protocol consists of each side exchanging a "Commit" payload 429 and then proving knowledge of the resulting shared secret. 431 The "Commit" payload contributes ephemeral information to the 432 exchange and binds the sender to a single value of the pre-shared key 433 from the pool of potential pre-shared keys. An authentication 434 payload (either the HASH or AUTH payload depending on whether IKEv1 435 or IKEv2, respectively, is being used) proves that the pre-shared key 436 is known and completes the zero-knowledge proof. 438 8.1. Fixing the Secret Element, SKE 440 The method of fixing SKE depends on the type of group, either MODP or 441 ECP. The function "prf+" from [RFC4306] is used as a key derivation 442 function. This is true even if performing secure pre-shared key 443 authentication with IKEv1. 445 Fixing SKE involves an iterative hunting-and-pecking technique using 446 the prime from the negotiated group's domain parameter set and an 447 ECP- or MODP-specific operation depending on the negotiated group. 448 This technique requires the pre-shared key to be a binary string, 449 therefore any password pre-processing transformation (see Section 6) 450 MUST be performed on a password prior to fixing SKE. 452 First, an 8-bit counter is set to the value one (1). Then, the 453 pseudo-random function is used to generate a secret seed using the 454 counter, the pre-shared key, and the two nonces exchanged by the 455 Initiator and the Responder: 457 ske-seed = prf(Ni | Nr, psk | counter) 459 Then, the ske-seed is expanded using prf+ to create an ske-value: 461 ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking") 463 where len(ske-value) is the same as len(p), the length of the prime 464 from the domain parameter set of the negotiated group. 466 If the ske-seed is greater than or equal to the prime, p, the counter 467 is incremented and a new ske-seed is generated and the hunting-and- 468 pecking continues. If ske-seed is less than the prime, p, it is 469 passed to the group-specific operation to select the SKE or fail. If 470 the group-specific operation fails, the counter is incremented, a new 471 ske-seed is generated and the hunting-and-pecking continues. 473 8.1.1. ECP Operation to Select SKE 475 The group-specific operation for ECP groups uses ske-value, ske-seed 476 and the equation of the curve to produce SKE. First ske-value is 477 used directly as the x-coordinate, x, with the equation of the 478 elliptic curve, with parameters a and b from the domain parameter set 479 of the curve, to solve for a y-coordinate, y. 481 If there is no solution to the equation the operation fails (and the 482 hunting-and-pecking continues). If a solution is found then an 483 ambiguity exists as there are technically two solutions to the 484 equation, and ske-seed is used to unambiguously select one of them. 485 If the low-order bit of ske-seed is equal to the low-order bit of y 486 then a candidate SKE is defined as the point (x,y); if the low-order 487 bit of ske-seed differs from the low-order bit of y then a candidate 488 SKE is defined as the point (x, p-y) where p is the prime from the 489 negotiated group's domain parameter set. The candidate SKE becomes 490 the SKE and the ECP-specific operation completes successfully. 492 Algorithmically, the process looks like this: 494 found = 0 495 counter = 1 496 do { 497 ske-seed = prf(Ni | Nr, psk | counter) 498 ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking") 499 if (ske-value < p) 500 then 501 x = ske-value 502 if ( (y = sqrt(x^3 + ax + b)) != FAIL) 503 then 504 if (LSB(y) == LSB(ske-seed)) 505 then 506 SKE = (x,y) 507 else 508 SKE = (x, p-y) 509 fi 510 found = 1 511 fi 512 fi 513 counter = counter + 1 514 } while (found == 0) 516 Figure 1: Fixing SKE for ECP Groups 518 8.1.2. MODP Operation to Select SKE 520 The group-specific operation for MODP groups takes ske-value, and the 521 prime, p, and order, r, from the group's domain parameter set to 522 directly produce a candidate SKE by exponentiating the ske-value to 523 the value ((p-1)/r) modulo the prime. If the candidate SKE is 524 greater than one (1) the candidate SKE becomes the SKE and the MODP- 525 specific operation completes successfully. Otherwise, the MODP- 526 specific operation fails (and the hunting-and-pecking continues). 528 Algorithmically, the process looks like this: 530 found = 0 531 counter = 1 532 do { 533 ske-seed = prf(Ni | Nr, psk | counter) 534 ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking") 535 if (ske-value < p) 536 then 537 SKE = ske-value ^ ((p-1)/r) mod p 538 if (SKE > 1) 539 then 540 found = 1 541 fi 542 fi 543 counter = counter + 1 544 } while (found == 0) 546 Figure 2: Fixing SKE for MODP Groups 548 8.2. Encoding and Decoding of Group Elements and Scalars 550 The payloads used in the secure pre-shared key authentication method 551 contain elements from the negotiated group and scalar values. To 552 ensure interoperability, scalars and field elements MUST be 553 represented in payloads in accordance with the requirements in this 554 section. 556 8.2.1. Encoding and Decoding of Scalars 558 Scalars MUST be represented (in binary form) as unsigned integers 559 that are strictly less than r, the order of the generator of the 560 agreed-upon cryptographic group. The binary representation of each 561 scalar MUST have a bit length equal to the bit length of the binary 562 representation of r. This requirement is enforced, if necessary, by 563 prepending the binary representation of the integer with zeros until 564 the required length is achieved. 566 Scalars in the form of unsigned integers are converted into octet- 567 strings and back again using the technique described in [FUN-ECC]. 569 8.2.2. Encoding and Decoding of ECP Elements 571 Elements in ECP groups are points on the negotiated elliptic curve. 572 Each such element MUST be represented by the concatenation of two 573 components, an x-coordinate and a y-coordinate. 575 Each of the two components, the x-coordinate and the y-coordinate, 576 MUST be represented (in binary form) as an unsigned integer that is 577 strictly less than the prime, p, from the group's domain parameter 578 set. The binary representation of each component MUST have a bit 579 length equal to the bit length of the binary representation of p. 580 This length requirement is enforced, if necessary, by prepending the 581 binary representation of the integer with zeros until the required 582 length is achieved. 584 The unsigned integers that represent the coordinates of the point are 585 converted into octet-strings and back again using the technique 586 described in [FUN-ECC]. 588 Since the field element is represented in a payload by the 589 x-coordinate followed by the y-coordinate it follows, then, that the 590 length of the element in the payload MUST be twice the bit length of 591 p. 593 8.2.3. Encoding and Decoding of MODP Elements 595 Elements in MODP groups MUST be represented (in binary form) as 596 unsigned integers that are strictly less than the prime, p, from the 597 group's domain parameter set. The binary representation of each 598 group element MUST have a bit length equal to the bit length of the 599 binary representation of p. This length requirement is enforced, if 600 necessary, by prepending the binary representation of the interger 601 with zeros until the required length is achieved. 603 The unsigned integer that represents a MODP element is converted into 604 an octet-string and back using the technique described in [FUN-ECC]. 606 8.3. Message Generation and Processing 608 8.3.1. Generation of a Commit 610 A Commit has two components, a scalar and an Element. To generate a 611 Commit, two random numbers, a "private" value and a "mask" value, are 612 generated (see Section 5). Their sum modulo the order of the group, 613 r, becomes the scalar component: 615 scalar = (private + mask) mod r 617 If the scalar is not greater than one (1), the private and mask 618 values MUST be thrown away and new values randomly generated. If the 619 scalar is greater than one (1), the inverse of the scalar operation 620 with the mask and SKE becomes the Element component. 622 Element = inverse(scalar-op(mask, SKE)) 624 The Commit payload consists of the scalar followed by the Element and 625 the scalar and Element are encoded in the Commit payload according to 626 Section 8.2. 628 8.3.2. Processing of a Commit 630 Upon receipt of a peer's Commit the scalar and element MUST be 631 validated. The processing of an element depends on the type, either 632 an ECP element or a MODP element. 634 8.3.2.1. Validation of an ECP Element 636 Validating a received ECP Element involves: 1) checking whether the 637 two coordinates, x and y, are both greater than zero (0) and less 638 than the prime defining the underlying field; and 2) checking whether 639 the x- and y-coordinates satisfy the equation of the curve (that is, 640 that they produce a valid point on the curve that is not "0"). If 641 either of these conditions are not met the received Element is 642 invalid, otherwise the received Element is valid. 644 8.3.2.2. Validation of a MODP Element 646 A received MODP Element is valid if: 1) it is between one (1) and the 647 prime, p, exclusive; and 2) if modular exponentiation of the Element 648 by the group order, r, equals one (1). If either of these conditions 649 are not true the received Element is invalid. 651 8.3.2.3. Commit Processing Steps 653 Commit validation is accomplished by the following steps: 655 1. The length of the Commit payload is checked against the 656 anticipated size (the length of the scalar plus the length of the 657 element for the negotiated group. If it is incorrect, the Commit 658 is invalidated, otherwise processing continues. 660 2. The peer's scalar is extracted from the Commit payload according 661 to Section 8.2.1 and checked to ensure it is between one (1) and 662 r, the order of the negotiated group, exclusive. If it is not, 663 the Commit is invalidated, otherwise processing continues. 665 3. The peer's Element is extracted from the Commit payload according 666 to Section 8.2.2 and checked in a manner that depends on the type 667 of group negotiated. If the group is ECP the element is 668 validated according to Section 8.3.2.1, if the group is MODP the 669 element is validated according to Section 8.3.2.2. If the 670 Element is not valid then the Commit is invalidated, otherwise 671 the Commit is validated. 673 4. The Initiator of the IKE exchange has an added requirement to 674 verify that the received element and scalar from the Commit 675 payload differ from the element and scalar sent to the Responder. 676 If they are identical, it signifies a reflection attack and the 677 Commit is invalidated. 679 If the Commit is invalidated the payload MUST be discarded and the 680 IKE exchange aborted. 682 8.3.3. Authentication of the Exchange 684 After a Commit has been generated and a peer's Commit has been 685 processed a shared secret used to authenticate the peer is derived. 686 Using SKE, the "private" value generated as part of Commit 687 generation, and the peer's scalar and Element from its Commit, named 688 here peer-scalar and peer-element, respectively, a preliminary shared 689 secret, skey, is generated as: 691 skey = F(scalar-op(private, 692 element-op(peer-element, 693 scalar-op(peer-scalar, SKE)))) 695 For the purposes of subsequent computation, the bit length of skey 696 SHALL be equal to the bit length of the prime, p, used in either a 697 MODP or ECP group. This bit length SHALL be enforced, if necessary, 698 by prepending zeros to the value until the required length is 699 achieved. 701 A shared secret, ss, is then computed from skey using prf(): 703 ss = prf(Ni | Nr, skey | "Secure PSK Authentication in IKE") 705 The shared secret, ss, is used in an authentication payload (either 706 AUTH or HASH payload depending on whether IKEv1 or IKEv2, 707 respectively, is being used) to prove possession of the shared 708 secret, and therefore knowledge of the pre-shared key. 710 8.4. Payload Format 711 8.4.1. Commit Payload 713 The Commit Payload is defined as follows: 715 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 ! Next Payload !C! RESERVED ! Payload Length ! 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Prep | | 721 +-+-+-+-+-+-+-+-+ Scalar ~ 722 | | 723 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | | | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 726 | | 727 ~ Element ~ 728 | | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 The Commit Payload SHALL be indicated in both IKEv1 and IKEv2 with 732 TBD1 from the [IKEV2-IANA] registry maintained by IANA. 734 The Prep field represents the password pre-processing technique (see 735 Section 6) to be used prior to generating the ske-seed (see 736 Section 8.1). This document defines the following values for the 737 Prep field: 739 o 0x00 : None 741 o 0x01 : RFC2759 743 o 0x02 : SASLprep 745 All other values of the Prep field are reserved to IANA. 747 The Scalar and Element SHALL be encoded in the Commit payload 748 according to Section 8.2. 750 8.5. IKEv1 Messaging 752 Secure PSK Authentication can be used in either Main Mode (see 753 Figure 3) or Aggressive Mode (see Figure 4) with IKEv1 and SHALL be 754 indicated by negotiation of the TBD2 Authentication Method from 755 [IKEV1-IANA], in the SA payload. When using IKEv1 the "C" (critical) 756 bit from Section 8.4.1 MUST be clear (i.e. a value of zero). 758 Initiator Responder 759 ----------- ----------- 760 HDR, SAi --> 761 <-- HDR, SAr 762 HDR, KEi, Ni --> 763 <-- HDR, KEr, Nr 764 HDR*, IDii, COMi --> 765 <-- HDR*, IDir, COMr 766 HDR*, HASH_I --> 767 <-- HDR*, HASH_R 769 where COMi is the Commit payload sent by the Initiator and COMr is 770 the Commit payload sent by the Responder. 772 Figure 3: Secure PSK in Main Mode 774 Initiator Responder 775 ----------- ----------- 776 HDR, SAi, KEi, Ni, IDii, 777 COMi --> 778 <-- HDR, SAr, KEr, Nr, IDir, COMr 779 HDR, HASH_I --> 780 <-- HDR, HASH_R 782 where COMi is the Commit payload sent by the Initiator and COMr is 783 the Commit payload sent by the Responder. 785 Figure 4: Secure PSK in Aggressive Mode 787 For Secure PSK Authentication with IKEv1 the SKEYID value is computed 788 as follows: 790 SKEYID = prf(Ni_b | Nr_b, g^xy) 792 Note that in Main Mode, SKEYID_a and SKEYID_e are used to protect the 793 messages containing the identities and Commit payloads. HASH_I and 794 HASH_R are computed as follows: 796 HASH_I = prf(SKEYID, ss | g^xi | g^xr | CKY-I | CKY-R | 797 SA_ib | IDii_b) 799 HASH_R = prf(SKEYID, ss | g^xr | g^xi | CKY-R | CKY-I | 800 SA_ib | IDir_b) 802 Where "ss" is the shared secret derived in Section 8.3.3. 804 8.6. IKEv2 Messaging 806 The specific authentication method being employed in IKEv2 is not 807 negotiated, like in IKEv1. It is inferred from the components of the 808 message. The presence of a Commit payload in second message sent by 809 the Initiator indicates an intention to perform secure pre-shared key 810 authentication (see Figure 5). The critical bit is used in the 811 Commit payload to prevent a peer that does not support Secure PSK 812 Authentication from inadvertantly attempting the insecure form of PSK 813 authentication in [RFC4306]; it MUST be set (i.e. a value of one). 815 Initiator Responder 816 ----------- ----------- 817 HDR, SAi1, KEi, Ni --> 818 <-- HDR, SAr1, KEr, Nr 819 HDR, SK {IDi, COMi, [IDr,] 820 SAi2, TSi, TSr} --> 821 <-- HDR, SK {IDr, COMr} 822 HDR, SK {AUTH} --> 823 <-- HDR, SK {AUTH, SAr2, TSi, TSr} 825 where COMi is the Commit payload sent by the Initiator and COMr is 826 the Commit payload sent by the Responder. 828 Figure 5: Secure PSK in IKEv2 830 In the case of secure pre-shared key authentication the AUTH value is 831 computed as: 833 AUTH = prf(ss, ) 835 Where "ss" is the shared secret derived in Section 8.3.3. The 836 Authentication Method indicated in the AUTH payload SHALL be TBD3 837 from [IKEV2-IANA]. 839 9. IANA Considerations 841 This memo contains a new numberspace to be managed by IANA, a 842 registry used to indicate a password preprocessing technique. The 843 initial layout of this registry SHALL be: 845 o 0x00 : None 847 o 0x01 : RFC2759 848 o 0x02 : SASLprep 850 The Prep field is 8 bits long and all other values are available 851 through assignment by IANA. IANA is instructed to assign values 852 based on "Specification Required" (see [RFC5226]). 854 IANA SHALL assign a value for the Commit payload (Section 8.4.1), and 855 replace TBD1 above, from the [IKEV2-IANA] of "IKEv2 Payload Types" 856 with the notation of "COM". 858 IANA SHALL assign a value for "Secure Shared Key Authentication", 859 replacing TBD2 above, from the IPSEC Authentication Method registry 860 in [IKEV1-IANA] with the method name of "Secure PSK Authentication." 862 IANA SHALL assign a value for "Secure Shared Key Authentication", 863 replacing TBD3 above, from the IKEv2 Authentication Method registry 864 in [IKEV2-IANA] with the Authentication Method name of "Secure PSK 865 Authentication." 867 10. Security Considerations 869 Both the Initiator and Responder obtain a shared secret, "ss" (see 870 Section 8.3.3) based on a secret group element and their own private 871 values contributed to the exchange. If they do not share the same 872 pre-shared key they will be unable to derive the same secret group 873 element and if they do not share the same secret group element they 874 will be unable to derive the same shared secret. 876 Resistance to dictionary attack means that the attacker must launch 877 an active attack to make a single guess at the pre-shared key. If 878 the size of the pool from which the key was extracted was D, and each 879 key in the pool has an equal probability of being chosen, then the 880 probability of success after a single guess is 1/D. After X guesses, 881 and removal of failed guesses from the pool of possible keys, the 882 probability becomes 1/(D-X). As X grows so does the probability of 883 success. Therefore it is possible for an attacker to determine the 884 pre-shared key through repeated brute-force, active, guessing 885 attacks. This authentication method does not presume to be secure 886 against this and implementations SHOULD ensure the size of D is 887 sufficiently large to prevent this attack. Implementations SHOULD 888 also take countermeasures, for instance refusing authentication 889 attempts for a certain amount of time, after the number of failed 890 authentication attempts reaches a certain threshold. No such 891 threshold or amount of time is recommended in this memo. 893 An active attacker can impersonate the Responder of the exchange and 894 send a forged Commit payload after receiving the Initiator's Commit. 896 The attacker then waits until it receives the authentication payload 897 from the Responder. Now the attacker can attempt to run through all 898 possible values of the pre-shared key, computing SKE (see 899 Section 8.1), computing "ss" (see Section 8.3.3), and attempting to 900 recreate the Confirm payload from the Responder. 902 But the attacker committed to a single guess of the pre-shared key 903 with her forged Commit. That value was used by the Responder in his 904 computation of "ss" which was used in the authentication payload. 905 Any guess of the pre-shared key which differs from the one used in 906 the forged Commit would result in each side using a different secret 907 element in the computation of "ss" and therefore the authentication 908 payload could not be verified as correct, even if a subsequent guess, 909 while running through all possible values, was correct. The attacker 910 gets one guess, and one guess only, per active attack. 912 An attacker, acting as either the Initiator or Responder, can take 913 the Element from the Commit message received from the other party, 914 reconstruct the random "mask" value used in its construction and then 915 recover the other party's "private" value from the Scalar in the 916 Commit message. But this requires the attacker to solve the discrete 917 logarithm problem which we assumed was intractable above (Section 7). 919 Instead of attempting to guess at pre-shared keys an attacker can 920 attempt to determine SKE and then launch an attack. But SKE is 921 determined by the output of the pseudo-random function, prf,, which 922 is assumed to be indistinguishable from a random source (Section 7). 923 Therefore, each element of the finite cyclic group will have an equal 924 probability of being the SKE. The probability of guessing SKE will 925 be 1/r, where r is the order of the group. This is the same 926 probability of guessing the solution to the discrete logarithm which 927 is assumed to be intractable (Section 7). The attacker would have a 928 better chance of success at guessing the input to prf, i.e. the pre- 929 shared key, since the order of the group will be many orders of 930 magnitude greater than the size of the pool of pre-shared keys. 932 The implications of resistance to dictionary attack are significant. 933 An implementation can provision a pre-shared key in a practical and 934 realistic manner-- i.e. it MAY be a character string and it MAY be 935 relatively short-- and still maintain security. The nature of the 936 pre-share key determines the size of the pool, D, and countermeasures 937 can prevent an attacker from determining the secret in the only 938 possible way: repeated, active, guessing attacks. For example, a 939 simple four character string using lower-case English characters, and 940 assuming random selection of those characters, will result in D of 941 over four hundred thousand. An attacker would need to mount over one 942 hundred thousand active, guessing attacks (which will easily be 943 detected) before gaining any significant advantage in determining the 944 pre-shared key. 946 For a more detailed discussion of the security of the key exchange 947 underlying this authentication method see [SAE] and [EAPPWD]. 949 11. Acknowledgements 951 The author would like to thank Scott Fluhrer and Hideyuki Suzuki for 952 their insight in discovering flaws in earlier versions of the key 953 exchange that underlies this authentication method and for their 954 helpful suggestions in improving it. Thanks to Lily Chen for useful 955 advice on the hunting-and-pecking technique to "hash into" an element 956 in a group and to Jin-Meng Ho for a discussion on countering a small 957 sub-group attack. Rich Davis suggested several checks on received 958 messages that greatly increase the security of the underlying key 959 exchange. Hugo Krawczyk suggested using the prf as an extractor. 961 12. References 963 12.1. Normative References 965 [FUN-ECC] McGrew, D., "Fundamental Elliptic Curve Cryptography 966 Algorithms", draft-mcgrew-fundamental-ecc-01 (work in 967 progress), October 2009. 969 [IKEV1-IANA] 970 "Internet Assigned Numbers Authority, Internet Key 971 Exchange (IKE) Attributes", 972 . 974 [IKEV2-IANA] 975 "Internet Assigned Numbers Authority, IKEv2 Parameters", 976 . 978 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 979 Hashing for Message Authentication", RFC 2104, 980 February 1997. 982 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 983 Requirement Levels", BCP 14, RFC 2119, March 1997. 985 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 986 (IKE)", RFC 2409, November 1998. 988 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 989 RFC 2759, January 2000. 991 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 992 Internationalized Strings ("stringprep")", RFC 3454, 993 December 2002. 995 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 996 and Passwords", RFC 4013, February 2005. 998 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 999 RFC 4306, December 2005. 1001 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1002 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1003 May 2008. 1005 12.2. Informative References 1007 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 1008 Password-Based Protocols Secure Against Dictionary 1009 Attack", Proceedings of the IEEE Symposium on Security and 1010 Privacy, Oakland, 1992. 1012 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 1013 Password Authenticated Key Exchange Using Diffie-Hellman", 1014 Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag, 1015 2000. 1017 [BPR00] Bellare, M., Pointcheval, D., and P. Rogaway, 1018 "Authenticated Key Exchange Secure Against Dictionary 1019 Attacks", Advances in Cryptology -- Eurocrypt '00, Lecture 1020 Notes in Computer Science Springer-Verlag, 2000. 1022 [EAPPWD] Harkins, D. and G. Zorn, "EAP Authentication Using Only A 1023 Password", draft-harkins-emu-eap-pwd-12 (work in 1024 progress), October 2009. 1026 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1027 Requirements for Security", BCP 106, RFC 4086, June 2005. 1029 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1030 Internet Protocol", RFC 4301, December 2005. 1032 [SAE] Harkins, D., "Simultaneous Authentication of Equals: A 1033 Secure, Password-Based Key Exchange for Mesh Networks", 1034 Proceedings of the 2008 Second International Conference on 1035 Sensor Technologies and Applications Volume 00, 2008. 1037 [XAUTH] Pereira, R. and S. Beaulieu, "Extended Authenticaiton 1038 within ISAKMP/Oakley (XAUTH)", 1039 draft-ietf-ipsec-isakmp-xauth-06.txt (work in progress), 1040 December 1999. 1042 Author's Address 1044 Dan Harkins 1045 Aruba Networks 1046 1322 Crossman Avenue 1047 Sunnyvale, CA 94089-1113 1048 United States of America 1050 Email: dharkins@arubanetworks.com