idnits 2.17.1 draft-harkins-ipsecme-spsk-auth-06.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 == Line 40 has weird spacing: '...date of publi...' == 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 (January 13, 2012) is 4459 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: 4 errors (**), 0 flaws (~~), 3 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 January 13, 2012 5 Expires: July 16, 2012 7 Secure PSK Authentication for IKE 8 draft-harkins-ipsecme-spsk-auth-06 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 July 16, 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 (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 . . . . . . . . . 5 58 4.2. Finite Field Cryptography (MODP) Groups . . . . . . . . . 6 59 5. Random Numbers . . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Using Passwords and Raw Keys For Authentication . . . . . . . 8 61 7. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 8. Secure PSK Authentication Message Exchange . . . . . . . . . . 9 63 8.1. Negotiation of Secure PSK Authentication . . . . . . . . . 10 64 8.2. Fixing the Secret Element, SKE . . . . . . . . . . . . . . 10 65 8.2.1. ECP Operation to Select SKE . . . . . . . . . . . . . 11 66 8.2.2. MODP Operation to Select SKE . . . . . . . . . . . . . 12 67 8.3. Encoding and Decoding of Group Elements and Scalars . . . 13 68 8.3.1. Encoding and Decoding of Scalars . . . . . . . . . . . 13 69 8.3.2. Encoding and Decoding of ECP Elements . . . . . . . . 13 70 8.3.3. Encoding and Decoding of MODP Elements . . . . . . . . 14 71 8.4. Message Generation and Processing . . . . . . . . . . . . 14 72 8.4.1. Generation of a Commit . . . . . . . . . . . . . . . . 14 73 8.4.2. Processing of a Commit . . . . . . . . . . . . . . . . 15 74 8.4.2.1. Validation of an ECP Element . . . . . . . . . . . 15 75 8.4.2.2. Validation of a MODP Element . . . . . . . . . . . 15 76 8.4.2.3. Commit Processing Steps . . . . . . . . . . . . . 15 77 8.4.3. Authentication of the Exchange . . . . . . . . . . . . 16 78 8.5. Payload Format . . . . . . . . . . . . . . . . . . . . . . 16 79 8.5.1. Commit Payload . . . . . . . . . . . . . . . . . . . . 16 80 8.6. IKEv2 Messaging . . . . . . . . . . . . . . . . . . . . . 17 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 1. Introduction 91 [RFC5996] allows for authentication of the IKE peers using a pre- 92 shared key. This exchange, though, is susceptible to dictionary 93 attack and is therefore insecure. To address the security issue, 94 [RFC5996] recommends that the pre-shared key used for authentication 95 "contain as much unpredictability as the strongest key being 96 negotiated". That means any non-hexidecimal key would require over 97 100 characters to provide enough strength to generate a 128-bit key 98 suitable for AES. This is an unrealistic requirement because humans 99 have a hard time entering a string over 20 characters without error. 100 Consequently, pre-shared key authentication in [RFC5996] is used 101 insecurely today. 103 A pre-shared key authentication method built on top of a zero- 104 knowledge proof will provide resistance to dictionary attack and 105 still allow for security when used with weak pre-shared keys, such as 106 user-chosen passwords. Such an authentication method is described in 107 this memo. 109 Resistance to dictionary attack is achieved when an adversary gets 110 one, and only one, guess at the secret per active attack (see for 111 example, [BM92], [BMP00] and [BPR00]). Another way of putting this 112 is that any advantage the adversary can realize is through 113 interaction and not through computation. This is demonstrably 114 different than the technique from [RFC5996] of using a large, random 115 number as the pre-shared key. That can only make a dictionary attack 116 less likely to succeed, it does not prevent a dictionary attack. 117 And, as [RFC5996] notes, it is completely insecure when used with 118 weak keys like user-generated passwords. 120 1.1. Keyword Definitions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Usage Scenarios 128 [RFC5996] describes usage scenarios for IKEv2. These are: 130 1. "Security Gateway to Security Gateway Tunnel": the endpoints of 131 the IKE (and IPsec) communication are network nodes that protect 132 traffic on behalf of connected networks. Protected traffic is 133 between devices on the respective protected networks. 135 2. "Endpoint-to-Endpoint Transport": the endpoints of the IKE (and 136 IPsec) communication are hosts according to [RFC4301]. Protected 137 traffic is between the two endpoints. 139 3. "Endpoint to Securty Gateway Tunnel": one endpoint connects to a 140 protected network through a network node. The endpoints of the 141 IKE (and IPsec) communication are the endpoint and network node, 142 but the protected traffic is between the endpoint and another 143 device on the protected network behind the node. 145 The authentication and key exchange described in this memo is 146 suitable for all the usage scenarios described in [RFC5996]. In the 147 "Security Gateway to Security Gateway Tunnel" scenario and the 148 "Endpoint-to-Endpoint Transport" scenario it provides a secure method 149 of authentication without requiring a certificate. For the "Endpoint 150 to Security Gateway Tunnel" scenario it provides for secure username+ 151 password authentication that is popular in remote access VPN 152 situations. 154 3. Notation 156 The following notation is used in this memo: 158 PSK 159 A shared, secret and potentially low-entropy word, phrase, code 160 or key used as a credential to mutually authenticate the peers. 162 a = prf(b, c) 163 The string "b" and "c" are given to a pseudo-random function to 164 produce a fixed-length output "a". 166 a | b 167 denotes concatenation of string "a" with string "b". 169 [a]b 170 indicates a string consisting of the single bit "a" repeated "b" 171 times. 173 len(a) 174 indicates the length in bits of the string "a". 176 LSB(a) 177 returns the least-significant bit of the bitstring "a". 179 The convention for this memo to represent an element in a finite 180 cyclic group is to use an upper-case letter or acronym, while a 181 scalar is indicated with a lower-case letter or acronym. 183 4. Discrete Logarithm Cryptography 185 This protocol uses Discrete Logarithm Cryptography to achieve 186 authentication. Each party to the exchange derives ephemeral public 187 and private keys with respect to a particular set of domain 188 parameters (referred to here as a "group"). Groups can be either 189 based on finite field cryptography (MODP groups) or elliptic curve 190 cryptography (ECP groups). 192 This protocol uses the same group as the IKE exchange in which it is 193 being used for authentication, with the exception of characteristic- 194 two elliptic curve groups (EC2N). Use of such groups is undefined 195 for this authentication method and an IKE exchange that negotiates 196 one of these groups MUST NOT use this method of authentication. 198 For each group the following operations are defined: 200 o "scalar operation"-- taking a scalar and an element in the group 201 producing another element-- Z = scalar-op(x, Y). 203 o "element operation"-- taking two elements in the group to produce 204 a third-- Z = element-op(X, Y). 206 o "inverse operation"-- take an element and returns another element 207 such that the element operation on the two produces the identity 208 element of the group-- Y = inverse(X). 210 4.1. Elliptic Curve Cryptography (ECP) Groups 212 The key exchange defined in this memo uses fundamental algorithms of 213 ECP groups as described in [RFC6090]. 215 Domain parameters for ECP elliptic curves used for secure pre-shared 216 key-based authentication include: 218 o A prime, p, determining a prime field GF(p). The cryptographic 219 group will be a subgroup of the full elliptic curve group which 220 consists points on an elliptic curve-- elements from GF(p) that 221 satisfy the curve's equation-- together with the "point at 222 infinity" (denoted here as "O") that serves as the identity 223 element. 225 o Elements a and b from GF(p) that define the curve's equation. The 226 point (x,y) is on the elliptic curve if and only if y^2 = x^3 + 227 a*x + b. 229 o A prime, r, which is the order of G, and thus is also the size of 230 the cryptographic subgroup that is generated by G. 232 The scalar operation is multiplication of a point on the curve by 233 itself a number of times. The point Y is multiplied x-times to 234 produce another point Z: 236 Z = scalar-op(x, Y) = x*Y 238 The element operation is addition of two points on the curve. Points 239 X and Y are summed to produce another point Z: 241 Z = element-op(X, Y) = X + Y 243 The inverse function is defined such that the sum of an element and 244 its inverse is "0": 246 Q + inverse(Q) = "O" 248 Elliptic curve groups require a mapping function, q = F(Q), to 249 convert a group element to an integer. The mapping function used in 250 this memo returns the x-coordinate of the point it is passed. 252 scalar-op(x, Y) can be viewed as x iterations of element-op() by 253 defining: 255 Y = scalar-op(1, Y) 257 Y = scalar-op(x, Y) = element-op(Y, scalar-op(x-1, Y)), for x > 1 259 A definition of how to add two points on an elliptic curve (i.e. 260 element-op(X, Y)) can be found in [RFC6090]. 262 Note: There is another ECP domain parameter, a co-factor, h, that is 263 defined by the requirement that the size of the full elliptic curve 264 group (including "O") be the product of h and r. ECP groups used for 265 secure pre-shared key-based authentication MUST have a co-factor of 266 one (1). At the time of publication of this memo, all ECP groups in 267 the IANA registry used by IKE had a co-factor of one (1). 269 4.2. Finite Field Cryptography (MODP) Groups 271 Domain parameters for MODP groups used for secure pre-shared key- 272 based authentication include: 274 o A prime, p, determining a prime field GF(p), the integers modulo 275 p. 277 o A prime, r, which is the multiplicative order of G, and thus also 278 the size of the cryptographic subgroup of GF(p)* that is generated 279 by G. 281 The scalar operation is exponentiation of a generator modulus a 282 prime. An element Y is taken to the x-th power modulo the prime 283 returning another element, Z: 285 Z = scalar-op(x, Y) = Y^x mod p 287 The element operation is modular multiplication. Two elementx, X and 288 Y, are multiplied modulo the prime returning another element, Z: 290 Z = element-op(X, Y) = (X * Y) mod p 292 The inverse function for a MODP group is defined such that the 293 product of an element and its inverse modulo the group prime equals 294 one (1). In other words, 296 (Q * inverse(Q)) mod p = 1 298 Unlike ECP groups, MODP groups do not require a mapping function to 299 convert an element into a scalar. But for the purposes of notation 300 in protocol definition, the function F, when used below, shall just 301 return the value that was passed to it-- i.e. F(i) = i. 303 Some MODP groups in the IANA registry for use by IKE (and the secure 304 pre-shared key authentication method) are based on safe primes and 305 the order is not included in the group's domain parameter set. In 306 this case only, the order, r, MUST be computed as the prime minus one 307 divided by two-- (p-1)/2. If an order is included in the group's 308 domain parameter set that value MUST be used in this exchange when an 309 order is called for. If a MODP group does not include an order in 310 its domain parameter set and is not based on a safe prime it MUST NOT 311 be used with this exchange. 313 5. Random Numbers 315 As with IKE itself, the security of the secure pre-shared key 316 authentication method relies upon each participant in the protocol 317 producing quality secret random numbers. A poor random number chosen 318 by either side in a single exchange can compromise the shared secret 319 from that exchange and open up the possibility of dictionary attack. 321 Producing quality random numbers without specialized hardware entails 322 using a cryptographic mixing function (like a strong hash function) 323 to distill entropy from multiple, uncorrelated sources of information 324 and events. A very good discussion of this can be found in 325 [RFC4086]. 327 6. Using Passwords and Raw Keys For Authentication 329 The PSK used as an authentication credential with this protocol can 330 be either a character-based password or passphrase, or it could be a 331 binary or hexidecimal string. Regardless though, this protocol 332 requires both the Initiator and Responder to have identical binary 333 representations of the shared credential. 335 If the PSK is a character-based password or passphrase, there are two 336 types of pre-preprocessing that SHALL be employed to convert the 337 password or passphrase into a hexidecimal string suitable for use 338 with Secure PSK authentication. If a PSK is already a hexidecimal or 339 binary string it can be used directly as the shared credential 340 without any pre-processing. 342 The first step of pre-processing is to remove ambiguities that may 343 arise due to internationalization. Each character-based password or 344 passphrase MUST be pre-processed to remove that ambiguity by 345 processing the character-based password or passphrase according to 346 the rules of the [RFC4013] profile of [RFC3454]. The password or 347 passphrase SHALL be considered a "stored string" per [RFC3454] and 348 unassigned code points are therefore prohibited. The output SHALL be 349 the binary representation of the processed UTF-8 character string. 350 Prohibited output and unassigned codepoints encountered in SASLprep 351 pre-processing SHALL cause a failure of pre-processing and the output 352 SHALL NOT be used with Secure Password Authentication. 354 The next pre-processing step for character-based passwords or 355 passphrases is to effectively obfuscate the string. This is done in 356 an attempt to reduce exposure of stored passwords in the event of 357 server compromise, or compromise of a server's database of stored 358 passwords. The step involves taking the output of the [RFC4013] 359 profile of [RFC3454] and passing it, as the key, with the ASCII 360 string "IKE Secure PSK Authentication", as the data, to HMAC- 361 SHA256(). The output of this obfuscation step SHALL become the 362 shared credential used with Secure PSK Authentication. 364 Note: Passwords tend to be shared for multiple purposes and 365 compromise of a server or database of stored plaintext passwords can 366 be used, in that event, to mount multiple attacks. The obfuscation 367 step is merely to hide the password in the event of server compromise 368 or compromise of the database of stored passwords. Advances in 369 distributed computing power have diminished the effectiveness of 370 performing multiple prf iterations as a technique to prevent 371 dictionary attacks, so no such behavior is proscribed here. Mutually 372 consenting implementations can agree to use a different password 373 obfuscation method, the one described here is for interoperability 374 purposes only. 376 If a device stores passwords for use at a later time it MUST pre- 377 process the password prior to storage. If a user enters a password 378 into a device at authentication time it MUST be pre-processed upon 379 entry and prior to use with Secure PSK Authentication. 381 7. Assumptions 383 The security of the protocol relies on certain assumptions. They 384 are: 386 1. The pseudo-random function, prf, defined in [RFC5996]) acts as an 387 "extractor" (see [RFC5869]) by concentrating the entropy from a 388 secret input into a short, fixed, string. The output of prf is 389 indistinguishable from a random source. 391 2. The discrete logarithm problem for the chosen finite cyclic group 392 is hard. That is, given G, p and Y = G^x mod p it is 393 computationally infeasible to determine x. Similarly for an 394 elliptic curve group given the curve definition, a generator G, 395 and Y = x * G it is computationally infeasible to determine x. 397 3. The pre-shared key is drawn from a finite pool of potential keys. 398 Each possible key in the pool has equal probability of being the 399 shared key. All potential adversaries have access to this pool 400 of keys. 402 8. Secure PSK Authentication Message Exchange 404 The key exchange described in this memo is based on the "Dragonfly" 405 key exchange which has also been proposed in 802.11 wireless networks 406 (see [SAE]) and as an EAP method (see [RFC5931]). "Dragonfly" is 407 patent-free and royalty-free. It makes use of the same pseudo-random 408 function (prf) and the same Diffie-Hellman group that are negotiated 409 for use in the IKE exchange that "dragonfly" is authenticating. 411 A pseudo-random function which uses a block cipher is NOT RECOMMENDED 412 for use with Secure PSK Authentication due to its poor job operating 413 as an "extractor" (see Section 7). Pseudo-random functions based on 414 hash functions using the HMAC construct from [RFC2104] SHOULD be 415 used. 417 To perform secure pre-shared key authentication each side must 418 generate a shared and secret element in the chosen group based on the 419 pre-shared key. This element, called the Secret Key Element, or SKE, 420 is then used in the "Dragonfly" authentication and key exchange 421 protocol. "Dragonfly" consists of each side exchanging a "Commit" 422 payload and then proving knowledge of the resulting shared secret. 424 The "Commit" payload contributes ephemeral information to the 425 exchange and binds the sender to a single value of the pre-shared key 426 from the pool of potential pre-shared keys. An authentication 427 payload (AUTH) proves that the pre-shared key is known and completes 428 the zero-knowledge proof. 430 8.1. Negotiation of Secure PSK Authentication 432 The Initiator indicates its desire to use Secure PSK Authentication, 433 by adding a Notify payload of type SECURE_PASSWORD_METHODS (see 434 [RFC6467]) to the first message of the IKE_SA_INIT exchange and by 435 putting TBD in the notification data field of the Notify payload, 436 indicating SPSK Authentication. 438 The Responder indicates its desire to perform Secure PSK 439 Authentication, by adding a Notify payload of type 440 SECURE_PASSWORD_METHODS to its response in the IKE_SA_INIT exchange 441 and by echoing back TBD in the notification data field of the Notify 442 payload. 444 8.2. Fixing the Secret Element, SKE 446 The method of fixing SKE depends on the type of group, either MODP or 447 ECP. The function "prf+" from [RFC5996] is used as a key derivation 448 function. 450 Fixing SKE involves an iterative hunting-and-pecking technique using 451 the prime from the negotiated group's domain parameter set and an 452 ECP- or MODP-specific operation depending on the negotiated group. 453 This technique requires the pre-shared key to be a binary string, 454 therefore any pre-processing transformation (see Section 6) MUST be 455 performed on the pre-shared key prior to fixing SKE. 457 First, an 8-bit counter is set to the value one (1). Then, the 458 pseudo-random function is used to generate a secret seed using the 459 counter, the pre-shared key, and two nonces (without the fixed 460 headers) exchanged by the Initiator and the Responder (see 461 Section 8.6): 463 ske-seed = prf(Ni | Nr, psk | counter) 465 Then, the ske-seed is expanded using prf+ to create an ske-value: 467 ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking") 469 where len(ske-value) is the same as len(p), the length of the prime 470 from the domain parameter set of the negotiated group. 472 If the ske-seed is greater than or equal to the prime, p, the counter 473 is incremented and a new ske-seed is generated and the hunting-and- 474 pecking continues. If ske-seed is less than the prime, p, it is 475 passed to the group-specific operation to select the SKE or fail. If 476 the group-specific operation fails, the counter is incremented, a new 477 ske-seed is generated and the hunting-and-pecking continues. 479 Note: The probability that more than "n" iterations of the "hunting- 480 and-pecking" loop are required to find SKE is roughly (1-(r/2p))^n 481 which rapidly approaches zero (0) as "n" increases. 483 8.2.1. ECP Operation to Select SKE 485 The group-specific operation for ECP groups uses ske-value, ske-seed 486 and the equation of the curve to produce SKE. First ske-value is 487 used directly as the x-coordinate, x, with the equation of the 488 elliptic curve, with parameters a and b from the domain parameter set 489 of the curve, to solve for a y-coordinate, y. 491 If there is no solution to the equation the operation fails (and the 492 hunting-and-pecking continues). If a solution is found then an 493 ambiguity exists as there are technically two solutions to the 494 equation, and ske-seed is used to unambiguously select one of them. 495 If the low-order bit of ske-seed is equal to the low-order bit of y 496 then a candidate SKE is defined as the point (x,y); if the low-order 497 bit of ske-seed differs from the low-order bit of y then a candidate 498 SKE is defined as the point (x, p-y) where p is the prime from the 499 negotiated group's domain parameter set. The candidate SKE becomes 500 the SKE and the ECP-specific operation completes successfully. 502 Algorithmically, the process looks like this: 504 found = 0 505 counter = 1 506 do { 507 ske-seed = prf(Ni | Nr, psk | counter) 508 ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking") 509 if (ske-value < p) 510 then 511 x = ske-value 512 if ( (y = sqrt(x^3 + ax + b)) != FAIL) 513 then 514 if (LSB(y) == LSB(ske-seed)) 515 then 516 SKE = (x,y) 517 else 518 SKE = (x, p-y) 519 fi 520 found = 1 521 fi 522 fi 523 counter = counter + 1 524 } while (found == 0) 526 Figure 1: Fixing SKE for ECP Groups 528 8.2.2. MODP Operation to Select SKE 530 The group-specific operation for MODP groups takes ske-value, and the 531 prime, p, and order, r, from the group's domain parameter set to 532 directly produce a candidate SKE by exponentiating the ske-value to 533 the value ((p-1)/r) modulo the prime. If the candidate SKE is 534 greater than one (1) the candidate SKE becomes the SKE and the MODP- 535 specific operation completes successfully. Otherwise, the MODP- 536 specific operation fails (and the hunting-and-pecking continues). 538 Algorithmically, the process looks like this: 540 found = 0 541 counter = 1 542 do { 543 ske-seed = prf(Ni | Nr, psk | counter) 544 ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking") 545 if (ske-value < p) 546 then 547 SKE = ske-value ^ ((p-1)/r) mod p 548 if (SKE > 1) 549 then 550 found = 1 551 fi 552 fi 553 counter = counter + 1 554 } while (found == 0) 556 Figure 2: Fixing SKE for MODP Groups 558 8.3. Encoding and Decoding of Group Elements and Scalars 560 The payloads used in the secure pre-shared key authentication method 561 contain elements from the negotiated group and scalar values. To 562 ensure interoperability, scalars and field elements MUST be 563 represented in payloads in accordance with the requirements in this 564 section. 566 8.3.1. Encoding and Decoding of Scalars 568 Scalars MUST be represented (in binary form) as unsigned integers 569 that are strictly less than r, the order of the generator of the 570 agreed-upon cryptographic group. The binary representation of each 571 scalar MUST have a bit length equal to the bit length of the binary 572 representation of r. This requirement is enforced, if necessary, by 573 prepending the binary representation of the integer with zeros until 574 the required length is achieved. 576 Scalars in the form of unsigned integers are converted into octet- 577 strings and back again using the technique described in [RFC6090]. 579 8.3.2. Encoding and Decoding of ECP Elements 581 Elements in ECP groups are points on the negotiated elliptic curve. 582 Each such element MUST be represented by the concatenation of two 583 components, an x-coordinate and a y-coordinate. 585 Each of the two components, the x-coordinate and the y-coordinate, 586 MUST be represented (in binary form) as an unsigned integer that is 587 strictly less than the prime, p, from the group's domain parameter 588 set. The binary representation of each component MUST have a bit 589 length equal to the bit length of the binary representation of p. 590 This length requirement is enforced, if necessary, by prepending the 591 binary representation of the integer with zeros until the required 592 length is achieved. 594 The unsigned integers that represent the coordinates of the point are 595 converted into octet-strings and back again using the technique 596 described in [RFC6090]. 598 Since the field element is represented in a payload by the 599 x-coordinate followed by the y-coordinate it follows, then, that the 600 length of the element in the payload MUST be twice the bit length of 601 p. 603 8.3.3. Encoding and Decoding of MODP Elements 605 Elements in MODP groups MUST be represented (in binary form) as 606 unsigned integers that are strictly less than the prime, p, from the 607 group's domain parameter set. The binary representation of each 608 group element MUST have a bit length equal to the bit length of the 609 binary representation of p. This length requirement is enforced, if 610 necessary, by prepending the binary representation of the interger 611 with zeros until the required length is achieved. 613 The unsigned integer that represents a MODP element is converted into 614 an octet-string and back using the technique described in [RFC6090]. 616 8.4. Message Generation and Processing 618 8.4.1. Generation of a Commit 620 Before a Commit can be generated, the SKE must be fixed using the 621 process described in Section 8.2. 623 A Commit has two components, a scalar and an Element. To generate a 624 Commit, two random numbers, a "private" value and a "mask" value, are 625 generated (see Section 5). Their sum modulo the order of the group, 626 r, becomes the scalar component: 628 scalar = (private + mask) mod r 630 If the scalar is not greater than one (1), the private and mask 631 values MUST be thrown away and new values randomly generated. If the 632 scalar is greater than one (1), the inverse of the scalar operation 633 with the mask and SKE becomes the Element component. 635 Element = inverse(scalar-op(mask, SKE)) 637 The Commit payload consists of the scalar followed by the Element and 638 the scalar and Element are encoded in the Commit payload according to 639 Section 8.3. 641 8.4.2. Processing of a Commit 643 Upon receipt of a peer's Commit the scalar and element MUST be 644 validated. The processing of an element depends on the type, either 645 an ECP element or a MODP element. 647 8.4.2.1. Validation of an ECP Element 649 Validating a received ECP Element involves: 1) checking whether the 650 two coordinates, x and y, are both greater than zero (0) and less 651 than the prime defining the underlying field; and 2) checking whether 652 the x- and y-coordinates satisfy the equation of the curve (that is, 653 that they produce a valid point on the curve that is not "0"). If 654 either of these conditions are not met the received Element is 655 invalid, otherwise the received Element is valid. 657 8.4.2.2. Validation of a MODP Element 659 A received MODP Element is valid if: 1) it is between one (1) and the 660 prime, p, exclusive; and 2) if modular exponentiation of the Element 661 by the group order, r, equals one (1). If either of these conditions 662 are not true the received Element is invalid. 664 8.4.2.3. Commit Processing Steps 666 Commit validation is accomplished by the following steps: 668 1. The length of the Commit payload is checked against its 669 anticipated length (the anticipated length of the scalar plus the 670 anticipated length of the element, for the negotiated group). If 671 it is incorrect, the Commit is invalidated, otherwise processing 672 continues. 674 2. The peer's scalar is extracted from the Commit payload according 675 to Section 8.3.1 and checked to ensure it is between one (1) and 676 r, the order of the negotiated group, exclusive. If it is not, 677 the Commit is invalidated, otherwise processing continues. 679 3. The peer's Element is extracted from the Commit payload according 680 to Section 8.3.2 and checked in a manner that depends on the type 681 of group negotiated. If the group is ECP the element is 682 validated according to Section 8.4.2.1, if the group is MODP the 683 element is validated according to Section 8.4.2.2. If the 684 Element is not valid then the Commit is invalidated, otherwise 685 the Commit is validated. 687 4. The Initiator of the IKE exchange has an added requirement to 688 verify that the received element and scalar from the Commit 689 payload differ from the element and scalar sent to the Responder. 690 If they are identical, it signifies a reflection attack and the 691 Commit is invalidated. 693 If the Commit is invalidated the payload MUST be discarded and the 694 IKE exchange aborted. 696 8.4.3. Authentication of the Exchange 698 After a Commit has been generated and a peer's Commit has been 699 processed a shared secret used to authenticate the peer is derived. 700 Using SKE, the "private" value generated as part of Commit 701 generation, and the peer's scalar and Element from its Commit, named 702 here peer-scalar and peer-element, respectively, a preliminary shared 703 secret, skey, is generated as: 705 skey = F(scalar-op(private, 706 element-op(peer-element, 707 scalar-op(peer-scalar, SKE)))) 709 For the purposes of subsequent computation, the bit length of skey 710 SHALL be equal to the bit length of the prime, p, used in either a 711 MODP or ECP group. This bit length SHALL be enforced, if necessary, 712 by prepending zeros to the value until the required length is 713 achieved. 715 A shared secret, ss, is then computed from skey and the nonces 716 exchanged by the Initiator (Ni) and Responder (Nr) (without the fixed 717 headers) using prf(): 719 ss = prf(Ni | Nr, skey | "Secure PSK Authentication in IKE") 721 The shared secret, ss, is used in an AUTH authentication payload to 722 prove possession of the shared secret, and therefore knowledge of the 723 pre-shared key. 725 8.5. Payload Format 727 8.5.1. Commit Payload 729 [RFC6467]) defines a Generic Secure Password Method (GSPM) payload 730 which is used to convey information that is specific to a particular 731 secure password method. This memo uses the GSPM payload as a "Commit 732 Payload" to contain the Scalar and Element used in the SPSK exchange: 734 The Commit Payload is defined as follows: 736 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 ! Next Payload !C! RESERVED ! Payload Length ! 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | | 742 + Scalar ~ 743 | | 744 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | | | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 747 | | 748 ~ Element ~ 749 | | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 The Scalar and Element SHALL be encoded in the Commit payload 753 according to Section 8.3. 755 8.6. IKEv2 Messaging 757 SPSK authentication modifies the IKE_AUTH exchange by adding one 758 additional round trip to exchange Commit payloads to perform the 759 Secure PSK Authentication exchange, and by changing the calculation 760 of the AUTH payload data to bind the IKEv2 exchange to the outcome of 761 the Secure PSK Authentication exchange (see Figure 3). 763 Initiator Responder 764 ----------- ----------- 766 IKE_SA_INIT: 768 HDR, SAi1, KEi, Ni, 769 N(SPM-SPSK) --> 771 <-- HDR, SAr1, KEr, Nr, 772 N(SPM-SPSK) 774 IKE_AUTH: 776 HDR, SK {IDi, COMi, [IDr,] 777 SAi2, TSi, TSr} --> 778 <-- HDR, SK {IDr, COMr} 779 HDR, SK {AUTHi} --> 780 <-- HDR, SK {AUTHr, SAr2, TSi, TSr} 782 where N(SPM-SPSK) indicates the Secure Password Methods Notify 783 payloads used to negotiate the use of SPSK authentication (see 784 Section 8.1), COMi and AUTHi are the Commit payload and AUTH payload, 785 respectively, sent by the Initiator and COMr and AUTHr are the Commit 786 payload and AUTH payload, respectively, sent by the Responder. 788 Figure 3: Secure PSK in IKEv2 790 The AUTH payloads when doing SPSK authentication SHALL be computed as 792 AUTHi = prf(ss, | COMi | COMr) 794 AUTHr = prf(ss, | COMr | COMi) 796 Where "ss" is the shared secret derived in Section 8.4.3, COMi and 797 COMr are the entire Commit payloads (including the fixed headers) 798 sent by the Initiator and Responder, respectively, and 799 and are defined in 800 [RFC5996]. The Authentication Method indicated in both AUTH payloads 801 SHALL be "Secure Password Authentication Method" from [IKEV2-IANA]. 803 9. IANA Considerations 805 IANA SHALL assign a value for "Secure PSK Authentication", replacing 806 TBD above, from the Secure Password Authentication Method registry in 807 [IKEV2-IANA] with the method name of "Secure PSK Authentication". 809 10. Security Considerations 811 Both the Initiator and Responder obtain a shared secret, "ss" (see 812 Section 8.4.3) based on a secret group element and their own private 813 values contributed to the exchange. If they do not share the same 814 pre-shared key they will be unable to derive the same secret group 815 element and if they do not share the same secret group element they 816 will be unable to derive the same shared secret. 818 Resistance to dictionary attack means that the adversary must launch 819 an active attack to make a single guess at the pre-shared key. If 820 the size of the pool from which the key was extracted was D, and each 821 key in the pool has an equal probability of being chosen, then the 822 probability of success after a single guess is 1/D. After X guesses, 823 and removal of failed guesses from the pool of possible keys, the 824 probability becomes 1/(D-X). As X grows so does the probability of 825 success. Therefore it is possible for an adversary to determine the 826 pre-shared key through repeated brute-force, active, guessing 827 attacks. This authentication method does not presume to be secure 828 against this and implementations SHOULD ensure the size of D is 829 sufficiently large to prevent this attack. Implementations SHOULD 830 also take countermeasures, for instance refusing authentication 831 attempts for a certain amount of time, after the number of failed 832 authentication attempts reaches a certain threshold. No such 833 threshold or amount of time is recommended in this memo. 835 An active attacker can impersonate the Responder of the exchange and 836 send a forged Commit payload after receiving the Initiator's Commit. 837 The attacker then waits until it receives the authentication payload 838 from the Responder. Now the attacker can attempt to run through all 839 possible values of the pre-shared key, computing SKE (see 840 Section 8.2), computing "ss" (see Section 8.4.3), and attempting to 841 recreate the Confirm payload from the Responder. 843 But the attacker committed to a single guess of the pre-shared key 844 with her forged Commit. That value was used by the Responder in his 845 computation of "ss" which was used in the authentication payload. 846 Any guess of the pre-shared key which differs from the one used in 847 the forged Commit would result in each side using a different secret 848 element in the computation of "ss" and therefore the authentication 849 payload could not be verified as correct, even if a subsequent guess, 850 while running through all possible values, was correct. The attacker 851 gets one guess, and one guess only, per active attack. 853 An attacker, acting as either the Initiator or Responder, can take 854 the Element from the Commit message received from the other party, 855 reconstruct the random "mask" value used in its construction and then 856 recover the other party's "private" value from the Scalar in the 857 Commit message. But this requires the attacker to solve the discrete 858 logarithm problem which we assumed was intractable above (Section 7). 860 Instead of attempting to guess at pre-shared keys an attacker can 861 attempt to determine SKE and then launch an attack. But SKE is 862 determined by the output of the pseudo-random function, prf, which is 863 assumed to be indistinguishable from a random source (Section 7). 864 Therefore, each element of the finite cyclic group will have an equal 865 probability of being the SKE. The probability of guessing SKE will 866 be 1/r, where r is the order of the group. This is the same 867 probability of guessing the solution to the discrete logarithm which 868 is assumed to be intractable (Section 7). The attacker would have a 869 better chance of success at guessing the input to prf, i.e. the pre- 870 shared key, since the order of the group will be many orders of 871 magnitude greater than the size of the pool of pre-shared keys. 873 The implications of resistance to dictionary attack are significant. 874 An implementation can provision a pre-shared key in a practical and 875 realistic manner-- i.e. it MAY be a character string and it MAY be 876 relatively short-- and still maintain security. The nature of the 877 pre-shared key determines the size of the pool, D, and 878 countermeasures can prevent an adversary from determining the secret 879 in the only possible way: repeated, active, guessing attacks. For 880 example, a simple four character string using lower-case English 881 characters, and assuming random selection of those characters, will 882 result in D of over four hundred thousand. An adversary would need 883 to mount over one hundred thousand active, guessing attacks (which 884 will easily be detected) before gaining any significant advantage in 885 determining the pre-shared key. 887 For a more detailed discussion of the security of the key exchange 888 underlying this authentication method see [SAE] and [RFC5931]. 890 11. Acknowledgements 892 The author would like to thank Scott Fluhrer and Hideyuki Suzuki for 893 their insight in discovering flaws in earlier versions of the key 894 exchange that underlies this authentication method and for their 895 helpful suggestions in improving it. Thanks to Lily Chen for useful 896 advice on the hunting-and-pecking technique to "hash into" an element 897 in a group and to Jin-Meng Ho for a discussion on countering a small 898 sub-group attack. Rich Davis suggested several checks on received 899 messages that greatly increase the security of the underlying key 900 exchange. Hugo Krawczyk suggested using the prf as an extractor. 902 12. References 903 12.1. Normative References 905 [IKEV2-IANA] 906 "Internet Assigned Numbers Authority, IKEv2 Parameters", 907 . 909 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 910 Hashing for Message Authentication", RFC 2104, 911 February 1997. 913 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 914 Requirement Levels", BCP 14, RFC 2119, March 1997. 916 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 917 Internationalized Strings ("stringprep")", RFC 3454, 918 December 2002. 920 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 921 and Passwords", RFC 4013, February 2005. 923 [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication 924 Protocol (EAP) Authentication Using Only a Password", 925 RFC 5931, August 2010. 927 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 928 "Internet Key Exchange Protocol Version 2 (IKEv2)", 929 RFC 5996, September 2010. 931 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 932 Curve Cryptography Algorithms", RFC 6090, February 2011. 934 [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key 935 Exchange Version 2 (IKEv2)", RFC 6467, December 2011. 937 12.2. Informative References 939 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 940 Password-Based Protocols Secure Against Dictionary 941 Attack", Proceedings of the IEEE Symposium on Security and 942 Privacy, Oakland, 1992. 944 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 945 Password Authenticated Key Exchange Using Diffie-Hellman", 946 Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag, 947 2000. 949 [BPR00] Bellare, M., Pointcheval, D., and P. Rogaway, 950 "Authenticated Key Exchange Secure Against Dictionary 951 Attacks", Advances in Cryptology -- Eurocrypt '00, Lecture 952 Notes in Computer Science Springer-Verlag, 2000. 954 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 955 Requirements for Security", BCP 106, RFC 4086, June 2005. 957 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 958 Internet Protocol", RFC 4301, December 2005. 960 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 961 Key Derivation Function (HKDF)", RFC 5869, May 2010. 963 [SAE] Harkins, D., "Simultaneous Authentication of Equals: A 964 Secure, Password-Based Key Exchange for Mesh Networks", 965 Proceedings of the 2008 Second International Conference on 966 Sensor Technologies and Applications Volume 00, 2008. 968 Author's Address 970 Dan Harkins 971 Aruba Networks 972 1322 Crossman Avenue 973 Sunnyvale, CA 94089-1113 974 United States of America 976 Email: dharkins@arubanetworks.com