idnits 2.17.1 draft-harkins-ipsecme-spsk-auth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 11, 2009) is 5281 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 646, but not defined -- 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: 4 errors (**), 0 flaws (~~), 3 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 November 11, 2009 5 Expires: May 15, 2010 7 Secure PSK Authentication for IKE 8 draft-harkins-ipsecme-spsk-auth-00 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 May 15, 2010. 33 Copyright Notice 35 Copyright (c) 2009 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 in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 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. Finite Cyclic Groups . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Elliptic Curve Groups . . . . . . . . . . . . . . . . . . 6 58 4.2. Prime Modulus Groups . . . . . . . . . . . . . . . . . . . 6 59 5. Random Numbers . . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. The Random Function . . . . . . . . . . . . . . . . . . . . . 7 61 7. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 8. Secure Pre-Shared Key Authentication Message Exchange . . . . 8 63 8.1. Fixing the Secret Element, SKE . . . . . . . . . . . . . . 9 64 8.1.1. Elliptic Curve SKE . . . . . . . . . . . . . . . . . . 9 65 8.1.2. Prime Modulus SKE . . . . . . . . . . . . . . . . . . 11 66 8.2. Encoding of Elements . . . . . . . . . . . . . . . . . . . 11 67 8.3. Generation of a Commit . . . . . . . . . . . . . . . . . . 11 68 8.4. Generation of a Confirm . . . . . . . . . . . . . . . . . 12 69 8.5. Commit Payload . . . . . . . . . . . . . . . . . . . . . . 13 70 8.6. Confirm Payload . . . . . . . . . . . . . . . . . . . . . 13 71 8.7. IKEv1 Messaging . . . . . . . . . . . . . . . . . . . . . 14 72 8.8. IKEv2 Messaging . . . . . . . . . . . . . . . . . . . . . 15 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 78 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 1. Introduction 83 Both [RFC2409] and [RFC4306] allow for authentication of the IKE 84 peers using a pre-shared key. The exchanges, though, are susceptible 85 to dictionary attack and are therefore insecure. 87 To address this security issue, [RFC4306] recommends that the pre- 88 shared key used for authentication "contain as much unpredictability 89 as the strongest key being negotiated". That means any non- 90 hexidecimal key would require over 100 characters to provide enough 91 strength to generate a 128-bit key for AES. This is an unrealistic 92 requirement because humans have a hard time entering a string over 20 93 characters without error. 95 A pre-shared key authentication method built on top of a zero- 96 knowledge proof will provide resistance to dictionary attack and 97 still allow for security when used with weak pre-shared keys, such as 98 user-chosen passwords. Such an authentication method is described in 99 this memo. 101 Resistance to dictionary attack is achieved when an attacker gets 102 one, and only one, guess at the secret per active attack (see for 103 example, [BM92], [BMP00] and [BPR00]). Another way of putting this 104 is that any advantage the attacker can realize is through interaction 105 and not through computation. This is demonstrably different than the 106 technique from [RFC4306] of using a large, random number as the pre- 107 shared key. That can only make a dictionary attack less likely to 108 suceed, it does not prevent a dictionary attack. And, as [RFC4306] 109 notes, it is completely insecure when used with weak keys like user- 110 generated passwords. 112 1.1. Keyword Definitions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2. Scenarios 120 [RFC4306] describes usage scenarios for IKEv2. These are: 122 1. "Security Gateway to Security Gateway Tunnel": the endpoints of 123 the IKE (and IPsec) communication are network nodes that protect 124 traffic on behalf of connected networks. Protected traffic is 125 between devices on the respective protected networks. 127 2. "Endpoint-to-Endpoint Transport": the endpoints of the IKE (and 128 IPsec) communication are hosts according to [RFC4301]. Protected 129 traffic is between the two endpoints. 131 3. "Endpoint to Securty Gateway Tunnel": one endpoint connects to a 132 protected network through a network node. The endpoints of the 133 IKE (and IPsec) communication are the endpoint and network node, 134 but the protected traffic is between the endpoint and another 135 device on the protected network behind the node. 137 [RFC4306] also defines an EAP authentication method which can use a 138 pre-shared key or password in a manner that is resistant to 139 dictionary attack. But this requires the IKE Responder to have a 140 certificate. Also, EAP is strictly a client-server protocol used for 141 network access where one side is, typically, has a human behind it 142 and the other side is a network node. And, for EAP to scale a server 143 that terminates the EAP conversation is typically located on the 144 protected network behind the network node. Therefore EAP 145 authentication is really only applicable to the "Endpoint to Security 146 Gateway Tunnel" usage scenario. 148 The authentication and key exchange described in this memo is 149 therefore suitable for both the "Security Gateway to Security Gateway 150 Tunnel" scenario and the "Endpoint-to-Endpoint Transport" scenario. 151 In both of those, there is no defined roles. Either party could 152 initiate an IKE connection to the other and there isn't necessarily a 153 human involved. Also, both sides will have access to the pre-shared 154 key (i.e. no external authentication server) and neither side is 155 required to have a certificate. While it is certainly possible to 156 use EAP authentication in these cases with an EAP method such as 157 [EAPPWD], it will be a pointless and problematic encapsulation-- it 158 requires implementation of both the EAP client and EAP server state 159 machines, requires support of at least one EAP method, requires 160 support for EAP fragmentation, etc. 162 [RFC2409] does not describe usage scenarios for IKEv1 but IKEv1 has, 163 traditionally, been used in the same "Security Gateway to Security 164 Gateway Tunnel" scenario and the "Endpoint-to-Endpoint Transport" 165 scenario. Its pre-shared key-based authentication method is 166 constrained to only allow keys identified by IP address. Also, it 167 lacks a robust way to do user authentication using a password, 168 prompting the definition of different insecure ways to do password 169 authentication. Therefore, a secure pre-shared key-based 170 authentication method in IKEv1 will mitigate the need to do insecure 171 password-based authentication and remove the requirement that a pre- 172 shared key in IKEv1 needs to be based on IP address. 174 There is a need to do secure pre-shared key-based authentication in 175 IKE and it makes sense to do it as part of IKE and not by requiring 176 additional authentication protocols. 178 3. Notation 180 The following notation is used in this memo: 182 psk 183 The key shared between the two protocol participants. 185 a = H(b) 186 The binary string "b" is given to a function H which produces a 187 fixed-length output "a". 189 a | b 190 denotes concatenation of string "a" with string "b". 192 [a]b 193 indicates a string consisting of the single bit "a" repeated "b" 194 times. 196 len(x) 197 indicates the length in bits of the string x. 199 LSB(x) 200 returns the least-significant bit of the bitstring "x". 202 The convention for this memo to represent an element in a finite 203 cyclic group is to use an upper-case letter while a scalar is 204 indicated with a lower-case letter. 206 4. Finite Cyclic Groups 208 This protocol uses the same group (from the IANA repository created 209 by [RFC2409]) as the IKE exchange in which this authentication method 210 is used. Groups can be either based on exponentiation modulo a prime 211 or on an elliptic curve. These groups all define the following 212 operations: 214 o "scalar operation"-- taking a scalar and an element in the group 215 producing another element-- Z = scalar-op(x, Y). 217 o "element operation"-- taking two elements in the group to produce 218 a third-- Z = element-op(X, Y). 220 o "inverse operation"-- take an element an return another element 221 such that the element operation on the two produces the identity 222 element of the group-- Y = inverse(X). 224 4.1. Elliptic Curve Groups 226 ECP elliptic curves are defined by a curve equation, y^2 = x^3 + ax + 227 b, for a defined "a" and "b". ECP groups have a generator G, a prime 228 p, an order r, and, optionally, a co-factor f. The scalar operation 229 is multiplication of a point on the curve by itself a number of 230 times, and the element operation is addition of two points on the 231 curve: 233 Z = scalar-op(x, Y) = x*Y 235 the point Y is multiplied x-times to produce another point on the 236 curve, Z. 238 Z = element-op(X, Y) = X + Y 240 points X and Y are summed to produce another point on the curve, 241 Z. 243 Elliptic curve groups require a mapping function, q = F(Q), to 244 convert a group element to an integer. The mapping function used in 245 this memo returns the x-coordinate of the point it is passed. 247 If a co-factor is given in the group definition it MUST be used as 248 the co-factor, f, when a co-factor is called for, otherwise the co- 249 factor, f, MUST be 1. 251 The inverse function for an elliptic group is defined such that the 252 sum of an element and its inverse is the "point at infinity", denoted 253 here as "O". In other words, 255 Q + inverse(Q) = "O" 257 Only ECP elliptic curve can be used by the secure pre-shared key 258 authentication method. EC2N elliptic curves SHALL NOT be used. 259 While such groups exist in the IANA registry their use is not 260 defined. 262 4.2. Prime Modulus Groups 264 Groups formed by a prime modulus have a generator G, a prime modulus 265 p, and an order r. 267 The scalar operation is exponentiation of a generator modulus a 268 prime, and the element operation is modular multiplication: 270 Z = scalar-op(x, Y) = Y^x mod p 272 an element, Y taken to the x-th power modulo the prime returning 273 another element in the group, Z. 275 Z = element-op(X, Y) = (X * Y) mod p 277 two elements, X and Y, are multiplied modulo the prime returning 278 another element, Z. 280 If the order of the generator of the group is part of the group 281 definition that value MUST be used as the order of the group, r, when 282 an order is called for, otherwise the order, r, MUST be computed as 283 the prime minus one divided by two-- (p-1)/2. 285 Unlike elliptic curve groups, prime modulus groups do not require a 286 mapping function to convert an element into a scalar. But for the 287 purposes of notation in protocol definition, the function F, when 288 used below, shall just return the integer representation of an 289 element in a prime modulus group. 291 The inverse function for a prime modulus group is defined such that 292 the product of an element and its inverse modulo the group prime 293 equals one (1). In other words, 295 (Q * inverse(Q)) mod p = 1 297 5. Random Numbers 299 As with IKE itself, the security of the secure pre-shared key 300 authenticaiton method relies upon each participant in the protocol 301 producing quality secret random numbers. A poor random number chosen 302 by either side in a single exchange can compromise the shared secret 303 from that exchange and open up the possibility of dictionary attack. 305 Producing quality random numbers without specialized hardware entails 306 using a cryptographic mixing function (like a strong hash function) 307 to distill entropy from multiple, uncorrelated sources of information 308 and events. A very good discussion of this can be found in 309 [RFC4086]. 311 6. The Random Function 313 The protocol described in this memo uses a random function, H. This 314 is a "random oracle" as defined in [RANDOR]. At first glance one may 315 view this as a hash function. As noted in [RANDOR], though, hash 316 functions are too structured to be used directly as a random oracle. 317 But they can be used to instantiate a random oracle. 319 The random function, H, in this memo is instantiated by HMAC-SHA256 320 (see [RFC4634]) with a key whose length is 32 octets and whose value 321 is zero. In other words, 323 H(x) = HMAC-SHA-256([0]32, x) 325 7. Assumptions 327 The security of the protocol relies on certain assumptions. They 328 are: 330 1. Function H maps a binary string of indeterminate length onto a 331 fixed binary string that is x bits in length. 333 H: {0,1}^* --> {0,1}^x 335 2. Function H is a "random oracle" (see [RANDOR]). Given knowledge 336 of the input to H an adversary is unable to distinguish the 337 output of H from a random data source. 339 3. The discrete logarithm problem for the chosen finite cyclic group 340 is hard. That is, given G, p and Y = G^x mod p it is 341 computationally infeasible to determine x. Similarly for an 342 elliptic curve group given the curve definition, a generator G, 343 and Y = x * G it is computationally infeasible to determine x. 345 4. The pre-shared key is drawn from a finite pool of potential keys. 346 Each possible key in the pool has equal probability of being the 347 shared key. All potential attackers have access to this pool of 348 keys. 350 8. Secure Pre-Shared Key Authentication Message Exchange 352 To perform secure pre-shared key authentication each side must 353 generate a shared and secret element in the chosen group based on the 354 pre-shared key. This element, called the Secret Key Element, or SKE, 355 is then used in an authentication and key exchange protocol. The key 356 exchange protocol consists of each side exchanging two data, a 357 "Commit" and a "Confirm". 359 The "Commit" contributes ephemeral information to the exchange and 360 binds the sender to a single value of the pre-shared key from the 361 pool of potential pre-shared keys. The "Confirm" proves that the 362 pre-shared key is known and completes the zero-knowledge proof. 364 8.1. Fixing the Secret Element, SKE 366 The method of fixing SKE depends on the type of group, either MODP or 367 ECP. For the sake of convenience, we will use a single notation of 368 prf+() to denote the function prf+() from [RFC4306] as well as the 369 function prf() from [RFC2409], depending on whether the exchange is 370 being performed in IKEv2 or IKEv1, respectively. 372 8.1.1. Elliptic Curve SKE 374 For a finite cyclic group based on an elliptic curve it is necessary 375 to use an iterative hunt-and-peck technique to fix the secret key 376 element. 378 First, an 8-bit counter is set to the value one (1). Then, the 379 random function is used to generate a secret seed using the counter, 380 the pre-shared key, and the two nonces exchange by the Initiator and 381 the Responder: 383 ske-seed = H(psk | counter | Ni | Nr) 385 Then, the swe-seed is expanded using prf+ to create an ske-value: 387 ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking") 389 where len(ske-value) is the same as len(p), the length of the prime 390 of the curve. 392 If the ske-value is greater than or equal to the prime, p, the 393 counter is incremented, and a new ske-seed is gnerated and the 394 hunting-and-pecking continues. If ske-value is less than the prime, 395 p, it is used as the x-coordinate, x, with the equation for the 396 elliptic curve, with parameters a and b from the definition of the 397 curve, to solve for a y-coordinate, y. If there is no solution to 398 the quadratic equation the counter is incremented, a new ske-seed is 399 generated and the hunting and pecking continues. If a solution is 400 found then an ambiguity exists as there are technically two solutions 401 to the equation and ske-seed is used to unambiguously select one of 402 them. If the low-order bit of ske-seed is equal to the low-order bit 403 of y then a candidate SKE is defined as the point (x, y); if the low- 404 order bit of ske-seed differs from the low-order bit of y then a 405 candidate SKE is defined as the point (x, p - y), where p is the 406 prime over which the curve is defined. If the co-factor equals 1 407 then the candidate SKE becomes the SKE and hunting and pecking 408 terminates. If the co-factor of the curve is not equal to one the 409 order of the candidate SKE is checked to make sure it can safely be 410 used as a generator in the protocol. If the co-factor of the curve 411 multiplied by the candidate SKE equals the point-at-infinity then the 412 candidate SKE is discarded, the counter is incremented, a new ske- 413 seed is generated and the hunting and pecking continues. If it does 414 not equal the point-at-infinity the candidate SKE becomes the SKE and 415 hunting and pecking terminates. (Note: the point multiplied by the 416 co-factor does not become SKE, it is only used to determine the order 417 of the group defined with SKE as a generator). 419 Algorithmically, the process looks like this: 421 found = 0 422 counter = 1 423 do { 424 ske-seed = H(psk | counter | Ni | Nr) 425 ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking") 426 if (ske-value < p) 427 then 428 x = ske-value 429 if ( (y = sqrt(x^3 + ax + b)) != FAIL) 430 then 431 if (LSB(y) == LSB(ske-seed)) 432 then 433 SKE = (x,y) 434 else 435 SKE = (x, p-y) 436 fi 437 if (f == 1) 438 then 439 found = 1 440 else 441 P = f*SKE 442 if (P != "O") 443 then 444 found = 1 445 fi 446 fi 447 fi 448 fi 449 counter = counter + 1 450 } while (found == 0) 452 Figure 1: Fixing SKE for Elliptic Curves 454 8.1.2. Prime Modulus SKE 456 For a finite cyclic group based on exponentiation of a generator, G, 457 modulo a large prime p it is not necessary to hunt-and-peck to find 458 SKE. An SKE can be computed in a sub-field of the group directly 459 using the prime, p, and order r. 461 First, the random function is used to generate a seed: 463 ske-seed = H(psk | Ni | Nr) 465 Then the ske-seed is expanded using prf+ to the length of the prime, 466 modulo the prime. 468 ske-gen = prf+(ske-seed, "IKE Affixing the SKE") 470 ske-gen = ske-gen mod p 472 The ske is then computed by exponentiating the ske-gen to the value 473 ((p-1)/r) modulo the prime. 475 SKE = ske-gen ^ ((p-1)/r) mod p 477 8.2. Encoding of Elements 479 Encoding of an element in a finite cyclic group depends on the type 480 of group. 482 For MODP groups the element is treated as an unsigned integer less 483 than the prime that defines the group. The length of each MODP 484 element MUST have a bit length equal to the bit length of the prime. 485 This length is enforced, if necessary, by prepending the integer with 486 zeros until the required length is achieved. 488 For ECP groups the element is treated as two unsigned integers, each 489 less than the prime that defines the group, representing the 490 coordinates of the point. The first is the x-coordinate and the 491 second is the y-coordinate. Each of these two integers MUST have a 492 bit length equal to the bit length of the prime. This length is 493 enforced, if necessary, by prepending the integer with zeros until 494 the required length is achieved. 496 8.3. Generation of a Commit 498 A Commit has two components, a Scalar and an Element. To generate a 499 Commit, two random numbers, a "private" value and a "mask" value, are 500 generated (see Section 5). Their sum modulo the order of the group, 501 r, becomes the Scalar component: 503 Scalar = (private + mask) mod r 505 and the inverse of the scalar operation with the mask and SWE becomes 506 the Element component. 508 Element = inverse(scalar-op(mask, SKE)) 510 The Commit payload consists of the Scalar followed by the Element. 512 8.4. Generation of a Confirm 514 After receipt of a peer's Commit and generation of one's own Commit a 515 candidate shared secret to authenticate the peer is derived. Using 516 SKE, the "private" value generated as part of Commit generation, and 517 the peer's Scalar and Element from its Commit, peer-scalar and peer- 518 element, respectively, the shared secret, ss, is generated as: 520 ss = scalar-op(private, element-op(peer-element, scalar-op(peer- 521 scalar, SKE))) 523 For the purposes of subsequent computation, the bit length of ss 524 SHALL be equal to the bit length of the prime, p, used in either a 525 MODP or ECP group. This bit length SHALL be enforced, if necessary, 526 by prepending zeros to the value until the required length is 527 achieved. 529 Using the shared secret, ss, and the generated Scalar and Element, 530 self-scalar and self-element, respectively, and the received Scalar 531 and Element, peer-scalar and peer-element, respectively, an 532 authenticating Tag is generated as: 534 Tag = H(self-scalar | peer-scalar | F(self-element) | F(peer- 535 element) | ss) 537 The Commit payload consists of the authenticating Tag. 539 8.5. Commit Payload 541 The Commit Payload is defined as follows: 543 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 ! Next Payload !C! RESERVED ! Payload Length ! 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | | 549 ~ Scalar ~ 550 | | 551 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | | | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 554 | | 555 ~ Element ~ 556 | | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 The Commit Payload SHALL be indicated in both IKEv1 and IKEv2 with 560 TBD1 from the [IKEV2-IANA] registry maintained by IANA. 562 The Scalar SHALL be encoded as an unsigned integer with a bit length 563 equal to the bit length of the order of the group used in the 564 exchange. This length is enforced, if necessary, by prepending the 565 integer with zeros until the required length is achieved. The 566 Element is encoded according to Section 8.2. 568 8.6. Confirm Payload 570 The Confirm Payload is defined as follows: 572 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 ! Next Payload !C! RESERVED ! Payload Length ! 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 ! ! 578 ~ Tag ~ 579 ! ! 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 The Confirm Payload SHALL be indicated in both IKEv1 and IKEv2 with 583 TBD2 from the [IKEV2-IANA] registry maintained by IANA. 585 8.7. IKEv1 Messaging 587 Secure pre-shared key authentication can be used in either Main Mode 588 (see Figure 2) or Aggressive Mode (see Figure 3) with IKEv1 and SHALL 589 be indicated by negotiation of the TBD3 Authentication Method from 590 the [IKEV1-IANA] registry maintained by IANA, in the SA payload. 591 When using IKEv1 the "C" (critical) bit from Section 8.5 and 592 Section 8.6 MUST be clear (i.e. a value of zero). 594 Initiator Responder 595 ----------- ----------- 596 HDR, SAi --> 597 <-- HDR, SAr 598 HDR, KEi, Ni --> 599 <-- HDR, KEr, Nr 600 HDR*, IDii, Commit --> 601 <-- HDR*, IDir, Commit, Confirm 602 HDR*, Confirm, HASH_I --> 603 <-- HDR*, HASH_R 605 Figure 2: Secure PSK in Main Mode 607 Initiator Responder 608 ----------- ----------- 609 HDR, SAi, KEi, Ni, IDii, 610 Commit --> 611 <-- HDR, SAr, KEr, Nr, IDir, 612 Commit, Confirm 613 HDR, Confirm, HASH_I --> 614 <-- HDR, HASH_R 616 Figure 3: Secure PSK in Aggressive Mode 618 For secure pre-shared key authentication with IKEv1 the SKEYID value 619 is computed as follows: 621 SKEYID = prf(Ni_b | Nr_b, g^xy) 623 And HASH_I and HASH_R are computed as follows: 625 HASH_I = prf(SKEYID, ss | g^xi | g^xr | CKY-I | CKY-R | SA_ib | 626 IDii_b) 628 HASH_R = prf(SKEYID, ss | g^xr | g^xi | CKY-R | CKY-I | SA_ib | 629 IDir_b) 631 Where "ss" is the shared secret derived in Section 8.4. 633 8.8. IKEv2 Messaging 635 The specific authentication method being employed in IKEv2 is not 636 negotiated, like in IKEv1. It is inferred from the components of the 637 message. The presence of a Commit payload in second message sent by 638 the Initiator indicates an intention to perform secure pre-shared key 639 authentication (see Figure 4). The critical bit is used in both the 640 Commit and Confirm payloads to allow for backwards compatibility and 641 MUST be set (i.e. a value of one). 643 Initiator Responder 644 ----------- ----------- 645 HDR, SAi1, KEi, Ni --> 646 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 647 HDR, SK {IDi, Commit, [IDr,] 648 SAi2, TSi, TSr} --> 649 <-- HDR, SK {IDr, Commit, Confirm} 650 HDR, SK {Confirm, AUTH} --> 651 <-- HDR, SK {AUTH, SAr2, TSi, TSr} 653 Figure 4: Secure PSK in IKEv2 655 In the case of secure pre-shared key authentication the AUTH value is 656 computed as: 658 AUTH = prf(ss, ) 660 Where "ss" is the shared secret derived in Section 8.4. The 661 Authentication Method indicated in the AUTH payload SHALL be TBD4 662 from the [IKEV2-IANA] registry maintained by IANA. 664 9. IANA Considerations 666 IANA SHALL assign values for the Commit payload (Section 8.5) and the 667 Confirm payload (Section 8.6), and replace TBD1 and TBD2, 668 respectively, above, from the [IKEV2-IANA] of "IKEv2 Payload Types". 670 IANA SHALL assign a value for "Secure Shared Key Authentication", 671 replacing TBD3 above, from the IPSEC Authentication Method registry 672 in [IKEV1-IANA]. 674 IANA SHALL assign a value for "Secure Shared Key Authentication", 675 replacing TBD4 above, from the IKEv2 Authentication Method registry 676 in [IKEV2-IANA]. 678 10. Security Considerations 680 Both the Initiator and Responder obtain a shared secret, "ss" (see 681 Section 8.4) based on a secret group element and their own private 682 values contributed to the exchange. If they do not share the same 683 pre-shared key they will be unable to derive the same secret group 684 element and if they do not share the same secret group element they 685 will be unable to derive the same shared secret. 687 Resistance to dictionary attack means that the attacker must launch 688 an active attack to make a single guess at the pre-shared key. If 689 the size of the pool from which the key was extracted was D, and each 690 key in the pool has an equal probability of being chosen, then the 691 probability of success after a single guess is 1/D. After X guesses, 692 and removal of failed guesses from the pool of possible keys, the 693 probability becomes 1/(D-X). As X grows so does the probability of 694 success. Therefore it is possible for an attacker to determine the 695 pre-shared key through repeated brute-force, active, guessing 696 attacks. This authentication method does not presume to be secure 697 against this and implementations SHOULD ensure the size of D is 698 sufficiently large to prevent this attack. Implementations SHOULD 699 also take countermeasures, for instance refusing authentication 700 attempts for a certain amount of time, after the number of failed 701 authentication attempts reaches a certain threshold. No such 702 threshold or amount of time is recommended in this memo. 704 An active attacker can impersonate the Initiator of the exchange and 705 send a forged Commit payload. The attacker then waits until it 706 receives a Commit and a Confirm from the Responder. Now the attacker 707 can attempt to run through all possible values of the pre-shared key, 708 computing SKE (see Section 8.1), computing "ss" (see Section 8.4), 709 and attempting to recreate the Confirm payload from the Responder. 711 But the attacker committed to a single guess of the pre-shared key 712 with her forged Commit. That value was used by the Responder in his 713 computation of "ss" which was used to construct his Confirm. Any 714 guess of the pre-shared key which differs from the one used in the 715 forged Commit would result in each side using a different secret 716 element in the computation of "ss" and therefore the Confirm could 717 not be verified as correct, even if a subsequent guess, while running 718 through all possible values, was correct. The attacker gets one 719 guess, and one guess only, per active attack. 721 An attacker, acting as either the Initiator or Responder, can take 722 the Element from the Commit message received from the other party, 723 reconstruct the random "mask" value used in its construction and then 724 recover the other party's "private" value from the Scalar in the 725 Commit message. But this requires the attacker to solve the discrete 726 logarithm problem which we assumed was intractable above (Section 7). 728 Instead of attempting to guess at pre-shared keys an attacker can 729 attempt to determine SKE and then launch an attack. But SKE is 730 determined by the output of the random function, H, which is assumed 731 to be indistinguishable from a random source (Section 7). Therefore, 732 each element of the finite cyclic group will have an equal 733 probability of being the SKE. The probability of guessing SKE will 734 be 1/r, where r is the order of the group. This is the same 735 probability of guessing the solution to the discrete logarithm which 736 is assumed to be intractable (Section 7). The attacker would have a 737 better chance of success at guessing the input to H, i.e. the pre- 738 shared key, since the order of the group will be many orders of 739 magnitude greater than the size of the pool of pre-shared keys. 741 The implications of resistance to dictionary attack are significant. 742 An implementation can provision a pre-shared key in a practical and 743 realistic manner-- i.e. it MAY be a character string and it MAY be 744 relatively short-- and still maintain security. The nature of the 745 pre-share key determines the size of the pool, D, and countermeasures 746 can prevent an attacker from determining the secret in the only 747 possible way: repeated, active, guessing attacks. For example, a 748 simple four character string using lower-case English characters, and 749 assuming random selection of those characters, will result in D of 750 over four hundred thousand. An attacker would need to mount over one 751 hundred thousand active, guessing attacks (which will easily be 752 detected) before gaining any significant advantage in determining the 753 pre-shared key. 755 For a more detailed discussion of the security of the key exchange 756 underlying this authentication method see [SAE] and [EAPPWD]. 758 11. Acknowledgements 760 The author would like to thank Scott Fluhrer and Hideyuki Suzuki for 761 their insight in discovering flaws in earlier versions of the key 762 exchange that underlies this authentication method and for their 763 helpful suggestions in improving it. Lily Chen provided useful 764 advice on how to "hash into an element" in a finite cyclic group. 765 Hugo Krawczyk suggested the particular instantiation of the random 766 function, H. 768 12. References 769 12.1. Normative References 771 [IKEV1-IANA] 772 "Internet Assigned Numbers Authority, Internet Key 773 Exchange (IKE) Attributes", 774 . 776 [IKEV2-IANA] 777 "Internet Assigned Numbers Authority, IKEv2 Parameters", 778 . 780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 781 Requirement Levels", BCP 14, RFC 2119, March 1997. 783 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 784 (IKE)", RFC 2409, November 1998. 786 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 787 Internet Protocol", RFC 4301, December 2005. 789 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 790 RFC 4306, December 2005. 792 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 793 (SHA and HMAC-SHA)", RFC 4634, July 2006. 795 12.2. Informative References 797 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 798 Password-Based Protocols Secure Against Dictionary 799 Attack", Proceedings of the IEEE Symposium on Security and 800 Privacy, Oakland, 1992. 802 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 803 Password Authenticated Key Exchange Using Diffie-Hellman", 804 Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag, 805 2000. 807 [BPR00] Bellare, M., Pointcheval, D., and P. Rogaway, 808 "Authenticated Key Exchange Secure Against Dictionary 809 Attacks", Advances in Cryptology -- Eurocrypt '00, Lecture 810 Notes in Computer Science Springer-Verlag, 2000. 812 [EAPPWD] Harkins, D. and G. Zorn, "EAP Authentication Using Only A 813 Password", draft-harkins-emu-eap-pwd-12 (work in 814 progress), October 2009. 816 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 818 A Paradigm for Designing Efficient Protocols", Proceedings 819 of the 1st ACM Conference on Computer and Communication 820 Security, ACM Press, 1993, 821 . 823 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 824 Requirements for Security", BCP 106, RFC 4086, June 2005. 826 [SAE] Harkins, D., "Simultaneous Authentication of Equals: A 827 Secure, Password-Based Key Exchange for Mesh Networks", 828 Proceedings of the 2008 Second International Conference on 829 Sensor Technologies and Applications Volume 00, 2008. 831 Author's Address 833 Dan Harkins 834 Aruba Networks 835 1322 Crossman Avenue 836 Sunnyvale, CA 94089-1113 837 United States of America 839 Email: dharkins@arubanetworks.com