Security Area D. Harkins
Internet-Draft G. Zorn
Intended status: Standards Track Aruba Networks
Expires: August 8, 2008 February 5, 2008
EAP Authentication Using Only A Password
draft-harkins-emu-eap-pwd-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 8, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This memo describes an Extensible Authentication Protocol (EAP)
method, EAP-pwd, which uses a shared password for authentication.
The password may be a low-entropy one and may be drawn from some set
of possible passwords, like a dictionary, which is available to an
attacker.
Harkins & Zorn Expires August 8, 2008 [Page 1]
Internet-Draft EAP Password February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Keyword Definitions . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1. Resistance to Passive Attack . . . . . . . . . . . . . 4
1.3.2. Resistance to Active Attack . . . . . . . . . . . . . 5
1.3.3. Resistance to Dictionary Attack . . . . . . . . . . . 5
1.3.4. Forward Secrecy . . . . . . . . . . . . . . . . . . . 5
2. Specification of EAP-pwd . . . . . . . . . . . . . . . . . . . 5
2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Prime Modulus Groups . . . . . . . . . . . . . . . . . 6
2.1.2. Elliptic Curve Groups . . . . . . . . . . . . . . . . 7
2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Instantiating the Random Function . . . . . . . . . . . . 8
2.4. Key Derivation Function . . . . . . . . . . . . . . . . . 8
2.5. Random Numbers . . . . . . . . . . . . . . . . . . . . . . 9
2.6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.2. Message Flows . . . . . . . . . . . . . . . . . . . . 9
2.6.3. Message Construction . . . . . . . . . . . . . . . . . 11
2.6.3.1. Elliptic Curve Groups . . . . . . . . . . . . . . 11
2.6.3.2. Prime Modulus Groups . . . . . . . . . . . . . . . 12
2.6.4. Message Processing . . . . . . . . . . . . . . . . . . 14
2.6.4.1. EAP-pwd-ID Exchange . . . . . . . . . . . . . . . 14
2.6.4.2. EAP-pwd-Commit Exchange . . . . . . . . . . . . . 15
2.6.4.3. EAP-pwd-Confirm Exchange . . . . . . . . . . . . . 16
2.6.5. Management of EAP-pwd Keys . . . . . . . . . . . . . . 16
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. EAP-pwd Header . . . . . . . . . . . . . . . . . . . . . . 17
3.2. EAP-pwd Payloads . . . . . . . . . . . . . . . . . . . . . 18
3.2.1. EAP-pwd-ID . . . . . . . . . . . . . . . . . . . . . . 19
3.2.2. EAP-pwd-Commit . . . . . . . . . . . . . . . . . . . . 20
3.2.3. EAP-pwd-Confirm . . . . . . . . . . . . . . . . . . . 20
3.3. Representation of Field Elements . . . . . . . . . . . . . 21
3.3.1. Prime Modulus Groups . . . . . . . . . . . . . . . . . 21
3.3.2. Elliptic Curve Groups . . . . . . . . . . . . . . . . 21
4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6.1. Resistance to Passive Attack . . . . . . . . . . . . . . . 24
6.2. Resistance to Active Attack . . . . . . . . . . . . . . . 25
6.3. Resistance to Dictionary Attack . . . . . . . . . . . . . 25
6.4. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 26
6.5. Random Functions . . . . . . . . . . . . . . . . . . . . . 26
7. Security Claims . . . . . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
Harkins & Zorn Expires August 8, 2008 [Page 2]
Internet-Draft EAP Password February 2008
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Harkins & Zorn Expires August 8, 2008 [Page 3]
Internet-Draft EAP Password February 2008
1. Introduction
1.1. Background
The predominant access method for the Internet today is of a human
using a username and password to authenticate to a computer enforcing
access control. Proof of knowledge of the password authenticates the
human and computer.
Typically these passwords are not stored on a user's computer for
security reasons and must be entered each time the human desires
network access. Therefore the passwords must be ones that can be
repeatedly entered by a human with a low probability of error. They
will not be ones with high-entropy and it is assumed an adversary
with access to a dictionary will have the ability to guess a user's
password. It is therefore desirable to have a robust authentication
that is secure even when used with a weak password in the presence of
a strong adversary.
EAP-pwd is an EAP method that addresses the problem of password-based
authenticated key exchange-- using a possibly weak password for
authentication to derive an authenticated and cryptographically
strong shared secret. This problem was first described by Bellovin
and Merritt in [BM92] and [BM93]. There have been a number of
subsequent suggestions ([JAB96], [LUC97], [BMP00], and others) for
password-based authenticated key exchanges.
1.2. 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].
1.3. Requirements
A protocol that solves the problem of password-authenticated key
exchange MUST provide the following:
1.3.1. Resistance to Passive Attack
A passive, or benign, attacker is one that merely relays messages
back and forth between the peer and server, faithfully, and without
modification. The contents of the messages are available for
inspection, but that is all. To achieve resistance to passive
attack, such an attacker must not be able to obtain any information
about the password or anything about the resulting shared secret from
watching repeated runs of the protocol. Even if a passive attacker
is able to learn the password, she will not be able to determine any
Harkins & Zorn Expires August 8, 2008 [Page 4]
Internet-Draft EAP Password February 2008
information about the resulting secret shared by the peer and server.
1.3.2. Resistance to Active Attack
An active attacker is able to modify, add, delete, and replay
messages sent between protcol participants. For this protocol to be
resistant to active attack, the attacker must not be able to obtain
any information about the password or about the secret shared by
using any of its capabilities. In addition, the attacker must not be
able to fool a protocol participant into thinking that the protocol
completed successfully.
It is always possible for an active attacker to deny delivery of a
message critical in completing the exchange. This is no different
than dropping all messages and is not an attack against the protocol.
1.3.3. Resistance to Dictionary Attack
For this protocol to be resistant to dictionary attack any advantage
an adversary can gain must be directly related to the number of
interactions she makes with an honest protocol participant and not
through computation. The adversary will not be able to obtain any
information about the password except whether a single guess for a
single protocol run is correct or incorrect.
1.3.4. Forward Secrecy
Compromise of the password must not provide any information about the
secrets generated by earlier runs of the protocol.
2. Specification of EAP-pwd
2.1. Notation
The following notation is used in this memo:
peer-ID
The peer's identity, the peer NAI RFC 4282 [RFC4282].
server-ID
A string that identifies the server to the peer.
password
The password shared between the peer and server.
Harkins & Zorn Expires August 8, 2008 [Page 5]
Internet-Draft EAP Password February 2008
y = H(x)
The binary string x is given to a function H which produces an
output y.
a | b
denotes concatenation of string a with string b.
len(x)
indicates the length in bits of the string x.
chop(x, y)
is reduction of string x, being at least y bits in length, to y
bits.
CipherSuite
an encoding of a finite cyclic group to use with EAP-pwd, the
definition of function H, and a PRF, in that order.
MSK
The Master Session Key exported by EAP-pwd. This is a high-
entropy secret 512 bits in length.
EMSK
The Extended Master Session Key exported by EAP-pwd. This is a
high-entropy secret 512 bits in length.
This protocol uses a finite cyclic group in which the discrete
logarithm problem is known to be hard. Groups can be either based on
a prime modulus or on an elliptic curve.
2.1.1. Prime Modulus Groups
Groups formed by a prime modulus have a generator, g, a prime modulus
p, optionally an order r. The group operation is exponentiation
modulus the prime:
y = g^x mod p
the generator taken to the x-th power modulus the prime returns
an element in the group.
If the order is not part of the definition of the prime modulus group
the value for r used in this memo MUST be computed as the prime minus
one (p-1).
Harkins & Zorn Expires August 8, 2008 [Page 6]
Internet-Draft EAP Password February 2008
2.1.2. Elliptic Curve Groups
Groups formed by an elliptic curve have a base point G, a prime p,
and an order r. The group operation is multiplication of a point on
the curve by itself a numer of times:
Y = x*G
the base point G is multiplied x-times to produce another point
on the curve, Y.
The convention for this memo to represent a point on a curve is to
use an upper-case letter while a scalar is indicated with a lower-
case letter.
Elliptic curve groups require a bijective function, q = F(Q), to
convert a group element to an integer. The bijective function used
in this memo returns the x-coordinate of the point it is passed.
2.2. Assumptions
In order to see how the protocol addresses the requirements above
(see Section 1.3) it is necessary to state some assumptions under
which the protocol can be evaluated. They are:
1. Function H maps a binary string of indeterminate length onto a
fixed binary string that is x bits in length. That is H: {0,1}^*
--> {0,1}^x.
2. Function H is a "random oracle" (see [RANDOR]). Given knowledge
of the input to H an adversary is unable to distinguish the
output of H from a random data source.
3. Function H is a one-way function. Given the output of H it is
computationally infeasible for an adversary to determine the
input.
4. For any given input to function H each of the 2^x possible
outputs are equally probable.
5. 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 G and Y = x * G it is computationally
infeasible to determine x.
6. There exists a pool of passwords from which the password shared
by the peer and server is drawn. This pool can consist of words
Harkins & Zorn Expires August 8, 2008 [Page 7]
Internet-Draft EAP Password February 2008
from a dictionary, for example. Each password in this pool has
an equal probability of being the shared password. All potential
attackers have access to this pool of passwords.
2.3. Instantiating the Random Function
The protocol described in this memo uses a random function, H. As
noted in Section 2.2 this is a "random oracle" as defined in
[RANDOR]. At first glace one may view this as a hash function. As
noted in [RANDOR], though, hash functions are too structured to be
used directly as a random oracle. But they can be used to
instantiate the random oracle.
The random function, H, in this memo is instantiated by truncating
the output of SHA-512 [SHA2] to 256 bits.
2.4. Key Derivation Function
The keys output by this protocol, MSK and EMSK, are 512 bits in
length each. The shared secret that results from the successful
termination of this protocol is only 256 bits. Therefore it is
necessary to stretch the shared secret using a key derivation
function (KDF).
The KDF used in this protocol has a counter-mode with feed-back
construction using a generic pseudo-random function (PRF). The
specific value of the PRF is specified along with the random function
and finite cyclic group when the server sends the first EAP-pwd
packet to the peer.
The KDF takes a key to stretch, a label to bind into the key, and an
indication of the desired length of the output. Algorithmically it
is:
KDF(key, label, length) {
i = 1
K = PRF(key, label, i)
while (len(K) < length)
do
i = i + 1
K = K | PRF(key, K | label | i)
done
return chop(K, length)
}
where "i" is 8-bits in length
Figure 1
Harkins & Zorn Expires August 8, 2008 [Page 8]
Internet-Draft EAP Password February 2008
2.5. Random Numbers
The security of EAP-pwd relies upon each side, the peer and server,
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.
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].
2.6. Protocol
2.6.1. Overview
EAP is a two-party protocol spoken between an EAP peer and an
authenticator. For scaling purposes the functionality of the
authenticator that speaks EAP is frequently broken out into a stand-
alone EAP server. In this case the EAP peer communicates with an EAP
server through the authenticator with the authenticator merely being
a passthrough.
An EAP method defines the specific authentication protocol being used
by EAP. This memo defines a particular method and therefore defines
the messages sent between the EAP server (or the "EAP server"
functionality in an authenticator if it is not broken out) and the
EAP peer for the purpose of authentication and key derivation.
2.6.2. Message Flows
EAP-pwd defines an identity exchange for the peer and server to agree
upon each other's identity. Once they know each other's identity,
they can construct a shared secret value based on the shared password
and their identities. This secret value, the password scalar (pws),
is used to obtain an element in the finite cyclic group called the
password element (pwe/PWE).
For a finite cyclic group based on an elliptic curve with a base
point G:
pws = H(peer-ID | server-ID | password)
PWE = pws * G
For a finite cyclic group based on exponentiation of a generator, g,
modulus a large prime p:
Harkins & Zorn Expires August 8, 2008 [Page 9]
Internet-Draft EAP Password February 2008
pws = H(peer-ID | server-ID | password)
pwe = g^pws mod p
An authentication exchange is then performed where each side commits
to the exchange and then each side verifies the other's committment.
The entire EAP-pwd exchange is shown in Figure 2.
+--------+ +--------+
| | EAP-pwd-ID/Request | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-pwd-ID/Response | |
| |------------------------------------>| |
| | | |
| | EAP-pwd-Commit/Request | |
| |<------------------------------------| |
| | | |
| | EAP-pwd-Commit/Response | |
| |------------------------------------>| |
| | | |
| | EAP-pwd-Confirm/Request | |
| |<------------------------------------| |
| | | |
| | EAP-pwd-Confirm/Response | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
a successful EAP-pwd exchange
Figure 2
The components of the EAP-pwd-* messages are as follows:
EAP-pwd-ID/Request
Server_ID, Ciphersuite
EAP-pwd-ID/Response
Peer_ID, Ciphersuite
EAP-pwd-Commit/Request
Scalar_S, Element_S
Harkins & Zorn Expires August 8, 2008 [Page 10]
Internet-Draft EAP Password February 2008
EAP-pwd-Commit/Response
Scalar_P, Element_P
EAP-pwd-Confirm/Request
Confirm_S
EAP-pwd-Confirm/Response
Confirm_P
2.6.3. Message Construction
After the EAP-pwd Identity exchange the construction of the
components of each message depends on the finite cyclic group from
the ciphersuite.
2.6.3.1. Elliptic Curve Groups
Assuming an elliptic curve group with base point G and order r:
Harkins & Zorn Expires August 8, 2008 [Page 11]
Internet-Draft EAP Password February 2008
Server: EAP-pwd-Commit/Request
- choose random number, 1 < s_rand < r
- compute ES = s_rand * G
- compute ss = F(ES)
- compute Element_S = -(ss * PWE)
- compute Scalar_S = (s_rand + ss) mod r
Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request
Peer: EAP-pwd-Commit/Response
- choose random number, 1 < p_rand < r
- compute EP = p_rand * G
- compute sp = F(EP)
- compute Element_P = -(sp * PWE)
- compute Scalar_P = (p_rand + sp) mod r
Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response
Server: EAP-pwd-Confirm/Request
- compute KS = s_rand * (Scalar_P * PWE + Element_P)
- compute ks = F(KS)
- compute Confirm_S = H(ks | Element_S | Scalar_S |
Element_P | Scalar_P | Ciphersuite)
Confirm_S is used to construct EAP-pwd-Confirm/Request
Peer: EAP-pwd-Confirm/Response
- compute KP = p_rand * (Scalar_S * PWE + Element_S)
- compute kp = F(KP)
- compute Confirm_P = H(kp | Element_P | Scalar_P |
Element_S | Scalar_S | Ciphersuite)
Confirm_P is used to construct EAP-pwd-Confirm/Response
The EAP Server computes the shared secret as:
MK = H(ks | F(Element_S+Element_P) | (Scalar_S+Scalar_P) mod r)
The EAP Peer computes the shared secet as:
MK = H(kp | F(Element_P+Element_S) | (Scalar_P+Scalar_S) mod r)
The MSK and EMSK are derived from MK per Section 2.6.5.
2.6.3.2. Prime Modulus Groups
When using a finite cyclic group based on exponentiaton of a
generator (g) modulus a prime (p), a subgroup order (r) may or may
not be specified. If it is not specified r is set to p-1 for use in
Harkins & Zorn Expires August 8, 2008 [Page 12]
Internet-Draft EAP Password February 2008
this protocol. Also, there is no bijective function needed when
using such a group.
Server: EAP-pwd-Commit/Request
- choose random number, 1 < s_rand < r
- compute ss = g^s_rand mod p
- compute Element_S = 1/(pwe^ss mod p)
- compute Scalar_S = (s_rand + ss) mod r
Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request
Peer: EAP-pwd-Commit/Response
- choose random number, 1 < p_rand < r
- compute sp = g^p_rand mod p
- compute Element_P = 1/(pwe^sp mod p)
- compute Scalar_P = (p_rand + sp) mod r
Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response
Server: EAP-pwd-Confirm/Request
- compute ks = ((pwe^Scalar_P mod p) * Element_P)^s_rand mod p
- compute Confirm_S = H(ks | Element_S | Scalar_S |
Element_P | Scalar_P | Ciphersuite)
Confirm_S is used to construct EAP-pwd-Confirm/Request
Peer: EAP-pwd-Confirm/Response
- compute kp = ((pwe^Scalar_S mod p) * Element_S)^p_rand mod p
- compute Confirm_P = H(kp | Element_P | Scalar_P |
Element_S | Scalar_S | Ciphersuite)
Confirm_P is used to construct EAP-pwd-Confirm/Request
The EAP Server computes the shared secret as:
MK = H(ks | (Element_S + Element_P) mod r |
(Scalar_S + Scalar_P) mod r)
The EAP Peer computes the shared secet as:
MK = H(kp | (Element_P + Element_S) mod r |
(Scalar_P + Scalar_S) mod r)
The MSK and EMSK derived from MK per Section 2.6.5.
Harkins & Zorn Expires August 8, 2008 [Page 13]
Internet-Draft EAP Password February 2008
2.6.4. Message Processing
2.6.4.1. EAP-pwd-ID Exchange
[RFC3748] defines an EAP Identity exchange to determine the identity
of the peer. Unfortunately, the Response to an Identity Request
cannot be used by EAP-pwd. [RFC3748] says:
The Identity Response may not be the appropriate identity for
the method; it may have been truncated or obfuscated so as to
provide privacy, or it may have been decorated for routing
purposes.
Therefore [RFC3748] recommends that the EAP-ID exchange only be used
for method selection and that a method-specific mechanism be used to
determine a usable identity. The EAP-pwd-ID exchange serves this
purpose.
The EAP-pwd-ID/Request contains a Ciphersuite the server has selected
for the subsequent authentication exchange as well as its identity.
The Ciphersuite is comprised of a definition of a finite cyclic
group, a definition of a random function, and a definition of a PRF.
The EAP-pwd-ID/Request also contains an anti-clogging token. The
value of this token MUST be unpredictable and SHOULD NOT be from a
source of random entropy. The purpose of the anti-clogging token is
to provide the server an assurance that the peer constructing the
EAP-pwd-ID/Response is genuine and not part of a flooding attack.
The server chooses an unpredictable 32-bit number and adds it to the
Token field of the EAP-pwd-ID/Request.
Upon receipt of an EAP-pwd-ID/Request, the peer determines whether
the Ciphersuite is acceptable. If not, the peer MUST respond with an
EAP-NAK. If acceptable, the peer responds to the EAP-pwd-ID/Request
acknowledging the Ciphersuite and token and adding its identity.
After sending the EAP-pwd-ID/Response, the peer has the identity of
the server (from the Request) and its own identity (it encoded in the
Response) and can compute the password scalar and password element
according to Section 2.6.2. The password element is stored in state
allocated for this exchange.
The EAP-pwd-ID/Response acknowledges the Ciphersuite from the
Request, acknowledges the anti-clogging token from the Request
providing a demonstration of "liveness" on the part of the peer, and
contains the identity of the peer. Upon receipt of the Response, the
server verifies that the Ciphersuite acknowledged by the peer is the
same as that sent in the Request and that the token added by the peer
in the Response is the same as the one the server sent in the
Harkins & Zorn Expires August 8, 2008 [Page 14]
Internet-Draft EAP Password February 2008
Request. If Ciphersuites or tokens differ, the server MUST respond
with an EAP-Failure message. If the Ciphersuites are the same, the
server now knows its own identity (it encoded in the Request) and the
peer's identity (from the Response) and can compute the password
scalar and password element according to Section 2.6.2. The server
stores the password element in state it has allocated for this
exchange. The server then initiates an EAP-pwd-Commit exchange.
2.6.4.2. EAP-pwd-Commit Exchange
The server begins the EAP-pwd-Confirm exchange by choosing a random
number between 1 and r (where r is described in Section 2.1 according
to the group established in Section 2.6.4.1). It then computes
Element_S and Scalar_S as defined in Section 2.6.3 and constructs an
EAP-pwd-Commit/Request according to Section 3.3. Element_S and
Scalar_S are added to the state allocated for this exchange.
Upon receipt of the EAP-pwd-Commit/Request, the peer validates the
length of the entire payload based upon the expected lengths of
Element_S and Scalar_S (which are fixed according to the agreed-upon
group). If the length is incorrect, the peer MUST terminate the
exchange and free up any state allocated. If the length is correct,
the peer chooses a random number between 1 and r (where r is
described in Section 2.1 according to the group established in
Section 2.6.4.1). It then computes Element_P and Scalar_P and
constructs an EAP-pwd-Commit/Response according to Section 3.3. The
peer also computes kp from Element_S, Scalar_S and the password
element according to Section 2.6.3 and stores kp, Element_P and
Scalar_P in state allocated for this exchange.
Upon receipt of the EAP-pwd-Commit/Response, the server validates the
length of the entire payload based upon the expected lengths of
Element_P and Scalar_P (which are fixed according to the agreed-upon
group). If the length is incorrect, the server MUST respond with an
EAP-Failure message and it MUST terminate the exchange and free up
any state allocated. If the length is correct, the server checks
whether Scalar_P equals Scalar_S and Element_P equals Element_S. If
this is true it indicates a reflection attack and the server MUST
respond with an EAP-Failure and terminate the exchange freeing up all
allocated state. If the scalars and elements are not equal, the
server computes kp from Element_P, Scalar_P and the password element
according to Section 2.6.3. The server stores ks in the state it has
allocated for this exchange and initiates an EAP-pwd-Confirm
Exchange.
Harkins & Zorn Expires August 8, 2008 [Page 15]
Internet-Draft EAP Password February 2008
2.6.4.3. EAP-pwd-Confirm Exchange
The server computes Confirm_S according to Section 2.6.3 and
constructs an EAP-pwd-Confirm/Request and sends it to the peer.
Upon receipt of an EAP-pwd-Confirm/Request, the peer validates the
length of of the entire payload based upon the expected length of
Confirm_S (whose length is fixed by the agreed-upon random function).
If the length is incorrect, the peer MUST terminate the exchange and
free up any state allocated. If the length is correct, the peer
verifies that Confirm_S is the value it expects based on the value of
kp. If the value of Confirm_S is incorrect, the peer MUST terminate
the exchange and free up any state allocated. If the value of
Confirm_S is correct, the peer computes Confirm_P, constructs an EAP-
pwd-Confirm/Response and sends it off to the server. The peer then
computes MK (according to Section 2.6.3) and the MSK and EMSK
(according to Section 2.6.5) and stores these keys in state allocated
for this exchange. The peer SHOULD export the MSK and EMSK at this
time in anticipation of a secure association protocol by the lower-
layer to create session keys. Alternately, the peer can wait until
an EAP-success messsage from the server before exporting the MSK and
EMSK.
Upon receipt of an EAP-pwd-Confirm/Response, the server validates the
length of of the entire payload based upon the expected length of
Confirm_P (whose length is fixed by the agreed-upon random function).
If the length is incorrect, the server MUST respond with an EAP-
Failure message and it MUST terminate the exchange and free up any
state allocated. If the length is correct, the server verifies that
Confirm_P is the value it expects based on the value of ks. If the
value of Confirm_P is incorrect, the server MUST respond with an EAP-
Failure message. If the value of Confirm_P is correct, the server
computes MK (according to Section 2.6.3) and the MSK and EMSK
(according to Section 2.6.5). It exports the MSK and EMSK and
responds with an EAP-success Request. The server SHOULD free up
state allocated for this exchange.
2.6.5. Management of EAP-pwd Keys
[EAPKEY] recommends each EAP method define how to construct a
Method-ID and Session-ID to identify a particular EAP session between
a peer and server. This information is constructed thusly:
Method-ID = H(Ciphersuite | Scalar_P | Scalar_S)
Session-ID = Type-Code | Method-ID
where Ciphersuite, Scalar_P and Scalar_S are from the specific
Harkins & Zorn Expires August 8, 2008 [Page 16]
Internet-Draft EAP Password February 2008
exchange being identified; H is the random function specified in the
Ciphersuite; and, Type-Code is the code assigned by IANA for EAP-pwd:
TBD1.
The authenticated key exchange of EAP-pwd generates a shared and
authenticated key, MK. The size of MK is dependent on the random
function, H, asserted in the Ciphersuite. EAP-pwd must export two
512-bit keys, MSK and EMSK. Regardless of the value of len(MK)
implementations MUST invoke the KDF defined in Section 2.4 to
construct the MSK and EMSK. The MSK and EMSK are derived thusly:
MSK | EMSK = KDF(MK, Session-ID, 1024)
[RFC4962] mentions the importance of naming keys, particularly when
key caching is being used. To faciliate such an important
optimization names are assigned thusly:
o EMSK-name = Session-ID | 'E' | 'M'| 'S' | 'K'
o MSK-name = Session-ID | 'M'| 'S' | 'K'
where 'E' is a single octet of value 0x45, 'M' is a single octet of
value 0x4d, 'S' is a single octet of value 0x53, and 'K' is a single
octet of value 0x4b.
This naming scheme allows for key management applications to quickly
and accurately identify keys for a particular session or all keys of
a particular type.
3. Packet Formats
3.1. EAP-pwd Header
The EAP-pwd header has the following structure:
Harkins & Zorn Expires August 8, 2008 [Page 17]
Internet-Draft EAP Password February 2008
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | PWD-Exchange |M| Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EAP-pwd Header
Figure 5
The Code, Identifier, Length, and Type fields are all part of the EAP
header, and defined in RFC 3748 [RFC3748]. The EAP Method Type for
EAP-pwd is assigned by IANA and is TBD1.
The PWD-Exchange field is one of three values:
o 0x01 : EAP-pwd-ID exchange
o 0x02 : EAP-pwd-Commit exchange
o 0x03 : EAP-pwd-Confirm exchange
All other values of the PWD-Exchange field are reserved to IANA.
The "M" bit signifies a fragmented EAP-pwd message when set and an
unfragmented EAP-pwd message when clear (see Section 4).
The "Sequence" field is used to reassemble fragmented payloads (see
Section 4). If the "M" bit, above, is clear this field MUST be set
to zero on transmission and ignored on receipt.
3.2. EAP-pwd Payloads
EAP-pwd payloads all contain the EAP-pwd header and encoded
information. Encoded information is comprised of sequences of data.
Payloads in the EAP-pwd-ID exchange also include a ciphersuite
statement indicating what finite cyclic group to use, what
cryptographic primitive to use for H, and what PRF to use for
deriving keys.
Harkins & Zorn Expires August 8, 2008 [Page 18]
Internet-Draft EAP Password February 2008
3.2.1. EAP-pwd-ID
The Group Description, Random Function, and PRF together, and in that
order, comprise the Ciphersuite included in the calculation of the
peer's and server's confirm messages.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | PWD-Exchange |M| Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Description | Random Func'n | PRF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Identity ~
| |
~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EAP-pwd-ID Payload
Figure 6
The Group Description field value is taken from the IANA registry for
DIffie-Hellman groups used in IKE [RFC2409].
The Random Function field has the following value:
o 0x01 : Function defined in this memo in Section 2.3
All other values of the Random Function field are reserved to IANA.
The PRF field has the following value:
o 0x01 : HMAC-SHA256 as defined in [RFC4634]
All other values of the PRF field are reserved to IANA.
The Token field contains an unpredictable value assigned by the
server in an EAP-pwd-ID/Request and acknowledged by the peer in an
EAP-pwd-ID/Response (see Section 2.6.4).
Harkins & Zorn Expires August 8, 2008 [Page 19]
Internet-Draft EAP Password February 2008
The Identity field depends on the value of PWD-Exchange.
o EAP-pwd-ID/Request : Server_ID
o EAP-pwd-ID/Response : Peer_ID
The length of the identity is computed from the Length field in the
EAP header.
3.2.2. EAP-pwd-Commit
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | PWD-Exchange |M| Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Element ~
| |
~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| |
~ Scalar +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EAP-pwd-Commit Payload
Figure 7
The Element and Scalar fields depend on the value of PWD-Exchange.
o EAP-pwd-Commit/Request : Element_S, Scalar_S
o EAP-pwd-Commit/Response : Element_P, Scalar_P
The length of the Element is inferred by the finite cyclic group from
the agreed-upon Ciphersuite (see Section 3.3). The length of the
scalar can then be computed from the Length in the EAP header.
3.2.3. EAP-pwd-Confirm
Harkins & Zorn Expires August 8, 2008 [Page 20]
Internet-Draft EAP Password February 2008
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | PWD-Exchange |M| Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Confirm ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EAP-pwd-Confirm Payload
Figure 8
The Confirm field depends on the value of PWD-Exchange.
o EAP-pwd-Confirm/Request : Confirm_S
o EAP-pwd-Confirm/Response : Confirm_P
The length of the Confirm field computed from the Length in the EAP
header.
3.3. Representation of Field Elements
Payloads in the EAP-pwd-Commit exchange contain elements from the
finite cyclic group. To ensure interoperability field elements MUST
be represented according to one of the following two techniques,
depending on the type of group.
3.3.1. Prime Modulus Groups
Field elements in a prime modulus group are integers less than the
prime modulus. Each element MUST have a bit length equal to the bit
length of the prime modulus. This length is enforced, if necessary,
by prepending the integer with zeros until the required length is
achieved.
3.3.2. Elliptic Curve Groups
Elliptic curve field elements are points on the elliptic curve and
consist of two components, an x-coordinate and a y-coordinate. Each
component MUST have a bit length equal to the field size of the
group. This length is enforced, if necessary, by prepending the
component with zeros until the required length is achieved.
Harkins & Zorn Expires August 8, 2008 [Page 21]
Internet-Draft EAP Password February 2008
The field element is represented in a payload by the x-coordinate
followed by the y-coordinate. Therefore the field element in the
payload MUST be twice the size of the field size defined in the
group.
4. Fragmentation
[RFC3748] is a request-response protocol. The server sends requests
and the peer responds. These request and response messages are
assumed to be limited to at most 1020 bytes. Messages in EAP-pwd can
be larger than 1020 bytes and therefore require support for
fragmentation and reassembly.
Implementations MUST establish a fragmentation threshold that
indicates the maximum size of an EAP-pwd payload. When an
implementation knows the maximum transmission unit (MTU) of its
lower-layer, it SHOULD calculate the fragmentation threshold from
that value. In lieu of knowledge of the lower-layer's MTU the
fragmentation threshold MUST be 1020 bytes.
The "M" bit in the EAP-pwd header is used to indicate when a message
is fragmented. The syntax is "more": there are more data coming.
When a message is received with the "M" bit set the "Data" portion of
the next payload is concatenated to the "Data" portion of the current
payload (after some basic sanity checks) to construct a complete EAP-
pwd message.
The "Sequence" field in the EAP-pwd header is used to assemble
fragments. It is a monotonically increasing number, from 1 to 2^15,
and the "Data" field from fragmented EAP-pwd payloads are
concatenated together in order.
A server (peer) will fragment EAP-pwd Request (Response) messages
when the total size of the message is larger than the fragmentation
threshold. The first fragment MUST have the "M" bit set and the
"Sequence" number set to 1. The server (peer) MUST increment the
"Sequence" number for all subsequent fragments and all fragments,
except the last, MUST have the "M" bit set.
When a peer (server) receives an EAP-pwd Request (Response) message
with the "M" bit set in the EAP-pwd header it MUST acknowledge
receipt of the fragmented Request (Response) by responding with an
EAP-pwd Response (Request) having the same "PWD-Exchange", "M" bit,
and "Sequence" number as the fragmented Request. The "Data" field of
an acknowledgement MUST be empty. A server (peer) MUST NOT send the
next fragment until the current fragment has been acknowledged.
Harkins & Zorn Expires August 8, 2008 [Page 22]
Internet-Draft EAP Password February 2008
Subsequent fragments of the EAP-pwd Request (Response) message
received by the peer (server) MUST all have the same "PWD-exchange"
value. Any discrepancy MUST result in the peer (server) terminating
the exchange (in addition a server who detects such a discrepancy
MUST send an EAP-Failure message). Fragments which do not have a
value in the "Sequence" field that is one (1) greater than the last
received fragment MUST be silently dropped. The peer (server) MUST
continue to acknowledge all fragments until a Request (Response)
message is received with the correct "PWD-Exchange" value, correct
"Sequence" number, and the "M" bit clear. This signifies the final
fragment. Upon receipt of the final fragment, the final received
message is formed by concatenating the "Data" portion of all received
fragments in a monotonically increasing order by "Sequence" number.
A peer (server) MUST NOT attempt to process a message until all its
component fragments have been received and formed into a complete
message.
5. IANA Considerations
This memo contains new numberspaces to be managed by IANA. The
policies used to allocate numbers are described in [RFC2434]. This
memo requires IANA to allocate a new EAP method type for EAP-pwd.
This memo also requires IANA to create new registries for PWD-
exchange messages, random functions, PRFs, and error codes and to add
the specified message numbers, random function, PRF and error codes,
defined in this memo to those registries, respectively.
The following is the initial PWD-exchange message registry layout:
o 0x01 : EAP-pwd-ID exchange
o 0x02 : EAP-pwd-Commit exchange
o 0x03 : EAP-pwd-Confirm exchange
The PWD-exchange field is 8 bits long and all other values are
available through assignment by IANA. IANA is instructed to assign
values based on "IETF Consensus" (see [RFC2434]).
The following is the initial Random Function registry layout:
o 0x01 : Function defined in this memo in Section 2.3
The Random Function field is 8 bits long and all other values are
available through assignment by IANA. IANA is instructed to assign
values based on "Standards Action" and "Expert Review" (see
Harkins & Zorn Expires August 8, 2008 [Page 23]
Internet-Draft EAP Password February 2008
[RFC2434]) to ensure that new random functions have received the
proper vetting.
The following is the initial PRF registry layout:
o 0x01 : HMAC-SHA256 as defined in [RFC4634]
The PRF field is 8 bits long and all other values are available
through assignment by IANA. IANA is instructed to assign values
based on "IETF Consensus" (see [RFC2434]).
The following is the initial Failure Code registry layout:
o 0x00000001: MALFORMED-MESSAGE
o 0x00000002: AUTHENTICATION-FAILURE
o 0x00000003: FRAGMENTATION-ERROR
The Failure-Code is 16 bits long and all other values are available
through assignment by IANA. IANA is instructed to assign values
based on "IETF Consensus" (see [RFC2434]).
6. Security Considerations
In Section 1.3 several security properties were presented that
motivated the design of this protocol. This section will address how
well they are met.
6.1. Resistance to Passive Attack
A passive attacker will see Scalar_P, Element_P, Scalar_S, and
Element_S. She can guess at passwords to compute the password element
but will not know s_rand or p_rand and therefore will not be able to
compute MK.
The secret random value of the peer (server) is effectively hidden by
adding sp (ss) to p_rand (s_rand) modulus the order of the group. If
the order is "r", then there are approximately "r" distinct pairs of
numbers that will sum to the value Scalar_P (Scalar_S). Attempting
to guess the particular pair is just as difficult as guessing the
secret random value p_rand (s_rand), the probability of a guess is
1/(r - i) after "i" guesses and for a large value of r (e.g. on the
order of 2^160) this exhaustive search technique is computationally
infeasible. An attacker would do better by determining the discrete
logarithm of Element_P (Element_S) using an algorithm like Baby-Step
giant-step (see [APPCRY]), which runs on the order of the square root
Harkins & Zorn Expires August 8, 2008 [Page 24]
Internet-Draft EAP Password February 2008
of r group operations (e.g. a group with order 2^160 that would be
2^80 exponentiations or point multiplications). Based on the
assumptions made on the finite cyclic group made in Section 2.2 that
is also computationally infeasible.
6.2. Resistance to Active Attack
An active attacker can launch her attack after an honest server has
sent EAP-pwd-Commit/Request to an honest peer. This would result in
the peer sending EAP-pwd-Commit/Response. In this case the active
attack has been reduced to that of a passive attacker since p_rand
and s_rand will remain unknown. The active attacker could forge a
value of Confirm_P (Confirm_S) and send it to the EAP server (EAP
peer) in the hope that it will be accepted but due to the assumptions
on H made in Section 2.2 that is computationally infeasible.
The active attacker can launch her attack by forging EAP-pwd-Commit/
Request and sending it to the peer. This will result in the peer
responding with EAP-pwd-Commit/Response. The attacker can then
attempt to compute ks but since she doesn't know the password this is
infeasible. It can be shown that an attack by receiving EAP-pwd-
Commit/Request from an honest server and forging EAP-pwd-Commit/
Response is an identical attack with equally infeasibility.
6.3. Resistance to Dictionary Attack
An active attacker can wait until an honest server sends EAP-pwd-
Commit/Request and then forge EAP-pwd-Commit/Response and send it to
the server. The server will respond with EAP-pwd-Confirm/Request.
Now the attacker has everything she needs to launch a dictionary
attack. She can guess at potential passwords, compute the password
element and compute kp using Scalar_P and Element_P from EAP-pwd-
Commit/Request and the candidate password element from her guess.
She will know if her guess is correct when she is able to verify
Confirm_S in EAP-pwd-Confirm/Request.
But the attacker committed to a password guess with her forged EAP-
pwd-Commit/Response when she computed Element_P. That value was used
by the server in his computation of ks which was used when he
constructed Confirm_S in EAP-pwd-Confirm/Request. Any guess of the
password that differs from the one used in the forged EAP-pwd-Commit/
Response could not be verified as correct since the attacker has no
way of knowing whether it is correct. She is able to make one guess
and one guess only per attack. This means that any advantage she can
gain-- guess a password, if it fails exclude it from the pool of
possible passwords and try again-- is solely through interaction with
an honest protocol peer.
Harkins & Zorn Expires August 8, 2008 [Page 25]
Internet-Draft EAP Password February 2008
The attacker can commit to the guess with the forged EAP-pwd-Commit/
Response and then run through the dictionary, computing the password
element and ks using her forged Scalar_P and Element_P. She will know
she is correct if she can compute the same value for Confirm_S that
the server produced in EAP-pwd-Confirm/Request. But this requires
the attacker to know s_rand which we noted, above, was not possible.
The best advantage an attacker can gain in a single active attack is
to determine whether a single guess at the password was correct.
Therefore her advantage is solely through interaction and not
computation, which is the definition for resistance to dictionary
attack.
Resistance to dictionary attack means that the attacker must launch
an active attack to make a single guess at the password. If the size
of the dictionary from which the password was extracted was D, and
each password in the dictionary 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 passwords, the probability becomes 1/(D-X). Therefore it is
possible for an attacker to determine the password through brute-
force, active, guessing attacks. This protocol does not presume to
be secure against trivial guessing and implementations SHOULD 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.
6.4. Forward Secrecy
The MSK and EMSK are extracted from MK which is derived from doing
group operations with s_rand, p_rand, and the password scalar value.
The peer and server choose random values with each run of the
protocol. So even if an attacker is able to learn the password, she
will not know the random values used by either the peer or server
from an earlier run and will therefore be unable to determine MK, or
the MSK or EMSK. This is the definition of Forward Secrecy.
6.5. Random Functions
The protocol described in this memo uses a function referred to as a
"random oracle" (as defined in [RANDOR]). A significant amount of
care must be taken to instantiate a random oracle out of handy
cryptographic primitives. Section 6 of [RANDOR] provides guidance on
how to do this using hash functions. The random function, H, defined
in this memo in Section 2.3 uses one of the suggested constructs-- a
hash algorithm with truncated output.
Harkins & Zorn Expires August 8, 2008 [Page 26]
Internet-Draft EAP Password February 2008
This protocol can use any properly instantiated random oracle. To
ensure that any new value for H will use a properly instantiated
random oracle IANA has been instructed (in Section 5) to only
allocate values from the Random Function registry after being vetted
by an expert. The other requirement for a random function is that it
map its input to a target of at least 128 bits.
7. Security Claims
[RFC3748] requires that documents describing new EAP methods clearly
articulate the security properties of the method. In addition, for
use with wireless LANs [RFC4017] mandates and recommends several of
these. The claims are:
a. mechanism: password.
b. claims:
* mutual authentication: the peer and server both authenticate
each other by proving possession of a shared password. This
is REQUIRED by [RFC4017].
* foward secrecy: compromise of the password does not reveal
the secret keys-- MK, MSK, or EMSK-- from earlier runs of the
protocol.
* replay protection: an attacker is unable to replay messages
from a previous exchange either learn the password or a key
derived by the exchange. Similarly the attacker is unable to
induce either the peer or server to believe the exchange has
successfully completed when it hasn't. Reflection attacks
are foiled because the server ensures that the scalar and
element supplied by the peer do not equal its own.
* key derivation: keys are derived by performing a group
operation in a finite cyclic group (e.g. exponentiation)
using secret data contributed by both the peer and server.
An MSK and EMSK are derived from that shared secret. This is
REQUIRED by [RFC4017]
* dictionary attack resistance: an attacker can only make one
password guess per active attack. The advantage she can gain
is through interaction not through computation. This is
REQUIRED by [RFC4017].
* session independence: this protocol is resistant to active
and passive attack and does not enable compromise of
Harkins & Zorn Expires August 8, 2008 [Page 27]
Internet-Draft EAP Password February 2008
subsequent or prior MSKs or EMSKs from either passive or
active attack.
* Denial of Service Resistance: it is possible for an attacker
to cause a server to allocate state and consume CPU
generating Scalar_S and Element_S. Such an attack is gated,
though, by the requirement that the attacker first obtain
connectivity through a lower-layer protocol (e.g. 802.11
authentication followed by 802.11 association, or 802.3
"link-up") and respond to two EAP messages--the EAP-ID/
Request and the EAP-pwd-ID/Request. The EAP-pwd-ID exchange
further includes an anti-clogging token that provides a level
of assurance to the server that the peer is, at least,
performing a rudimentary amount of processing and not merely
spraying packets. This prevents distributed denial of
service attacks and also requires the attacker to announce,
and commit to, a lower-layer identity (such as a MAC
address).
* Man-in-the-Middle Attack Resistance: this exchange is
resistant to active attack, which is a requirement for
launching a man-in-the-middle attack. This is REQUIRED by
[RFC4017].
* shared state equivalence: upon completion of EAP-pwd the peer
and server both agree on MK, MSK, EMSK, Method-ID, and
Session-ID. The peer has authenticated the server based on
the Server-ID and the server has authenticated the peer based
on the Peer-ID. This is due to the fact that Peer-ID,
Server-ID, and the shared password are all combined to make
the password element which must be shared between the peer
and server for the exchange to complete. This is REQUIRED by
[RFC4017].
* fragmentation: this protocol defines a technique for
fragmentation and reassembly in Section 4.
* resistance to "Denning-Sacco" attack: learning keys
distributed from an earlier run of the protocol, such as the
MSK or EMSK, will not help an adversary learn the password.
c. key strength: the strength of the resulting key depends on the
finite cyclic group chosen. For example, [RFC5114] defines new
groups available for use with this protocol. Using groups from
[RFC5114] the strength can vary from 80 bits (for the 1024-bit
MODP with 160-bit Prime Subgroup) to 256 bits (for the 521-bit
Random ECP Group). Other groups can be defined and the strength
of those groups depends on their definition. This is REQUIRED by
Harkins & Zorn Expires August 8, 2008 [Page 28]
Internet-Draft EAP Password February 2008
[RFC4017].
d. key hierarchy: MSKs and EMSKs are derived from the MK using the
KDF defined in Section 2.4 as described in Section 2.6.3.
e. vulnerabilities (note that none of these are REQUIRED by
[RFC4017]):
* protected ciphersuite negotiation: the ciphersuite offer made
by the server is not protected from tampering by an active
attacker. Downgrade attacks are prevented, though, since
this is not a "negotiation" with a list of acceptable
ciphersuites. If a Ciphersuite was modified by an active
attacker it would result in a failure to confirm the message
sent by the other party and the protocol would fail as a
result.
* confidentiality: none of the messages sent in this protocol
are encrypted.
* integrity protection: messages in the EAP-pwd-Commit exchange
are not integrity protected.
* channel binding: this protocol does not enable the exchange
of integrity-protected channel information that can be
compared with values communicated via out-of-band mechanisms.
* fast reconnect: this protocol does not provide a fast
reconnect capability.
* cryptographic binding: this protocol is not a tunneled EAP
method and therefore has no cryptographic information to
bind.
* identity protection: the EAP-pwd-ID exchange is not
protected. An attacker will see the server's identity in the
EAP-pwd-ID/Request and see the peer's identity in EAP-pwd-ID/
Response.
8. Acknowledgements
The authors would like to thank Hideyuki Suzuki for his insight in
discovering an attack against a previous version of this protocol.
Scott Kelly suggested adding the anti-clogging token to the ID
exchange to prevent distributed denial of service attacks. Dorothy
Stanley provided valuable suggestions to improve the quality of this
memo.
Harkins & Zorn Expires August 8, 2008 [Page 29]
Internet-Draft EAP Password February 2008
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
Request For Comments (RFC) 3748, June 2004.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", Request For Comments
(RFC) 4282, December 2005.
9.2. Informative References
[APPCRY] Menezes, A., van Oorshot, P., and S. Vanstone, "Handbook
of Applied Cryptography", CRC Press Series on Discrete
Mathematics and Its Applications, 1996.
[BM92] Bellovin, S. and M. Merritt, "Password-Based Protocols
Secure Against Dictionary Attack", Proc. of the Symposium
on Security and Privacy, pages 72-84, 1992.
[BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key
Exchange: A Password-Based Protocol Secure against
Dictionary Attacks and Password File Compromise", Proc. of
the 1st Annual COnference on Computer and Communication
Security, ACM, 1993.
[BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure
Password Authenticated Key Exchange Using Diffie-Hellman",
Proc. of Eurocrypt 2000.
[EAPKEY] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22 (work in progress),
November 2007.
[JAB96] Jablon, D., "Strong Passowrd-Only Authenticated Key
Exchange", ACM Computer Communications Review October
1996.
[LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary
Attacks Without Encrypting Public Keys", Proc. of the
Security Protocols Workshop, LNCS 1361. Springer-Verlag,
Berlin, 1997.
Harkins & Zorn Expires August 8, 2008 [Page 30]
Internet-Draft EAP Password February 2008
[RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practicle:
A Paradigm for Designing Efficient Protocols", Proceedings
of First ACM Conference on Computer and Communications
Security, November 1993,
<http://www.cs.ucsd.edu/~mihir/papers/ro.pdf>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange",
Request For Comments (RFC) 2409, November 1998.
[RFC2434] Marten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", Request For Comments
(RFC) 2434, October 1998.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", Request For Comments (RFC) 4017,
March 2005.
[RFC4086] Eastlake, D., Schiller, S., and S. Crocker, "Randomness
Recommendations for Security", Request For Comments
(RFC) 4086, June 2005.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms",
Request For Comments (RFC) 4634, July 2006.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
Request For Comments (RFC) 4962, July 2007.
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman
Groups for Use with IETF Standards", Request For Comments
(RFC) 5114, January 2008.
[SHA2] National Institute of Standards and Technology, "Secure
Hash Standard", Federal Information Processing Standard
(FIPS) 180-2.
Authors' Addresses
Dan Harkins
Aruba Networks
Sunnyvale, California
United States of America
Email: dharkins@arubanetworks.com
Harkins & Zorn Expires August 8, 2008 [Page 31]
Internet-Draft EAP Password February 2008
Glen Zorn
Aruba Networks
Bangkok,
Kingdom of Thailand
Email: gwz@arubanetworks.com
Harkins & Zorn Expires August 8, 2008 [Page 32]
Internet-Draft EAP Password February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Harkins & Zorn Expires August 8, 2008 [Page 33]
