One document matched: draft-sheffer-emu-eap-eke-08.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<rfc category="info" ipr="pre5378Trust200902"
docName="draft-sheffer-emu-eap-eke-08">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<front>
<title abbrev="The EAP-EKE Method">An EAP Authentication Method Based on the EKE Protocol</title>
<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
<organization>Independent</organization>
<address>
<email>yaronf.ietf@gmail.com</email>
</address>
</author>
<author fullname="Glen Zorn" initials="G.Z." surname="Zorn">
<organization>Network Zen</organization>
<address>
<postal>
<street>1310 East Thomas Street</street>
<street>#306</street>
<city>Seattle</city>
<region>Washington</region>
<code>98102</code>
<country>USA</country>
</postal>
<phone>+1 (206) 377-9035</phone>
<email>gwz@net-zen.net</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
<organization abbrev="Cisco">Cisco Systems.</organization>
<address>
<postal>
<street>1414 Massachusetts Ave.</street>
<city>Boxborough, MA</city>
<code>01719</code>
<country>USA</country>
</postal>
<email>sfluhrer@cisco.com</email>
</address>
</author>
<date year="2010"/>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<!-- ************************************************************************************ -->
<section title="Introduction">
<t>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.</t>
<t>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.</t>
<t>EAP-EKE is an EAP method <xref target="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 <xref target="BM92"/> and <xref target="BM93"/>.
Subsequently, a number of other solution approaches have been proposed, for example <xref
target="JAB96"/>, <xref target="LUC97"/>, <xref target="BMP00"/>, and others.</t>
<t> This proposal is based on the original Encrypted Key Exchange (EKE) proposal, as described
in <xref target="BM92"/>. Some of the variants of the original EKE have been attacked,
see e.g. <xref target="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 <xref target="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.</t>
</section>
<!-- ************************************************************************************ -->
<section title="Terminology">
<t>
This document uses Encr(Ke, ...) to denote encrypted information, and Prot(Ke, Ki, ...) to denote
encrypted and integrity protected information.
</t>
<t>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
<xref target="RFC2119"/>.</t>
</section>
<!-- ************************************************************************************ -->
<section title="Protocol" anchor="protocol">
<t> 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. </t>
<section title="Message Flows">
<t>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 <xref target="message-flows"/>.</t>
<t>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 (note that the second message of the Commit exchange already plays an essential
part in this liveness proof).</t>
<t>
<figure anchor="message-flows" title="A Successful EAP-EKE Exchange">
<artwork>
<![CDATA[
+--------+ +--------+
| | 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 | |
| |<------------------------------------| |
+--------+ +--------+
]]>
</artwork>
</figure>
</t>
<t> Schematically, the original exchange as described in <xref target="BM92"/> (and with the
roles reversed) is: <figure>
<artwork>
<![CDATA[
Server Peer
------ ----
Encr(Password, y_s) ->
<- Encr(Password, y_p), Encr(SharedSecret, Nonce_P)
Encr(SharedSecret, Nonce_S | Nonce_P) ->
<- Encr(SharedSecret, Nonce_S)
]]>
</artwork>
</figure>
Where:
<list style="symbols">
<t>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.</t>
<t>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).</t>
<t>Nonce_S, Nonce_P are random strings generated by the server and the peer as
cryptographic challenges.</t>
<t>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).</t>
</list>
The current protocol extends the basic cryptographic protocol, and the regular
successful exchange becomes: <figure>
<artwork>
<![CDATA[
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
]]>
</artwork>
</figure>
Where, in addition to the above terminology:
<list style="symbols">
<t>Encr means encryption only, and Prot is encryption with integrity protection.</t>
<t>Ke is an encryption key, Ki an integrity-protection key.</t>
</list>
<xref target="protocol-sequence"/> explains the various cryptographic values and how they are derived.
</t>
<t>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. </t>
</section>
</section>
<!-- ************************************************************************************ -->
<section title="Message Formats">
<t>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.</t>
<t>As usual, all multi-octet strings MUST be laid out in network byte order.</t>
<section anchor="eap-eke-header-sec" title="EAP-EKE Header">
<t>The EAP-EKE header consists of the standard EAP header (see Section 4 of <xref
target="RFC3748"/>), followed an EAP-EKE exchange type. The header has the following
structure:</t>
<t>
<figure anchor="eap-eke-header" title="EAP-EKE Header">
<artwork>
<![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t> The Code, Identifier, Length, and Type fields are all part of the EAP header as
defined in <xref target="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.]</t>
<t> 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: <list
style="symbols">
<t>0x00: Reserved</t>
<t>0x01: EAP-EKE-ID exchange</t>
<t>0x02: EAP-EKE-Commit exchange</t>
<t>0x03: EAP-EKE-Confirm exchange</t>
<t>0x04: EAP-EKE-Failure message</t>
</list></t>
<t>Further values of this EKE-Exch field are available via IANA registration
(<xref target="iana-exchange"/>). </t>
</section>
<section title="EAP-EKE Payloads">
<t>EAP-EKE messages all contain the EAP-EKE header and information encoded
in a single payload, which differs for the different exchanges.</t>
<section title="The EAP-EKE-ID Payload">
<t>
<figure anchor="eap-eke-id-payload" title="EAP-EKE-ID Payload">
<artwork>
<![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>The EAP-EKE-ID payload contains the following fields:</t>
<t>
<list style="hanging">
<t hangText="NumProposals:">
<vspace blankLines="1"/>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.<vspace
blankLines="1"/></t>
<t hangText="Proposal:"><vspace blankLines="1"/>Each proposal consists of four one-octet
fields, in this order: <vspace blankLines="1"/>
<list style="hanging">
<t hangText="Group Description:"><vspace blankLines="1"/>This field's value is taken
from the IANA registry for Diffie-Hellman groups defined in <xref
target="iana-group"/>.<vspace blankLines="1"/></t>
<t hangText="Encryption:"><vspace blankLines="1"/>This field's value is taken from
the IANA registry for encryption algorithms defined in <xref target="iana-enc"
/>.<vspace blankLines="1"/></t>
<t hangText="PRF:"><vspace blankLines="1"/>This field's value is taken from the IANA
registry for pseudo random functions defined in <xref target="iana-prf"/>.<vspace
blankLines="1"/></t>
<t hangText="MAC:"><vspace blankLines="1"/>This field's value is taken from the IANA
registry for keyed message digest algorithms defined in <xref target="iana-mac"/>.
<vspace blankLines="1"/></t>
</list></t>
<t hangText="Reserved:"><vspace blankLines="1"/>This field MUST be sent as zero,
and MUST be ignored by the recipient.<vspace blankLines="1"/></t>
<t hangText="IDType:"><vspace blankLines="1"/>Denotes the Identity Type. This is taken
from the IANA registry defined in <xref target="iana-identity"/>. 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.
<vspace blankLines="1"/></t>
<t hangText="Identity:"><vspace blankLines="1"/>The meaning of the Identity field depends
on the values of the Code
and IDType fields.
<list style="symbols">
<t>EAP-EKE-ID/Request: server ID</t>
<t>EAP-EKE-ID/Response: peer ID</t>
</list>
</t>
<t>The length of the Identity field is computed from the Length field in the EAP header.
Specifically, its length is
<list style="empty">
<t>eap_header_length - 9 - 4 * number_of_proposals.</t>
</list>
This field, like all other fields in this specification, MUST be octet-aligned.</t>
</list>
</t>
</section>
<section title="The EAP-EKE-Commit Payload">
<t>This payload allows both parties send their encrypted ephemeral public key, with the peer
also including a Challenge.</t>
<t>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.</t>
<t>
<figure anchor="eap-eke-commit-payload" title="EAP-EKE-Commit Payload">
<artwork>
<![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNonce_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBValue (zero or more occurrences) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>
<list style="hanging">
<t hangText="DHComponent_S/DHComponent_P:">
<vspace blankLines="1"/>This field contains the password-encrypted Diffie-Hellman
public key, see <xref target="commit-request"/>.
Its size is determined by the group and the encryption algorithm.<vspace blankLines="1"/></t>
<t hangText="PNonce_P:">
<vspace blankLines="1"/>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 <xref target="commit-response"/>.<vspace blankLines="1"/></t>
<t hangText="CBValue:">
<vspace blankLines="1"/>This structure MAY be included both in the request and in
the response, and MAY be repeated multiple times in a single payload.
See <xref target="channel-bindings"/>. Each structure contains its own length.
The field is neither encrypted nor integrity protected, instead it is protected by the
AUTH payloads in the Confirm exchange.
</t>
</list>
</t>
</section>
<section title="The EAP-EKE-Confirm Payload">
<t>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.</t>
<t>
<figure anchor="eap-eke-confirm-payload" title="EAP-EKE-Confirm Payload">
<artwork>
<![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNonce_PS/PNonce_S ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth_S/Auth_P ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>
<list style="hanging">
<t hangText="PNonce_PS/PNonce_S:">
<vspace blankLines="1"/>This field ("protected nonce") contains the encrypted and integrity-protected
response to the other party's
challenge, see <xref target="confirm-request"/> and <xref target="confirm-response"
/>. Similarly to the PNonce_P field, this field's size is determined by the encryption
and MAC algorithms.<vspace blankLines="1"/></t>
<t hangText="Auth_S/Auth_P:">
<vspace blankLines="1"/>This field signs the preceding messages,
including the Identity and the negotiated fields. This prevents various possible attacks,
such as
algorithm downgrade attacks. See <xref target="confirm-request"/> and <xref
target="confirm-response"/>. The size is determined by the
pseudo-random function negotiated.</t>
</list>
</t>
</section>
<section anchor="eap-eke-failure" title="The EAP-EKE-Failure Payload">
<t> The EAP-EKE-Failure payload format is defined as follows: <figure
anchor="eap-eke-failure-payload" title="EAP-EKE-Failure Payload">
<artwork>
<![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>The payload's size is always exactly 4 octets.</t>
<t>The following Failure-Code values are defined:</t>
<texttable>
<ttcol>Value</ttcol>
<ttcol>Name</ttcol>
<ttcol>Meaning</ttcol>
<c>0x00000000</c><c>Reserved</c><c></c>
<c>0x00000001</c><c>No Error</c><c>This code is used for failure acknowledgement, see below.</c>
<c>0x00000002</c><c>Protocol Error</c><c>A failure to parse or understand a protocol message or one
of its payloads.</c>
<c>0x00000003</c><c>Password Not Found</c><c>A password
could not be located for 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.</c>
<c>0x00000004</c><c>Authentication Failure</c><c>Failure in the cryptographic
computation most likely caused by an incorrect password, or an inappropriate identity type.</c>
<c>0x00000005</c><c>Authorization Failure</c><c>
While the password being used is correct, the user is not authorized to connect.</c>
<c>0x00000006</c><c>No Proposal Chosen</c><c>The peer is unwilling to select any of the
cryptographic proposals offered by the server.</c>
</texttable>
<t>Additional values of this field are available via IANA registration, see
<xref target="iana-failure"/>. </t>
<t>
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.
</t>
<t>
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 EAP-Failure message to end the exchange.
</t>
</section>
</section>
<section anchor="protected-fields-sec" title="Protected Fields">
<t>Several fields are encrypted and integrity-protected.
They are denoted Prot(...).
Their general structure is as follows:</t>
<t>
<figure anchor="protected-field" title="Protected Field Structure">
<artwork>
<![CDATA[
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>The protected field is a concatenation of three octet strings:</t>
<t>
<list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<t>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.</t>
</section>
<section anchor="encrypted-fields-sec" title="Encrypted Fields">
<t>
Two fields are encrypted but not integrity protected. They are denoted Encr(...).
Their format is identical to
a protected field (<xref target="protected-fields-sec"/>),
except that the Integrity Check Value is omitted.
</t>
</section>
<section anchor="channel-bindings" title="Channel Binding Values">
<t>
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. See
Sec. 7.15 of <xref target="RFC3748"/> for more on the rationale behind this facility.</t>
<t>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.
</t>
<t>An unknown Channel Binding Value SHOULD be ignored by the recipient. </t>
<t>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.</t>
<t>Each Channel Binding Value is encoded using a simple TLV structure:</t>
<t>
<figure anchor="cb-payload" title="Channel Binding Value">
<artwork>
<![CDATA[
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
</t>
<t>
<list style="hanging">
<t hangText="CBType:">
<vspace blankLines="1"/>This is the Channel Binding Value's type. This document defines
the value 0x0000 as reserved. Other values are available for IANA allocation,
see <xref target="iana-cbtype"/>.
<vspace blankLines="1"/></t>
<t hangText="Length:">
<vspace blankLines="1"/>This field is the total length in octets of the
structure, including the CBType and Length fields.</t>
</list>
</t>
<t>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
<xref target="RFC5209"/>.</t>
</section>
</section>
<!-- ************************************************************************************ -->
<section anchor="protocol-sequence" title="Protocol Sequence">
<t>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.</t>
<section anchor="commit-request" title="EAP-EKE-Commit/Request">
<t>The server computes </t>
<t>
<list style="empty">
<t>y_s = g ^ x_s (mod p),</t>
</list>
</t>
<t>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.</t>
<t>The server transmits the encrypted field (<xref target="encrypted-fields-sec"/>)</t>
<t>
<list style="empty">
<t>DHComponent_S = Encr(kmac+(password), y_s).</t>
</list>
</t>
<t>See <xref target="key-from-password"/> for the kmac+ notation. The first output octets of kmac+ are
used as the encryption key for the negotiated encryption algorithm, according to that algorithm's key length.</t>
<t>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 <xref target="RFC4086"/>, and see also <xref target="NIST.800-90.2007"/> for additional recommendations
on cryptographic-level randomness.
When decrypting this field, the real length of
y_s is determined according to the negotiated Diffie Hellman group.</t>
<t>If the password needs to be stored on the server, it is RECOMMENDED to store the
randomized password value, i.e. kmac+(password, ...), as a password-equivalent, rather than
the cleartext password. See also <xref target="password-equivalent"/>.</t>
<t>
The input password string SHOULD be processed according to the
rules of the <xref target="RFC4013"/> profile of <xref target="RFC3454"/>.
A password SHOULD be
considered a "stored string" per <xref target="RFC3454"/> and unassigned code
points are therefore prohibited. The output is the binary
representation of the processed UTF-8 <xref target="RFC3629"/> character string.
Prohibited output and unassigned codepoints encountered in
SASLprep preprocessing SHOULD cause a preprocessing failure
and the output SHOULD NOT be used.
</t>
</section>
<section anchor="commit-response" title="EAP-EKE-Commit/Response">
<t>The peer computes</t>
<t>
<list style="empty">
<t>y_p = g ^ x_p (mod p)</t>
</list>
</t>
<t>and sends</t>
<t>
<list style="empty">
<t>DHComponent_P = Encr(kmac+(password), y_p)</t>
</list>
</t>
<t>formatted as an encrypted field (<xref target="encrypted-fields-sec"/>).
</t>
<t>Both sides calculate </t>
<t>
<list style="empty">
<t>SharedSecret = prf(0+, g ^ (x_s * x_p) (mod p))</t>
</list>
</t>
<t>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).
This extra
application of the pseudo-random function is the "extraction step" of
<xref target="RFC5869"/>. Note that the peer needs to compute the SharedSecret value
before sending out its response.
</t>
<t>
The encryption and integrity protection keys are computed: </t>
<t>
<list style="empty">
<t>Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys" | ID_S | ID_P)</t>
</list>
</t>
<t>And the peer generates the Protected Nonce: </t>
<t>
<list style="empty">
<t>PNonce_P = Prot(Ke, Ki, Nonce_P),</t>
</list>
</t>
<t>where Nonce_P is a randomly generated binary string.
The length of Nonce_P MUST be the maximum of 16 octets,
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 (<xref target="protected-fields-sec"/>),
encrypted using Ke and integrity protected using Ki with the negotiated encryption
and MAC algorithm.</t>
<t>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.</t>
</section>
<section anchor="confirm-request" title="EAP-EKE-Confirm/Request">
<t>The server constructs:</t>
<t>
<list style="empty">
<t>PNonce_PS = Prot(Ke, Ki, Nonce_P | Nonce_S),</t>
</list>
</t>
<t>as a protected field, where Nonce_S is a randomly generated string,
of the same size as Nonce_P.</t>
<t>It computes: </t>
<t>
<list style="empty">
<t>Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P | Nonce_S)</t>
</list>
</t>
<t>whose length is the preferred key length of the negotiated prf
(see <xref target="commit-response"/>). It then constructs:</t>
<t>
<list style="empty">
<t>Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE-ID/Response |
EAP-EKE-Commit/Request | EAP-EKE-Commit/Response).</t>
</list>
</t>
<t>The messages are
included in full, starting with the EAP header, and including any possible future
extensions. </t>
<t>This construction of the Auth_S (and Auth_P) value implies that any future extensions MUST NOT be added
to the EAP-EKE-Confirm/Request or EAP-EKE-Confirm/Response messages themselves, unless these
extensions are integrity-protected in some other manner.</t>
<t>The server now sends a message that contains the two payloads.</t>
<t>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.</t>
</section>
<section anchor="confirm-response" title="EAP-EKE-Confirm/Response">
<t>The peer computes Ka, and sends:</t>
<t>
<list style="empty">
<t>PNonce_S = Prot(Ke, Ki, Nonce_S)</t>
</list>
</t>
<t>as a protected field, and</t>
<t>
<list style="empty">
<t>Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/Response |
EAP-EKE-Commit/Request | EAP-EKE-Commit/Response)</t>
</list>
</t>
<t>The server MUST verify the correct integrity protection of the received nonce and
the correctness of the Auth_P value,
and MUST abort the protocol if either is incorrect, with an "Authentication Failure" code.</t>
</section>
<section title="MSK and EMSK">
<t>Following the last message of the protocol, both sides compute and export the shared
keys, each 64 bytes in length:</t>
<t>
<list style="empty">
<t>MSK | EMSK = prf+(SharedSecret, "EAP-EKE Exported Keys" | ID_S | ID_P | Nonce_P | Nonce_S)</t>
</list>
</t>
<t>
When the RADIUS attributes specified in <xref target="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.
</t>
<t>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.</t>
</section>
</section>
<!-- ************************************************************************************ -->
<section title="Cryptographic Details">
<section anchor="key-from-password" title="Deriving a Key from the Password">
<t>The negotiated keyed MAC algorithm is used as a hash function, to derive a bit string (albeit with low entropy)
from the password. If "kmac" is the negotiated algorithm, we define:</t>
<t>
<list style="empty">
<t>kmac+(P) = T1 | T2 | ...</t>
</list>
</t>
<t>where each Ti is an application of the keyed MAC with a fixed key:</t>
<t>
<list style="empty">
<t>T1 = kmac("S"+, P | 0x01)</t>
<t>T2 = kmac("S"+, T1 | P | 0x02)</t>
<t>T3 = kmac("S"+, T2 | P | 0x03)</t>
</list>
</t>
<t>The key is a string containing the octet ASCII "S" (0x53) repeated
N times, where N is the key length of the algorithm.
Similarly to prf+ (<xref target="gen-key-material"/>), The keys are taken from the output
string without regard to boundaries.</t>
</section>
<section anchor="gen-key-material" title="Generating Keying Material">
<t>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):</t>
<t>
<list style="empty">
<t>prf+ (K, S) = T1 | T2 | T3 | T4 | ...</t>
</list>
</t>
<t> where: <list style="empty">
<t>T1 = prf(K, S | 0x01)</t>
<t>T2 = prf(K, T1 | S | 0x02)</t>
<t>T3 = prf(K, T2 | S | 0x03)</t>
<t>T4 = prf(K, T3 | S | 0x04)</t>
</list>
</t>
<t> 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) 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). </t>
<t> 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. </t>
</section>
<section anchor="dh-groups" title="Diffie-Hellman Groups">
<t>
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.
</t>
<t>
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:
<list style="numbers">
<t>The generator is a primitive element of the group.</t>
<t>The most significant 64 bits of the prime number are 1.</t>
<t>The group's order p is a "safe prime", i.e. (p-1)/2 is also prime.
</t>
</list>
</t>
<t>
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.
</t>
<t>Suitable groups are defined in <xref target="iana-group"/>.</t>
</section>
<section title="Mandatory Algorithms">
<t>To facilitate interoperability, the following algorithms are mandatory to implement:</t>
<t>
<list style="symbols">
<t>ENCR_AES128_CBC (encryption algorithm)</t>
<t>PRF_HMAC_SHA1 (pseudo random function)</t>
<t>MAC_HMAC_SHA1 (keyed message digest)</t>
<t>DHGROUP_EKE_14 (DH-group)</t>
</list>
</t>
</section>
</section>
<!-- ************************************************************************************ -->
<section title="IANA Considerations" anchor="iana">
<t>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.]</t>
<t>This document requests that IANA create the registries described in the following sub-sections.
Values (other than private-use ones) can be added to these registries per
Specification Required <xref target="RFC5226"/>, with two exceptions:
the Exchange and Failure Code registries can only be extended per
RFC Required <xref target="RFC5226"/>.</t>
<section toc="exclude" anchor="iana-group" title="Diffie-Hellman Group Registry">
<t>This section defines an IANA registry for Diffie-Hellman groups.
</t>
<t>
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.
</t>
<texttable>
<ttcol>Name</ttcol>
<ttcol>Length</ttcol>
<ttcol>Value</ttcol>
<ttcol>Description</ttcol>
<c>Reserved</c>
<c></c>
<c>0</c>
<c></c>
<c>DHGROUP_EKE_2</c>
<c>1024</c>
<c>1</c>
<c>The prime number of Group 2 <xref target="RFC4306"/>, with the generator 5 (decimal)</c>
<c>DHGROUP_EKE_5</c>
<c>1536</c>
<c>2</c>
<c>The prime number of Group 5 <xref target="RFC3526"/>, g=31</c>
<c>DHGROUP_EKE_14</c>
<c>2048</c>
<c>3</c>
<c>The prime number of Group 14 <xref target="RFC3526"/>, g=11</c>
<c>DHGROUP_EKE_15</c>
<c>3072</c>
<c>4</c>
<c>The prime number of Group 15 <xref target="RFC3526"/>, g=5</c>
<c>DHGROUP_EKE_16</c>
<c>4096</c>
<c>5</c>
<c>The prime number of Group 16 <xref target="RFC3526"/>, g=5</c>
<c>Available for allocation via IANA</c>
<c></c>
<c>6-127</c>
<c></c>
<c>Reserved for private use</c>
<c></c>
<c>128-255</c>
<c></c>
</texttable>
</section>
<section toc="exclude" anchor="iana-enc" title="Encryption Algorithm Registry">
<t>This section defines an IANA registry for encryption algorithms:</t>
<texttable>
<ttcol>Name</ttcol>
<ttcol>Value</ttcol>
<ttcol>Definition</ttcol>
<c>Reserved</c><c>0</c><c></c>
<c>ENCR_AES128_CBC</c><c>1</c><c>AES with a 128-bit key, CBC mode</c>
<c></c><c>2-127</c><c>Available for allocation via IANA</c>
<c></c><c>128-255</c><c>Reserved for private use</c>
</texttable>
</section>
<section toc="exclude" anchor="iana-prf" title="Pseudo Random Function Registry">
<t>This section defines an IANA registry for pseudo random function algorithms: </t>
<texttable>
<ttcol>Name</ttcol>
<ttcol>Value</ttcol>
<ttcol>Definition</ttcol>
<c>Reserved</c><c>0</c><c></c>
<c>PRF_HMAC_SHA1</c><c>1</c><c>HMAC SHA-1, as defined in <xref target="RFC2104"/></c>
<c>PRF_HMAC_SHA2_256</c><c>2</c><c>HMAC SHA-2-256 <xref target="SHA"/></c>
<c></c><c>3-127</c><c>Available for allocation via IANA</c>
<c></c><c>128-255</c><c>Reserved for private use</c>
</texttable>
<t>A pseudo-random function takes two parameters K and S (the key and input string respectively),
and, to be usable in this context, must be defined for all lengths
of K between 0 and 65,535 bits (inclusive).</t>
</section>
<section toc="exclude" anchor="iana-mac" title="Keyed Message Digest (MAC) Registry">
<t>This section defines an IANA registry for keyed message digest algorithms:</t>
<texttable>
<ttcol>Name</ttcol>
<ttcol>Value</ttcol>
<ttcol>Key Length (Octets)</ttcol>
<ttcol>Definition</ttcol>
<c>Reserved</c><c>0</c><c></c><c></c>
<c>MAC_HMAC_SHA1</c><c>1</c><c>20</c><c>HMAC SHA-1, as defined in <xref target="RFC2104"/></c>
<c>MAC_HMAC_SHA2_256</c><c>2</c><c>32</c><c>HMAC SHA-2-256</c>
<c>Reserved</c><c>3-127</c><c></c><c>Available for allocation via IANA</c>
<c>Reserved</c><c>128-255</c><c></c><c>Reserved for private use</c>
</texttable>
</section>
<section toc="exclude" anchor="iana-identity" title="Identity Type Registry">
<t>In addition, an identity type registry is defined: <figure>
<artwork>
<![CDATA[
+-----------+---------+---------------------------------------------+
| Name | Value | Definition |
+-----------+---------+---------------------------------------------+
| Reserved | 0 | |
| ID_OPAQUE | 1 | An opaque octet string |
| 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, see note |
| | | below |
| | 6-127 | Available for allocation via IANA |
| | 128-255 | Reserved for private use |
+-----------+---------+---------------------------------------------+
]]>
</artwork>
</figure>
</t>
<t>
An example of a ID_FQDN
is "example.com". The string MUST NOT contain any terminators
(e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
for an "internationalized domain name", the syntax is as defined
in <xref target="RFC5891"/>, for example "xn--tmonesimerkki-bfbb.example.net".
</t>
</section>
<section toc="exclude" anchor="iana-cbtype" title="EAP-EKE Channel Binding Type Registry">
<t>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 and including 0xfeff are
available for allocation via IANA. The remaining values
up to and including 0xffff are available for private use.
</t>
</section>
<section toc="exclude" anchor="iana-exchange" title="Exchange Registry">
<t>This section defines an IANA registry for the EAP-EKE Exchange registry, an 8-bit long code.
Initial values are defined in <xref target="eap-eke-header-sec"/>. All values up to and including 0x7f are
available for allocation via IANA. The remaining values
up to and including 0xff are available for private use.
</t>
</section>
<section toc="exclude" anchor="iana-failure" title="Failure-Code Registry">
<t>This section defines an IANA registry for the Failure-Code registry, a 32-bit long code.
Initial values are defined in <xref target="eap-eke-failure"/>. All values up to and including 0xfeffffff are
available for allocation via IANA. The remaining values
up to and including 0xffffffff are available for private use.
</t>
</section>
</section>
<!-- ************************************************************************************ -->
<section title="Security Considerations" anchor="security">
<t>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.</t>
<t>
<list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Forward Secrecy"> Compromise of the password must not provide any information
about the secrets generated by earlier runs of the protocol.</t>
</list>
</t>
<t>
<xref target="RFC3748"/> requires that documents describing new EAP methods clearly
articulate the security properties of the method. In addition, for use with wireless LANs,
<xref target="RFC4017"/> mandates and recommends several of these. The claims are: <list
style="numbers">
<t>Mechanism: password.</t>
<t>Claims: <list style="symbols">
<t>Mutual authentication: the peer and server both authenticate each other by proving
possession of a shared password. This is REQUIRED by <xref target="RFC4017"/>.</t>
<t>Forward secrecy: compromise of the password does not reveal the secret keys (MSK
and EMSK) from earlier runs of the protocol.</t>
<t>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 successfully completed when it hasn't.</t>
<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 <xref target="RFC4017"/>.</t>
<t>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 <xref target="RFC4017"/>.</t>
<t>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.</t>
<t>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.</t>
<t>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
<xref target="RFC4017"/>.</t>
<t>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 <xref target="RFC4017"/>.</t>
<t>Fragmentation: this protocol does not define a technique for fragmentation and
reassembly.</t>
<t>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.</t>
</list></t>
<t>Key strength: the strength of the resulting key depends on the finite cyclic group
chosen. Sufficient key strength is REQUIRED by <xref target="RFC4017"/>.
Clearly, "sufficient" strength varies over time, depending on computation power
assumed to be available to potential attackers.
</t>
<t>Key hierarchy: MSKs and EMSKs are derived from the secret values generated during the
protocol run, using a negotiated pseudo-random function.</t>
<t>Vulnerabilities (note that none of these are REQUIRED by <xref target="RFC4017"/>):
<list style="symbols">
<t>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.</t>
<t>Confidentiality: none of the messages sent in this protocol are encrypted,
though many of the protocol fields are.</t>
<t>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.</t>
<t>Channel binding: this protocol enables the exchange of integrity-protected
channel information that can be compared with values communicated via out-of-band
mechanisms.</t>
<t>Fast reconnect: this protocol does not provide a fast reconnect capability.</t>
<t>Cryptographic binding: this protocol is not a tunneled EAP method and therefore has
no cryptographic information to bind.</t>
<t>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 <xref target="id-protection"/>.</t>
</list></t>
</list></t>
<!--
<t>Here's a few, more to come:</t>
<t>
<list style="symbols">
<t>No identity protection.</t>
<t>Denial-of-service resistance, e.g. an anti clogging token.</t>
<t>Binding of EAP-EKE identity with EAP identity.</t>
</list>
</t>
-->
<section title="Cryptographic Analysis">
<t>
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.
</t>
</section>
<section title="Diffie Hellman Group Considerations">
<t>
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 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.
</t>
<t>
For MODP groups, <xref target="dh-groups"/> 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.
</t>
<t>
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. <xref target="BR02"/> presents several alternative solutions for this problem.
</t>
</section>
<section title="Resistance to Active Attacks">
<t>
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.
</t>
</section>
<section anchor="id-protection" title="Identity Protection, Anonymity and Pseudonymity">
<t>
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.
</t>
<t>
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 method in a tunneled EAP method in
order to achieve this level of identity protection.
</t>
</section>
<section anchor="password-equivalent" title="Password Processing and Long Term Storage">
<t>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:
<list style="symbols">
<t>Each stored password must identify the hash function that was used
to compute the stored value.</t>
<t>Complex deployments and migration scenarios might necessitate multiple stored passwords,
one per each algorithm.</t>
<t>Changing the algorithm can require in some cases that the users manually change their passwords.</t>
</list>
</t>
<t>The reader is referred to <xref target="RFC3629"/> for security considerations related to the parsing and processing of
UTF-8 strings.</t>
</section>
</section>
<!-- ************************************************************************************ -->
<section title="Acknowledgements">
<t>Much of this document was unashamedly picked from <xref target="RFC5931"/>
and <xref target="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, Russ Housley,
Brian Weis, Dan Harkins and Alexey Melnikov 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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2104.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2548.xml"?>
<?rfc include="reference.RFC.3454.xml"?>
<?rfc include="reference.RFC.3526.xml"?>
<?rfc include="reference.RFC.3629.xml"?>
<?rfc include="reference.RFC.4013.xml"?>
<?rfc include="reference.RFC.3748.xml"?>
<?rfc include="reference.RFC.4306.xml"?>
<?rfc include="reference.RFC.4282.xml"?>
<?rfc include="reference.RFC.5891.xml"?>
<reference anchor="SHA">
<front>
<title>Secure Hash Standard</title>
<author>
<organization>National Institute of Standards and Technology, U.S. Department of Commerce</organization>
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="NIST" value="FIPS 180-3" />
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4017.xml"?>
<?rfc include="reference.RFC.4086.xml"?>
<?rfc include="reference.RFC.5209.xml"?>
<?rfc include="reference.RFC.5226.xml"?>
<?rfc include="reference.RFC.5869.xml"?>
<?rfc include="reference.RFC.5931.xml"?>
<reference
anchor="I-D.ietf-pppext-eap-srp-03">
<front>
<title>EAP SRP-SHA1 Authentication Protocol</title>
<author initials="J." surname="Carlson" fullname="James Carlson">
<organization/>
</author>
<author initials="B." surname="Aboba" fullname="Bernard Aboba">
<organization/>
</author>
<author initials="H." surname="Haverinen" fullname="Henry Haverinen">
<organization/>
</author>
<date month="July" year="2001"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pppext-eap-srp-03"/>
</reference>
<reference anchor="BM92">
<front>
<title>Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks</title>
<author initials="S." surname="Bellovin" fullname="Steven M. Bellovin">
<organization/>
</author>
<author initials="M." surname="Merritt" fullname="Michael Merritt">
<organization/>
</author>
<date month="May" year="1992"/>
</front>
<seriesInfo name="Proc. IEEE Symp. on Research in Security and Privacy" value=""/>
</reference>
<reference anchor="BM93">
<front>
<title>Augmented Encrypted Key Exchange: A Password-Based Protocol Secure against
Dictionary Attacks and Password File Compromise</title>
<author initials="S." surname="Bellovin" fullname="Steven M. Bellovin">
<organization/>
</author>
<author initials="M." surname="Merritt" fullname="Michael Merritt">
<organization/>
</author>
<date year="1993"/>
</front>
<seriesInfo name="Proc. 1st ACM Conference on Computer and Communication Security" value=""
/>
</reference>
<reference anchor="BMP00">
<front>
<title>Provably Secure Password Authenticated Key Exchange Using Diffie-Hellman</title>
<author initials="V." surname="Boyko" fullname="Victor Boyko">
<organization/>
</author>
<author initials="P." surname="MacKenzie" fullname="Philip MacKenzie">
<organization/>
</author>
<author initials="S." surname="Patel" fullname="Sarvar Patel">
<organization/>
</author>
<date year="2000"/>
</front>
<seriesInfo name="Advances in Cryptology, EUROCRYPT 2000"
value=""/>
</reference>
<reference anchor="BR02">
<front>
<title>Ciphers with Arbitrary Finite Domains</title>
<author initials="J." surname="Black" fullname="John Black">
<organization/>
</author>
<author initials="P." surname="Rogaway" fullname="Phillip Rogaway">
<organization/>
</author>
<date year="2002"/>
</front>
<seriesInfo name="Proc. of the RSA Cryptographer's Track (RSA CT '02), LNCS 2271"
value=""/>
</reference>
<reference anchor="PA97">
<front>
<title>Number Theoretic Attacks On Secure Password Schemes</title>
<author initials="S." surname="Patel" fullname="Sarvar Patel">
<organization/>
</author>
<date year="1997"/>
</front>
<seriesInfo name="Proceedings of the 1997 IEEE Symposium on Security and Privacy"
value=""/>
</reference>
<reference anchor="JAB96">
<front>
<title>Strong Password-Only Authenticated Key Exchange</title>
<author initials="D." surname="Jablon" fullname="David P. Jablon">
<organization/>
</author>
<date month="October" year="1996"/>
</front>
<seriesInfo name="ACM Computer Communications Review" value="Volume 1, Issue 5"/>
</reference>
<reference anchor="LUC97">
<front>
<title>Open Key Exchange: How to Defeat Dictionary Attacks Without
Encrypting Public Keys</title>
<author initials="S." surname="Lucks" fullname="Stefan Lucks">
<organization/>
</author>
<date year="1997"/>
</front>
<seriesInfo name="Proc. of the Security Protocols Workshop" value="LNCS 1361"/>
</reference>
<reference anchor="NIST.800-90.2007">
<front>
<title>Recommendation for Random Number Generation Using
Deterministic Random Bit Generators (Revised)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="March" year="2007" />
</front>
<seriesInfo name="NIST" value="SP 800-90" />
</reference>
</references>
<section title="Change Log">
<t>Note to RFC Editor: please remove this section before publication.</t>
<section toc="exclude" title="-08">
<t>Implemented Alexey Melnikov's "discuss" comments.</t>
</section>
<section toc="exclude" title="-07">
<t>Implemented IETF LC review comments, primarily from Dan Harkins. Changed the derivation
of an encryption key from the plaintext password. Changed the derivation of EMSK for efficiency.
Clarified the ranges of IANA allocations, and added a key length column for keyed MAC algorithms.
Renamed some protocol fields for clarity.</t>
</section>
<section toc="exclude" title="-06">
<t>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).
</t>
</section>
<section toc="exclude" title="-05">
<t>Revised the Anonymity section. Added more
MODP groups. Note that DHGROUP_EKE_14 was renumbered.</t>
</section>
<section toc="exclude" title="-04">
<t>Changed the intended document status to Informational.</t>
</section>
<section toc="exclude" title="-03">
<t>Added a provision for channel binding.</t>
<t>Clarified the notation for protected vs. encrypted fields.</t>
<t>Explained how pseudonymity can be provided.</t>
<t>Implementations need not implement the "password not found" failure.</t>
<t>Eliminated the Design Options appendix.</t>
</section>
<section toc="exclude" title="-02">
<t>Added text from EAP-SIM re: exporting MSK in RADIUS MPPE attributes.</t>
<t>Eliminated protected failures: they are too rarely useful.</t>
<t>Added the "extraction step" of HKDF.</t>
<t>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.</t>
<t>Added an Exchange Registry to the IANA Considerations.</t>
<t>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 <xref target="BM92"/>.</t>
</section>
<section toc="exclude" title="-01">
<t>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.</t>
</section>
<section toc="exclude" title="-00">
<t>Initial version.</t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:05:21 |