summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6617.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6617.txt')
-rw-r--r--doc/rfc/rfc6617.txt1347
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc6617.txt b/doc/rfc/rfc6617.txt
new file mode 100644
index 0000000..6dbde7a
--- /dev/null
+++ b/doc/rfc/rfc6617.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Harkins
+Request for Comments: 6617 Aruba Networks
+Category: Experimental June 2012
+ISSN: 2070-1721
+
+
+ Secure Pre-Shared Key (PSK) Authentication
+ for the Internet Key Exchange Protocol (IKE)
+
+Abstract
+
+ This memo describes a secure pre-shared key (PSK) authentication
+ method for the Internet Key Exchange Protocol (IKE). It is resistant
+ to dictionary attack and retains security even when used with weak
+ pre-shared keys.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6617.
+
+Copyright Notice
+
+ Copyright (c) 2012 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. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+Harkins Experimental [Page 1]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Keyword Definitions ........................................3
+ 2. Usage Scenarios .................................................3
+ 3. Terms and Notation ..............................................4
+ 4. Discrete Logarithm Cryptography .................................5
+ 4.1. Elliptic Curve Cryptography (ECP) Groups ...................5
+ 4.2. Finite Field Cryptography (MODP) Groups ....................7
+ 5. Random Numbers ..................................................8
+ 6. Using Passwords and Raw Keys For Authentication .................8
+ 7. Assumptions .....................................................9
+ 8. Secure PSK Authentication Message Exchange ......................9
+ 8.1. Negotiation of Secure PSK Authentication ..................10
+ 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 .......14
+ 8.3.1. Encoding and Decoding of Scalars ...................14
+ 8.3.2. Encoding and Decoding of ECP Elements ..............15
+ 8.3.3. Encoding and Decoding of MODP Elements .............15
+ 8.4. Message Generation and Processing .........................16
+ 8.4.1. Generation of a Commit .............................16
+ 8.4.2. Processing of a Commit .............................16
+ 8.4.2.1. Validation of an ECP Element ..............16
+ 8.4.2.2. Validation of a MODP Element ..............16
+ 8.4.2.3. Commit Processing Steps ...................17
+ 8.4.3. Authentication of the Exchange .....................17
+ 8.5. Payload Format ............................................18
+ 8.5.1. Commit Payload .....................................18
+ 8.6. IKEv2 Messaging ...........................................19
+ 9. IANA Considerations ............................................20
+ 10. Security Considerations .......................................20
+ 11. Acknowledgements ..............................................22
+ 12. References ....................................................22
+ 12.1. Normative References .....................................22
+ 12.2. Informative References ...................................23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins Experimental [Page 2]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+1. Introduction
+
+ [RFC5996] allows for authentication of the IKE peers using a pre-
+ shared key. This exchange, though, is susceptible to dictionary
+ attack and is therefore insecure when used with weak pre-shared keys,
+ such as human-memorizable passwords. 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-hexadecimal key would require over
+ 100 characters to provide enough strength to generate a 128-bit key
+ suitable 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 [RFC5996] is 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 adversary 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 adversary 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.
+ Furthermore, 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
+ traffic on behalf of connected networks. Protected traffic is
+ between devices on the respective protected networks.
+
+
+
+
+
+Harkins Experimental [Page 3]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ 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 Security 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 process 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.
+
+3. Terms and Notation
+
+ The following terms and notations are 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
+ (prf) to produce a fixed-length output "a".
+
+ 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".
+
+ element
+ one member of a finite cyclic group.
+
+
+
+
+
+Harkins Experimental [Page 4]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ scalar
+ a quantity that can multiply an element.
+
+ 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 lowercase 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 (modular exponentiation (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" -- takes a scalar and an element in the group
+ to produce another element -- Z = scalar-op(x, Y).
+
+ o "element operation" -- takes two elements in the group to produce
+ a third -- Z = element-op(X, Y).
+
+ o "inverse operation" -- takes an element and returns another
+ element such that the element operation on the two produces the
+ identity element of the group -- Y = inverse(X).
+
+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 PSK
+ 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 that
+ consists of points on an elliptic curve -- elements from GF(p)
+ that satisfy the curve's equation -- together with the "point at
+ infinity" (denoted here as "0") that serves as the identity
+ element.
+
+
+
+Harkins Experimental [Page 5]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ 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, or number of elements in, a
+ subgroup generated by an element 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", the point-at-infinity of an elliptic curve group:
+
+ Q + inverse(Q) = "0"
+
+ 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)
+
+ 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 cofactor, h, that is
+ defined by the requirement that the size of the full elliptic curve
+ group (including "0") be the product of h and r. ECP groups used for
+ Secure PSK Authentication MUST have a cofactor of one (1). At the
+ time of publication of this memo, all ECP groups in [IKEV2-IANA] had
+ a cofactor of one (1).
+
+
+
+
+
+
+
+
+Harkins Experimental [Page 6]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+4.2. Finite Field Cryptography (MODP) Groups
+
+ Domain parameters for MODP groups used for Secure PSK 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, and thus also the
+ size, of the cryptographic subgroup of GF(p)* that is generated by
+ an element G.
+
+ The scalar operation is exponentiation of a generator modulo a prime.
+ An element Y is taken to the x-th power modulo the prime, thereby
+ returning another element, Z:
+
+ Z = scalar-op(x, Y) = Y^x mod p
+
+ The element operation is modular multiplication. Two elements, X and
+ Y, are multiplied modulo the prime, thereby 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 an integer. However, 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 [IKEV2-IANA] are based on safe primes, and 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.
+
+
+
+
+
+
+
+
+Harkins Experimental [Page 7]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+5. Random Numbers
+
+ As with IKE itself, the security of the Secure PSK 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 a dictionary attack.
+
+ Producing quality random numbers without specialized hardware entails
+ using a cryptographic mixing function (like a strong hash function)
+ to mix entropy from multiple, uncorrelated sources of information and
+ events. A very good discussion of this can be found in [RFC4086].
+
+6. Using Passwords and Raw Keys For Authentication
+
+ The PSK used as an authentication credential with this protocol can
+ be either a character-based password or passphrase, or it could be a
+ binary or hexadecimal string. Regardless, however, this protocol
+ requires both the Initiator and Responder to have identical binary
+ representations of the shared credential.
+
+ If the PSK is a character-based password or passphrase, there are two
+ types of pre-processing that SHALL be employed to convert the
+ password or passphrase into a hexadecimal string suitable for use
+ with Secure PSK Authentication. If a PSK is already a hexadecimal or
+ binary string, it SHALL be used directly as the shared credential
+ without any pre-processing.
+
+ The first step of pre-processing is to remove ambiguities that may
+ arise due to internationalization. Each character-based password or
+ passphrase MUST be pre-processed to remove that ambiguity by
+ processing the character-based password or passphrase according to
+ the rules of the SASLprep [RFC4013] profile of [RFC3454]. The
+ password or passphrase 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 PSK
+ Authentication.
+
+ The next pre-processing step for character-based passwords or
+ passphrases is to effectively obfuscate the string. This is done in
+ an attempt to reduce exposure of stored passwords in the event of
+ server compromise, or compromise of a server's database of stored
+ passwords. The step involves taking the output of the SASLprep
+ [RFC4013] profile of [RFC3454] and passing it, as the key, with the
+
+
+
+
+Harkins Experimental [Page 8]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ ASCII string "IKE Secure PSK Authentication", as the data, to HMAC-
+ SHA256(). The output of this obfuscation step SHALL become the
+ shared credential used with Secure PSK Authentication.
+
+ Note: Passwords tend to be shared for multiple purposes, and
+ compromise of a server or database of stored plaintext passwords can
+ be used, in that event, to mount multiple attacks. The obfuscation
+ step is merely to hide the password in the event of server compromise
+ or compromise of the database of stored passwords. Advances in
+ distributed computing power have diminished the effectiveness of
+ performing multiple prf iterations as a technique to prevent
+ dictionary attacks, so no such behavior is proscribed here. Mutually
+ consenting implementations can agree to use a different password
+ obfuscation method; the one described here is for interoperability
+ purposes only.
+
+ If a device stores passwords for use at a later time, it SHOULD pre-
+ process the password prior to storage. If a user enters a password
+ into a device at authentication time, it MUST be pre-processed upon
+ entry and prior to use with Secure PSK Authentication.
+
+7. Assumptions
+
+ The security of the protocol relies on certain assumptions. They
+ are:
+
+ 1. The pseudo-random function, prf, defined in [RFC5996], acts as an
+ "extractor" (see [RFC5869]) by distilling 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 adversaries have access to this pool
+ of keys.
+
+8. Secure PSK Authentication Message Exchange
+
+ The key exchange described in this memo is based on the "Dragonfly"
+ key exchange, which has also been defined for use in 802.11 wireless
+ networks (see [SAE]) and as an Extensible Authentication Protocol
+ (EAP) method (see [RFC5931]). "Dragonfly" is patent-free and
+
+
+
+Harkins Experimental [Page 9]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ royalty-free. It SHALL use 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 that 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 PSK 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 the "Dragonfly" authentication and key exchange protocol.
+ "Dragonfly" 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 (AUTH)
+ proves that the pre-shared key is known and completes the zero-
+ knowledge proof.
+
+8.1. Negotiation of Secure PSK Authentication
+
+ The Initiator indicates its desire to use Secure PSK Authentication
+ by adding a Notify payload of type SECURE_PASSWORD_METHODS (see
+ [RFC6467]) to the first message of the IKE_SA_INIT exchange and by
+ including 3 in the notification data field of the Notify payload,
+ indicating Secure PSK Authentication.
+
+ The Responder indicates its acceptance to perform Secure PSK
+ Authentication by adding a Notify payload of type
+ SECURE_PASSWORD_METHODS to its response in the IKE_SA_INIT exchange
+ and by adding the sole value of 3 to the notification data field of
+ the Notify payload.
+
+ If the Responder does not include a Notify payload of type
+ SECURE_PASSWORD_METHODS in its IKE_SA_INIT response, the Initiator
+ MUST terminate the exchange, and it MUST NOT fall back to the PSK
+ authentication method of [RFC5996]. If the Initiator only indicated
+ its support for Secure PSK Authentication (i.e., if the Notify data
+ field only contained 3) and the Responder replies with a Notify
+ payload of type SECURE_PASSWORD_METHODS and a different value in the
+ Notify data field, the Initiator MUST terminate the exchange.
+
+
+
+
+
+
+Harkins Experimental [Page 10]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+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.
+
+ 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 pre-processing transformation (see Section 6) MUST be
+ performed on the pre-shared key prior to fixing SKE.
+
+ To thwart side-channel attacks that attempt to determine the number
+ of iterations of the hunting-and-pecking loop that are used to find
+ SKE for a given password, a security parameter, k, is used to ensure
+ that at least k iterations are always performed.
+
+ Prior to beginning the hunting-and-pecking loop, an 8-bit counter is
+ set to the value one (1). Then the loop begins. First, 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):
+
+ 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, 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. This
+ process continues until the group-specific operation returns the
+ password element. After the password element has been chosen, a
+ random number is used in place of the password in the ske-seed
+ calculation, and the hunting-and-pecking continues until the counter
+ is greater than the security parameter, k.
+
+
+
+
+
+
+
+Harkins Experimental [Page 11]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+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.
+
+ Note: A method of checking whether a solution to the equation of the
+ elliptic curve is to see whether the Legendre symbol of (x^3 + ax +
+ b) equals one (1). If it does, then a solution exists; if it does
+ not, then there is no solution.
+
+ If there is no solution to the equation of the elliptic curve, then
+ the operation fails, the counter is incremented, a new ske-value and
+ ske-seed are selected, and the hunting-and-pecking continues. If
+ there is a solution then, y is calculated as the square root of (x^3
+ + ax + b) using the equation of the elliptic curve. In this case, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins Experimental [Page 12]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ Algorithmically, the process looks like this:
+
+ found = 0
+ counter = 1
+ v = psk
+ do {
+ ske-seed = prf(Ni | Nr, v | 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 (found == 0)
+ then
+ if (LSB(y) == LSB(ske-seed))
+ then
+ SKE = (x,y)
+ else
+ SKE = (x, p-y)
+ fi
+ found = 1
+ v = random()
+ fi
+ fi
+ fi
+ counter = counter + 1
+ } while ((found == 0) || (counter <= k))
+
+ where FAIL indicates that there is no solution to sqrt(x^3 + ax + b).
+
+ Figure 1: Fixing SKE for ECP Groups
+
+ Note: For ECP groups, the probability that more than "n" iterations
+ of the hunting-and-pecking loop are required to find SKE is roughly
+ (1-(r/2p))^n, which rapidly approaches zero (0) as "n" increases.
+
+8.2.2. MODP Operation to Select SKE
+
+ The group-specific operation for MODP groups takes ske-value, 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).
+
+
+
+
+
+Harkins Experimental [Page 13]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ Algorithmically, the process looks like this:
+
+ found = 0
+ counter = 1
+ v = psk
+ do {
+ ske-seed = prf(Ni | Nr, v | counter)
+ ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking")
+ if (ske-value < p)
+ then
+ ELE = ske-value ^ ((p-1)/r) mod p
+ if (ELE > 1)
+ then
+ if (found == 0)
+ SKE = ELE
+ found = 1
+ v = random()
+ fi
+ fi
+ fi
+ counter = counter + 1
+ } while ((found == 0) || (counter <= k))
+
+ Figure 2: Fixing SKE for MODP Groups
+
+ Note: For MODP groups, the probability that more than "n" iterations
+ of the hunting-and-pecking loop are required to find SKE is roughly
+ ((m-p)/p)^n, where m is the largest unsigned number that can be
+ expressed in len(p) bits, which rapidly approaches zero (0) as "n"
+ increases.
+
+8.3. Encoding and Decoding of Group Elements and Scalars
+
+ The payloads used in the Secure PSK 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 Experimental [Page 14]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ 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 integer
+ 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].
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins Experimental [Page 15]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+8.4. Message Generation and Processing
+
+8.4.1. Generation of a Commit
+
+ Before a Commit payload can be generated, the SKE must be fixed using
+ the process described in Section 8.2.
+
+ A Commit payload has two components, a scalar and an element. To
+ generate a Commit payload, 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 payload, 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; otherwise, the
+ received element is valid.
+
+
+
+Harkins Experimental [Page 16]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+8.4.2.3. Commit Processing Steps
+
+ Commit payload 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
+ it is incorrect, the Commit payload 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 payload 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 payload is invalidated;
+ otherwise, the Commit payload 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 payload is invalidated.
+
+ If the Commit payload is invalidated, the payload MUST be discarded
+ and the IKE exchange aborted.
+
+8.4.3. Authentication of the Exchange
+
+ After a Commit payload has been generated and a peer's Commit payload
+ has been processed, a shared secret used to authenticate the peer is
+ derived. Using SKE, the "private" value generated as part of Commit
+ payload generation, and the peer's scalar and element from the peer's
+ Commit payload, 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))))
+
+
+
+
+
+
+Harkins Experimental [Page 17]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ 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():
+
+ ss = prf(Ni | Nr, skey | "Secure PSK Authentication in IKE")
+
+ The shared secret, ss, is used in an AUTH authentication payload to
+ prove possession of the shared secret and therefore knowledge of the
+ pre-shared key.
+
+8.5. Payload Format
+
+8.5.1. Commit Payload
+
+ [RFC6467] defines a Generic Secure Password Method (GSPM) payload
+ that is used to convey information that is specific to a particular
+ secure password method. This memo uses the GSPM payload as a Commit
+ payload to contain the scalar and element used in the Secure PSK
+ Authentication exchange:
+
+ 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 scalar and element SHALL be encoded in the Commit payload
+ according to Section 8.3.
+
+
+
+
+
+Harkins Experimental [Page 18]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+8.6. IKEv2 Messaging
+
+ Secure PSK Authentication modifies the IKE_AUTH exchange by adding
+ one additional round trip to exchange Commit payloads to perform the
+ Secure PSK Authentication exchange and by changing the calculation of
+ the AUTH payload data to bind the IKEv2 exchange to the outcome of
+ the Secure PSK Authentication exchange (see Figure 3).
+
+ Initiator Responder
+ ----------- -----------
+
+ IKE_SA_INIT:
+
+ HDR, SAi1, KEi, Ni,
+ N(SPM-SPSK) -->
+
+ <-- HDR, SAr1, KEr, Nr,
+ N(SPM-SPSK)
+
+ IKE_AUTH:
+
+ HDR, SK {IDi, COMi, [IDr,]
+ SAi2, TSi, TSr} -->
+ <-- HDR, SK {IDr, COMr}
+ HDR, SK {AUTHi} -->
+ <-- HDR, SK {AUTHr, SAr2, TSi, TSr}
+
+ where N(SPM-SPSK) indicates the Secure Password Methods Notify
+ payloads used to negotiate the use of Secure PSK Authentication (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 3: Secure PSK in IKEv2
+
+ When doing Secure PSK Authentication, the AUTH payloads 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
+
+
+
+
+
+Harkins Experimental [Page 19]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ [RFC5996]. The Authentication Method indicated in both AUTH payloads
+ SHALL be "Generic Secure Password Authentication Method", value 12,
+ from [IKEV2-IANA].
+
+9. IANA Considerations
+
+ IANA has assigned the value 3 for "Secure PSK Authentication" from
+ the Secure Password Authentication Method registry in [IKEV2-IANA].
+
+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 adversary 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 adversary 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 value 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
+ payload. 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, by sending a forged Commit payload the attacker commits to a
+ single guess of the pre-shared key. 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 that differs
+ from the one used in the forged Commit payload would result in each
+
+
+
+Harkins Experimental [Page 20]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ 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 payload 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 payload. But this requires the attacker to solve the discrete
+ logarithm problem, which we assumed was intractable (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-shared key determines the size of the pool, D, and
+ countermeasures can prevent an adversary from determining the secret
+ in the only possible way: repeated, active, guessing attacks. For
+ example, a simple four-character string using lowercase English
+ characters, and assuming random selection of those characters, will
+ result in D of over four hundred thousand. An adversary would need
+ to mount over one hundred thousand active, guessing attacks (which
+ will easily be detected) before gaining any significant advantage in
+ determining the pre-shared key.
+
+ If an attacker knows the number of hunting-and-pecking loops that
+ were required to determine SKE, it is possible to eliminate passwords
+ from the pool of potential passwords and increase the probability of
+ successfully guessing the real password. MODP groups will require
+ more than "n" loops with a probability based on the value of the
+ prime -- if m is the largest unsigned number that can be expressed in
+ len(p) bits, then the probability is ((m-p)/p)^n -- which will
+ typically be very small for the groups defined in [IKEV2-IANA]. ECP
+
+
+
+Harkins Experimental [Page 21]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ groups will require more than one "n" loop with a probability of
+ roughly (1-(r/2p))^n. Therefore, a security parameter, k, is defined
+ that will ensure that at least k loops will always be executed
+ regardless of whether SKE is found in less than k loops. There is
+ still a probability that a password would require more than k loops,
+ and a side-channel attacker could use that information to his
+ advantage, so selection of the value of k should be based on a trade-
+ off between the additional workload to always perform k iterations
+ and the potential of providing information to a side-channel
+ attacker. It is important to note that the possibility of a
+ successful side-channel attack is greater against ECP groups than
+ MODP groups, and it might be appropriate to have separate values of k
+ for the two.
+
+ 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
+
+ [IKEV2-IANA] IANA, "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.
+
+ [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings ("stringprep")", RFC 3454,
+ December 2002.
+
+
+
+
+
+Harkins Experimental [Page 22]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
+ Names and Passwords", RFC 4013, February 2005.
+
+ [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.
+
+ [RFC6467] Kivinen, T., "Secure Password Framework for Internet
+ Key Exchange Version 2 (IKEv2)", RFC 6467,
+ December 2011.
+
+12.2. Informative References
+
+ [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange:
+ Password-Based Protocols Secure Against Dictionary
+ Attacks", 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.
+
+ [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-
+ Expand Key Derivation Function (HKDF)", RFC 5869,
+ May 2010.
+
+ [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication
+ Protocol (EAP) Authentication Using Only a Password",
+ RFC 5931, August 2010.
+
+
+
+
+Harkins Experimental [Page 23]
+
+RFC 6617 Secure PSK Authentication for IKE June 2012
+
+
+ [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.
+
+Author's Address
+
+ Dan Harkins
+ Aruba Networks
+ 1322 Crossman Avenue
+ Sunnyvale, CA 94089-1113
+ United States of America
+
+ EMail: dharkins@arubanetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins Experimental [Page 24]
+