Network Working Group D. Harkins Internet-Draft Aruba Networks Intended status: Experimental April 26, 2011 Expires: October 28, 2011 Secure PSK Authentication for IKE draft-harkins-ipsecme-spsk-auth-04 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 28, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo describes a secure pre-shared key authentication method for IKE. It is resistant to dictionary attack and retains security even when used with weak pre-shared keys. Harkins Expires October 28, 2011 [Page 1]

Internet-Draft Secure PSK Authentication for IKE April 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Keyword Definitions . . . . . . . . . . . . . . . . . . . 3 2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3 3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Discrete Logarithm Cryptography . . . . . . . . . . . . . . . 5 4.1. Elliptic Curve Cryptography (ECP) Groups . . . . . . . . . 6 4.2. Finite Field Cryptography (MODP) Groups . . . . . . . . . 7 5. Random Numbers . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Using Passwords as a Pre-Shared Key . . . . . . . . . . . . . 8 7. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Secure PSK Authentication Message Exchange . . . . . . . . . . 10 8.1. Negotiation of Secure PSK Authentication . . . . . . . . . 10 8.1.1. IKEv1 Negotiation . . . . . . . . . . . . . . . . . . 10 8.1.2. IKEv2 Negotiation . . . . . . . . . . . . . . . . . . 11 8.2. Fixing the Secret Element, SKE . . . . . . . . . . . . . . 11 8.2.1. ECP Operation to Select SKE . . . . . . . . . . . . . 12 8.2.2. MODP Operation to Select SKE . . . . . . . . . . . . . 13 8.3. Encoding and Decoding of Group Elements and Scalars . . . 13 8.3.1. Encoding and Decoding of Scalars . . . . . . . . . . . 13 8.3.2. Encoding and Decoding of ECP Elements . . . . . . . . 14 8.3.3. Encoding and Decoding of MODP Elements . . . . . . . . 14 8.4. Message Generation and Processing . . . . . . . . . . . . 14 8.4.1. Generation of a Commit . . . . . . . . . . . . . . . . 14 8.4.2. Processing of a Commit . . . . . . . . . . . . . . . . 15 8.4.2.1. Validation of an ECP Element . . . . . . . . . . . 15 8.4.2.2. Validation of a MODP Element . . . . . . . . . . . 15 8.4.2.3. Commit Processing Steps . . . . . . . . . . . . . 15 8.4.3. Authentication of the Exchange . . . . . . . . . . . . 16 8.5. Payload Format . . . . . . . . . . . . . . . . . . . . . . 17 8.5.1. SPSK Notify Payload . . . . . . . . . . . . . . . . . 17 8.5.2. Commit Payload . . . . . . . . . . . . . . . . . . . . 18 8.6. IKEv1 Messaging . . . . . . . . . . . . . . . . . . . . . 18 8.7. IKEv2 Messaging . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 Harkins Expires October 28, 2011 [Page 2]

Internet-Draft Secure PSK Authentication for IKE April 2011 1. Introduction Both [RFC2409] and [RFC5996] allow for authentication of the IKE peers using a pre-shared key. The exchanges, though, are susceptible to dictionary attack and are therefore insecure. In addition, [RFC2409] requires that a pre-shared key be identified by IP address and this severely constrains its usefulness. These are obvious drawbacks to using pre-shared key authentication in IKEv1 and IKEv2. To address the security issue, [RFC5996] recommends that the pre- shared key used for authentication "contain as much unpredictability as the strongest key being negotiated". That means any non- hexidecimal key would require over 100 characters to provide enough strength to generate a 128-bit key for AES. This is an unrealistic requirement because humans have a hard time entering a string over 20 characters without error. Consequently, pre-shared key authentication in [RFC2409] and [RFC5996] are used insecurely today. A pre-shared key authentication method built on top of a zero- knowledge proof will provide resistance to dictionary attack and still allow for security when used with weak pre-shared keys, such as user-chosen passwords. Such an authentication method is described in this memo. Resistance to dictionary attack is achieved when an attacker gets one, and only one, guess at the secret per active attack (see for example, [BM92], [BMP00] and [BPR00]). Another way of putting this is that any advantage the attacker can realize is through interaction and not through computation. This is demonstrably different than the technique from [RFC5996] of using a large, random number as the pre- shared key. That can only make a dictionary attack less likely to succeed, it does not prevent a dictionary attack. And, as [RFC5996] notes, it is completely insecure when used with weak keys like user- generated passwords. 1.1. Keyword Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Usage Scenarios [RFC5996] describes usage scenarios for IKEv2. These are: 1. "Security Gateway to Security Gateway Tunnel": the endpoints of the IKE (and IPsec) communication are network nodes that protect Harkins Expires October 28, 2011 [Page 3]

Internet-Draft Secure PSK Authentication for IKE April 2011 traffic on behalf of connected networks. Protected traffic is between devices on the respective protected networks. 2. "Endpoint-to-Endpoint Transport": the endpoints of the IKE (and IPsec) communication are hosts according to [RFC4301]. Protected traffic is between the two endpoints. 3. "Endpoint to Securty Gateway Tunnel": one endpoint connects to a protected network through a network node. The endpoints of the IKE (and IPsec) communication are the endpoint and network node, but the protected traffic is between the endpoint and another device on the protected network behind the node. The authentication and key exchange described in this memo is suitable for all the usage scenarios described in [RFC5996]. In the "Security Gateway to Security Gateway Tunnel" scenario and the "Endpoint-to-Endpoint Transport" scenario it provides a secure method of authentication without requiring a certificate. For the "Endpoint to Security Gateway Tunnel" scenario it provides for secure username+ password authentication that is popular in remote access VPN situations. [RFC2409] does not describe usage scenarios for IKEv1 but IKEv1 has, traditionally, been used in the same "Security Gateway to Security Gateway Tunnel" scenario and the "Endpoint-to-Endpoint Transport" scenario. Its pre-shared key-based authentication method is constrained to only allow keys identified by IP address and therefore it lacks a robust way to do user authentication using a password, prompting the definition of different insecure ways to do password authentication. Therefore, a secure pre-shared key-based authentication method in IKEv1 will obviate the need to do insecure password-based authentication, such as [XAUTH], and remove the requirement that a pre-shared key in IKEv1 needs to be based on IP address. 3. Notation The following notation is used in this memo: psk A shared, secret and potentially low-entropy word, phrase, code or key used as a credential to mutually authenticate the peers. a = prf(b, c) The string "b" and "c" are given to a pseudo-random function to produce a fixed-length output "a". Harkins Expires October 28, 2011 [Page 4]

Internet-Draft Secure PSK Authentication for IKE April 2011 a | b denotes concatenation of string "a" with string "b". [a]b indicates a string consisting of the single bit "a" repeated "b" times. len(a) indicates the length in bits of the string "a". LSB(a) returns the least-significant bit of the bitstring "a". The convention for this memo to represent an element in a finite cyclic group is to use an upper-case letter or acronym, while a scalar is indicated with a lower-case letter or acronym. 4. Discrete Logarithm Cryptography This protocol uses Discrete Logarithm Cryptography to achieve authentication. Each party to the exchange derives ephemeral public and private keys with respect to a particular set of domain parameters (referred to here as a "group"). Groups can be either based on finite field cryptography (MODP groups) or elliptic curve cryptography (ECP groups). This protocol uses the same group as the IKE exchange in which it is being used for authentication, with the exception of characteristic- two elliptic curve groups (EC2N). Use of such groups is undefined for this authentication method and an IKE exchange that negotiates one of these groups MUST NOT use this method of authentication. For each group the following operations are defined: o "scalar operation"-- taking a scalar and an element in the group producing another element-- Z = scalar-op(x, Y). o "element operation"-- taking two elements in the group to produce a third-- Z = element-op(X, Y). o "inverse operation"-- take an element and returns another element such that the element operation on the two produces the identity element of the group-- Y = inverse(X). Harkins Expires October 28, 2011 [Page 5]

Internet-Draft Secure PSK Authentication for IKE April 2011 4.1. Elliptic Curve Cryptography (ECP) Groups The key exchange defined in this memo uses fundamental algorithms of ECP groups as described in [RFC6090]. Domain parameters for ECP elliptic curves used for secure pre-shared key-based authentication include: o A prime, p, determining a prime field GF(p). The cryptographic group will be a subgroup of the full elliptic curve group which consists points on an elliptic curve-- elements from GF(p) that satisfy the curve's equation-- together with the "point at infinity" (denoted here as "O") that serves as the identity element. o Elements a and b from GF(p) that define the curve's equation. The point (x,y) is on the elliptic curve if and only if y^2 = x^3 + a*x + b. o A prime, r, which is the order of G, and thus is also the size of the cryptographic subgroup that is generated by G. The scalar operation is multiplication of a point on the curve by itself a number of times. The point Y is multiplied x-times to produce another point Z: Z = scalar-op(x, Y) = x*Y The element operation is addition of two points on the curve. Points X and Y are summed to produce another point Z: Z = element-op(X, Y) = X + Y The inverse function is defined such that the sum of an element and its inverse is "0": Q + inverse(Q) = "O" Elliptic curve groups require a mapping function, q = F(Q), to convert a group element to an integer. The mapping function used in this memo returns the x-coordinate of the point it is passed. scalar-op(x, Y) can be viewed as x iterations of element-op() by defining: Y = scalar-op(1, Y) Harkins Expires October 28, 2011 [Page 6]

Internet-Draft Secure PSK Authentication for IKE April 2011 Y = scalar-op(x, Y) = element-op(Y, scalar-op(x-1, Y)), for x > 1 A definition of how to add two points on an elliptic curve (i.e. element-op(X, Y)) can be found in [RFC6090]. Note: There is another ECP domain parameter, a co-factor, h, that is defined by the requirement that the size of the full elliptic curve group (including "O") be the product of h and r. ECP groups used for secure pre-shared key-based authentication MUST have a co-factor of one (1). At the time of publication of this memo, all ECP groups in the IANA registry used by IKE had a co-factor of one (1). 4.2. Finite Field Cryptography (MODP) Groups Domain parameters for MODP groups used for secure pre-shared key- based authentication include: o A prime, p, determining a prime field GF(p), the integers modulo p. o A prime, r, which is the multiplicative order of G, and thus also the size of the cryptographic subgroup of GF(p)* that is generated by G. The scalar operation is exponentiation of a generator modulus a prime. An element Y is taken to the x-th power modulo the prime returning another element, Z: Z = scalar-op(x, Y) = Y^x mod p The element operation is modular multiplication. Two elementx, X and Y, are multiplied modulo the prime returning another element, Z: Z = element-op(X, Y) = (X * Y) mod p The inverse function for a MODP group is defined such that the product of an element and its inverse modulo the group prime equals one (1). In other words, (Q * inverse(Q)) mod p = 1 Unlike ECP groups, MODP groups do not require a mapping function to convert an element into a scalar. But for the purposes of notation in protocol definition, the function F, when used below, shall just return the value that was passed to it-- i.e. F(i) = i. Some MODP groups in the IANA registry for use by IKE (and the secure pre-shared key authentication method) are based on safe primes and Harkins Expires October 28, 2011 [Page 7]

Internet-Draft Secure PSK Authentication for IKE April 2011 the order is not included in the group's domain parameter set. In this case only, the order, r, MUST be computed as the prime minus one divided by two-- (p-1)/2. If an order is included in the group's domain parameter set that value MUST be used in this exchange when an order is called for. If a MODP group does not include an order in its domain parameter set and is not based on a safe prime it MUST NOT be used with this exchange. 5. Random Numbers As with IKE itself, the security of the secure pre-shared key authentication method relies upon each participant in the protocol producing quality secret random numbers. A poor random number chosen by either side in a single exchange can compromise the shared secret from that exchange and open up the possibility of dictionary attack. Producing quality random numbers without specialized hardware entails using a cryptographic mixing function (like a strong hash function) to distill entropy from multiple, uncorrelated sources of information and events. A very good discussion of this can be found in [RFC4086]. 6. Using Passwords as a Pre-Shared Key This protocol requires the pre-shared key to be represented as a binary string. When passwords are used it is necessary to transform the password into a binary string in a manner that will produce identical binary strings on the Initiator and the Responder. This imposes processing requirements on a password prior to its use. A registry maintained by IANA (the "Password Pre-Processing Method" registry of [RFC5931]) is used by this protocol to indicate, to a peer, a particular password pre-processing method to use. At the time of publication, three methods for password pre-processing were defined: o None: The input password string SHALL be treated as an ASCII string or a hexadecimal string with no treatment or normalization performed. The output SHALL be the binary representation of the input string. o RFC2759: The input password string SHALL be processed to produce the output PasswordHashHash, as defined in [RFC2759], including any approved errata to [RFC2759]. This technique is useful when at least one side does not have access to the plaintext password. Harkins Expires October 28, 2011 [Page 8]

Internet-Draft Secure PSK Authentication for IKE April 2011 o SASLprep: The input password string is processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHALL be considered a "stored string" per [RFC3454] and unassigned code points are therefore prohibited. The output SHALL be the binary representation of the processed UTF-8 character string. Prohibited output and unassigned codepoints encountered in SASLprep pre-processing SHALL cause a failure of pre-processing and the output SHALL NOT be used with Secure Password Authentication. For the purposes of interoperability, a password pre-processing method of "None" MUST be supported. "RFC2759" and "SASLprep" SHOULD be supported. Other methods defined in the future MAY be supported. Changing a password is out-of-scope of this memo but due to the ambiguities in the way internationalized character strings are handled it SHOULD be done using SASLprep ensure a canonical representation of the new password is stored and subsequent invocations of Secure PSK Authentication SHOULD use SASLprep to ensure that both sides generate an identical binary string from the input password. 7. Assumptions The security of the protocol relies on certain assumptions. They are: 1. The pseudo-random function, prf, defined in IKE (either [RFC2409] or [RFC5996]) acts as an "extractor" by concentrating the entropy from a secret input into a short, fixed, string. The output of prf is indistinguishable from a random source. 2. The discrete logarithm problem for the chosen finite cyclic group is hard. That is, given G, p and Y = G^x mod p it is computationally infeasible to determine x. Similarly for an elliptic curve group given the curve definition, a generator G, and Y = x * G it is computationally infeasible to determine x. 3. The pre-shared key is drawn from a finite pool of potential keys. Each possible key in the pool has equal probability of being the shared key. All potential attackers have access to this pool of keys. Harkins Expires October 28, 2011 [Page 9]

Internet-Draft Secure PSK Authentication for IKE April 2011 8. Secure PSK Authentication Message Exchange The key exchange described in this memo is based on the "Dragonfly" key exchange which has also been proposed in 802.11 wireless networks (see [SAE]) and as an EAP method (see [RFC5931]). "Dragonfly" is patent-free and royalty-free. It has been defined here for use in both IKEv1 ([RFC2409]) and IKEv2 ([RFC5996]). It makes use of the same pseudo-random function (prf) and the same Diffie-Hellman group that are negotiated for use in the IKE exchange that "dragonfly" is authenticating. A pseudo-random function which uses a block cipher is NOT RECOMMENDED for use with Secure PSK Authentication due to its poor job operating as an "extractor" (see Section 7). Pseudo-random functions based on hash functions using the HMAC construct from [RFC2104] SHOULD be used. To perform secure pre-shared key authentication each side must generate a shared and secret element in the chosen group based on the pre-shared key. This element, called the Secret Key Element, or SKE, is then used in an authentication and key exchange protocol. The key exchange protocol consists of each side exchanging a "Commit" payload and then proving knowledge of the resulting shared secret. The "Commit" payload contributes ephemeral information to the exchange and binds the sender to a single value of the pre-shared key from the pool of potential pre-shared keys. An authentication payload (either the HASH or AUTH payload depending on whether IKEv1 or IKEv2, respectively, is being used) proves that the pre-shared key is known and completes the zero-knowledge proof. 8.1. Negotiation of Secure PSK Authentication The technique used for negotiating whether, and how, to use Secure PSK Authentication depends on whether IKEv1 or IKEv2 is being used. 8.1.1. IKEv1 Negotiation With IKEv1, the Initiator indicates its desire to use Secure PSK Authentication by setting the Authentication Method in the SA payload to TBD1 from [IKEV1-IANA], by appending a Notify payload of type SPSK_AUTH (TBD2) [IKEV2-IANA] to the message containing the SA payload. See Section 8.5.1. The Responder indicates its desire to use Secure PSK Authentication by replying with an SA payload with the Authentication Method set to TBD1 and a Notify payload of type SPSK_AUTH. See Section 8.5.1. Harkins Expires October 28, 2011 [Page 10]

Internet-Draft Secure PSK Authentication for IKE April 2011 8.1.2. IKEv2 Negotiation With IKEv2, the Initiator indicates its desire to use Secure PSK Authentication by including a Notify payload of type SPSK_AUTH (TBD2) to the first message of the IKE_SA_INIT exchange. See Section 8.5.1. The Responder indicates its desire to perform Secure PSK Authentication by appending a Notify payload of type SPSK_AUTH (TBD2) to its response in the IKE_SA_INIT exchange. See Section 8.5.1. 8.2. Fixing the Secret Element, SKE The method of fixing SKE depends on the type of group, either MODP or ECP. The function "prf+" from [RFC5996] is used as a key derivation function. This is true even if performing secure pre-shared key authentication with IKEv1. Fixing SKE involves an iterative hunting-and-pecking technique using the prime from the negotiated group's domain parameter set and an ECP- or MODP-specific operation depending on the negotiated group. This technique requires the pre-shared key to be a binary string, therefore any password pre-processing transformation (see Section 6) MUST be performed on a password prior to fixing SKE. First, an 8-bit counter is set to the value one (1). Then, the pseudo-random function is used to generate a secret seed using the counter, the pre-shared key, and two nonces (without the fixed headers) exchanged by the Initiator and the Responder (see Section 8.6 and Section 8.7): ske-seed = prf(Ni | Nr, psk | counter) Then, the ske-seed is expanded using prf+ to create an ske-value: ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking") where len(ske-value) is the same as len(p), the length of the prime from the domain parameter set of the negotiated group. If the ske-seed is greater than or equal to the prime, p, the counter is incremented and a new ske-seed is generated and the hunting-and- pecking continues. If ske-seed is less than the prime, p, it is passed to the group-specific operation to select the SKE or fail. If the group-specific operation fails, the counter is incremented, a new ske-seed is generated and the hunting-and-pecking continues. Harkins Expires October 28, 2011 [Page 11]

Internet-Draft Secure PSK Authentication for IKE April 2011 8.2.1. ECP Operation to Select SKE The group-specific operation for ECP groups uses ske-value, ske-seed and the equation of the curve to produce SKE. First ske-value is used directly as the x-coordinate, x, with the equation of the elliptic curve, with parameters a and b from the domain parameter set of the curve, to solve for a y-coordinate, y. If there is no solution to the equation the operation fails (and the hunting-and-pecking continues). If a solution is found then an ambiguity exists as there are technically two solutions to the equation, and ske-seed is used to unambiguously select one of them. If the low-order bit of ske-seed is equal to the low-order bit of y then a candidate SKE is defined as the point (x,y); if the low-order bit of ske-seed differs from the low-order bit of y then a candidate SKE is defined as the point (x, p-y) where p is the prime from the negotiated group's domain parameter set. The candidate SKE becomes the SKE and the ECP-specific operation completes successfully. Algorithmically, the process looks like this: found = 0 counter = 1 do { ske-seed = prf(Ni | Nr, psk | counter) ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking") if (ske-value < p) then x = ske-value if ( (y = sqrt(x^3 + ax + b)) != FAIL) then if (LSB(y) == LSB(ske-seed)) then SKE = (x,y) else SKE = (x, p-y) fi found = 1 fi fi counter = counter + 1 } while (found == 0) Figure 1: Fixing SKE for ECP Groups Harkins Expires October 28, 2011 [Page 12]

Internet-Draft Secure PSK Authentication for IKE April 2011 8.2.2. MODP Operation to Select SKE The group-specific operation for MODP groups takes ske-value, and the prime, p, and order, r, from the group's domain parameter set to directly produce a candidate SKE by exponentiating the ske-value to the value ((p-1)/r) modulo the prime. If the candidate SKE is greater than one (1) the candidate SKE becomes the SKE and the MODP- specific operation completes successfully. Otherwise, the MODP- specific operation fails (and the hunting-and-pecking continues). Algorithmically, the process looks like this: found = 0 counter = 1 do { ske-seed = prf(Ni | Nr, psk | counter) ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking") if (ske-value < p) then SKE = ske-value ^ ((p-1)/r) mod p if (SKE > 1) then found = 1 fi fi counter = counter + 1 } while (found == 0) Figure 2: Fixing SKE for MODP Groups 8.3. Encoding and Decoding of Group Elements and Scalars The payloads used in the secure pre-shared key authentication method contain elements from the negotiated group and scalar values. To ensure interoperability, scalars and field elements MUST be represented in payloads in accordance with the requirements in this section. 8.3.1. Encoding and Decoding of Scalars Scalars MUST be represented (in binary form) as unsigned integers that are strictly less than r, the order of the generator of the agreed-upon cryptographic group. The binary representation of each scalar MUST have a bit length equal to the bit length of the binary representation of r. This requirement is enforced, if necessary, by prepending the binary representation of the integer with zeros until the required length is achieved. Harkins Expires October 28, 2011 [Page 13]

Internet-Draft Secure PSK Authentication for IKE April 2011 Scalars in the form of unsigned integers are converted into octet- strings and back again using the technique described in [RFC6090]. 8.3.2. Encoding and Decoding of ECP Elements Elements in ECP groups are points on the negotiated elliptic curve. Each such element MUST be represented by the concatenation of two components, an x-coordinate and a y-coordinate. Each of the two components, the x-coordinate and the y-coordinate, MUST be represented (in binary form) as an unsigned integer that is strictly less than the prime, p, from the group's domain parameter set. The binary representation of each component MUST have a bit length equal to the bit length of the binary representation of p. This length requirement is enforced, if necessary, by prepending the binary representation of the integer with zeros until the required length is achieved. The unsigned integers that represent the coordinates of the point are converted into octet-strings and back again using the technique described in [RFC6090]. Since the field element is represented in a payload by the x-coordinate followed by the y-coordinate it follows, then, that the length of the element in the payload MUST be twice the bit length of p. 8.3.3. Encoding and Decoding of MODP Elements Elements in MODP groups MUST be represented (in binary form) as unsigned integers that are strictly less than the prime, p, from the group's domain parameter set. The binary representation of each group element MUST have a bit length equal to the bit length of the binary representation of p. This length requirement is enforced, if necessary, by prepending the binary representation of the interger with zeros until the required length is achieved. The unsigned integer that represents a MODP element is converted into an octet-string and back using the technique described in [RFC6090]. 8.4. Message Generation and Processing 8.4.1. Generation of a Commit Before a Commit can be generated, the SKE must be fixed using the process described in Section 8.2. The password pre-processing method is selected by the Initiator and echoed back, if supported (see Section 8.4.2.3), by the Responder. Harkins Expires October 28, 2011 [Page 14]

Internet-Draft Secure PSK Authentication for IKE April 2011 A Commit has two components, a scalar and an Element. To generate a Commit, two random numbers, a "private" value and a "mask" value, are generated (see Section 5). Their sum modulo the order of the group, r, becomes the scalar component: scalar = (private + mask) mod r If the scalar is not greater than one (1), the private and mask values MUST be thrown away and new values randomly generated. If the scalar is greater than one (1), the inverse of the scalar operation with the mask and SKE becomes the Element component. Element = inverse(scalar-op(mask, SKE)) The Commit payload consists of the scalar followed by the Element and the scalar and Element are encoded in the Commit payload according to Section 8.3. 8.4.2. Processing of a Commit Upon receipt of a peer's Commit the scalar and element MUST be validated. The processing of an element depends on the type, either an ECP element or a MODP element. 8.4.2.1. Validation of an ECP Element Validating a received ECP Element involves: 1) checking whether the two coordinates, x and y, are both greater than zero (0) and less than the prime defining the underlying field; and 2) checking whether the x- and y-coordinates satisfy the equation of the curve (that is, that they produce a valid point on the curve that is not "0"). If either of these conditions are not met the received Element is invalid, otherwise the received Element is valid. 8.4.2.2. Validation of a MODP Element A received MODP Element is valid if: 1) it is between one (1) and the prime, p, exclusive; and 2) if modular exponentiation of the Element by the group order, r, equals one (1). If either of these conditions are not true the received Element is invalid. 8.4.2.3. Commit Processing Steps Commit validation is accomplished by the following steps: 1. The length of the Commit payload is checked against its anticipated length (the anticipated length of the scalar plus the anticipated length of the element, for the negotiated group). If Harkins Expires October 28, 2011 [Page 15]

Internet-Draft Secure PSK Authentication for IKE April 2011 it is incorrect, the Commit is invalidated, otherwise processing continues. 2. The peer's scalar is extracted from the Commit payload according to Section 8.3.1 and checked to ensure it is between one (1) and r, the order of the negotiated group, exclusive. If it is not, the Commit is invalidated, otherwise processing continues. 3. The peer's Element is extracted from the Commit payload according to Section 8.3.2 and checked in a manner that depends on the type of group negotiated. If the group is ECP the element is validated according to Section 8.4.2.1, if the group is MODP the element is validated according to Section 8.4.2.2. If the Element is not valid then the Commit is invalidated, otherwise the Commit is validated. 4. The Initiator of the IKE exchange has an added requirement to verify that the received element and scalar from the Commit payload differ from the element and scalar sent to the Responder. If they are identical, it signifies a reflection attack and the Commit is invalidated. If the Commit is invalidated the payload MUST be discarded and the IKE exchange aborted. 8.4.3. Authentication of the Exchange After a Commit has been generated and a peer's Commit has been processed a shared secret used to authenticate the peer is derived. Using SKE, the "private" value generated as part of Commit generation, and the peer's scalar and Element from its Commit, named here peer-scalar and peer-element, respectively, a preliminary shared secret, skey, is generated as: skey = F(scalar-op(private, element-op(peer-element, scalar-op(peer-scalar, SKE)))) For the purposes of subsequent computation, the bit length of skey SHALL be equal to the bit length of the prime, p, used in either a MODP or ECP group. This bit length SHALL be enforced, if necessary, by prepending zeros to the value until the required length is achieved. A shared secret, ss, is then computed from skey and the nonces exchanged by the Initiator (Ni) and Responder (Nr) (without the fixed headers) using prf(): Harkins Expires October 28, 2011 [Page 16]

Internet-Draft Secure PSK Authentication for IKE April 2011 ss = prf(Ni | Nr, skey | "Secure PSK Authentication in IKE") The shared secret, ss, is used in an authentication payload (either HASH or AUTH payload depending on whether IKEv1 or IKEv2, respectively, is being used) to prove possession of the shared secret, and therefore knowledge of the pre-shared key. 8.5. Payload Format 8.5.1. SPSK Notify Payload The Notify payload is used to convey a desire to perform SPSK Authentication as well as to negotiate a password pre-processing scheme to perform prior to generation of the SKE and performing the SPSK exchange. The header of a Notify payload differs subtly from IKEv1 to IKEv2 but, regardless, the body remains the same for SPSK. The body of a Notify payload used in SPSK is defined as follows: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain Of Interpretation (IKEv1 only) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol-ID | SPI Size ! Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Pre-process#1 | Pre-process#2 | .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Notify Message Type SHALL be indicated in both IKEv1 and IKEv2 with TBD2 from the [IKEV2-IANA] registry maintained by IANA. The Domain Of Interpretation is only present in IKEv1 Notify payloads. As indicated in [RFC5996], the Protocol-ID and SPI Size in Notify payloads that refer to the IKE SA (such as this one) SHALL be set to zero and, therefore, the "Security Parameter Index (SPI)" field SHALL not be included in the body of the Notify payload. The Pre-process fields indicate password pre-processing methods (see Section 6) to be negotiated prior to generating the SKE (see Section 8.2). The pre-processing field value is taken from the password "Password Pre-processing Methods" registry created by EAP- pwd [RFC5931]. The Initiator adds a series of pre-processing methods, and MUST include at least one, indicating its preferred methods, in order of Harkins Expires October 28, 2011 [Page 17]

Internet-Draft Secure PSK Authentication for IKE April 2011 preference, highest to lowest. The Responder MUST respond with a single pre-preocesing method that MUST be chosen from the series offered by the Initiator. 8.5.2. Commit Payload The Commit Payload is defined as follows: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Scalar ~ | | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | | ~ Element ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Commit Payload SHALL be indicated in both IKEv1 and IKEv2 with TBD3 from the [IKEV2-IANA] registry maintained by IANA. The Scalar and Element SHALL be encoded in the Commit payload according to Section 8.3. 8.6. IKEv1 Messaging Secure PSK Authentication can be used in either Main Mode (see Figure 3) or Aggressive Mode (see Figure 4) with IKEv1 and SHALL be indicated by negotiation of the TBD1 Authentication Method from [IKEV1-IANA], in the SA payload. When using IKEv1 the "C" (critical) bit from Section 8.5.2 MUST be clear (i.e. a value of zero). If the Responder sends a Notify payload indicating UNSUPPORTED_PREP (TBD4) in response to the initial message sent by the Initiator, the Initiator SHOULD choose another password pre-processing method, if supported, generate a new initial message containing this new Notify payload and attempt to initiate the exchange again. If no more password pre-processing methods are supported the exchange MUST be terminated. Harkins Expires October 28, 2011 [Page 18]

Internet-Draft Secure PSK Authentication for IKE April 2011 Initiator Responder ----------- ----------- HDR, SAi, Ii(SPSK) --> <-- HDR, SAr, Ir(SPSK) HDR, KEi, Ni --> <-- HDR, KEr, Nr HDR*, IDii, COMi --> <-- HDR*, IDir, COMr HDR*, HASH_I --> <-- HDR*, HASH_R where Ii and Ir are the Notify payload sent by the Initiator and Responder, respectively, and COMi is the Commit payload sent by the Initiator and COMr is the Commit payload sent by the Responder. Figure 3: Secure PSK in Main Mode Initiator Responder ----------- ----------- HDR, SAi, Ii(SPSK), KEi, Ni, IDii, COMi --> <-- HDR, SAr, Ir(SPSK), KEr, Nr, IDir, COMr HDR, HASH_I --> <-- HDR, HASH_R where Ii and Ir are the Notify payload sent by the Initiator and the Responder, respectively, and COMi is the Commit payload sent by the Initiator and COMr is the Commit payload sent by the Responder. Figure 4: Secure PSK in Aggressive Mode For Secure PSK Authentication with IKEv1 the SKEYID value is computed as follows: SKEYID = prf(Ni_b | Nr_b, g^xy) Note that in Main Mode, SKEYID_a and SKEYID_e are used to protect the messages containing the identities and Commit payloads. HASH_I and HASH_R are computed as follows: HASH_I = prf(SKEYID, ss | g^xi | g^xr | CKY-I | CKY-R | SA_ib | IDii_b | Ii_b | COMi_b | COMr_b) HASH_R = prf(SKEYID, ss | g^xr | g^xi | CKY-R | CKY-I | SA_ib | IDir_b | Ir_b | COMr_b | COMi_b) Harkins Expires October 28, 2011 [Page 19]

Internet-Draft Secure PSK Authentication for IKE April 2011 Where Ii_b and Ir_b indicate the body of the Notify payload (i.e. only the password pre-processing methods) from the Initiator's Notify and the Responder's Notify, respectively, "ss" is the shared secret derived in Section 8.4.3, and COMi_b and COMr_b are the scalar and Element from the Commit payloads (i.e. without the header) sent by the Initiator and Responder, respectively. 8.7. IKEv2 Messaging Secure PSK authentication in IKEv2 is negotiated in the IKE_SA_INIT exchange by including a Notify payload of type TBD2, indicating Secure PSK Authentication. The Initiator offers, and the Responder accepts (or refuses). If Secure PSK Authentication is negotiated during IKE_SA_INIT, the two peers SHALL immediately perform the IKE_SPSK_AUTH exchange (TBD5 from [IKEV2-IANA]) in lieu of an IKE_AUTH exchange (see [RFC5996]). If the Responder replies to the first message of the IKE_SA_INIT exchange with a Notify payload of type TBD4 indicating UNSUPPORTED_PREP, the Initiator SHOULD choose another password pre- processing method, if supported, and attempt the IKE_SA_INIT exchange indicating this new new password pre-processing method. If no more password pre-processing method are supported the Initiator MUST terminate the exchange. The IKE_SPSK_AUTH exchange is a two round-trip (i.e. four message) exchange which comprises the heart of the Secure PSK Authentication exchange. The parties exchange Commit payloads, perform the Secure PSK Authentication exchange, and then exchange AUTH payloads whose contents bind the IKEv2 exchange to the outcome of the Secure PSK Authentication exchange (see Figure 5). Harkins Expires October 28, 2011 [Page 20]

Internet-Draft Secure PSK Authentication for IKE April 2011 Initiator Responder ----------- ----------- IKE_SA_INIT: HDR, SAi1, KEi, Ni, Ii(SPSK) --> <-- HDR, SAr1, KEr, Nr, Ir(SPSK) IKE_SPSK_AUTH: HDR, SK {IDi, COMi, [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, COMr} HDR, SK {AUTHi} --> <-- HDR, SK {AUTHr, SAr2, TSi, TSr} where Ii(SPSK) and Ir(SPSK) are the Notify payloads sent by the Initiator and Responder, respectively, to perform password pre- processing negotiation (see Section 8.1), COMi and AUTHi are the Commit payload and AUTH payload, respectively, sent by the Initiator and COMr and AUTHr are the Commit payload and AUTH payload, respectively, sent by the Responder. Figure 5: Secure PSK in IKEv2 The AUTH payloads in the IKE_SPSK_AUTH exchange SHALL be computed as AUTHi = prf(ss, <InitiatorSignedOctets> | COMi | COMr) AUTHr = prf(ss, <ResponderSignedOctets> | COMr | COMi) Where "ss" is the shared secret derived in Section 8.4.3, COMi and COMr are the entire Commit payloads (including the fixed headers) sent by the Initiator and Responder, respectively, and <InitiatorSignedOctets> and <ResponderSignedOctets> are defined in [RFC5996]. The Authentication Method indicated in both AUTH payloads SHALL be TBD6 from [IKEV2-IANA]. 9. IANA Considerations IANA SHALL assign a value for "Secure Shared Key Authentication", replacing TBD1 above, from the IPSEC Authentication Method registry in [IKEV1-IANA] with the method name of "Secure PSK Authentication Method." IANA SHALL assign a value for "Secure Shared Key Authentication", replacing TBD2 above, from the IKEv2 Notify Message Types - Status Harkins Expires October 28, 2011 [Page 21]

Internet-Draft Secure PSK Authentication for IKE April 2011 Types registry in [IKEV2-IANA] with the type name of "SPSK_AUTH". IANA SHALL assign a value for the Commit payload (Section 8.5.2), replacing TBD3 above, from the "IKEv2 Payload Types" registry in [IKEV2-IANA] with the notation of "COM". IANA SHALL assign a value for UNSUPPORTED_PREP, replacing TBD4 above, from the IKEv2 Notify Message Types - Error Codes registry in [IKEV2-IANA] with the name "Unsupported Password Pre-Processing". IANA SHALL assign a value for the IKE_SPSK_AUTH exchange, replacing TBD5 above, from the IKEv2 Exchange Types registry in [IKEV2-IANA] with the name of "Secure PSK Authentication Exchange". IANA SHALL assign a value for "Secure Shared Key Authentication", replacing TBD6 above, from the IKEv2 Authentication Method registry in [IKEV2-IANA] with the Authentication Method name of "Secure PSK Authentication Method." 10. Security Considerations Both the Initiator and Responder obtain a shared secret, "ss" (see Section 8.4.3) based on a secret group element and their own private values contributed to the exchange. If they do not share the same pre-shared key they will be unable to derive the same secret group element and if they do not share the same secret group element they will be unable to derive the same shared secret. Resistance to dictionary attack means that the attacker must launch an active attack to make a single guess at the pre-shared key. If the size of the pool from which the key was extracted was D, and each key in the pool has an equal probability of being chosen, then the probability of success after a single guess is 1/D. After X guesses, and removal of failed guesses from the pool of possible keys, the probability becomes 1/(D-X). As X grows so does the probability of success. Therefore it is possible for an attacker to determine the pre-shared key through repeated brute-force, active, guessing attacks. This authentication method does not presume to be secure against this and implementations SHOULD ensure the size of D is sufficiently large to prevent this attack. Implementations SHOULD also take countermeasures, for instance refusing authentication attempts for a certain amount of time, after the number of failed authentication attempts reaches a certain threshold. No such threshold or amount of time is recommended in this memo. An active attacker can impersonate the Responder of the exchange and send a forged Commit payload after receiving the Initiator's Commit. Harkins Expires October 28, 2011 [Page 22]

Internet-Draft Secure PSK Authentication for IKE April 2011 The attacker then waits until it receives the authentication payload from the Responder. Now the attacker can attempt to run through all possible values of the pre-shared key, computing SKE (see Section 8.2), computing "ss" (see Section 8.4.3), and attempting to recreate the Confirm payload from the Responder. But the attacker committed to a single guess of the pre-shared key with her forged Commit. That value was used by the Responder in his computation of "ss" which was used in the authentication payload. Any guess of the pre-shared key which differs from the one used in the forged Commit would result in each side using a different secret element in the computation of "ss" and therefore the authentication payload could not be verified as correct, even if a subsequent guess, while running through all possible values, was correct. The attacker gets one guess, and one guess only, per active attack. An attacker, acting as either the Initiator or Responder, can take the Element from the Commit message received from the other party, reconstruct the random "mask" value used in its construction and then recover the other party's "private" value from the Scalar in the Commit message. But this requires the attacker to solve the discrete logarithm problem which we assumed was intractable above (Section 7). Instead of attempting to guess at pre-shared keys an attacker can attempt to determine SKE and then launch an attack. But SKE is determined by the output of the pseudo-random function, prf, which is assumed to be indistinguishable from a random source (Section 7). Therefore, each element of the finite cyclic group will have an equal probability of being the SKE. The probability of guessing SKE will be 1/r, where r is the order of the group. This is the same probability of guessing the solution to the discrete logarithm which is assumed to be intractable (Section 7). The attacker would have a better chance of success at guessing the input to prf, i.e. the pre- shared key, since the order of the group will be many orders of magnitude greater than the size of the pool of pre-shared keys. The implications of resistance to dictionary attack are significant. An implementation can provision a pre-shared key in a practical and realistic manner-- i.e. it MAY be a character string and it MAY be relatively short-- and still maintain security. The nature of the pre-share key determines the size of the pool, D, and countermeasures can prevent an attacker from determining the secret in the only possible way: repeated, active, guessing attacks. For example, a simple four character string using lower-case English characters, and assuming random selection of those characters, will result in D of over four hundred thousand. An attacker would need to mount over one hundred thousand active, guessing attacks (which will easily be detected) before gaining any significant advantage in determining the Harkins Expires October 28, 2011 [Page 23]

Internet-Draft Secure PSK Authentication for IKE April 2011 pre-shared key. For a more detailed discussion of the security of the key exchange underlying this authentication method see [SAE] and [RFC5931]. 11. Acknowledgements The author would like to thank Scott Fluhrer and Hideyuki Suzuki for their insight in discovering flaws in earlier versions of the key exchange that underlies this authentication method and for their helpful suggestions in improving it. Thanks to Lily Chen for useful advice on the hunting-and-pecking technique to "hash into" an element in a group and to Jin-Meng Ho for a discussion on countering a small sub-group attack. Rich Davis suggested several checks on received messages that greatly increase the security of the underlying key exchange. Hugo Krawczyk suggested using the prf as an extractor. 12. References 12.1. Normative References [IKEV1-IANA] "Internet Assigned Numbers Authority, Internet Key Exchange (IKE) Attributes", <http://www.iana.org/assignments/ipsec-registry>. [IKEV2-IANA] "Internet Assigned Numbers Authority, IKEv2 Parameters", <http://www.iana.org/assignments/ikev2-parameters>. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000. [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. Harkins Expires October 28, 2011 [Page 24]

Internet-Draft Secure PSK Authentication for IKE April 2011 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005. [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", RFC 5931, August 2010. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011. 12.2. Informative References [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attack", Proceedings of the IEEE Symposium on Security and Privacy, Oakland, 1992. [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure Password Authenticated Key Exchange Using Diffie-Hellman", Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag, 2000. [BPR00] Bellare, M., Pointcheval, D., and P. Rogaway, "Authenticated Key Exchange Secure Against Dictionary Attacks", Advances in Cryptology -- Eurocrypt '00, Lecture Notes in Computer Science Springer-Verlag, 2000. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [SAE] Harkins, D., "Simultaneous Authentication of Equals: A Secure, Password-Based Key Exchange for Mesh Networks", Proceedings of the 2008 Second International Conference on Sensor Technologies and Applications Volume 00, 2008. [XAUTH] Pereira, R. and S. Beaulieu, "Extended Authentication within ISAKMP/Oakley (XAUTH)", draft-ietf-ipsec-isakmp-xauth-06.txt (work in progress), December 1999. Harkins Expires October 28, 2011 [Page 25]

```
Internet-Draft Secure PSK Authentication for IKE April 2011
Author's Address
Dan Harkins
Aruba Networks
1322 Crossman Avenue
Sunnyvale, CA 94089-1113
United States of America
Email: dharkins@arubanetworks.com
Harkins Expires October 28, 2011 [Page 26]
```