idnits 2.17.1 draft-harkins-ipsecme-spsk-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There 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 date (March 7, 2010) is 5163 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 774, but not defined == Outdated reference: A later version (-04) exists of draft-mcgrew-fundamental-ecc-01 ** Downref: Normative reference to an Informational draft: draft-mcgrew-fundamental-ecc (ref. 'ECC-CRYPTO') -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV1-IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2-IANA' ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) == Outdated reference: A later version (-14) exists of draft-harkins-emu-eap-pwd-12 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). 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: Standards Track March 7, 2010 5 Expires: September 8, 2010 7 Secure PSK Authentication for IKE 8 draft-harkins-ipsecme-spsk-auth-01 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 September 8, 2010. 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. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 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. The Random Function . . . . . . . . . . . . . . . . . . . . . 8 61 7. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 8. Secure Pre-Shared Key Authentication Message Exchange . . . . 9 63 8.1. Fixing the Secret Element, SKE . . . . . . . . . . . . . . 9 64 8.1.1. ECP Operation to Select SKE . . . . . . . . . . . . . 10 65 8.1.2. MODP Operation to Select SKE . . . . . . . . . . . . . 11 66 8.2. Encoding of Group Elements and Scalars . . . . . . . . . . 12 67 8.2.1. Encoding of ECP Elements . . . . . . . . . . . . . . . 12 68 8.2.2. Encoding of MODP Elements . . . . . . . . . . . . . . 13 69 8.2.3. Scalars . . . . . . . . . . . . . . . . . . . . . . . 13 70 8.3. Message Generation and Processing . . . . . . . . . . . . 13 71 8.3.1. Generation of a Commit . . . . . . . . . . . . . . . . 13 72 8.3.2. Processing of a Commit . . . . . . . . . . . . . . . . 13 73 8.3.2.1. Validation of an ECP Element . . . . . . . . . . . 14 74 8.3.2.2. Validation of a MODP Element . . . . . . . . . . . 14 75 8.3.2.3. Commit Processing Steps . . . . . . . . . . . . . 14 76 8.3.3. Generation of a Confirm . . . . . . . . . . . . . . . 14 77 8.3.4. Processing of a Confirm . . . . . . . . . . . . . . . 15 78 8.4. Payload Formats . . . . . . . . . . . . . . . . . . . . . 15 79 8.4.1. Commit Payload . . . . . . . . . . . . . . . . . . . . 16 80 8.4.2. Confirm Payload . . . . . . . . . . . . . . . . . . . 16 81 8.5. IKEv1 Messaging . . . . . . . . . . . . . . . . . . . . . 17 82 8.6. IKEv2 Messaging . . . . . . . . . . . . . . . . . . . . . 18 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 88 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 Both [RFC2409] and [RFC4306] allow for authentication of the IKE 94 peers using a pre-shared key. The exchanges, though, are susceptible 95 to dictionary attack and are therefore insecure. 97 To address this security issue, [RFC4306] recommends that the pre- 98 shared key used for authentication "contain as much unpredictability 99 as the strongest key being negotiated". That means any non- 100 hexidecimal key would require over 100 characters to provide enough 101 strength to generate a 128-bit key for AES. This is an unrealistic 102 requirement because humans have a hard time entering a string over 20 103 characters without error. Consequently, pre-shared key 104 authentication in [RFC2409] and [RFC4306] are used insecurely today. 106 A pre-shared key authentication method built on top of a zero- 107 knowledge proof will provide resistance to dictionary attack and 108 still allow for security when used with weak pre-shared keys, such as 109 user-chosen passwords. Such an authentication method is described in 110 this memo. 112 Resistance to dictionary attack is achieved when an attacker gets 113 one, and only one, guess at the secret per active attack (see for 114 example, [BM92], [BMP00] and [BPR00]). Another way of putting this 115 is that any advantage the attacker can realize is through interaction 116 and not through computation. This is demonstrably different than the 117 technique from [RFC4306] of using a large, random number as the pre- 118 shared key. That can only make a dictionary attack less likely to 119 suceed, it does not prevent a dictionary attack. And, as [RFC4306] 120 notes, it is completely insecure when used with weak keys like user- 121 generated passwords. 123 1.1. Keyword Definitions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. Scenarios 131 [RFC4306] describes usage scenarios for IKEv2. These are: 133 1. "Security Gateway to Security Gateway Tunnel": the endpoints of 134 the IKE (and IPsec) communication are network nodes that protect 135 traffic on behalf of connected networks. Protected traffic is 136 between devices on the respective protected networks. 138 2. "Endpoint-to-Endpoint Transport": the endpoints of the IKE (and 139 IPsec) communication are hosts according to [RFC4301]. Protected 140 traffic is between the two endpoints. 142 3. "Endpoint to Securty Gateway Tunnel": one endpoint connects to a 143 protected network through a network node. The endpoints of the 144 IKE (and IPsec) communication are the endpoint and network node, 145 but the protected traffic is between the endpoint and another 146 device on the protected network behind the node. 148 [RFC4306] also defines an EAP authentication method which can use a 149 pre-shared key or password in a manner that is resistant to 150 dictionary attack. But this requires the IKE Responder to have a 151 certificate. Also, EAP is strictly a client-server protocol used for 152 network access where one side is, typically, has a human behind it 153 and the other side is a network node. And, for EAP to scale a server 154 that terminates the EAP conversation is typically located on the 155 protected network behind the network node. Therefore EAP 156 authentication is really only applicable to the "Endpoint to Security 157 Gateway Tunnel" usage scenario. 159 The authentication and key exchange described in this memo is 160 therefore suitable for both the "Security Gateway to Security Gateway 161 Tunnel" scenario and the "Endpoint-to-Endpoint Transport" scenario. 162 In both of those, there is no defined roles. Either party could 163 initiate an IKE connection to the other and there isn't necessarily a 164 human involved. Also, both sides will have access to the pre-shared 165 key (i.e. no external authentication server) and neither side is 166 required to have a certificate. While it is certainly possible to 167 use EAP authentication in these cases with an EAP method such as 168 [EAPPWD], it will be a pointless and problematic encapsulation-- it 169 requires implementation of both the EAP client and EAP server state 170 machines, requires support of at least one EAP method, requires 171 support for EAP fragmentation, etc. 173 [RFC2409] does not describe usage scenarios for IKEv1 but IKEv1 has, 174 traditionally, been used in the same "Security Gateway to Security 175 Gateway Tunnel" scenario and the "Endpoint-to-Endpoint Transport" 176 scenario. Its pre-shared key-based authentication method is 177 constrained to only allow keys identified by IP address. Also, it 178 lacks a robust way to do user authentication using a password, 179 prompting the definition of different insecure ways to do password 180 authentication. Therefore, a secure pre-shared key-based 181 authentication method in IKEv1 will mitigate the need to do insecure 182 password-based authentication and remove the requirement that a pre- 183 shared key in IKEv1 needs to be based on IP address. 185 There is a need to do secure pre-shared key-based authentication in 186 IKE and it makes sense to do it as part of IKE and not by requiring 187 additional authentication protocols. 189 3. Notation 191 The following notation is used in this memo: 193 psk 194 A shared, secret and potentially low-entropy word, phrase, code 195 or key used as a credential to mutually authenticate the peers. 197 a = H(b) 198 The binary string "b" is given to a function H which produces a 199 fixed-length output "a". 201 a | b 202 denotes concatenation of string "a" with string "b". 204 [a]b 205 indicates a string consisting of the single bit "a" repeated "b" 206 times. 208 len(x) 209 indicates the length in bits of the string x. 211 LSB(x) 212 returns the least-significant bit of the bitstring "x". 214 The convention for this memo to represent an element in a finite 215 cyclic group is to use an upper-case letter while a scalar is 216 indicated with a lower-case letter. 218 4. Discrete Logarithm Cryptography 220 This protocol uses Discrete Logarithm Cryptography to achieve 221 authentication. Each party to the exchange derives ephemeral public 222 and private keys with respect to a particular set of domain 223 parameters (referred to here as a "group"). Groups can be either 224 based on finite field cryptography (MODP groups) or elliptic curve 225 cryptography (ECP groups). 227 This protocol uses the same group as the IKE exchange in which it is 228 being used for authentication, with the exception of characteristic- 229 two elliptic curve groups (EC2N). Use of such groups is undefined 230 for this authentication method and an IKE exchange that negotiates 231 one of these groups MUST NOT use this method of authentication. 233 The key exchange defined in this memo uses fundamental algorithms of 234 ECP groups as described in [ECC-CRYPTO]. 236 For each group the following operations are defined: 238 o "scalar operation"-- taking a scalar and an element in the group 239 producing another element-- Z = scalar-op(x, Y). 241 o "element operation"-- taking two elements in the group to produce 242 a third-- Z = element-op(X, Y). 244 o "inverse operation"-- take an element an return another element 245 such that the element operation on the two produces the identity 246 element of the group-- Y = inverse(X). 248 4.1. Elliptic Curve Cryptography (ECP) Groups 250 Domain parameters for ECP elliptic curves used for secure pre-shared 251 key-based authentication include: 253 o A prime, p, determining a prime field GF(p). The cryptographic 254 group will be a subgroup of the full elliptic curve group which 255 consists points on an elliptic curve-- elements from GF(p) that 256 satisfy the curve's equation-- together with the "point at 257 infinity" (denoted here as "O") that serves as the identity 258 element. The group operation for ECP groups is addition of points 259 on the elliptic curve. 261 o Elements a and b from GF(p) that define the curve's equation. The 262 point (x,y) is on the elliptic curve if and only if (y^2 - x^3 - 263 a*x - b) mod p equals zero (0). 265 o A prime, r, which is the order of G, and thus is also the size of 266 the cryptographic subgroup that is generated by G. 268 The scalar operation is multiplication of a point on the curve by 269 itself a number of times. The point Y is multiplied x-times to 270 produce another point Z: 272 Z = scalar-op(x, Y) = x*Y 274 The element operation is addition of two points on the curve. Points 275 X and Y are summed to produce another point Z: 277 Z = element-op(X, Y) = X + Y 279 The inverse function is defined such that the sum of an element and 280 its inverse is "0": 282 Q + inverse(Q) = "O" 284 Elliptic curve groups require a mapping function, q = F(Q), to 285 convert a group element to an integer. The mapping function used in 286 this memo returns the x-coordinate of the point it is passed. 288 Note: There is another ECP domain parameter, a co-factor, f, that is 289 defined by the requirement that the size of the full elliptic curve 290 group (including "O") is the product f and r. ECP groups used for 291 secure pre-shared key-based authentication MUST have a co-factor of 292 one (1). At the time of publication of this memo, all ECP groups in 293 the IANA registry used by IKE had a co-factor of one (1). 295 4.2. Finite Field Cryptography (MODP) Groups 297 Domain parameters for MODP groups used for secure pre-shared key- 298 based authentication include: 300 o A prime, p, determining a prime field GF(p), the integers modulo 301 p. The group operation for MODP groups is multiplication modulo 302 p. 304 o A prime, r, which is the multiplicative order of G, and thus also 305 the size of the cryptographic subgroup of GF(p)* that is generated 306 by G. 308 The scalar operation is exponentiation of a generator modulus a 309 prime. An element Y is taken to the x-th power modulo the prime 310 returning another element, Z: 312 Z = scalar-op(x, Y) = Y^x mod p 314 The element operation is modular multiplication. Two elementx, X and 315 Y, are multiplied modulo the prime returning another element, Z: 317 Z = element-op(X, Y) = (X * Y) mod p 319 The inverse function for a MODP group is defined such that the 320 product of an element and its inverse modulo the group prime equals 321 one (1). In other words, 323 (Q * inverse(Q)) mod p = 1 325 Unlike ECP groups, MODP groups do not require a mapping function to 326 convert an element into a scalar. But for the purposes of notation 327 in protocol definition, the function F, when used below, shall just 328 return the integer that was passed to it-- i.e. F(i) = i. 330 Some MODP groups in the IANA registry for use by IKE (and the secure 331 pre-shared key authentication method) are based on safe primes and 332 the order is not included in the group's domain parameter set. In 333 this case only, the order, r, MUST be computed as the prime minus one 334 divided by two-- (p-1)/2. If an order is included in the group's 335 domain parameter set that value MUST be used in this exchange when an 336 order is called for. If a MODP group does not include an order in 337 its domain parameter set and is not based on a safe prime it MUST NOT 338 be used with this exchange. 340 5. Random Numbers 342 As with IKE itself, the security of the secure pre-shared key 343 authenticaiton method relies upon each participant in the protocol 344 producing quality secret random numbers. A poor random number chosen 345 by either side in a single exchange can compromise the shared secret 346 from that exchange and open up the possibility of dictionary attack. 348 Producing quality random numbers without specialized hardware entails 349 using a cryptographic mixing function (like a strong hash function) 350 to distill entropy from multiple, uncorrelated sources of information 351 and events. A very good discussion of this can be found in 352 [RFC4086]. 354 6. The Random Function 356 The protocol described in this memo uses a random function, H. This 357 is a "random oracle" as defined in [RANDOR]. At first glance one may 358 view this as a hash function. As noted in [RANDOR], though, hash 359 functions are too structured to be used directly as a random oracle. 360 But they can be used to instantiate a random oracle. 362 The random function, H, in this memo is instantiated by HMAC-SHA256 363 (see [RFC4634]) with a key whose length is 32 octets and whose value 364 is zero. In other words, 366 H(x) = HMAC-SHA-256([0]32, x) 368 7. Assumptions 370 The security of the protocol relies on certain assumptions. They 371 are: 373 1. Function H maps a binary string of indeterminate length onto a 374 fixed binary string that is x bits in length. 376 H: {0,1}^* --> {0,1}^x 378 2. Function H is a "random oracle" (see [RANDOR]). Given knowledge 379 of the input to H an adversary is unable to distinguish the 380 output of H from a random data source. 382 3. The discrete logarithm problem for the chosen finite cyclic group 383 is hard. That is, given G, p and Y = G^x mod p it is 384 computationally infeasible to determine x. Similarly for an 385 elliptic curve group given the curve definition, a generator G, 386 and Y = x * G it is computationally infeasible to determine x. 388 4. The pre-shared key is drawn from a finite pool of potential keys. 389 Each possible key in the pool has equal probability of being the 390 shared key. All potential attackers have access to this pool of 391 keys. 393 8. Secure Pre-Shared Key Authentication Message Exchange 395 To perform secure pre-shared key authentication each side must 396 generate a shared and secret element in the chosen group based on the 397 pre-shared key. This element, called the Secret Key Element, or SKE, 398 is then used in an authentication and key exchange protocol. The key 399 exchange protocol consists of each side exchanging two data, a 400 "Commit" and a "Confirm". 402 The "Commit" contributes ephemeral information to the exchange and 403 binds the sender to a single value of the pre-shared key from the 404 pool of potential pre-shared keys. The "Confirm" proves that the 405 pre-shared key is known and completes the zero-knowledge proof. 407 8.1. Fixing the Secret Element, SKE 409 The method of fixing SKE depends on the type of group, either MODP or 410 ECP. For the sake of convenience, we will use a single notation of 411 prf+() to denote the function prf+() from [RFC4306] as well as the 412 function prf() from [RFC2409], depending on whether the exchange is 413 being performed in IKEv2 or IKEv1, respectively. 415 Fixing the SKE involves an iterative hunting-and-pecking technique 416 using the prime from the negotiated group's domain parameter set and 417 an ECP- or MODP-specific operation depending on the negotiated group. 419 First, an 8-bit counter is set to the value one (1). Then, the 420 random function is used to generate a secret seed using the counter, 421 the pre-shared key, and the two nonces exchanged by the Initiator and 422 the Responder: 424 ske-seed = H(Ni | Nr | psk | counter) 426 Then, the swe-seed is expanded using prf+ to create an ske-value: 428 ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking") 430 where len(ske-value) is the same as len(p), the length of the prime 431 from the domain parameter set of the negotiated group. 433 If the swe-seed is greater than or equal to the prime, p, the counter 434 is incremented and a new ske-seed is generated and the hunting-and- 435 pecking continues. If swe-seed is less than the prime, p, it is 436 passed to the group-specific operation to select the SKE or fail. If 437 the group-specific operation fails, the counter is incremented, a new 438 ske-seed is generated and the hunting-and-pecking continues. 440 8.1.1. ECP Operation to Select SKE 442 The group-specific operation for ECP groups uses ske-value, ske-seed 443 and the equation of the curve to produce SKE. First ske-value is 444 used directly as the x-coordinate, x, with the equation of the 445 elliptic curve, with parameters a and b from the domain parameter set 446 of the curve, to solve for a y-coordinate, y. 448 If there is no solution to the equation the operation fails (and the 449 hunting-and-pecking continues). If a solution is found then an 450 ambiguity exists as there are technically two solutions to the 451 equation, and ske-seed is used to unambiguously select one of them. 452 If the low-order bit of ske-seed is equal to the low-order bit of y 453 then a candidate SKE is defined as the point (x,y); if the low-order 454 bit of ske-seed differs from the low-order bit of y then a candidate 455 SKE is defined as the point (x, p-y) where p is the prime from the 456 negotiated group's domain parameter set. The candidate SKE becomes 457 the SKE and the ECP-specific operation completes successfully. 459 Algorithmically, the process looks like this: 461 found = 0 462 counter = 1 463 do { 464 ske-seed = H(Ni | Nr | psk | counter) 465 ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking") 466 if (ske-value < p) 467 then 468 x = ske-value 469 if ( (y = sqrt(x^3 + ax + b)) != FAIL) 470 then 471 if (LSB(y) == LSB(ske-seed)) 472 then 473 SKE = (x,y) 474 else 475 SKE = (x, p-y) 476 fi 477 found = 1 478 fi 479 fi 480 counter = counter + 1 481 } while (found == 0) 483 Figure 1: Fixing SKE for ECP Groups 485 8.1.2. MODP Operation to Select SKE 487 The group-specific operation for MODP groups takes ske-value, and the 488 prime, p, and order, r, from the group's domain parameter set to 489 directly produce a candidate SKE by exponentiating the ske-value to 490 the value ((p-1)/r) modulo the prime. If the candidate SKE is 491 greater than one (1) the candidate SKE becomes the SKE and the MODP- 492 specific operation completes successfully. Otherwise, the MODP- 493 specific operation fails (and the hunting-and-pecking continues). 495 Algorithmically, the process looks like this: 497 found = 0 498 counter = 1 499 do { 500 ske-seed = H(Ni | Nr | psk | counter) 501 ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking") 502 if (ske-value < p) 503 then 504 SKE = ske-value ^ ((p-1)/r) mod p 505 if (SKE > 1) 506 then 507 found = 1 508 fi 509 fi 510 counter = counter + 1 511 } while (found == 0) 513 Figure 2: Fixing SKE for MODP Groups 515 8.2. Encoding of Group Elements and Scalars 517 The payloads used in the secure pre-shared key authentication method 518 contain elements from the negotiated group and scalar values. To 519 ensure interoperability, field elements and scalars MUST be 520 represented in payloads in accordance with the requirements in this 521 section. 523 8.2.1. Encoding of ECP Elements 525 Elements in ECP groups are points on the negotiated elliptic curve. 526 Each such element MUST be rpresented by the concatenation of two 527 components, an x-coordinate and a y-coordinate. 529 Each of the two components, the x-coordinate and the y-coordinate, 530 MUST be represented (in binary form) as an unsigned integer that is 531 strictly less than the prime, p, from the group's domain parameter 532 set. The binary representation of each component MUST have a bit 533 length equal to the bit length of the binary representation of p. 534 This length requirement is enforced, if necessary, by prepending the 535 binary representation of the integer with zeros until the required 536 length is achieved. 538 Since the field element is represented in a payload by the 539 x-coordinate followed by the y-coordinate it follows, then, that the 540 length of the element in the payload MUST be twice the bit length of 541 p. 543 8.2.2. Encoding of MODP Elements 545 Elements in MODP groups MUST be represented (in binary form) as 546 unsigned integers that are strictly less than the prime, p, from the 547 group's domain parameter set. The binary representation of each 548 group element MUST have a bit length equal to the bit length of the 549 binary representation of p. This length requirement is enforced, if 550 necessary, by prepending the binary representation of the interger 551 with zeros until the required length is achieved. 553 8.2.3. Scalars 555 Scalars MUST be represented (in binary form) as unsigned integers 556 that are strictly less than r, the order of the generator of the 557 agreed-upon cryptographic group. The binary representation of each 558 scalar MUST have a bit length equal to the bit length of the binary 559 representation of r. This requirement is enforced, if necessary, by 560 prepending the binary representation of the integer with zeros until 561 the required length is achieved. 563 8.3. Message Generation and Processing 565 8.3.1. Generation of a Commit 567 A Commit has two components, a Scalar and an Element. To generate a 568 Commit, two random numbers, a "private" value and a "mask" value, are 569 generated (see Section 5). Their sum modulo the order of the group, 570 r, becomes the Scalar component: 572 Scalar = (private + mask) mod r 574 If the Scalar is not greater than one (1), the private and mask 575 values MUST be thrown away and new values randomly generated. If the 576 Scalar is greater than one (1), the inverse of the scalar operation 577 with the mask and SWE becomes the Element component. 579 Element = inverse(scalar-op(mask, SKE)) 581 The Commit payload consists of the Scalar followed by the Element. 583 8.3.2. Processing of a Commit 585 Upon receipt of a peer's Commit the scalar and element MUST be 586 validated. The processing of an element depends on the type, either 587 an ECP element or a MODP element. 589 8.3.2.1. Validation of an ECP Element 591 Validating a received ECP Element involves: 1) checking whether the 592 two coordinates, x and y, are both greater than zero (0) and less 593 than the prime defining the underlying field; and 2) checking whether 594 the x- and y-coordinates satisfy the equation of the curve (that is, 595 that they produce a valid point on the curve that is not "0"). If 596 either of these conditions are not met the received Element is 597 invalid, otherwise the received Element is valid. 599 8.3.2.2. Validation of a MODP Element 601 A received MODP Element is valid if: 1) it is between one (1) and the 602 prime, p, exclusive; and 2) if modular exponentiation of the Element 603 by the group order, r, equals one (1). If either of these conditions 604 are not true the received Element is invalid. 606 8.3.2.3. Commit Processing Steps 608 Commit validation is accomplished by the following steps: 610 1. The length of the Commit payload is checked against the 611 anticipated size (the length of the scalar plus the length of the 612 element for the negotiated group. If it is incorrect, the Commit 613 is invalidated, otherwise processing continues. 615 2. The scalar is extracted from the Commit payload and checked to 616 ensure it is between one (1) and r, the order of the negotiated 617 group, exclusive. If it is not, the Commit is invalidated, 618 otherwise processing continues. 620 3. The element is extracted from the Commit payload and checked in a 621 manner that depends on the type of group negotiated. If the 622 group is ECP the element is validated according to 623 Section 8.3.2.1, if the group is MODP the element is validated 624 according to Section 8.3.2.2. If the Element is not valid then 625 the Commit is invalidated, otherwise the Commit is validated. 627 If the Commit is invalidated the payload MUST be discarded and the 628 IKE exchange aborted. 630 8.3.3. Generation of a Confirm 632 A Confirm message is generated after a Commit has been generated and 633 a pper's Commit has been processed. First, a candidate shared secret 634 to authenticate the peer is derived. Using SKE, the "private" value 635 generated as part of Commit generation, and the peer's Scalar and 636 Element from its Commit, peer-scalar and peer-element, respectively, 637 the shared secret, ss, is generated as: 639 ss = F(scalar-op(private, 640 element-op(peer-element, 641 scalar-op(peer-scalar, SKE)))) 643 For the purposes of subsequent computation, the bit length of ss 644 SHALL be equal to the bit length of the prime, p, used in either a 645 MODP or ECP group. This bit length SHALL be enforced, if necessary, 646 by prepending zeros to the value until the required length is 647 achieved. 649 Then, using the shared secret, ss, and the generated Scalar and 650 Element, self-scalar and self-element, respectively, and the received 651 Scalar and Element, peer-scalar and peer-element, respectively, an 652 authenticating Tag is generated as: 654 Tag = H(self-scalar | peer-scalar | 655 F(self-element) | F(peer-element) | ss) 657 The Commit payload consists of the authenticating Tag. 659 8.3.4. Processing of a Confirm 661 Upon receipt of a peer's Confirm message an expected Tag value is 662 computed and compared against the Tag value in the Confirm payload. 663 If the two differ the exchange MUST be aborted. If they equal the 664 peer has been successfully authenticated. 666 8.4. Payload Formats 667 8.4.1. Commit Payload 669 The Commit Payload is defined as follows: 671 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 ! Next Payload !C! RESERVED ! Payload Length ! 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | | 677 ~ Scalar ~ 678 | | 679 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | | | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 682 | | 683 ~ Element ~ 684 | | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 The Commit Payload SHALL be indicated in both IKEv1 and IKEv2 with 688 TBD1 from the [IKEV2-IANA] registry maintained by IANA. 690 The Scalar SHALL be encoded as an unsigned integer with a bit length 691 equal to the bit length of the order of the group used in the 692 exchange. This length is enforced, if necessary, by prepending the 693 integer with zeros until the required length is achieved. The 694 Element is encoded according to Section 8.2. 696 8.4.2. Confirm Payload 698 The Confirm Payload is defined as follows: 700 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 ! Next Payload !C! RESERVED ! Payload Length ! 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 ! ! 706 ~ Tag ~ 707 ! ! 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 The Confirm Payload SHALL be indicated in both IKEv1 and IKEv2 with 711 TBD2 from the [IKEV2-IANA] registry maintained by IANA. 713 8.5. IKEv1 Messaging 715 Secure pre-shared key authentication can be used in either Main Mode 716 (see Figure 3) or Aggressive Mode (see Figure 4) with IKEv1 and SHALL 717 be indicated by negotiation of the TBD3 Authentication Method from 718 the [IKEV1-IANA] registry maintained by IANA, in the SA payload. 719 When using IKEv1 the "C" (critical) bit from Section 8.4.1 and 720 Section 8.4.2 MUST be clear (i.e. a value of zero). 722 Initiator Responder 723 ----------- ----------- 724 HDR, SAi --> 725 <-- HDR, SAr 726 HDR, KEi, Ni --> 727 <-- HDR, KEr, Nr 728 HDR*, IDii, Commit --> 729 <-- HDR*, IDir, Commit, Confirm 730 HDR*, Confirm, HASH_I --> 731 <-- HDR*, HASH_R 733 Figure 3: Secure PSK in Main Mode 735 Initiator Responder 736 ----------- ----------- 737 HDR, SAi, KEi, Ni, IDii, 738 Commit --> 739 <-- HDR, SAr, KEr, Nr, IDir, 740 Commit, Confirm 741 HDR, Confirm, HASH_I --> 742 <-- HDR, HASH_R 744 Figure 4: Secure PSK in Aggressive Mode 746 For secure pre-shared key authentication with IKEv1 the SKEYID value 747 is computed as follows: 749 SKEYID = prf(Ni_b | Nr_b, g^xy) 751 And HASH_I and HASH_R are computed as follows: 753 HASH_I = prf(SKEYID, ss | g^xi | g^xr | CKY-I | CKY-R | 754 SA_ib | IDii_b) 756 HASH_R = prf(SKEYID, ss | g^xr | g^xi | CKY-R | CKY-I | 757 SA_ib | IDir_b) 759 Where "ss" is the shared secret derived in Section 8.3.3. 761 8.6. IKEv2 Messaging 763 The specific authentication method being employed in IKEv2 is not 764 negotiated, like in IKEv1. It is inferred from the components of the 765 message. The presence of a Commit payload in second message sent by 766 the Initiator indicates an intention to perform secure pre-shared key 767 authentication (see Figure 5). The critical bit is used in both the 768 Commit and Confirm payloads to allow for backwards compatibility and 769 MUST be set (i.e. a value of one). 771 Initiator Responder 772 ----------- ----------- 773 HDR, SAi1, KEi, Ni --> 774 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 775 HDR, SK {IDi, Commit, [IDr,] 776 SAi2, TSi, TSr} --> 777 <-- HDR, SK {IDr, Commit, Confirm} 778 HDR, SK {Confirm, AUTH} --> 779 <-- HDR, SK {AUTH, SAr2, TSi, TSr} 781 Figure 5: Secure PSK in IKEv2 783 In the case of secure pre-shared key authentication the AUTH value is 784 computed as: 786 AUTH = prf(ss, ) 788 Where "ss" is the shared secret derived in Section 8.3.3. The 789 Authentication Method indicated in the AUTH payload SHALL be TBD4 790 from the [IKEV2-IANA] registry maintained by IANA. 792 9. IANA Considerations 794 IANA SHALL assign values for the Commit payload (Section 8.4.1) and 795 the Confirm payload (Section 8.4.2), and replace TBD1 and TBD2, 796 respectively, above, from the [IKEV2-IANA] of "IKEv2 Payload Types". 798 IANA SHALL assign a value for "Secure Shared Key Authentication", 799 replacing TBD3 above, from the IPSEC Authentication Method registry 800 in [IKEV1-IANA]. 802 IANA SHALL assign a value for "Secure Shared Key Authentication", 803 replacing TBD4 above, from the IKEv2 Authentication Method registry 804 in [IKEV2-IANA]. 806 10. Security Considerations 808 Both the Initiator and Responder obtain a shared secret, "ss" (see 809 Section 8.3.3) based on a secret group element and their own private 810 values contributed to the exchange. If they do not share the same 811 pre-shared key they will be unable to derive the same secret group 812 element and if they do not share the same secret group element they 813 will be unable to derive the same shared secret. 815 Resistance to dictionary attack means that the attacker must launch 816 an active attack to make a single guess at the pre-shared key. If 817 the size of the pool from which the key was extracted was D, and each 818 key in the pool has an equal probability of being chosen, then the 819 probability of success after a single guess is 1/D. After X guesses, 820 and removal of failed guesses from the pool of possible keys, the 821 probability becomes 1/(D-X). As X grows so does the probability of 822 success. Therefore it is possible for an attacker to determine the 823 pre-shared key through repeated brute-force, active, guessing 824 attacks. This authentication method does not presume to be secure 825 against this and implementations SHOULD ensure the size of D is 826 sufficiently large to prevent this attack. Implementations SHOULD 827 also take countermeasures, for instance refusing authentication 828 attempts for a certain amount of time, after the number of failed 829 authentication attempts reaches a certain threshold. No such 830 threshold or amount of time is recommended in this memo. 832 An active attacker can impersonate the Initiator of the exchange and 833 send a forged Commit payload. The attacker then waits until it 834 receives a Commit and a Confirm from the Responder. Now the attacker 835 can attempt to run through all possible values of the pre-shared key, 836 computing SKE (see Section 8.1), computing "ss" (see Section 8.3.3), 837 and attempting to recreate the Confirm payload from the Responder. 839 But the attacker committed to a single guess of the pre-shared key 840 with her forged Commit. That value was used by the Responder in his 841 computation of "ss" which was used to construct his Confirm. Any 842 guess of the pre-shared key which differs from the one used in the 843 forged Commit would result in each side using a different secret 844 element in the computation of "ss" and therefore the Confirm could 845 not be verified as correct, even if a subsequent guess, while running 846 through all possible values, was correct. The attacker gets one 847 guess, and one guess only, per active attack. 849 An attacker, acting as either the Initiator or Responder, can take 850 the Element from the Commit message received from the other party, 851 reconstruct the random "mask" value used in its construction and then 852 recover the other party's "private" value from the Scalar in the 853 Commit message. But this requires the attacker to solve the discrete 854 logarithm problem which we assumed was intractable above (Section 7). 856 Instead of attempting to guess at pre-shared keys an attacker can 857 attempt to determine SKE and then launch an attack. But SKE is 858 determined by the output of the random function, H, which is assumed 859 to be indistinguishable from a random source (Section 7). Therefore, 860 each element of the finite cyclic group will have an equal 861 probability of being the SKE. The probability of guessing SKE will 862 be 1/r, where r is the order of the group. This is the same 863 probability of guessing the solution to the discrete logarithm which 864 is assumed to be intractable (Section 7). The attacker would have a 865 better chance of success at guessing the input to H, i.e. the pre- 866 shared key, since the order of the group will be many orders of 867 magnitude greater than the size of the pool of pre-shared keys. 869 The implications of resistance to dictionary attack are significant. 870 An implementation can provision a pre-shared key in a practical and 871 realistic manner-- i.e. it MAY be a character string and it MAY be 872 relatively short-- and still maintain security. The nature of the 873 pre-share key determines the size of the pool, D, and countermeasures 874 can prevent an attacker from determining the secret in the only 875 possible way: repeated, active, guessing attacks. For example, a 876 simple four character string using lower-case English characters, and 877 assuming random selection of those characters, will result in D of 878 over four hundred thousand. An attacker would need to mount over one 879 hundred thousand active, guessing attacks (which will easily be 880 detected) before gaining any significant advantage in determining the 881 pre-shared key. 883 For a more detailed discussion of the security of the key exchange 884 underlying this authentication method see [SAE] and [EAPPWD]. 886 11. Acknowledgements 888 The author would like to thank Scott Fluhrer and Hideyuki Suzuki for 889 their insight in discovering flaws in earlier versions of the key 890 exchange that underlies this authentication method and for their 891 helpful suggestions in improving it. Thanks to Lily Chen for useful 892 advice on the hunting-and-pecking technique to "hash into" an element 893 in a group and to Jin-Meng Ho for a discussion on countering a small 894 sub-group attack. Rich Davis suggested several checks on received 895 messages that greatly increase the security of the underlying key 896 exchange. Hugo Krawczyk suggested the particular instantiation of 897 the random function, H. 899 12. References 900 12.1. Normative References 902 [ECC-CRYPTO] 903 McGrew, D., "Fundamental Elliptic Curve Cryptography 904 Algorithms", draft-mcgrew-fundamental-ecc-01 (work in 905 progress), October 2009. 907 [IKEV1-IANA] 908 "Internet Assigned Numbers Authority, Internet Key 909 Exchange (IKE) Attributes", 910 . 912 [IKEV2-IANA] 913 "Internet Assigned Numbers Authority, IKEv2 Parameters", 914 . 916 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 917 Requirement Levels", BCP 14, RFC 2119, March 1997. 919 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 920 (IKE)", RFC 2409, November 1998. 922 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 923 Internet Protocol", RFC 4301, December 2005. 925 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 926 RFC 4306, December 2005. 928 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 929 (SHA and HMAC-SHA)", RFC 4634, July 2006. 931 12.2. Informative References 933 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 934 Password-Based Protocols Secure Against Dictionary 935 Attack", Proceedings of the IEEE Symposium on Security and 936 Privacy, Oakland, 1992. 938 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 939 Password Authenticated Key Exchange Using Diffie-Hellman", 940 Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag, 941 2000. 943 [BPR00] Bellare, M., Pointcheval, D., and P. Rogaway, 944 "Authenticated Key Exchange Secure Against Dictionary 945 Attacks", Advances in Cryptology -- Eurocrypt '00, Lecture 946 Notes in Computer Science Springer-Verlag, 2000. 948 [EAPPWD] Harkins, D. and G. Zorn, "EAP Authentication Using Only A 949 Password", draft-harkins-emu-eap-pwd-12 (work in 950 progress), October 2009. 952 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 953 A Paradigm for Designing Efficient Protocols", Proceedings 954 of the 1st ACM Conference on Computer and Communication 955 Security, ACM Press, 1993, 956 . 958 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 959 Requirements for Security", BCP 106, RFC 4086, June 2005. 961 [SAE] Harkins, D., "Simultaneous Authentication of Equals: A 962 Secure, Password-Based Key Exchange for Mesh Networks", 963 Proceedings of the 2008 Second International Conference on 964 Sensor Technologies and Applications Volume 00, 2008. 966 Author's Address 968 Dan Harkins 969 Aruba Networks 970 1322 Crossman Avenue 971 Sunnyvale, CA 94089-1113 972 United States of America 974 Email: dharkins@arubanetworks.com