Network Working Group D. Harkins
Internet-Draft Aruba Networks
Intended status: Experimental July 27, 2011
Expires: January 28, 2012
Secure PSK Authentication for IKE
draft-harkins-ipsecme-spsk-auth-05
Abstract
This memo describes a secure pre-shared key authentication method for
IKE. It is resistant to dictionary attack and retains security even
when used with weak pre-shared keys.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 28, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. 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 Expires January 28, 2012 [Page 1]
Internet-Draft Secure PSK Authentication for IKE July 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Keyword Definitions . . . . . . . . . . . . . . . . . . . 3
2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3
3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Discrete Logarithm Cryptography . . . . . . . . . . . . . . . 5
4.1. Elliptic Curve Cryptography (ECP) Groups . . . . . . . . . 6
4.2. Finite Field Cryptography (MODP) Groups . . . . . . . . . 7
5. Random Numbers . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Using Passwords 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.1.1. IKEv1 Negotiation . . . . . . . . . . . . . . . . . . 10
8.1.2. IKEv2 Negotiation . . . . . . . . . . . . . . . . . . 11
8.2. Fixing the Secret Element, SKE . . . . . . . . . . . . . . 11
8.2.1. ECP Operation to Select SKE . . . . . . . . . . . . . 12
8.2.2. MODP Operation to Select SKE . . . . . . . . . . . . . 13
8.3. Encoding and Decoding of Group Elements and Scalars . . . 14
8.3.1. Encoding and Decoding of Scalars . . . . . . . . . . . 14
8.3.2. Encoding and Decoding of ECP Elements . . . . . . . . 14
8.3.3. Encoding and Decoding of MODP Elements . . . . . . . . 15
8.4. Message Generation and Processing . . . . . . . . . . . . 15
8.4.1. Generation of a Commit . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . 16
8.4.3. Authentication of the Exchange . . . . . . . . . . . . 17
8.5. Payload Format . . . . . . . . . . . . . . . . . . . . . . 17
8.5.1. Commit Payload . . . . . . . . . . . . . . . . . . . . 18
8.5.2. Notify Payload . . . . . . . . . . . . . . . . . . . . 18
8.6. IKEv1 Messaging . . . . . . . . . . . . . . . . . . . . . 19
8.7. IKEv2 Messaging . . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Harkins Expires January 28, 2012 [Page 2]
Internet-Draft Secure PSK Authentication for IKE July 2011
1. Introduction
Both [RFC2409] and [RFC5996] allow for authentication of the IKE
peers using a pre-shared key. The exchanges, though, are susceptible
to dictionary attack and are therefore insecure. In addition,
[RFC2409] requires that a pre-shared key be identified by IP address
and this severely constrains its usefulness. These are obvious
drawbacks to using pre-shared key authentication in IKEv1 and IKEv2.
To address the security issue, [RFC5996] recommends that the pre-
shared key used for authentication "contain as much unpredictability
as the strongest key being negotiated". That means any non-
hexidecimal key would require over 100 characters to provide enough
strength to generate a 128-bit key for AES. This is an unrealistic
requirement because humans have a hard time entering a string over 20
characters without error. Consequently, pre-shared key
authentication in [RFC2409] and [RFC5996] are used insecurely today.
A pre-shared key authentication method built on top of a zero-
knowledge proof will provide resistance to dictionary attack and
still allow for security when used with weak pre-shared keys, such as
user-chosen passwords. Such an authentication method is described in
this memo.
Resistance to dictionary attack is achieved when an attacker gets
one, and only one, guess at the secret per active attack (see for
example, [BM92], [BMP00] and [BPR00]). Another way of putting this
is that any advantage the attacker can realize is through interaction
and not through computation. This is demonstrably different than the
technique from [RFC5996] of using a large, random number as the pre-
shared key. That can only make a dictionary attack less likely to
succeed, it does not prevent a dictionary attack. And, as [RFC5996]
notes, it is completely insecure when used with weak keys like user-
generated passwords.
1.1. Keyword Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Usage Scenarios
[RFC5996] describes usage scenarios for IKEv2. These are:
1. "Security Gateway to Security Gateway Tunnel": the endpoints of
the IKE (and IPsec) communication are network nodes that protect
Harkins Expires January 28, 2012 [Page 3]
Internet-Draft Secure PSK Authentication for IKE July 2011
traffic on behalf of connected networks. Protected traffic is
between devices on the respective protected networks.
2. "Endpoint-to-Endpoint Transport": the endpoints of the IKE (and
IPsec) communication are hosts according to [RFC4301]. Protected
traffic is between the two endpoints.
3. "Endpoint to Securty Gateway Tunnel": one endpoint connects to a
protected network through a network node. The endpoints of the
IKE (and IPsec) communication are the endpoint and network node,
but the protected traffic is between the endpoint and another
device on the protected network behind the node.
The authentication and key exchange described in this memo is
suitable for all the usage scenarios described in [RFC5996]. In the
"Security Gateway to Security Gateway Tunnel" scenario and the
"Endpoint-to-Endpoint Transport" scenario it provides a secure method
of authentication without requiring a certificate. For the "Endpoint
to Security Gateway Tunnel" scenario it provides for secure username+
password authentication that is popular in remote access VPN
situations.
[RFC2409] does not describe usage scenarios for IKEv1 but IKEv1 has,
traditionally, been used in the same "Security Gateway to Security
Gateway Tunnel" scenario and the "Endpoint-to-Endpoint Transport"
scenario. Its pre-shared key-based authentication method is
constrained to only allow keys identified by IP address and therefore
it lacks a robust way to do user authentication using a password,
prompting the definition of different insecure ways to do password
authentication. Therefore, a secure pre-shared key-based
authentication method in IKEv1 will obviate the need to do insecure
password-based authentication, such as [XAUTH], and remove the
requirement that a pre-shared key in IKEv1 needs to be based on IP
address.
3. Notation
The following notation is used in this memo:
PSK
A shared, secret and potentially low-entropy word, phrase, code
or key used as a credential to mutually authenticate the peers.
a = prf(b, c)
The string "b" and "c" are given to a pseudo-random function to
produce a fixed-length output "a".
Harkins Expires January 28, 2012 [Page 4]
Internet-Draft Secure PSK Authentication for IKE July 2011
a | b
denotes concatenation of string "a" with string "b".
[a]b
indicates a string consisting of the single bit "a" repeated "b"
times.
len(a)
indicates the length in bits of the string "a".
LSB(a)
returns the least-significant bit of the bitstring "a".
The convention for this memo to represent an element in a finite
cyclic group is to use an upper-case letter or acronym, while a
scalar is indicated with a lower-case letter or acronym.
4. Discrete Logarithm Cryptography
This protocol uses Discrete Logarithm Cryptography to achieve
authentication. Each party to the exchange derives ephemeral public
and private keys with respect to a particular set of domain
parameters (referred to here as a "group"). Groups can be either
based on finite field cryptography (MODP groups) or elliptic curve
cryptography (ECP groups).
This protocol uses the same group as the IKE exchange in which it is
being used for authentication, with the exception of characteristic-
two elliptic curve groups (EC2N). Use of such groups is undefined
for this authentication method and an IKE exchange that negotiates
one of these groups MUST NOT use this method of authentication.
For each group the following operations are defined:
o "scalar operation"-- taking a scalar and an element in the group
producing another element-- Z = scalar-op(x, Y).
o "element operation"-- taking two elements in the group to produce
a third-- Z = element-op(X, Y).
o "inverse operation"-- take an element and returns another element
such that the element operation on the two produces the identity
element of the group-- Y = inverse(X).
Harkins Expires January 28, 2012 [Page 5]
Internet-Draft Secure PSK Authentication for IKE July 2011
4.1. Elliptic Curve Cryptography (ECP) Groups
The key exchange defined in this memo uses fundamental algorithms of
ECP groups as described in [RFC6090].
Domain parameters for ECP elliptic curves used for secure pre-shared
key-based authentication include:
o A prime, p, determining a prime field GF(p). The cryptographic
group will be a subgroup of the full elliptic curve group which
consists points on an elliptic curve-- elements from GF(p) that
satisfy the curve's equation-- together with the "point at
infinity" (denoted here as "O") that serves as the identity
element.
o Elements a and b from GF(p) that define the curve's equation. The
point (x,y) is on the elliptic curve if and only if y^2 = x^3 +
a*x + b.
o A prime, r, which is the order of G, and thus is also the size of
the cryptographic subgroup that is generated by G.
The scalar operation is multiplication of a point on the curve by
itself a number of times. The point Y is multiplied x-times to
produce another point Z:
Z = scalar-op(x, Y) = x*Y
The element operation is addition of two points on the curve. Points
X and Y are summed to produce another point Z:
Z = element-op(X, Y) = X + Y
The inverse function is defined such that the sum of an element and
its inverse is "0":
Q + inverse(Q) = "O"
Elliptic curve groups require a mapping function, q = F(Q), to
convert a group element to an integer. The mapping function used in
this memo returns the x-coordinate of the point it is passed.
scalar-op(x, Y) can be viewed as x iterations of element-op() by
defining:
Y = scalar-op(1, Y)
Harkins Expires January 28, 2012 [Page 6]
Internet-Draft Secure PSK Authentication for IKE July 2011
Y = scalar-op(x, Y) = element-op(Y, scalar-op(x-1, Y)), for x > 1
A definition of how to add two points on an elliptic curve (i.e.
element-op(X, Y)) can be found in [RFC6090].
Note: There is another ECP domain parameter, a co-factor, h, that is
defined by the requirement that the size of the full elliptic curve
group (including "O") be the product of h and r. ECP groups used for
secure pre-shared key-based authentication MUST have a co-factor of
one (1). At the time of publication of this memo, all ECP groups in
the IANA registry used by IKE had a co-factor of one (1).
4.2. Finite Field Cryptography (MODP) Groups
Domain parameters for MODP groups used for secure pre-shared key-
based authentication include:
o A prime, p, determining a prime field GF(p), the integers modulo
p.
o A prime, r, which is the multiplicative order of G, and thus also
the size of the cryptographic subgroup of GF(p)* that is generated
by G.
The scalar operation is exponentiation of a generator modulus a
prime. An element Y is taken to the x-th power modulo the prime
returning another element, Z:
Z = scalar-op(x, Y) = Y^x mod p
The element operation is modular multiplication. Two elementx, X and
Y, are multiplied modulo the prime returning another element, Z:
Z = element-op(X, Y) = (X * Y) mod p
The inverse function for a MODP group is defined such that the
product of an element and its inverse modulo the group prime equals
one (1). In other words,
(Q * inverse(Q)) mod p = 1
Unlike ECP groups, MODP groups do not require a mapping function to
convert an element into a scalar. But for the purposes of notation
in protocol definition, the function F, when used below, shall just
return the value that was passed to it-- i.e. F(i) = i.
Some MODP groups in the IANA registry for use by IKE (and the secure
pre-shared key authentication method) are based on safe primes and
Harkins Expires January 28, 2012 [Page 7]
Internet-Draft Secure PSK Authentication for IKE July 2011
the order is not included in the group's domain parameter set. In
this case only, the order, r, MUST be computed as the prime minus one
divided by two-- (p-1)/2. If an order is included in the group's
domain parameter set that value MUST be used in this exchange when an
order is called for. If a MODP group does not include an order in
its domain parameter set and is not based on a safe prime it MUST NOT
be used with this exchange.
5. Random Numbers
As with IKE itself, the security of the secure pre-shared key
authentication method relies upon each participant in the protocol
producing quality secret random numbers. A poor random number chosen
by either side in a single exchange can compromise the shared secret
from that exchange and open up the possibility of dictionary attack.
Producing quality random numbers without specialized hardware entails
using a cryptographic mixing function (like a strong hash function)
to distill entropy from multiple, uncorrelated sources of information
and events. A very good discussion of this can be found in
[RFC4086].
6. Using Passwords 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 hexidecimal string. Regardless though, this protocol
requires both the Initiator and Responder to have identical binary
representations of the shared credential. If the PSK is a character
string in a character set other than US-ASCII, ambiguities may arise
due to internationalization. In that case, the PSK MUST be pre-
processed to remove any ambiguity before it is used in this protocol.
When the PSK can be unambigouously represented as a binary string--
i.e. it is already a raw hexidecimal string, or it is restricted to
the US-ASCII character set-- it can be used directly without any pre-
processing.
This memo describes two ways to pre-process the shared, secret
credential depending on the type of credential:
o None/Raw Key: The input credential SHALL be treated as an ASCII
string or a binary/hexadecimal string with no pre-processing or
normalization performed. The output SHALL be the binary
representation of the input string.
Harkins Expires January 28, 2012 [Page 8]
Internet-Draft Secure PSK Authentication for IKE July 2011
o SASLprep/Character String: The input credential is processed
according to the rules of the [RFC4013] profile of [RFC3454].
The credential SHALL be considered a "stored string" per
[RFC3454] and unassigned code points are therefore prohibited.
The output SHALL be the binary representation of the processed
UTF-8 character string. Prohibited output and unassigned
codepoints encountered in SASLprep pre-processing SHALL cause a
failure of pre-processing and the output SHALL NOT be used with
Secure Password Authentication.
During negotiation of Secure PSK Authentication (see Section 8.1),
the Initiator indicates the type of credential it will be using--
either a raw key (no pre-processing required) or a character-based
key (SASLprep pre-processing required)-- and the Responder
acknowledges it will do the same.
For the purposes of interoperability, pre-processing of "None"-- i.e.
using raw keys or the ASCII character set-- MUST be supported and
SASLprep SHOULD be supported.
7. Assumptions
The security of the protocol relies on certain assumptions. They
are:
1. The pseudo-random function, prf, defined in IKE (either [RFC2409]
or [RFC5996]) acts as an "extractor" (see [RFC5869]) by
concentrating the entropy from a secret input into a short,
fixed, string. The output of prf is indistinguishable from a
random source.
2. The discrete logarithm problem for the chosen finite cyclic group
is hard. That is, given G, p and Y = G^x mod p it is
computationally infeasible to determine x. Similarly for an
elliptic curve group given the curve definition, a generator G,
and Y = x * G it is computationally infeasible to determine x.
3. The pre-shared key is drawn from a finite pool of potential keys.
Each possible key in the pool has equal probability of being the
shared key. All potential attackers have access to this pool of
keys.
8. Secure PSK Authentication Message Exchange
The key exchange described in this memo is based on the "Dragonfly"
key exchange which has also been proposed in 802.11 wireless networks
Harkins Expires January 28, 2012 [Page 9]
Internet-Draft Secure PSK Authentication for IKE July 2011
(see [SAE]) and as an EAP method (see [RFC5931]). "Dragonfly" is
patent-free and royalty-free. It has been defined here for use in
both IKEv1 ([RFC2409]) and IKEv2 ([RFC5996]). It makes use of the
same pseudo-random function (prf) and the same Diffie-Hellman group
that are negotiated for use in the IKE exchange that "dragonfly" is
authenticating.
A pseudo-random function which uses a block cipher is NOT RECOMMENDED
for use with Secure PSK Authentication due to its poor job operating
as an "extractor" (see Section 7). Pseudo-random functions based on
hash functions using the HMAC construct from [RFC2104] SHOULD be
used.
To perform secure pre-shared key authentication each side must
generate a shared and secret element in the chosen group based on the
pre-shared key. This element, called the Secret Key Element, or SKE,
is then used in 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 (either the HASH or AUTH payload depending on whether IKEv1
or IKEv2, respectively, is being used) proves that the pre-shared key
is known and completes the zero-knowledge proof.
8.1. Negotiation of Secure PSK Authentication
The technique used for negotiating whether, and how, to use Secure
PSK Authentication depends on whether IKEv1 or IKEv2 is being used.
Secure PSK Authentication in IKEv2 MUST be implemented to claim
conformance to this memo. Secure PSK Authentication in IKEv1 is NOT
RECOMMENDED.
8.1.1. IKEv1 Negotiation
With IKEv1, the Initiator indicates its desire to use Secure PSK
Authentication, and the pre-processing it will apply to the shared
credential (see Section 6), by setting the Authentication Method in
the SA payload to either TBD1 or TBD2 indicating SPSK with a raw or
ASCII key (no pre-processing) or SPSK with a character string
(SASLprep pre-processing), respectively.
The Responder indicates its desire to use Secure PSK Authentication
and its agreement on the pre-processing applied to the shared
credential by echoing back an SA payload with the same Authentication
Method.
Harkins Expires January 28, 2012 [Page 10]
Internet-Draft Secure PSK Authentication for IKE July 2011
8.1.2. IKEv2 Negotiation
With IKEv2, the Initiator indicates its desire to use Secure PSK
Authentication, and the type of pre-processing to perform on the PSK
(see Section 6), by adding a Notify payload of type
SECURE_PASSWORD_METHODS (see
[I-D.kivinen-ipsecme-secure-password-framework]) to the first message
of the IKE_SA_INIT exchange and by putting TBD3 or TBD4 in the
notification data field of the Notify payload, indicating SPSK with a
raw or ASCII key (no preprocessing) or SPSK with a character string
(SASLprep pre-processing), respectively.
The Responder indicates its desire to perform Secure PSK
Authentication, and agrees on the type of PSK pre-processing, by
adding a Notify payload of type SECURE_PASSWORD_METHODS to its
response in the IKE_SA_INIT exchange and by echoing back the pre-
processing technique in the notification data field of the Notify
payload. If the Responder does not agree with the pre-processing
technique indicated by the Initiator it MUST abort the exchange.
8.2. Fixing the Secret Element, SKE
The method of fixing SKE depends on the type of group, either MODP or
ECP. The function "prf+" from [RFC5996] is used as a key derivation
function. This is true even if performing secure pre-shared key
authentication with IKEv1.
Fixing SKE involves an iterative hunting-and-pecking technique using
the prime from the negotiated group's domain parameter set and an
ECP- or MODP-specific operation depending on the negotiated group.
This technique requires the pre-shared key to be a binary string,
therefore any pre-processing transformation (see Section 6) MUST be
performed on the pre-shared key prior to fixing SKE.
First, an 8-bit counter is set to the value one (1). Then, the
pseudo-random function is used to generate a secret seed using the
counter, the pre-shared key, and two nonces (without the fixed
headers) exchanged by the Initiator and the Responder (see
Section 8.6 and Section 8.7):
ske-seed = prf(Ni | Nr, psk | counter)
Then, the ske-seed is expanded using prf+ to create an ske-value:
ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking")
where len(ske-value) is the same as len(p), the length of the prime
from the domain parameter set of the negotiated group.
Harkins Expires January 28, 2012 [Page 11]
Internet-Draft Secure PSK Authentication for IKE July 2011
If the ske-seed is greater than or equal to the prime, p, the counter
is incremented and a new ske-seed is generated and the hunting-and-
pecking continues. If ske-seed is less than the prime, p, it is
passed to the group-specific operation to select the SKE or fail. If
the group-specific operation fails, the counter is incremented, a new
ske-seed is generated and the hunting-and-pecking continues.
Note: 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.1. ECP Operation to Select SKE
The group-specific operation for ECP groups uses ske-value, ske-seed
and the equation of the curve to produce SKE. First ske-value is
used directly as the x-coordinate, x, with the equation of the
elliptic curve, with parameters a and b from the domain parameter set
of the curve, to solve for a y-coordinate, y.
If there is no solution to the equation the operation fails (and the
hunting-and-pecking continues). If a solution is found then an
ambiguity exists as there are technically two solutions to the
equation, and ske-seed is used to unambiguously select one of them.
If the low-order bit of ske-seed is equal to the low-order bit of y
then a candidate SKE is defined as the point (x,y); if the low-order
bit of ske-seed differs from the low-order bit of y then a candidate
SKE is defined as the point (x, p-y) where p is the prime from the
negotiated group's domain parameter set. The candidate SKE becomes
the SKE and the ECP-specific operation completes successfully.
Algorithmically, the process looks like this:
Harkins Expires January 28, 2012 [Page 12]
Internet-Draft Secure PSK Authentication for IKE July 2011
found = 0
counter = 1
do {
ske-seed = prf(Ni | Nr, psk | counter)
ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking")
if (ske-value < p)
then
x = ske-value
if ( (y = sqrt(x^3 + ax + b)) != FAIL)
then
if (LSB(y) == LSB(ske-seed))
then
SKE = (x,y)
else
SKE = (x, p-y)
fi
found = 1
fi
fi
counter = counter + 1
} while (found == 0)
Figure 1: Fixing SKE for ECP Groups
8.2.2. MODP Operation to Select SKE
The group-specific operation for MODP groups takes ske-value, and the
prime, p, and order, r, from the group's domain parameter set to
directly produce a candidate SKE by exponentiating the ske-value to
the value ((p-1)/r) modulo the prime. If the candidate SKE is
greater than one (1) the candidate SKE becomes the SKE and the MODP-
specific operation completes successfully. Otherwise, the MODP-
specific operation fails (and the hunting-and-pecking continues).
Algorithmically, the process looks like this:
Harkins Expires January 28, 2012 [Page 13]
Internet-Draft Secure PSK Authentication for IKE July 2011
found = 0
counter = 1
do {
ske-seed = prf(Ni | Nr, psk | counter)
ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking")
if (ske-value < p)
then
SKE = ske-value ^ ((p-1)/r) mod p
if (SKE > 1)
then
found = 1
fi
fi
counter = counter + 1
} while (found == 0)
Figure 2: Fixing SKE for MODP Groups
8.3. Encoding and Decoding of Group Elements and Scalars
The payloads used in the secure pre-shared key authentication method
contain elements from the negotiated group and scalar values. To
ensure interoperability, scalars and field elements MUST be
represented in payloads in accordance with the requirements in this
section.
8.3.1. Encoding and Decoding of Scalars
Scalars MUST be represented (in binary form) as unsigned integers
that are strictly less than r, the order of the generator of the
agreed-upon cryptographic group. The binary representation of each
scalar MUST have a bit length equal to the bit length of the binary
representation of r. This requirement is enforced, if necessary, by
prepending the binary representation of the integer with zeros until
the required length is achieved.
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
Harkins Expires January 28, 2012 [Page 14]
Internet-Draft Secure PSK Authentication for IKE July 2011
set. The binary representation of each component MUST have a bit
length equal to the bit length of the binary representation of p.
This length requirement is enforced, if necessary, by prepending the
binary representation of the integer with zeros until the required
length is achieved.
The unsigned integers that represent the coordinates of the point are
converted into octet-strings and back again using the technique
described in [RFC6090].
Since the field element is represented in a payload by the
x-coordinate followed by the y-coordinate it follows, then, that the
length of the element in the payload MUST be twice the bit length of
p.
8.3.3. Encoding and Decoding of MODP Elements
Elements in MODP groups MUST be represented (in binary form) as
unsigned integers that are strictly less than the prime, p, from the
group's domain parameter set. The binary representation of each
group element MUST have a bit length equal to the bit length of the
binary representation of p. This length requirement is enforced, if
necessary, by prepending the binary representation of the interger
with zeros until the required length is achieved.
The unsigned integer that represents a MODP element is converted into
an octet-string and back using the technique described in [RFC6090].
8.4. Message Generation and Processing
8.4.1. Generation of a Commit
Before a Commit can be generated, the SKE must be fixed using the
process described in Section 8.2.
A Commit has two components, a scalar and an Element. To generate a
Commit, two random numbers, a "private" value and a "mask" value, are
generated (see Section 5). Their sum modulo the order of the group,
r, becomes the scalar component:
scalar = (private + mask) mod r
If the scalar is not greater than one (1), the private and mask
values MUST be thrown away and new values randomly generated. If the
scalar is greater than one (1), the inverse of the scalar operation
with the mask and SKE becomes the Element component.
Harkins Expires January 28, 2012 [Page 15]
Internet-Draft Secure PSK Authentication for IKE July 2011
Element = inverse(scalar-op(mask, SKE))
The Commit payload consists of the scalar followed by the Element and
the scalar and Element are encoded in the Commit payload according to
Section 8.3.
8.4.2. Processing of a Commit
Upon receipt of a peer's Commit the scalar and element MUST be
validated. The processing of an element depends on the type, either
an ECP element or a MODP element.
8.4.2.1. Validation of an ECP Element
Validating a received ECP Element involves: 1) checking whether the
two coordinates, x and y, are both greater than zero (0) and less
than the prime defining the underlying field; and 2) checking whether
the x- and y-coordinates satisfy the equation of the curve (that is,
that they produce a valid point on the curve that is not "0"). If
either of these conditions are not met the received Element is
invalid, otherwise the received Element is valid.
8.4.2.2. Validation of a MODP Element
A received MODP Element is valid if: 1) it is between one (1) and the
prime, p, exclusive; and 2) if modular exponentiation of the Element
by the group order, r, equals one (1). If either of these conditions
are not true the received Element is invalid.
8.4.2.3. Commit Processing Steps
Commit validation is accomplished by the following steps:
1. The length of the Commit payload is checked against its
anticipated length (the anticipated length of the scalar plus the
anticipated length of the element, for the negotiated group). If
it is incorrect, the Commit is invalidated, otherwise processing
continues.
2. The peer's scalar is extracted from the Commit payload according
to Section 8.3.1 and checked to ensure it is between one (1) and
r, the order of the negotiated group, exclusive. If it is not,
the Commit is invalidated, otherwise processing continues.
3. The peer's Element is extracted from the Commit payload according
to Section 8.3.2 and checked in a manner that depends on the type
of group negotiated. If the group is ECP the element is
validated according to Section 8.4.2.1, if the group is MODP the
Harkins Expires January 28, 2012 [Page 16]
Internet-Draft Secure PSK Authentication for IKE July 2011
element is validated according to Section 8.4.2.2. If the
Element is not valid then the Commit is invalidated, otherwise
the Commit is validated.
4. The Initiator of the IKE exchange has an added requirement to
verify that the received element and scalar from the Commit
payload differ from the element and scalar sent to the Responder.
If they are identical, it signifies a reflection attack and the
Commit is invalidated.
If the Commit is invalidated the payload MUST be discarded and the
IKE exchange aborted.
8.4.3. Authentication of the Exchange
After a Commit has been generated and a peer's Commit has been
processed a shared secret used to authenticate the peer is derived.
Using SKE, the "private" value generated as part of Commit
generation, and the peer's scalar and Element from its Commit, named
here peer-scalar and peer-element, respectively, a preliminary shared
secret, skey, is generated as:
skey = F(scalar-op(private,
element-op(peer-element,
scalar-op(peer-scalar, SKE))))
For the purposes of subsequent computation, the bit length of skey
SHALL be equal to the bit length of the prime, p, used in either a
MODP or ECP group. This bit length SHALL be enforced, if necessary,
by prepending zeros to the value until the required length is
achieved.
A shared secret, ss, is then computed from skey and the nonces
exchanged by the Initiator (Ni) and Responder (Nr) (without the fixed
headers) using prf():
ss = prf(Ni | Nr, skey | "Secure PSK Authentication in IKE")
The shared secret, ss, is used in an authentication payload (either
HASH or AUTH payload depending on whether IKEv1 or IKEv2,
respectively, is being used) to prove possession of the shared
secret, and therefore knowledge of the pre-shared key.
8.5. Payload Format
Harkins Expires January 28, 2012 [Page 17]
Internet-Draft Secure PSK Authentication for IKE July 2011
8.5.1. Commit Payload
[I-D.kivinen-ipsecme-secure-password-framework]) defines a Generic
Secure Password Method (GSPM) payload which 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 SPSK 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.
8.5.2. Notify Payload
[I-D.kivinen-ipsecme-secure-password-framework] defines a new type of
Notify Payload to indicate support for Secure Password Methods (SPM)
in the IKE_SA_INIT exchange. The SPM Notify payload is defined as
follows:
Harkins Expires January 28, 2012 [Page 18]
Internet-Draft Secure PSK Authentication for IKE July 2011
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Secure PSK Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the SPM Notify payload the Protocol ID and SPI Size SHALL be set
to zero and, therefore, the SPI field SHALL be empty. The Notify
Message Type SHALL be SECURE_PASSWORD_METHODS from [IKEV2-IANA]. The
body of the SPM Notify payload is defined to be a list of 16-bit
numbers indicating the particular Secure Password Method to use. For
SPSK those values SHALL be either TBD3 or TBD4, indicating support
for SPSK with a raw key requiring no processing or SPSK with a
character string requiring SASLprep processing, respectively (see
Section 6).
8.6. IKEv1 Messaging
Secure PSK Authentication can be used in either Main Mode (see
Figure 3) or Aggressive Mode (see Figure 4) with IKEv1 and SHALL be
indicated by negotiation of an Authentication Method of either TBD1
or TBD2 from [IKEV1-IANA], in the SA payload. When using IKEv1 the
"C" (critical) bit in the Commit payload (Section 8.5.1) MUST be
clear (i.e. a value of zero).
Initiator Responder
----------- -----------
HDR, SAi -->
<-- HDR, SAr
HDR, KEi, Ni -->
<-- HDR, KEr, Nr
HDR*, IDii, COMi -->
<-- HDR*, IDir, COMr
HDR*, HASH_I -->
<-- HDR*, HASH_R
where COMi is the Commit payload sent by the Initiator and COMr is
the Commit payload sent by the Responder.
Harkins Expires January 28, 2012 [Page 19]
Internet-Draft Secure PSK Authentication for IKE July 2011
Figure 3: Secure PSK in Main Mode
Initiator Responder
----------- -----------
HDR, SAi, KEi,
Ni, IDii, COMi -->
<-- HDR, SAr, KEr, Nr,
IDir, COMr, HASH_R
HDR, HASH_I -->
where COMi is the Commit payload sent by the Initiator and COMr is
the Commit payload sent by the Responder.
Figure 4: Secure PSK in Aggressive Mode
For Secure PSK Authentication with IKEv1 the SKEYID value is computed
as follows:
SKEYID = prf(Ni_b | Nr_b, g^xy)
Note that in Main Mode, SKEYID_a and SKEYID_e are used to protect the
messages containing the identities and Commit payloads. HASH_I and
HASH_R are computed as follows:
HASH_I = prf(SKEYID, ss | g^xi | g^xr | CKY-I | CKY-R |
SA_ib | IDii_b | COMi_b | COMr_b)
HASH_R = prf(SKEYID, ss | g^xr | g^xi | CKY-R | CKY-I |
SA_ib | IDir_b | COMr_b | COMi_b)
Where "ss" is the shared secret derived in Section 8.4.3, and COMi_b
and COMr_b are the scalar and Element from the Commit payloads (i.e.
without the header) sent by the Initiator and Responder,
respectively.
8.7. IKEv2 Messaging
SPSK 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 5).
Harkins Expires January 28, 2012 [Page 20]
Internet-Draft Secure PSK Authentication for IKE July 2011
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 (with SPSK-specific pre-processing) used to negotiate the
use of SPSK authentication (see Section 8.1.2), COMi and AUTHi are
the Commit payload and AUTH payload, respectively, sent by the
Initiator and COMr and AUTHr are the Commit payload and AUTH payload,
respectively, sent by the Responder.
Figure 5: Secure PSK in IKEv2
The AUTH payloads when doing SPSK authentication SHALL be computed as
AUTHi = prf(ss, <InitiatorSignedOctets> | COMi | COMr)
AUTHr = prf(ss, <ResponderSignedOctets> | COMr | COMi)
Where "ss" is the shared secret derived in Section 8.4.3, COMi and
COMr are the entire Commit payloads (including the fixed headers)
sent by the Initiator and Responder, respectively, and
<InitiatorSignedOctets> and <ResponderSignedOctets> are defined in
[RFC5996]. The Authentication Method indicated in both AUTH payloads
SHALL be "Secure Password Authentication Method" from [IKEV2-IANA].
9. IANA Considerations
IANA SHALL assign a value for "SPSK Authentication with a raw key",
replacing TBD1 above, from the IPSEC Authentication Method registry
in [IKEV1-IANA] with the method name of "SPSK Authentication Method
with a raw key."
Harkins Expires January 28, 2012 [Page 21]
Internet-Draft Secure PSK Authentication for IKE July 2011
IANA SHALL assign a value for "SPSK Authentication with a character
string", replacing TBD2 above, from the IPSEC Authentication Method
registry in [IKEV1-IANA] with the method name of "SPSK Authentication
Method with a character string."
IANA SHALL assign a value for "SPSK Authentication with a raw key"
replacing TBD3 from the IKEv2 Secure Password Authentication Methods
registry in [IKEV2-IANA] with the method name of "SPSK Authentication
with a raw key".
IANA SHALL assign a value for "SPSK Authentication with a character
string" replacing TBD4 from the IKEv2 Secure Password Authentication
Methods registry in [IKEV2-IANA] with the method name of "SPSK
Authentication with a character string".
The RFC Editor SHALL remove these IANA Considerations after values
have been obtained from IANA and the TBD placeholders replaced by the
actual values.
10. Security Considerations
Both the Initiator and Responder obtain a shared secret, "ss" (see
Section 8.4.3) based on a secret group element and their own private
values contributed to the exchange. If they do not share the same
pre-shared key they will be unable to derive the same secret group
element and if they do not share the same secret group element they
will be unable to derive the same shared secret.
Resistance to dictionary attack means that the attacker must launch
an active attack to make a single guess at the pre-shared key. If
the size of the pool from which the key was extracted was D, and each
key in the pool has an equal probability of being chosen, then the
probability of success after a single guess is 1/D. After X guesses,
and removal of failed guesses from the pool of possible keys, the
probability becomes 1/(D-X). As X grows so does the probability of
success. Therefore it is possible for an attacker to determine the
pre-shared key through repeated brute-force, active, guessing
attacks. This authentication method does not presume to be secure
against this and implementations SHOULD ensure the size of D is
sufficiently large to prevent this attack. Implementations SHOULD
also take countermeasures, for instance refusing authentication
attempts for a certain amount of time, after the number of failed
authentication attempts reaches a certain threshold. No such
threshold or amount of time is recommended in this memo.
An active attacker can impersonate the Responder of the exchange and
send a forged Commit payload after receiving the Initiator's Commit.
Harkins Expires January 28, 2012 [Page 22]
Internet-Draft Secure PSK Authentication for IKE July 2011
The attacker then waits until it receives the authentication payload
from the Responder. Now the attacker can attempt to run through all
possible values of the pre-shared key, computing SKE (see
Section 8.2), computing "ss" (see Section 8.4.3), and attempting to
recreate the Confirm payload from the Responder.
But the attacker committed to a single guess of the pre-shared key
with her forged Commit. That value was used by the Responder in his
computation of "ss" which was used in the authentication payload.
Any guess of the pre-shared key which differs from the one used in
the forged Commit would result in each side using a different secret
element in the computation of "ss" and therefore the authentication
payload could not be verified as correct, even if a subsequent guess,
while running through all possible values, was correct. The attacker
gets one guess, and one guess only, per active attack.
An attacker, acting as either the Initiator or Responder, can take
the Element from the Commit message received from the other party,
reconstruct the random "mask" value used in its construction and then
recover the other party's "private" value from the Scalar in the
Commit message. But this requires the attacker to solve the discrete
logarithm problem which we assumed was intractable above (Section 7).
Instead of attempting to guess at pre-shared keys an attacker can
attempt to determine SKE and then launch an attack. But SKE is
determined by the output of the pseudo-random function, prf, which is
assumed to be indistinguishable from a random source (Section 7).
Therefore, each element of the finite cyclic group will have an equal
probability of being the SKE. The probability of guessing SKE will
be 1/r, where r is the order of the group. This is the same
probability of guessing the solution to the discrete logarithm which
is assumed to be intractable (Section 7). The attacker would have a
better chance of success at guessing the input to prf, i.e. the pre-
shared key, since the order of the group will be many orders of
magnitude greater than the size of the pool of pre-shared keys.
The implications of resistance to dictionary attack are significant.
An implementation can provision a pre-shared key in a practical and
realistic manner-- i.e. it MAY be a character string and it MAY be
relatively short-- and still maintain security. The nature of the
pre-share key determines the size of the pool, D, and countermeasures
can prevent an attacker from determining the secret in the only
possible way: repeated, active, guessing attacks. For example, a
simple four character string using lower-case English characters, and
assuming random selection of those characters, will result in D of
over four hundred thousand. An attacker would need to mount over one
hundred thousand active, guessing attacks (which will easily be
detected) before gaining any significant advantage in determining the
Harkins Expires January 28, 2012 [Page 23]
Internet-Draft Secure PSK Authentication for IKE July 2011
pre-shared key.
For a more detailed discussion of the security of the key exchange
underlying this authentication method see [SAE] and [RFC5931].
11. Acknowledgements
The author would like to thank Scott Fluhrer and Hideyuki Suzuki for
their insight in discovering flaws in earlier versions of the key
exchange that underlies this authentication method and for their
helpful suggestions in improving it. Thanks to Lily Chen for useful
advice on the hunting-and-pecking technique to "hash into" an element
in a group and to Jin-Meng Ho for a discussion on countering a small
sub-group attack. Rich Davis suggested several checks on received
messages that greatly increase the security of the underlying key
exchange. Hugo Krawczyk suggested using the prf as an extractor.
12. References
12.1. Normative References
[IKEV1-IANA]
"Internet Assigned Numbers Authority, Internet Key
Exchange (IKE) Attributes",
<http://www.iana.org/assignments/ipsec-registry>.
[IKEV2-IANA]
"Internet Assigned Numbers Authority, IKEv2 Parameters",
<http://www.iana.org/assignments/ikev2-parameters>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[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.
Harkins Expires January 28, 2012 [Page 24]
Internet-Draft Secure PSK Authentication for IKE July 2011
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011.
12.2. Informative References
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange:
Password-Based Protocols Secure Against Dictionary
Attack", Proceedings of the IEEE Symposium on Security and
Privacy, Oakland, 1992.
[BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure
Password Authenticated Key Exchange Using Diffie-Hellman",
Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag,
2000.
[BPR00] Bellare, M., Pointcheval, D., and P. Rogaway,
"Authenticated Key Exchange Secure Against Dictionary
Attacks", Advances in Cryptology -- Eurocrypt '00, Lecture
Notes in Computer Science Springer-Verlag, 2000.
[I-D.kivinen-ipsecme-secure-password-framework]
Kivinen, T., "Secure Password Framework for IKEv2",
draft-kivinen-ipsecme-secure-password-framework (a work in
progress), May 2011.
[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.
[XAUTH] Pereira, R. and S. Beaulieu, "Extended Authentication
Harkins Expires January 28, 2012 [Page 25]
Internet-Draft Secure PSK Authentication for IKE July 2011
within ISAKMP/Oakley (XAUTH)",
draft-ietf-ipsec-isakmp-xauth-06.txt (a work in progress),
December 1999.
Author's Address
Dan Harkins
Aruba Networks
1322 Crossman Avenue
Sunnyvale, CA 94089-1113
United States of America
Email: dharkins@arubanetworks.com
Harkins Expires January 28, 2012 [Page 26]
