RFC 6617
Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE)
Part 1 of 5 ✨
RFC 6617: Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE) 🎀
Internet Engineering Task Force (IETF) 💖 Request for Comments: 6617 Author: D. Harkins, Aruba Networks Category: Experimental Date: June 2012 ISSN: 2070-1721 Obsoletes / Updates: The header doesn't list anything this one obsoletes or updates 🧚
Abstract ✨
okay so this memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE) 🔐 it's resistant to dictionary attacks and it keeps its security even when people use weak pre-shared keys. iconic, right? 💅
Status of This Memo 🌸
this document is NOT an Internet Standards Track spec 🙅♀️ it's published so people can examine it, try it out with experimental implementations, and evaluate it.
it defines an Experimental Protocol for the Internet community 🧪 it's a product of the IETF, it represents the consensus of the IETF community, and it got public review and approval for publication from the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the deets 🤓
for info on the current status of this doc, any errata, and how to send feedback, go to 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this was published 📜 please actually read those, bestie, because they explain your rights and restrictions with respect to this document. also, any Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⭐
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 ...................................231. Introduction ✨
okay so [RFC5996] lets IKE peers authenticate each other with a pre-shared key 🔑 but here's the tea 🫖 this exchange is susceptible to dictionary attack, which makes it insecure when people use weak pre-shared keys like human-memorizable passwords 😭 to fix this, [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 need over 100 characters to be strong enough to generate a 128-bit key suitable for AES 💀 which is wild, because humans have a hard time typing a string over 20 characters without making errors. so pre-shared key authentication in [RFC5996] is used insecurely today 🙈
a pre-shared key authentication method built on top of a zero-knowledge proof gives you resistance to dictionary attack, and it still keeps security even with weak pre-shared keys like user-chosen passwords 🧚 that method is what this memo describes, and it's giving main character energy 👑
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 to put it is that any advantage the adversary can get comes through interaction and not through computation. this is demonstrably different from the technique in [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 one 😬 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. there are three of them 🙌
- "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. the protected traffic goes between devices on the respective protected networks.
- "Endpoint-to-Endpoint Transport": the endpoints of the IKE (and IPsec) communication are hosts according to [RFC4301]. the protected traffic goes between the two endpoints.
- "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 the network node, but the protected traffic goes between the endpoint and another device on the protected network behind the node.
the authentication and key exchange process in this memo is suitable for all the usage scenarios described in [RFC5996] 🫶 in the "Security Gateway to Security Gateway Tunnel" and "Endpoint-to-Endpoint Transport" scenarios, it gives you a secure method of authentication without requiring a certificate 🎉 for the "Endpoint to Security Gateway Tunnel" scenario, it provides secure username+password authentication, which is super 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 strings "b" and "c" are given to a pseudo-random function (prf) to produce a fixed-length output "a" ✨a | b: denotes concatenation of the string "a" with the 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 💎
- scalar: a quantity that can multiply an element ✖️
the convention in this memo for representing 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 🔤 so if it's CAPS it's an element and if it's lowercase it's a scalar. easy peasy 🌸
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 based on finite field cryptography (modular exponentiation (MODP) groups) or on elliptic curve cryptography (ECP groups) 🌈
this protocol uses the same group as the IKE exchange it's being used for authentication in, with one exception: characteristic-two elliptic curve groups (EC2N) 🚫 use of those groups is undefined for this authentication method, so an IKE exchange that negotiates one of these groups MUST NOT use this method of authentication 🙅♀️ bestie, don't do it.
for each group, the following operations are defined 🧩
- "scalar operation" -- takes a scalar and an element in the group to produce another element --
Z = scalar-op(x, Y). - "element operation" -- takes two elements in the group to produce a third --
Z = element-op(X, Y). - "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 ✨
okay so the key exchange in this memo uses the fundamental algorithms of ECP groups, as described in [RFC6090] 💖
bestie, these are the domain parameters for ECP elliptic curves used for Secure PSK Authentication:
- A prime, p, determining a prime field GF(p). The cryptographic group will be a subgroup of the full elliptic curve group. That group is made of points on an elliptic curve (elements from GF(p) that satisfy the curve's equation) plus the "point at infinity" (denoted here as "0"), which is the identity element 🧚
- 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🎀 - A prime, r, which is the order of, or number of elements in, a subgroup generated by an element G 🦋
the scalar operation is multiplying a point on the curve by itself a number of times. so point Y gets multiplied x-times to make another point Z:
Z = scalar-op(x, Y) = x*Ythe element operation is adding two points on the curve. points X and Y get summed to make another point Z:
Z = element-op(X, Y) = X + Ythe inverse function is set up so that an element plus its inverse equals "0", the point-at-infinity of an elliptic curve group. no cap, this is the core of the whole vibe:
Q + inverse(Q) = "0"elliptic curve groups need a mapping function, q = F(Q), to turn a group element into an integer. the mapping function used in this memo returns the x-coordinate of the point it gets passed 🌸
scalar-op(x, Y) can be seen as x iterations of element-op() if you define it like this:
Y = scalar-op(1, Y)
Y = scalar-op(x, Y) = element-op(Y, scalar-op(x-1, Y)), for x > 1the full details on how to add two points on an elliptic curve (that's element-op(X, Y)) are in [RFC6090] 💅
Note: There is another ECP domain parameter, a cofactor, h. It's 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) 🔥
4.2. Finite Field Cryptography (MODP) Groups 🍓
for MODP groups used with Secure PSK Authentication, the domain parameters are:
- A prime, p, determining a prime field GF(p), the integers modulo p 💜
- A prime, r, which is the multiplicative order, and therefore 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 gets raised to the x-th power modulo the prime, and that gives you another element, Z:
Z = scalar-op(x, Y) = Y^x mod pthe element operation is modular multiplication. two elements, X and Y, get multiplied modulo the prime, which returns another element, Z:
Z = element-op(X, Y) = (X * Y) mod pthe inverse function for a MODP group is set up so that an element times its inverse, modulo the group prime, equals one (1). in other words:
(Q * inverse(Q)) mod p = 1unlike ECP groups, MODP groups don't need a mapping function to turn an element into an integer. still, for notation in the protocol definition, the function F (when it shows up below) shall just return whatever value got passed to it, so F(i) = i ✨
some MODP groups in [IKEV2-IANA] are based on safe primes, and their order isn't included in the group's domain parameter set. in that case only, the order, r, MUST be computed as the prime minus one divided by two, which is (p-1)/2. if an order is included in the group's domain parameter set, that value MUST be used in this exchange whenever an order is called for. and if a MODP group doesn't include an order in its domain parameter set and isn't based on a safe prime, it MUST NOT be used with this exchange 🙅♀️
5. Random Numbers 🎲
just like IKE itself, the security of Secure PSK Authentication depends on every participant producing quality secret random numbers. a bad random number from either side in a single exchange can compromise the shared secret from that exchange and open the door to a dictionary attack 😭
to make quality random numbers without specialized hardware, you use a cryptographic mixing function (like a strong hash function) to mix entropy from multiple, uncorrelated sources of information and events. there's a really good discussion of this 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 a binary or hexadecimal string. either way, 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 turn the password or passphrase into a hexadecimal string suitable for Secure PSK Authentication. if a PSK is already a hexadecimal or binary string, it SHALL be used directly as the shared credential, no pre-processing needed 💖
the first pre-processing step is removing ambiguities that can come up because of internationalization. each character-based password or passphrase MUST be pre-processed to remove that ambiguity, by processing it according to the rules of the SASLprep [RFC4013] profile of [RFC3454]. the password or passphrase SHALL be considered a "stored string" per [RFC3454], so unassigned code points are prohibited. the output SHALL be the binary representation of the processed UTF-8 character string. if prohibited output or unassigned codepoints show up during SASLprep pre-processing, the pre-processing SHALL fail, and that output SHALL NOT be used with Secure PSK Authentication 🚫
the next pre-processing step for character-based passwords or passphrases is to obfuscate the string. this is done to reduce exposure of stored passwords if a server, or a server's database of stored passwords, gets compromised. the step takes the output of the SASLprep [RFC4013] profile of [RFC3454], passes it as the key, along with the ASCII string "IKE Secure PSK Authentication" as the data, into 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 there to hide the password if a server or a database of stored passwords gets compromised. 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:
- 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 🌸
- 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 🔥
- 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. it's 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 royalty-free, bestie 🎉 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 Secure PSK Authentication, because it does a 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 is called the Secret Key Element, or SKE, and it gets used in the "Dragonfly" authentication and key exchange protocol. "Dragonfly" works by each side exchanging a Commit payload and then proving knowledge of the resulting shared secret 🦋
the Commit payload adds 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 says it wants 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, which indicates Secure PSK Authentication 💖
the Responder says yes to performing 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 that Notify payload 🎀
if the Responder doesn't 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 support for Secure PSK Authentication (meaning the Notify data field only contained 3) and the Responder replies with a Notify payload of type SECURE_PASSWORD_METHODS with a different value in the Notify data field, the Initiator MUST terminate the exchange 🚨
8.2. Fixing the Secret Element, SKE ✨
okay so the way we fix SKE totally depends on what kind of group we're using, either MODP or ECP 💅 The function prf+ from [RFC5996] is the key derivation function we use here 🔑
Fixing SKE is an iterative hunting-and-pecking technique 🦋 It uses the prime from the negotiated group's domain parameter set, plus an ECP- or MODP-specific operation depending on which group got picked. This technique needs the pre-shared key to be a binary string, so 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 try to figure out how many iterations of the hunting-and-pecking loop were needed to find SKE for a given password, we use a security parameter, k, to make sure that at least k iterations are always performed 🙈 no peeking allowed bestie
Before the hunting-and-pecking loop starts, an 8-bit counter gets set to the value one (1) 🌸 then the loop begins! First, the pseudo-random function generates a secret seed using the counter, the pre-shared key, and two nonces (without the fixed headers) that the Initiator and the Responder exchanged (see Section 8.6) 🧚
ske-seed = prf(Ni | Nr, psk | counter)Then the ske-seed gets 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 gets incremented, a new ske-seed is generated, and the hunting-and-pecking keeps going 🔁 If ske-seed is less than the prime, p, it gets passed to the group-specific operation to either select the SKE or fail. If the group-specific operation fails, the counter gets incremented, a new ske-seed is generated, and the hunting-and-pecking continues 💀 This keeps happening until the group-specific operation returns the password element. Once 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 👑
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 exists 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 gets 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. Here's the twist: there are technically two solutions to the equation, so 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
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 GroupsNote: 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) 🍓
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 GroupsNote: 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 keep everything interoperable, 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 🧸
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] 🌈
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 rIf 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 🎉
8.4.2.3. Commit Processing Steps 🔍
Checking a Commit payload is a four-step glow-up 💅 Here's how it goes:
- The length of the Commit payload gets checked against its anticipated length, which is the anticipated length of the scalar plus the anticipated length of the element, for the negotiated group. If the length is wrong, the Commit payload is invalidated. Otherwise, processing continues. ✨
- The peer's scalar gets extracted from the Commit payload according to Section 8.3.1 and checked to make sure it's between one (1) and r, the order of the negotiated group, exclusive. If it isn't, the Commit payload is invalidated. Otherwise, processing continues. 🦋
- The peer's element gets extracted from the Commit payload according to Section 8.3.2 and checked in a way 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 isn't valid, the Commit payload is invalidated. Otherwise, the Commit payload is validated. 🌸
- The Initiator of the IKE exchange has an extra check to do 🙈 They need to verify that the element and scalar received in the Commit payload differ from the element and scalar they sent to the Responder. If they're identical, that's a reflection attack, and the Commit payload is invalidated. Not on my watch 😤
If the Commit payload is invalidated, the payload MUST be discarded and the IKE exchange aborted. 💀
8.4.3. Authentication of the Exchange 🔐
Okay so after a Commit payload has been generated and a peer's Commit payload has been processed, there's a shared secret used to authenticate the peer that gets derived. Using SKE, the "private" value generated during Commit payload generation, and the peer's scalar and element from the peer's Commit payload (named peer-scalar and Peer-Element here), a preliminary shared secret, skey, is generated like this:
skey = F(scalar-op(private,
element-op(Peer-Element,
scalar-op(peer-scalar, SKE))))For the purposes of later 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. 🎀
Next, a shared secret, ss, is 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, gets used in an AUTH authentication payload to prove possession of the shared secret, and therefore knowledge of the pre-shared key. It's the whole point, bestie 🫶
8.5. Payload Format 🎁
8.5.1. Commit Payload 💌
[RFC6467] defines a Generic Secure Password Method (GSPM) payload that's used to carry information 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. Here's the layout:
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. 🧚
8.6. IKEv2 Messaging 📨
Secure PSK Authentication changes the IKE_AUTH exchange in two ways. It adds one extra round trip to swap Commit payloads for the Secure PSK Authentication exchange, and it changes how the AUTH payload data is calculated, so the IKEv2 exchange is bound to the outcome of that Secure PSK Authentication exchange (see Figure 3). Main character energy ✨
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) marks 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 sent by the Initiator, and COMr and AUTHr are the Commit payload and AUTH payload sent by the Responder. 📝
Figure 3: Secure PSK in IKEv2When doing Secure PSK Authentication, the AUTH payloads SHALL be computed as:
AUTHi = prf(ss, <InitiatorSignedOctets> | COMi | COMr)
AUTHr = prf(ss, <ResponderSignedOctets> | COMr | COMi)Here, "ss" is the shared secret derived in Section 8.4.3. COMi and COMr are the entire Commit payloads (fixed headers included) sent by the Initiator and Responder, respectively. <InitiatorSignedOctets> and <ResponderSignedOctets> are defined in [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 🔐✨
okay bestie, this section is the most important one in the whole doc, so grab your snacks 🍓 and let's go. The big idea is that both the Initiator and the Responder end up with a shared secret, "ss" (see Section 8.4.3) 💖. It comes from a secret group element plus each side's own private values. If they don't have the same pre-shared key, they can't derive the same secret group element, and if they don't have the same secret group element, they can't derive the same shared secret. no cap, it's all connected 🫶
Now let's talk about dictionary attacks 💀. Resisting one means the attacker has to launch an active attack just to make a single guess at the pre-shared key. If the pool the key came from has d options and every key is equally likely, the chance of getting it right on one guess is 1/d. After x guesses, with the wrong ones tossed out of the pool, the chance becomes 1/(d-x). So the more guesses they make, the better their odds get 😭. That means an attacker can figure out the pre-shared key through repeated brute-force, active, guessing attacks. This method does not claim to be secure against that, so implementations SHOULD make sure the value of d is big enough to stop this attack 🌸. Implementations SHOULD also add countermeasures, like refusing authentication attempts for a while once the failed attempts hit a certain threshold. This memo doesn't recommend any particular threshold or amount of time 🙈
Next up, an active attacker can pretend to be the Responder and send a forged Commit payload after getting the Initiator's Commit payload 👀. Then they wait for the Responder's authentication payload. After that, the attacker can try every possible pre-shared key value, computing SKE (see Section 8.2), computing "ss" (see Section 8.4.3), and trying to recreate the Confirm payload from the Responder. it's a whole plan, honestly 🧚
BUT here's the plot twist 🦋: by sending that forged Commit payload, the attacker has already committed to one single guess of the pre-shared key. The Responder used that value when computing "ss", and "ss" went into the authentication payload. If any other guess differs from the one in the forged Commit payload, each side ends up using a different secret element when computing "ss", so the authentication payload can't be verified as correct. Even if a later guess in the run-through is the right one, it won't help. The attacker gets one guess, and only one guess, per active attack 👑
Another thing 🙈: an attacker acting as either the Initiator or the Responder can take the element from the Commit payload the other party sent, rebuild the random "mask" value that was used to make it, and then recover the other party's "private" value from the scalar in the Commit payload. But that requires solving the discrete logarithm problem, which we assumed is intractable (Section 7). so, not happening, periodt 💅
What if the attacker tries to figure out SKE directly instead of guessing passwords? SKE comes out of the pseudo-random function, prf, which is assumed to be indistinguishable from a random source (Section 7). So every element of the finite cyclic group has an equal chance of being the SKE. The chance of guessing SKE is 1/r, where r is the order of the group. That's the same chance as guessing the solution to the discrete logarithm, which is also assumed to be intractable (Section 7). Honestly the attacker would have a better shot guessing the input to prf, which is the pre-shared key, since the order of the group is many orders of magnitude bigger than the pool of pre-shared keys ✨
The implications of resisting dictionary attacks are huge 🎀. An implementation can set up a pre-shared key in a practical, realistic way. It MAY be a character string, and it MAY be fairly short, and it can still stay secure 💜. The nature of the pre-shared key decides the size of the pool, D, and countermeasures can stop an adversary from finding the secret in the only way left to them: repeated, active, guessing attacks. For example, a simple four-character string made of lowercase English letters, picked randomly, gives a D of over four hundred thousand. An adversary would need to run over one hundred thousand active, guessing attacks (which will easily get noticed) before getting any real advantage in figuring out the pre-shared key 🦋
Okay, now the side-channel stuff 👀. If an attacker knows how many hunting-and-pecking loops it took to find SKE, they can cross passwords off the list of possible passwords and boost their odds of guessing the real one. MODP groups will need more than "n" loops, with a probability based on the value of the prime. If m is the largest unsigned number that fits in len(p) bits, then the probability is ((m-p)/p)^n. For the groups defined in [IKEV2-IANA], that's typically very small. ECP groups need more than one "n" loop, with a probability of roughly (1-(r/2p))^n. So a security parameter, k, is defined to make sure at least k loops always run, even if SKE is found in fewer than k loops. Still, there's a chance a password needs more than k loops, and a side-channel attacker could use that info to their advantage. So picking k is a trade-off between the extra work of always doing k iterations and the risk of leaking info to a side-channel attacker. It's important to note that side-channel attacks are more likely to work against ECP groups than MODP groups, so it might make sense to have separate values of k for the two 😭🫶
For a deeper dive into the security of the key exchange underlying this authentication method, check out [SAE] and [RFC5931] 📚💖
11. Acknowledgements 🌷
The author wants to give a shout-out to 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.
- [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.
- [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
📦 where this page comes from
- ietf: rfc6617 2012-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms