Network Working Group Y. Sheffer
Internet-Draft Independent
Intended status: Informational G. Zorn
Expires: October 23, 2010 Network Zen
H. Tschofenig
Nokia Siemens Networks
S. Fluhrer
Cisco
April 21, 2010
An EAP Authentication Method Based on the EKE Protocol
draft-sheffer-emu-eap-eke-06
Abstract
The Extensible Authentication Protocol (EAP) describes a framework
that allows the use of multiple authentication mechanisms. This
document defines an authentication mechanism for EAP called EAP-EKE,
based on the Encrypted Key Exchange (EKE) protocol. This method
provides mutual authentication through the use of a short, easy to
remember password. Compared with other common authentication
methods, EAP-EKE is not susceptible to dictionary attacks. Neither
does it require the availability of public-key certificates.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). 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 October 23, 2010.
Copyright Notice
Copyright (c) 2010 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
Sheffer, et al. Expires October 23, 2010 [Page 1]
Internet-Draft The EAP-EKE Method April 2010
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Flows . . . . . . . . . . . . . . . . . . . . . . 5
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. EAP-EKE Header . . . . . . . . . . . . . . . . . . . . . . 7
4.2. EAP-EKE Payloads . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. The EAP-EKE-ID Payload . . . . . . . . . . . . . . . . 8
4.2.2. The EAP-EKE-Commit Payload . . . . . . . . . . . . . . 9
4.2.3. The EAP-EKE-Confirm Payload . . . . . . . . . . . . . 11
4.2.4. The EAP-EKE-Failure Payload . . . . . . . . . . . . . 11
4.3. Protected Fields . . . . . . . . . . . . . . . . . . . . . 13
4.4. Encrypted Fields . . . . . . . . . . . . . . . . . . . . . 14
4.5. Channel Binding Values . . . . . . . . . . . . . . . . . . 14
5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 15
5.1. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 15
5.2. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 16
5.3. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 17
5.4. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 17
5.5. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 18
6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 18
6.1. Generating Keying Material . . . . . . . . . . . . . . . . 18
6.2. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 19
6.3. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 25
8.2. Diffie Hellman Group Considerations . . . . . . . . . . . 25
8.3. Resistance to Active Attacks . . . . . . . . . . . . . . . 26
8.4. Identity Protection, Anonymity and Pseudonymity . . . . . 26
8.5. Long Term Storage of Passwords . . . . . . . . . . . . . . 26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29
Sheffer, et al. Expires October 23, 2010 [Page 2]
Internet-Draft The EAP-EKE Method April 2010
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Sheffer, et al. Expires October 23, 2010 [Page 3]
Internet-Draft The EAP-EKE Method April 2010
1. Introduction
The predominant access method for the Internet today is that 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 to the 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 likely not possess high entropy and it may be assumed that 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 method that is secure even when used with a weak
password in the presence of a strong adversary.
EAP-EKE is an EAP method [RFC3748] that addresses the problem of
password-based authenticated key exchange, using a possibly weak
password for authentication and to derive an authenticated and
cryptographically strong shared secret. This problem was first
described by Bellovin and Merritt in [BM92] and [BM93].
Subsequently, a number of other solution approaches have been
proposed, for example [JAB96], [LUC97], [BMP00], and others.
This proposal is based on the original Encrypted Key Exchange (EKE)
proposal, as described in [BM92]. Some of the variants of the
original EKE have been attacked, see e.g. [PA97], and improvements
have been proposed. None of these subsequent improvements have been
incorporated into the current protocol. However, we have used only
the subset of [BM92] (namely the variant described in Section 3.1 of
the paper) which has withstood the test of time and is believed
secure as of this writing.
2. Terminology
This document uses Encr(Ke, ...) to denote encrypted information, and
Prot(Ke, Ki, ...) to denote encrypted and integrity protected
information.
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 [RFC2119].
Sheffer, et al. Expires October 23, 2010 [Page 4]
Internet-Draft The EAP-EKE Method April 2010
3. Protocol
EAP is a two-party protocol spoken between an EAP peer and an EAP
server (also known as "authenticator"). 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 and the EAP peer for the purpose of
authentication and key derivation.
3.1. Message Flows
A successful run of EAP-EKE consists of three message exchanges: an
Identity exchange, a Commit exchange and a Confirm exchange. This is
shown in Figure 1.
The peer and server use the EAP-EKE Identity exchange to learn each
other's identities and to agree upon a ciphersuite to use in the
subsequent exchanges. In the Commit exchange the peer and server
exchange information to generate a shared key and also to bind each
other to a particular guess of the password. In the Confirm exchange
the peer and server prove liveness and knowledge of the password by
generating and verifying verification data.
+--------+ +--------+
| | EAP-EKE-ID/Request | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| (P) | EAP-EKE-ID/Response | (S) |
| |------------------------------------>| |
| | | |
| | EAP-EKE-Commit/Request | |
| |<------------------------------------| |
| | | |
| | EAP-EKE-Commit/Response | |
| |------------------------------------>| |
| | | |
| | EAP-EKE-Confirm/Request | |
| |<------------------------------------| |
| | | |
| | EAP-EKE-Confirm/Response | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
Sheffer, et al. Expires October 23, 2010 [Page 5]
Internet-Draft The EAP-EKE Method April 2010
Figure 1: A Successful EAP-EKE Exchange
Schematically, the original exchange as described in [BM92] (and with
the roles reversed) is:
Server Peer
------ ----
Encr(Password, y_s) ->
<- Encr(Password, y_p), Encr(SharedSecret, Nonce_P)
Encr(SharedSecret, Nonce_S | Nonce_P) ->
<- Encr(SharedSecret, Nonce_S)
Where:
o Password is a typically short string, shared between the server
and the peer. In other words, the same password is used to
authenticate the server to the peer, and vice versa.
o y_s and y_p are the server's and respectively, the peer's,
ephemeral public key, i.e. y_s = g ^ x_s (mod p) and y_p = g ^ x_p
(mod p).
o Nonce_S, Nonce_P are random strings generated by the server and
the peer as cryptographic challenges.
o SharedSecret is the secret created by the Diffie-Hellman
algorithm, namely SharedSecret = g^(x_s * x_p) (mod p). This
value is calculated by the server as: SharedSecret = y_p ^ x_s
(mod p), and by the peer as: SharedSecret = y_s ^ x_p (mod p).
The current protocol extends the basic cryptographic protocol, and
the regular successful exchange becomes:
Message Server Peer
--------- -------- ------
ID/Request ID_S, CryptoProposals ->
ID/Response <- ID_P, CryptoSelection
Commit/Request Encr(Password, y_s) ->
Commit/Response <- Encr(Password, y_p), Prot(Ke, Ki, Nonce_P)
Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S ->
Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_P
Sheffer, et al. Expires October 23, 2010 [Page 6]
Internet-Draft The EAP-EKE Method April 2010
Section 5 explains how the various cryptographic values are derived.
As shown in the exchange above, the following information elements
have been added to the original protocol: identity values for both
protocol parties (ID_S, ID_P), negotiation of cryptographic
protocols, and signature fields to protect the integrity of the
negotiated parameters (Auth_S, Auth_P). In addition the shared
secret is not used directly. A few details have been omitted for
brevity.
4. Message Formats
EAP-EKE defined a small number of message types, each message
consisting of a header followed by a payload. This section defines
the header, several payload formats, as well as the format of
specific fields within the payloads.
4.1. EAP-EKE Header
The EAP-EKE header consists of the standard EAP header (see Section 4
of [RFC3748]), followed an EAP-EKE exchange type. The header has the
following structure:
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 | EKE-Exch | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EAP-EKE Header
The Code, Identifier, Length, and Type fields are all part of the EAP
header as defined in [RFC3748]. The Type field in the EAP header is
[TBD by IANA] for EAP-EKE version 1. [Note to RFC Editor: insert the
IANA-allocated value here.]
The EKE-Exch (EKE Exchange) field identifies the type of EAP-EKE
payload encapsulated in the Data field. This document defines the
following values for the EKE-Exch field:
o 0x00: Reserved
Sheffer, et al. Expires October 23, 2010 [Page 7]
Internet-Draft The EAP-EKE Method April 2010
o 0x01: EAP-EKE-ID exchange
o 0x02: EAP-EKE-Commit exchange
o 0x03: EAP-EKE-Confirm exchange
o 0x04: EAP-EKE-Failure message
Further values of this EKE-Exch field are available via IANA
registration (Section 7.7).
4.2. EAP-EKE Payloads
EAP-EKE messages all contain the EAP-EKE header and information
encoded in a single payload, which differs for the different
exchanges.
4.2.1. The EAP-EKE-ID Payload
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumProposals | Reserved | Proposal ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Proposal | IDType | Identity ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EAP-EKE-ID Payload
The EAP-EKE-ID payload contains the following fields:
NumProposals:
The NumProposals field contains the number of Proposal fields
subsequently contained in the payload. In the EAP-EKE-ID/Request
the NumProposals field MUST NOT be set to zero (0) and in the EAP-
EKE-ID/Response message the NumProposals field MUST be set to one
(1). The offered proposals in the Request are listed contiguously
in priority order, most preferable first. The selected proposal
in the Response MUST be fully identical with one of the offered
proposals.
Proposal:
Each proposal consists of four one-octet fields, in this order:
Sheffer, et al. Expires October 23, 2010 [Page 8]
Internet-Draft The EAP-EKE Method April 2010
Group Description:
This field's value is taken from the IANA registry for Diffie-
Hellman groups defined in Section 7.1.
Encryption:
This field's value is taken from the IANA registry for
encryption algorithms defined in Section 7.2.
PRF:
This field's value is taken from the IANA registry for pseudo
random functions defined in Section 7.3.
MAC:
This field's value is taken from the IANA registry for keyed
message digest algorithms defined in Section 7.4.
Reserved:
This field MUST be sent as zero, and MUST be ignored by the
recipient.
IDType:
Denotes the Identity Type. This is taken from the IANA registry
defined in Section 7.5. The server and the peer MAY use different
identity types. All implementations MUST be able to receive two
identity types: ID_NAI and ID_FQDN.
Identity:
The meaning of the Identity field depends on the values of the
Code and IDType fields.
* EAP-EKE-ID/Request: server ID
* EAP-EKE-ID/Response: peer ID
The length of the Identity field is computed from the Length field
in the EAP header. Specifically, its length is
eap_header_length - 9 - 4 * number_of_proposals.
This field, like all other fields in this specification, MUST be
octet-aligned.
4.2.2. The EAP-EKE-Commit Payload
This payload allows both parties send their encrypted ephemeral
public key, with the peer also including a Challenge.
Sheffer, et al. Expires October 23, 2010 [Page 9]
Internet-Draft The EAP-EKE Method April 2010
In addition, a small amount of data can be included by the server
and/or the peer, and used for channel binding. This data is sent
here unprotected, but is verified later, when it is signed by the
Auth_S/Auth_P payloads of the EAP-EKE-Confirm exchange.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHComponent_S/DHComponent_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Commit_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBValue* ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EAP-EKE-Commit Payload
DHComponent_S/DHComponent_P:
This field contains the password-encrypted Diffie-Hellman public
key, see Section 5.1. Its size is determined by the group and the
encryption algorithm.
Commit_P:
This field only appears in the response, and contains the
encrypted and integrity-protected challenge value sent by the
peer. The field's size is determined by the encryption and MAC
algorithms being used, since this protocol mandates a fixed nonce
size for a given choice of algorithms. See Section 5.2.
CBValue:
This structure MAY be included both in the request and in the
response, and MAY be repeated multiple times, once per each value
transmitted. See Section 4.5. Each structure contains its own
length.
Sheffer, et al. Expires October 23, 2010 [Page 10]
Internet-Draft The EAP-EKE Method April 2010
4.2.3. The EAP-EKE-Confirm Payload
Using this payload, both parties complete the authentication by
generating a shared temporary key, authenticating the entire
protocol, and generating key material for the EAP consumer protocol.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Confirm_S/Confirm_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth_S/Auth_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: EAP-EKE-Confirm Payload
Confirm_S/Confirm_P:
This field contains the encrypted and integrity-protected response
to the other party's challenge, see Section 5.3 and Section 5.4.
Similarly to the Commit_P field, this field's size is determined
by the encryption and MAC algorithms.
Auth_S/Auth_P:
This field signs the preceding messages, including the Identity
and the negotiated fields. This prevents various possible
attacks, such as algorithm downgrade attacks. See Section 5.3 and
Section 5.4. The size is determined by the pseudo-random function
negotiated.
4.2.4. The EAP-EKE-Failure Payload
The EAP-EKE-Failure payload format is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
Sheffer, et al. Expires October 23, 2010 [Page 11]
Internet-Draft The EAP-EKE Method April 2010
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EAP-EKE-Failure Payload
The payload's size is always exactly 4 octets.
The following Failure-Code values are defined:
+------------+----------------+-------------------------------------+
| Value | Name | Meaning |
+------------+----------------+-------------------------------------+
| 0x00000000 | Reserved | |
| 0x00000001 | No Error | This code is used for failure |
| | | acknowledgement, see below. |
| 0x00000002 | Protocol Error | A failure to parse or understand a |
| | | protocol message or one of its |
| | | payloads. |
| 0x00000003 | Password Not | A password could not be located for |
| | Found | the identity presented by the other |
| | | protocol party, making |
| | | authentication impossible. For |
| | | security reasons, implementations |
| | | MAY choose to eliminate this error |
| | | code and return "Authentication |
| | | Failure" also in this case. |
| 0x00000004 | Authentication | Failure in the cryptographic |
| | Failure | computation most likely caused by |
| | | an incorrect password, or an |
| | | inappropriate identity type. |
| 0x00000005 | Authorization | While the password being used is |
| | Failure | correct, the user is not authorized |
| | | to connect. |
| 0x00000006 | No Proposal | The peer is unwilling to select any |
| | Chosen | of the cryptographic proposals |
| | | offered by the server. |
+------------+----------------+-------------------------------------+
Additional values of this field are available via IANA registration,
see Section 7.8.
When the peer encounters an error situation, it MUST respond with
EAP-EKE-Failure. The server MUST reply with an EAP-Failure message
to end the exchange.
When the server encounters an error situation, it MUST respond with
EAP-EKE-Failure. The peer MUST send back an EAP-EKE-Failure message
containing a "No Error" failure code. Then the server MUST send an
Sheffer, et al. Expires October 23, 2010 [Page 12]
Internet-Draft The EAP-EKE Method April 2010
EAP-Failure message to end the exchange.
4.3. Protected Fields
Several fields are encrypted and integrity-protected. They are
denoted Prot(...). Their general structure is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector (IV) (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Random Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value (ICV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Protected Field Structure
The protected field is a concatenation of three octet strings:
o An optional IV, required when the encryption algorithm/mode
necessitates it, e.g. for CBC encryption. The content and size of
this field are determined by the selected encryption algorithm.
In the case of CBC encryption, this field is a random octet string
having the same size as the algorithm's block size.
o The original data, followed if necessary by random padding. This
padding has the minimal length (possibly zero) required to
complete the length of the encrypted data to the encryption
algorithm's block size. The original data and the padding are
encrypted together.
o ICV, a cryptographic checksum (MAC) of the encrypted data,
including the padding. The checksum is computed over the
encrypted, rather than the plaintext, data. Its length is
determined by the MAC algorithm negotiated.
We note that because of the requirement for an explicit ICV, this
specification does not support authenticated encryption algorithms.
Such algorithms may be added by a future extension.
Sheffer, et al. Expires October 23, 2010 [Page 13]
Internet-Draft The EAP-EKE Method April 2010
4.4. Encrypted Fields
Two fields are encrypted but not integrity protected. They are
denoted Encr(...). Their format is identical to a protected field
(Section 4.3), except that the Integrity Check Value is omitted.
4.5. Channel Binding Values
This protocol allows higher level protocols that are using it to
transmit opaque information between the peer and the server. This
information is integrity protected but not encrypted, and may be used
to ensure that protocol participants are identical at different
protocol layers. EAP-EKE neither validates nor makes any use of the
transmitted information. The information MUST NOT be used by the
consumer protocol until it is verified in the EAP-EKE-Confirm
exchange (specifically, it is integrity protected by the Auth_S,
Auth_P payloads). Consequently, it MUST NOT be relied upon in case
an error occurs at the EAP-EKE level.
An unknown Channel Binding Value SHOULD be ignored by the recipient.
Some implementations may require certain values to be present, and
will abort the protocol if they are not. Such policy is out of scope
of the current protocol.
Each Channel Binding Value is encoded using a simple TLV structure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBType | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Channel Binding Value
CBType:
This is the Channel Binding Value's type. This document defines
the value 0x0000 as reserved. Other values are available for IANA
allocation, see Section 7.6.
Sheffer, et al. Expires October 23, 2010 [Page 14]
Internet-Draft The EAP-EKE Method April 2010
Length:
This field is the total length in octets of the structure,
including the CBType and Length fields.
This facility should be used with care, since EAP-EKE does not
provide for message fragmentation. EAP-EKE is not a tunneled method,
and should not be used as a generic transport; specifically,
implementors should refrain from using the Channel Binding facility
to transmit posture information, in the sense of [RFC5209].
5. Protocol Sequence
This section describes the sequence of messages for the Commit and
Confirm exchanges, and lists the cryptographic operations performed
by the server and the peer.
5.1. EAP-EKE-Commit/Request
The server computes
y_s = g ^ x_s (mod p),
where x_s is a randomly chosen number in the range 2 .. p-1. The
randomly chosen number is the ephemeral private key, and the
calculated value is the corresponding ephemeral public key. The
server and the peer MUST both use a fresh, random value for x_s and
the corresponding x_p on each run of the protocol.
Note: If Elliptic Curve Diffie-Hellman is used, the corresponding
additive group operations are to be employed instead of
exponentiation.
The server transmits the encrypted field (Section 4.4)
DHComponent_S = Encr(prf+(password, "EAP-EKE Password"), y_s),
where the literal string is encoded using ASCII with no zero
terminator. See Section 6.1 for the prf+ notation. When using block
ciphers, it may be necessary to pad y_s on the right, to fit the
encryption algorithm's block size. In such cases, random padding
MUST be used, and this randomness is critical to the security of the
protocol. Randomness recommendations can be found in [RFC4086].
When decrypting this field, the real length of y_s is determined
according to the negotiated Diffie Hellman group.
If the password needs to be stored on the server, it is RECOMMENDED
Sheffer, et al. Expires October 23, 2010 [Page 15]
Internet-Draft The EAP-EKE Method April 2010
to store the randomized password value, i.e. prf+(password, ...), as
a password-equivalent, rather than the cleartext password. See also
Section 8.5.
If the password is non-ASCII, it SHOULD be normalized by the sender
before the EAP-EKE message is constructed. The normalization method
is SASLprep, [RFC4013]. Note that the password is not null-
terminated.
5.2. EAP-EKE-Commit/Response
The peer computes
y_p = g ^ x_p (mod p)
and sends
DHComponent_P = Encr(prf+(password, "EAP-EKE Password"), y_p)
formatted as an encrypted field (Section 4.4).
Both sides calculate
SharedSecret = prf(0+, g ^ (x_s * x_p) (mod p))
If an HMAC-based pseudo-random function is used, the first argument
to "prf" is a string of zero octets whose length is the output size
of the base hash algorithm, e.g. 20 octets for HMAC-SHA1; the result
is of the same length. If a non HMAC-based prf is used, the
algorithm should specify its preferred input length (to be used as
the length of the string of zeros) and its preferred output length.
This extra application of the pseudo-random function is the
"extraction step" of [I-D.krawczyk-hkdf]. Note that the peer needs
to compute the SharedSecret value before sending out its response.
The encryption and integrity protection keys are computed:
Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys" | ID_S | ID_P)
And the peer generates
Commit_P = Prot(Ke, Ki, Nonce_P),
where Nonce_P is a randomly generated binary string. The length of
Nonce_P MUST be the maximum of 128 bits, and half the key size of the
negotiated prf (rounded up to the next octet if necessary). The peer
sends this value as a protected field (Section 4.3), encrypted using
Ke and integrity protected using Ki with the negotiated encryptiom
Sheffer, et al. Expires October 23, 2010 [Page 16]
Internet-Draft The EAP-EKE Method April 2010
and MAC algorithm.
The server MUST verify the correct integrity protection of the
received nonce, and MUST abort the protocol if it is incorrect, with
an "Authentication Failure" code.
5.3. EAP-EKE-Confirm/Request
The server constructs:
Confirm_S = Prot(Ke, Ki, Nonce_P | Nonce_S),
as a protected field, where Nonce_S is a randomly generated string,
of the same size as Nonce_P.
It computes:
Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P |
Nonce_S)
And constructs:
Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE-
ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response).
The messages are included in full, starting with the EAP header, and
including any possible future extensions.
The server now sends a message that contains the two payloads.
The peer MUST verify the correct integrity protection of the received
nonces and the correctness of the Auth_S value, and MUST abort the
protocol if either is incorrect, with an "Authentication Failure"
code.
5.4. EAP-EKE-Confirm/Response
The peer computes Ka, and sends:
Confirm_P = Prot(Ke, Ki, Nonce_S)
as a protected field, and
Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/
Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response)
The server MUST verify the correct integrity protection of the
received nonce and the correctness of the Auth_P value, and MUST
Sheffer, et al. Expires October 23, 2010 [Page 17]
Internet-Draft The EAP-EKE Method April 2010
abort the protocol if either is incorrect, with an "Authentication
Failure" code.
5.5. MSK and EMSK
Following the last message of the protocol, both sides compute and
export the shared keys, each 512 bits in length:
MSK = prf+(SharedSecret, "EAP-EKE MSK" | ID_S | ID_P | Nonce_P |
Nonce_S)
EMSK = prf+(SharedSecret, "EAP-EKE EMSK" | ID_S | ID_P | Nonce_P |
Nonce_S)
When the RADIUS attributes specified in [RFC2548] are used to
transport keying material, then the first 32 bytes of the MSK
correspond to MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE-
SEND-KEY. In this case, only 64 bytes of keying material (the MSK)
are used.
At this point, both protocol participants MUST discard all
intermediate cryptographic values, including x_p, x_s, y_p, y_s, Ke,
Ki, Ka, SharedSecret. Similarly, both parties MUST immediately
discard these values whenever the protocol terminates with a failure
code or as a result of timeout.
6. Cryptographic Details
6.1. Generating Keying Material
Keying material is derived as the output of the negotiated pseudo-
random function (prf) algorithm. Since the amount of keying material
needed may be greater than the size of the output of the prf
algorithm, we will use the prf iteratively. We denote by "prf+" the
function that outputs a pseudo-random stream based on the inputs to a
prf as follows (where | indicates concatenation):
prf+ (K, S) = T1 | T2 | T3 | T4 | ...
where:
T1 = prf(K, S | 0x01)
T2 = prf(K, T1 | S | 0x02)
T3 = prf(K, T2 | S | 0x03)
T4 = prf(K, T3 | S | 0x04)
continuing as needed to compute all required keys. The keys are
taken from the output string without regard to boundaries (e.g., if
the required keys are a 256-bit Advanced Encryption Standard (AES)
Sheffer, et al. Expires October 23, 2010 [Page 18]
Internet-Draft The EAP-EKE Method April 2010
key and a 160-bit HMAC key, and the prf function generates 160 bits,
the AES key will come from T1 and the beginning of T2, while the HMAC
key will come from the rest of T2 and the beginning of T3).
The constant concatenated to the end of each string feeding the prf
is a single octet. prf+ in this document is not defined beyond 255
times the size of the prf output.
6.2. Diffie-Hellman Groups
Many of the commonly used Diffie Hellman groups are inappropriate for
use in EKE. Most of these groups use a generator which is not a
primitive element of the group. As a result, an attacker running a
dictionary attack would be able to learn at least 1 bit of
information for each decrypted password guess.
Any MODP Diffie Hellman group defined for use in this protocol MUST
have the following properties, to ensure that it does not leak a
usable amount of information about the password:
1. The generator is a primitive element of the group.
2. The most significant 64 bits of the prime number are 1.
3. The group's order p is a "safe prime", i.e. (p-1)/2 is also
prime.
The last requirement is related to the strength of the Diffie Hellman
algorithm, rather than the password encryption. It also makes it
easy to verify that the generator is primitive.
Suitable groups are defined in Section 7.1.
6.3. Mandatory Algorithms
To facilitate interoperability, the following algorithms are
mandatory to implement:
o ENCR_AES128_CBC (encryption algorithm)
o PRF_HMAC_SHA1 (pseudo random function)
o MAC_HMAC_SHA1 (keyed message digest)
o DHGROUP_EKE_14 (DH-group)
7. IANA Considerations
IANA shall allocate (has allocated) the EAP method type TBD, for
"EAP-EKE Version 1". [Note to RFC Editor: insert the IANA-allocated
value here.]
This document requests that IANA create the registries described in
Sheffer, et al. Expires October 23, 2010 [Page 19]
Internet-Draft The EAP-EKE Method April 2010
the following sub-sections. Values (other than private-use ones) can
be added to these registries per Specification Required [RFC5226],
with two exceptions: the Exchange and Failure Code registries can
only be extended per RFC Required [RFC5226].
7.1. Diffie-Hellman Group Registry
This section defines an IANA registry for Diffie-Hellman groups.
This table defines the initial contents of this registry. The Value
column is used when negotiating the group. Additional groups may be
defined through IANA allocation. Any future specification that
defines a non-MODP group MUST specify its use within EAP-EKE and MUST
demonstrate the group's security in this context.
+----------------+--------+---------+-------------------------------+
| Name | Length | Value | Description |
+----------------+--------+---------+-------------------------------+
| Reserved | | 0 | |
| DHGROUP_EKE_2 | 1024 | 1 | The prime number of Group 2 |
| | | | [RFC4306], with the generator |
| | | | 5 (decimal) |
| DHGROUP_EKE_5 | 1536 | 2 | The prime number of Group 5 |
| | | | [RFC3526], g=31 |
| DHGROUP_EKE_14 | 2048 | 3 | The prime number of Group 14 |
| | | | [RFC3526], g=11 |
| DHGROUP_EKE_15 | 3072 | 4 | The prime number of Group 15 |
| | | | [RFC3526], g=5 |
| DHGROUP_EKE_16 | 4096 | 5 | The prime number of Group 16 |
| | | | [RFC3526], g=5 |
| Available for | | 6-127 | |
| allocation via | | | |
| IANA | | | |
| Reserved for | | 128-255 | |
| private use | | | |
+----------------+--------+---------+-------------------------------+
7.2. Encryption Algorithm Registry
This section defines an IANA registry for encryption algorithms:
+-----------------+---------+----------------------------------+
| Name | Value | Definition |
+-----------------+---------+----------------------------------+
| Reserved | 0 | |
| ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode |
| | 2-127 | Available for allocation via IANA|
Sheffer, et al. Expires October 23, 2010 [Page 20]
Internet-Draft The EAP-EKE Method April 2010
| | 128-255 | Reserved for private use |
+-----------------+---------+----------------------------------+
7.3. Pseudo Random Function Registry
This section defines an IANA registry for pseudo random function
algorithms:
+-----------------+---------+-------------------------------------+
| Name | Value | Definition |
+-----------------+---------+-------------------------------------+
| Reserved | 0 | |
| PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] |
| PRF_HMAC_SHA256 | 2 | HMAC SHA-256 |
| | 3-127 | Available for allocation via IANA |
| | 128-255 | Reserved for private use |
+-----------------+---------+-------------------------------------+
A pseudo-random function takes two parameters K and S, and must be
defined for all lengths of K between 0 and 65,535 bits (inclusive).
7.4. Keyed Message Digest (MAC) Registry
This section defines an IANA registry for keyed message digest
algorithms:
+-----------------+---------+-------------------------------------+
| Name | Value | Definition |
+-----------------+---------+-------------------------------------+
| Reserved | 0 | |
| MAC_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] |
| MAC_HMAC_SHA256 | 2 | HMAC SHA-256 |
| | 3-127 | Available for allocation via IANA |
| | 128-255 | Reserved for private use |
+-----------------+---------+-------------------------------------+
7.5. Identity Type Registry
In addition, an identity type registry is defined:
Sheffer, et al. Expires October 23, 2010 [Page 21]
Internet-Draft The EAP-EKE Method April 2010
+-----------+---------+---------------------------------------------+
| Name | Value | Definition |
+-----------+---------+---------------------------------------------+
| Reserved | 0 | |
| ID_OPAQUE | 1 | A printable UTF-8 string whose format is |
| | | undefined |
| ID_NAI | 2 | A Network Access Identifier, as defined in |
| | | [RFC4282] |
| ID_IPv4 | 3 | An IPv4 address, in binary format |
| ID_IPv6 | 4 | An IPv6 address, in binary format |
| ID_FQDN | 5 | A fully qualified domain name |
| | 6-127 | Available for allocation via IANA |
| | 128-255 | Reserved for private use |
+-----------+---------+---------------------------------------------+
7.6. Channel Binding Type Registry
This section defines an IANA registry for the Channel Binding Type
registry, a 16-bit long code. The value 0x0000 has been defined as
Reserved. All other values up to 0xff00 are available for allocation
via IANA. The remaining values up to 0xffff are available for
private use.
7.7. Exchange Registry
This section defines an IANA registry for the EAP-EKE Exchange
registry, an 8-bit long code. Initial values are defined in
Section 4.1. All values up to 0x80 are available for allocation via
IANA. The remaining values up to 0xff are available for private use.
7.8. Failure-Code Registry
This section defines an IANA registry for the Failure-Code registry,
a 32-bit long code. Initial values are defined in Section 4.2.4.
All values up to 0xff000000 are available for allocation via IANA.
The remaining values up to 0xffffffff are available for private use.
8. Security Considerations
Any protocol that claims to solve the problem of password-
authenticated key exchange must be resistant to active, passive and
dictionary attack and have the quality of forward secrecy. These
characteristics are discussed further in the following paragraphs.
Sheffer, et al. Expires October 23, 2010 [Page 22]
Internet-Draft The EAP-EKE Method April 2010
Resistance to Passive Attack A passive 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 information about
the resulting secret shared by the peer and server.
Resistance to Active Attack An active attacker is able to modify,
add, delete, and replay messages sent between protocol
participants. For this protocol to be resistant to active attack,
the attacker must not be able to obtain any information about the
password or the shared secret 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.
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 from a single protocol run
is correct or incorrect.
Forward Secrecy Compromise of the password must not provide any
information about the secrets generated by earlier runs of the
protocol.
[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:
1. Mechanism: password.
2. Claims:
* Mutual authentication: the peer and server both authenticate
each other by proving possession of a shared password. This
is REQUIRED by [RFC4017].
* Forward secrecy: compromise of the password does not reveal
the secret keys (MSK and EMSK) from earlier runs of the
protocol.
* Replay protection: an attacker is unable to replay messages
from a previous exchange either to 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
Sheffer, et al. Expires October 23, 2010 [Page 23]
Internet-Draft The EAP-EKE Method April 2010
successfully completed when it hasn't.
* Key derivation: a shared secret is 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, and the protocol is designed
so that the attacker does not gain any confirmation of her
guess by observing the decrypted Y_x value (see below). 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 attacks and does not enable compromise of subsequent
or prior MSKs or EMSKs from either passive or active attacks.
* Denial of Service resistance: it is possible for an attacker
to cause a server to allocate state and consume CPU. 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-EKE-ID/Request.
* 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-EKE the peer
and server both agree on the MSK and EMSK values. 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 generated
shared secret are all combined to make the authentication
element which must be shared between the peer and server for
the exchange to complete. This is REQUIRED by [RFC4017].
* Fragmentation: this protocol does not define a technique for
fragmentation and reassembly.
* 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.
3. Key strength: the strength of the resulting key depends on the
finite cyclic group chosen. Sufficient key strength is REQUIRED
by [RFC4017]. Clearly, "sufficient" strength varies over time,
depending on computation power assumed to be available to
potential attackers.
4. Key hierarchy: MSKs and EMSKs are derived from the secret values
generated during the protocol run, using a negotiated pseudo-
random function.
Sheffer, et al. Expires October 23, 2010 [Page 24]
Internet-Draft The EAP-EKE Method April 2010
5. Vulnerabilities (note that none of these are REQUIRED by
[RFC4017]):
* Protected ciphersuite negotiation: the ciphersuite proposal
made by the server is not protected from tampering by an
active attacker. However if a proposal was modified by an
active attacker it would result in a failure to confirm the
message sent by the other party, since the proposal is bound
by each side into its Confirm message, and the protocol would
fail as a result. Note that this assumes that none of the
proposed ciphersuites enables an attacker to perform real-time
cryptanalysis.
* Confidentiality: none of the messages sent in this protocol
are encrypted, though many of the protocol fields are.
* Integrity protection: protocol messages are not directly
integrity protected; however the ID and Commit exchanges are
integrity protected through the Auth payloads exchanged in the
Confirm exchange.
* Channel binding: this protocol enables 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-EKE-ID exchange is not protected.
An attacker will see the server's identity in the EAP-EKE-ID/
Request and see the peer's identity in EAP-EKE-ID/ Response.
See also Section 8.4.
8.1. Cryptographic Analysis
When analyzing the Commit exchange, it should be noted that the base
security assumptions are different from "normal" cryptology.
Normally, we assume that the key has strong security properties, and
that the data may have little. Here, we assume that the key has weak
security properties (the attacker may have a list of possible keys),
and hence we need to ensure that the data has strong properties
(indistinguishable from random). This difference may mean that
conventional wisdom in cryptology might not apply in this case. This
also imposes severe constraints on the protocol, e.g. the mandatory
use of random padding, and the need to define specific finite groups.
8.2. Diffie Hellman Group Considerations
It is fundamental to the dictionary attack resistance that the Diffie
Hellman public values y_s and y_p are indistinguishable from a random
string. If this condition is not met, then a passive attacker can do
trial-decryption of the encrypted DHComponent_P or DHComponent_S
Sheffer, et al. Expires October 23, 2010 [Page 25]
Internet-Draft The EAP-EKE Method April 2010
values based on a password guess, and if they decrypt to a value
which is not a valid public value, they know that the password guess
was incorrect.
For MODP groups, Section 6.2 gives conditions on the group to make
sure that this criterion is met. For other groups (for example,
Elliptic Curve groups), some other means of ensuring this must be
employed. The standard way of expressing Elliptic Curve public
values does not meet this criterion, as a valid Elliptic Curve X
coordinate can be distinguished from a random string with probability
approximately 0.5.
A future document might introduce a group representation, and/or a
slight modification of the password encryption scheme, so that
Elliptic Curve groups can be accommodated. [BR02] presents several
alternative solutions for this problem.
8.3. Resistance to Active Attacks
An attacker, impersonating either the peer or the server, can always
try to enumerate all possible passwords, for example by using a
dictionary. To counter this likely attack vector, both peer and
server MUST implement rate-limiting mechanisms. We note that locking
out the other party after a small number of tries would create a
trivial denial of service opportunity.
8.4. Identity Protection, Anonymity and Pseudonymity
By default, the EAP-EKE-ID exchange is unprotected, and an
eavesdropper can observe both parties' identities. A future
extension of this protocol may support anonymity, e.g. by allowing
the server to send a temporary identity to the peer at the end of the
exchange, so that the peer can use that identity in subsequent
exchanges.
EAP-EKE differs in this respect from tunneled methods, which
typically provide unconditional identity protection to the peer by
encrypting the identity exchange, but reveal information in the
server certificate. It is possible to use EAP-EKE as the inner
menthod in a tunnelled EAP method in order to achieve this level of
identity protection.
8.5. Long Term Storage of Passwords
This document recommends to store a password-equivalent (a hash of
the password) instead of the cleartext password. While this solution
provides a measure of security, there are also tradeoffs related to
algorithm agility:
Sheffer, et al. Expires October 23, 2010 [Page 26]
Internet-Draft The EAP-EKE Method April 2010
o Each stored password must identify the pseudo-random function
(prf) that was used to compute the stored value.
o Complex deployments and migration scenarios might necessitate
multiple stored passwords, one per each prf algorithm.
o Changing the prf can require in some cases that the users manually
change their passwords.
9. Acknowledgements
Much of this document was unashamedly picked from
[I-D.harkins-emu-eap-pwd] and [I-D.ietf-pppext-eap-srp-03], and we
would like to acknowledge the authors of these documents: Dan
Harkins, Glen Zorn, James Carlson, Bernard Aboba and Henry Haverinen.
We would like to thank David Jacobson, Steve Bellovin and Russ
Housley for their useful comments. Lidar Herooty and Idan Ofrat
implemented this protocol and helped us improve it by asking the
right questions, and we would like to thank them both.
10. References
10.1. Normative References
[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.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
Sheffer, et al. Expires October 23, 2010 [Page 27]
Internet-Draft The EAP-EKE Method April 2010
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
10.2. Informative References
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange:
Password-Based Protocols Secure Against Dictionary
Attacks", Proc. IEEE Symp. on Research in Security and
Privacy , May 1992.
[BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key
Exchange: A Password-Based Protocol Secure against
Dictionary Attacks and Password File Compromise", Proc.
1st ACM Conference on Computer and Communication
Security , 1993.
[BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure
Password Authenticated Key Exchange Using Diffie-Hellman",
Advances in Cryptology, EUROCRYPT 2000 , 2000.
[BR02] Black, J. and P. Rogaway, "Ciphers with Arbitrary Finite
Domains", Proc. of the RSA Cryptographer's Track (RSA CT
'02), LNCS 2271 , 2002.
[I-D.harkins-emu-eap-pwd]
Harkins, D. and G. Zorn, "EAP Authentication Using Only A
Password", draft-harkins-emu-eap-pwd-14 (work in
progress), April 2010.
[I-D.ietf-pppext-eap-srp-03]
Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1
Authentication Protocol", draft-ietf-pppext-eap-srp-03
(work in progress), July 2001.
[I-D.krawczyk-hkdf]
Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", draft-krawczyk-hkdf-01
(work in progress), January 2010.
[JAB96] Jablon, D., "Strong Password-Only Authenticated Key
Exchange", ACM Computer Communications Review Volume 1,
Issue 5, 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, 1997.
[PA97] Patel, S., "Number Theoretic Attacks On Secure Password
Sheffer, et al. Expires October 23, 2010 [Page 28]
Internet-Draft The EAP-EKE Method April 2010
Schemes", Proceedings of the 1997 IEEE Symposium on
Security and Privacy , 1997.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Appendix A. Change Log
Note to RFC Editor: please remove this section before publication.
A.1. -06
Lots of small changes based on Russ's AD review. Clarified
processing of Channel Binding Values, some of which is currently out
of scope. Made a small but non-backward compatible change to the
generation of Ke, Ki. Changed the rules for nonce lengths (however
this results in no change for the currently specified algorithms).
A.2. -05
Revised the Anonymity section. Added more MODP groups. Note that
DHGROUP_EKE_14 was renumbered.
A.3. -04
Changed the intended document status to Informational.
A.4. -03
Added a provision for channel binding.
Clarified the notation for protected vs. encrypted fields.
Explained how pseudonymity can be provided.
Sheffer, et al. Expires October 23, 2010 [Page 29]
Internet-Draft The EAP-EKE Method April 2010
Implementations need not implement the "password not found" failure.
Eliminated the Design Options appendix.
A.5. -02
Added text from EAP-SIM re: exporting MSK in RADIUS MPPE attributes.
Eliminated protected failures: they are too rarely useful.
Added the "extraction step" of HKDF.
Removed the check for g^x != 0, since this can never happen for an
honest peer, and otherwise requires an active password-guessing
attacker, against which other protections are required. Added a
related subsection about rate limiting.
Added an Exchange Registry to the IANA Considerations.
A general structure for protected (and merely encrypted) fields,
which clarifies the protocol and also adds explicit integrity
protection for the encrypted nonces, as recommended by [BM92].
A.6. -01
Revised following comments raised on the CFRG mailing list. In
particular, added security considerations and a new DH group
definition, to resolve the vulnerability in case the group's
generator is not a primitive element.
A.7. -00
Initial version.
Authors' Addresses
Yaron Sheffer
Independent
Email: yaronf.ietf@gmail.com
Sheffer, et al. Expires October 23, 2010 [Page 30]
Internet-Draft The EAP-EKE Method April 2010
Glen Zorn
Network Zen
1310 East Thomas Street
#306
Seattle, Washington 98102
USA
Phone: +1 (206) 377-9035
Email: gwz@net-zen.net
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Scott Fluhrer
Cisco Systems.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Email: sfluhrer@cisco.com
Sheffer, et al. Expires October 23, 2010 [Page 31]
