Network Working Group                                         Y. Sheffer
Internet-Draft                                               Check Point
Intended status: Standards Track                                 G. Zorn
Expires: January 7, 2010                                     Network Zen
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                              S. Fluhrer
                                                                   Cisco
                                                            July 6, 2009


         An EAP Authentication Method Based on the EKE Protocol
                      draft-sheffer-emu-eap-eke-02

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 7, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.




Sheffer, et al.          Expires January 7, 2010                [Page 1]


Internet-Draft             The EAP-EKE Method                  July 2009


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.











































Sheffer, et al.          Expires January 7, 2010                [Page 2]


Internet-Draft             The EAP-EKE Method                  July 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Protocol Overview  . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Message Flows  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  EAP-EKE Header . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  EAP-EKE Payloads . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  EAP-EKE-ID . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.4.  EAP-EKE-Commit . . . . . . . . . . . . . . . . . . . . . .  9
     4.5.  EAP-EKE-Confirm  . . . . . . . . . . . . . . . . . . . . . 10
     4.6.  EAP-EKE-Failure  . . . . . . . . . . . . . . . . . . . . . 11
     4.7.  Protected Fields . . . . . . . . . . . . . . . . . . . . . 12
     4.8.  Encrypted Fields . . . . . . . . . . . . . . . . . . . . . 12
   5.  Cryptographic Operations . . . . . . . . . . . . . . . . . . . 13
     5.1.  Generating Keying Material . . . . . . . . . . . . . . . . 13
     5.2.  EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 13
     5.3.  EAP-EKE-Commit/Response  . . . . . . . . . . . . . . . . . 14
     5.4.  EAP-EKE-Confirm/Request  . . . . . . . . . . . . . . . . . 15
     5.5.  EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 15
     5.6.  MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 16
     5.7.  Diffie-Hellman Groups  . . . . . . . . . . . . . . . . . . 16
     5.8.  Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 16
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
     7.1.  Cryptographic Analysis . . . . . . . . . . . . . . . . . . 22
     7.2.  Diffie Hellman Group Considerations  . . . . . . . . . . . 22
     7.3.  Resistance to Active Attacks . . . . . . . . . . . . . . . 23
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 24
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 25
     A.1.  -02  . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     A.2.  -01  . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     A.3.  -00  . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
   Appendix B.  Design Options  . . . . . . . . . . . . . . . . . . . 26
     B.1.  Number of Round Trips  . . . . . . . . . . . . . . . . . . 26
     B.2.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26









Sheffer, et al.          Expires January 7, 2010                [Page 3]


Internet-Draft             The EAP-EKE Method                  July 2009


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 has 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)
   which has withstood the test of time and is believed secure as of
   this writing.


2.  Terminology

   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].


3.  Protocol

3.1.  Protocol Overview

   EAP is a two-party protocol spoken between an EAP peer and an EAP
   server (also known as "authenticator").  An EAP method defines the



Sheffer, et al.          Expires January 7, 2010                [Page 4]


Internet-Draft             The EAP-EKE Method                  July 2009


   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.2.  Message Flows

   EAP-EKE defines three message exchanges: an Identity exchange, a
   Commit exchange and a Confirm exchange.  A successful authentication
   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                |        |
              |        |<------------------------------------|        |
              +--------+                                     +--------+



                  Figure 1: A Successful EAP-EKE Exchange




Sheffer, et al.          Expires January 7, 2010                [Page 5]


Internet-Draft             The EAP-EKE Method                  July 2009


   Schematically, the original exchange as described in [BM92] (and with
   the roles reversed) is:


   Server                              Peer
   ------                              ----

   E(Password, Y_S)) ->

                         <- E(Password, Y_P), E(SharedSecret, Nonce_P)

   E(SharedSecret, Nonce_S | Nonce_P) ->

                                           <- E(SharedSecret, Nonce_S)


   Where:
   o  Y_S and Y_P are the server's (and respectively, the peer's)
      ephemeral public key, i.e. g^x (mod p), g^y (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 g^(x*y) (mod p).
   The current protocol extends the basic cryptographic protocol, and
   the regular successful exchange becomes:


     Message                   Server                       Peer
    ---------                 --------                     ------
  [EAP-EKE-ID/Request]       ID_S, CryptoProposals ->

  [EAP-EKE-ID/Response]                         <- ID_P, CryptoSelection

  [EAP-EKE-Commit/Request]   E(Password, Y_S)) ->

  [EAP-EKE-Commit/Response]          <- E(Password, Y_P), E(Ke, Nonce_P)

  [EAP-EKE-Confirm/Request]  E(Ke, Nonce_S | Nonce_P), Auth_S ->

  [EAP-EKE-Confirm/Response]                   <- E(Ke, Nonce_S), Auth_P


   As shown in the exchange above, the following information elements
   are 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.  Note that a few details have been omitted for



Sheffer, et al.          Expires January 7, 2010                [Page 6]


Internet-Draft             The EAP-EKE Method                  July 2009


   clarity.


4.  Packet Formats

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, and defined in [RFC3748].  The Type field in the EAP header
   MUST be the value allocated by IANA for EAP-EKE version 1.

   The EKE-Exch 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
   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.

4.2.  EAP-EKE Payloads

   EAP-EKE payloads all contain the EAP-EKE header and encoded
   information, which differs for the different exchanges.







Sheffer, et al.          Expires January 7, 2010                [Page 7]


Internet-Draft             The EAP-EKE Method                  July 2009


4.3.  EAP-EKE-ID



     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 proposals
      subsequently contained in the Proposal field.  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:

      Group Description:

         This field's value is taken from the IANA registry for Diffie-
         Hellman groups defined in Section 6.4.

      Encryption:

         This field's value is taken from the IANA registry for
         encryption algorithms defined in Section 6.1.

      PRF:

         This field's value is taken from the IANA registry for pseudo
         random functions defined in Section 6.2.




Sheffer, et al.          Expires January 7, 2010                [Page 8]


Internet-Draft             The EAP-EKE Method                  July 2009


      MAC:

         This field's value is taken from the IANA registry for keyed
         message digest algorithms defined in Section 6.3 used to
         provide integrity protection.

   IDType

      Denotes the Identity type.  This is taken from the IANA registry
      defined in Section 6.  The server and the peer MAY use different
      identity types.

   The meaning of the Identity field depends on the values of the Code
   and IDType fields.  It is RECOMMENDED that the Identity field be
   printable.

   o  EAP-EKE-ID/Request: server ID
   o  EAP-EKE-ID/Response: peer ID

   The server SHOULD assert its own identity (e.g. its host name), or it
   MAY use the peer's identity if it knows it before the protocol
   starts.

   The length of the Identity is computed from the Length field in the
   EAP header.

4.4.  EAP-EKE-Commit

   In this exchange both parties send their encrypted ephemeral public
   key, and the peer also includes a Challenge.



    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                                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Commit_P                                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                     Figure 4: EAP-EKE-Commit Payload



Sheffer, et al.          Expires January 7, 2010                [Page 9]


Internet-Draft             The EAP-EKE Method                  July 2009


   DHComponent:

      This field contains the password-encrypted Diffie-Hellman public
      key, see Section 5.2.

   Commit_P:

      This field only appears in the response, and contains the
      encrypted and integrity-protected challenge value sent by the
      peer.  See Section 5.3.

4.5.  EAP-EKE-Confirm

   In this exchange 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_?                                            ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Auth_?                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                     Figure 5: EAP-EKE-Confirm Payload

   Confirm_?:

      This field contains the encrypted and integrity-protected response
      to the other peer's challenge, see Section 5.4 and Section 5.5.

   Auth_?

      This field signs the Identity and the negotiated fields, to
      prevent downgrade attacks.  See Section 5.4 and Section 5.5.







Sheffer, et al.          Expires January 7, 2010               [Page 10]


Internet-Draft             The EAP-EKE Method                  July 2009


4.6.  EAP-EKE-Failure

   The EAP-EKE-Failure message 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                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                          EAP-EKE-Failure Payload

   Currently the following Failure-Code values are defined:
   o  0x00000000: Reserved
   o  0x00000001: No Error
   o  0x00000002: Protocol Error
   o  0x00000003: Password Not Found
   o  0x00000004: Authentication Failure
   o  0x00000005: Authorization Failure
   o  0x00000006: No Proposal Chosen

   Additional values of this field are available via IANA registration.

   "No Error" is used for failure acknowledgement, see below.  "Protocol
   Error" indicates a failure to parse or understand a protocol message
   or one of its payloads.  "Password Not Found" indicates a password
   for a particular user could not be located, making authentication
   impossible.  "Authentication Failure" indicates failure in the
   cryptographic computation most likely caused by an incorrect
   password, or an inappropriate identity type.  "Authorization Failure"
   indicates that while the password being used is correct, the user is
   not authorized to connect.  "No Proposal Chosen" indicates that the
   peer is unwilling to select any of the cryptographic proposals
   offered by the server.

   When the peer encounters an error situation, it MUST respond with
   EAP-EKE-Failure.  The server MUST send 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
   EAP-Failure message to end the exchange.






Sheffer, et al.          Expires January 7, 2010               [Page 11]


Internet-Draft             The EAP-EKE Method                  July 2009


4.7.  Protected Fields

   Several fields are encrypted and integrity-protected.  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 four octet strings:

   o  An optional IV, required when the encryption algorithm/mode
      necessitates it, e.g. for CBC encryption.  A randomly chosen value
      whose length is equal to the block length of the encryption
      algorithm.  The sender SHOULD pick this value pseudo-randomly and
      independently for each protected field.
   o  The encrypted data.
   o  Random padding of the minimal length (possibly zero) required to
      complete the length of the encrypted data to the encryption
      algorithm's block size.  This field is encrypted along with the
      preceding data.
   o  ICV, a cryptographic checksum 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 integrity
      algorithm negotiated.

4.8.  Encrypted Fields

   Two fields are encrypted but not integrity protected.  Their format
   is identical to a protected field (Section 4.7), except that the
   Integrity Check Value is omitted.





Sheffer, et al.          Expires January 7, 2010               [Page 12]


Internet-Draft             The EAP-EKE Method                  July 2009


5.  Cryptographic Operations

5.1.  Generating Keying Material

   Keying material will always be derived as the output of the
   negotiated 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 will use the terminology prf+ to
   describe 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)
   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.

5.2.  EAP-EKE-Commit/Request

   The server computes

      Y_S = g^x mod N,

   where 'x' is a randomly chosen number in the range 2 ..  N-1.  The
   randomly chosen number is the private key, and the calculated field
   is the corresponding public key.  Each of the peers MUST use a fresh,
   random value for this field on each run of the protocol.

   Note: If Elliptic Curve Diffie-Hellman is used, the corresponding
   additive group operations are to be understood.

   The server transmits






Sheffer, et al.          Expires January 7, 2010               [Page 13]


Internet-Draft             The EAP-EKE Method                  July 2009


      DHComponent_S = E(prf+(password, "EAP-EKE Password"), Y_S),

   formatted as an encrypted field (Section 4.8).

   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
   to store the randomized password value, i.e. prf+(password, ...), as
   a password-equivalent, rather than the cleartext password.

5.3.  EAP-EKE-Commit/Response

   The peer computes

      Y_P = g^y mod N

   and sends

      DHComponent_P = E(prf+(password, "EAP-EKE Password"), Y_P)

   formatted as an encrypted field (Section 4.8).  If the password is
   non-ASCII, it SHOULD be normalized by the peer before the EAP-EKE
   message is constructed.  The normalization method is SASLprep,
   [RFC4013].  Note that the password is not null-terminated.

   Both sides calculate

      SharedSecret = prf(0+, g^(x*y) mod N)

   where 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.  This extra
   application of the pseudo-random function is the "extraction step" of
   [I-D.krawczyk-hkdf].  Note that the peer must compute the
   SharedSecret value before sending out its response.

   The encryption key is computed:

      Ke = prf+(SharedSecret, "EAP-EKE Ke" | ID_S | ID_P)

   The integrity protection key is computed:





Sheffer, et al.          Expires January 7, 2010               [Page 14]


Internet-Draft             The EAP-EKE Method                  July 2009


      Ki = prf+(SharedSecret, "EAP-EKE Ki" | ID_S | ID_P)

   And the peer generates

      Commit_P = E(Ke, Nonce_P),

   where Nonce_P is a randomly generated binary string.  Nonce_P has
   length equal to the block size of E for block ciphers, or 32 octets
   if E is a stream cipher.  It sends this value as a protected field
   (Section 4.7), encrypted using Ke and signed using Ki with the
   negotiated MAC algorithm.

5.4.  EAP-EKE-Confirm/Request

   The server sends:

      Confirm_S = E(Ke, Nonce_P | Nonce_S),

   as a protected field, where Nonce_S is a randomly generated string,
   similar to Nonce_P.

   It computes:

      Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P |
      Nonce_S)

   And sends:

      Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE-
      ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response),

   where the literal string is encoded using ASCII with no zero
   terminator.  The messages are included in full, starting with the EAP
   header, and including any possible future extensions.

5.5.  EAP-EKE-Confirm/Response

   The peer computes Ka, and sends:

      Confirm_P = E(Ke, 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)






Sheffer, et al.          Expires January 7, 2010               [Page 15]


Internet-Draft             The EAP-EKE Method                  July 2009


5.6.  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.

5.7.  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.

   We have defined the following groups:
   o  DHGROUP_EKE_14 is defined by: the prime number of Group 14
      [RFC3526], with the generator 11 (decimal).
   o  Additional groups will be defined by future versions of this
      document.

5.8.  Mandatory Algorithms

   To facilitate interoperability, the following algorithms are
   mandatory to implement:





Sheffer, et al.          Expires January 7, 2010               [Page 16]


Internet-Draft             The EAP-EKE Method                  July 2009


   o  ENCR_AES128_CBC (encryption algorithm)
   o  PRF_HMAC_SHA1 (pseudo random function and keyed message digest)
   o  DHGROUP_EKE_14 (DH-group)


6.  IANA Considerations

   This document allocates an EAP method type, for "EAP-EKE Version 1".

   This document requires IANA to create the registries described in the
   subsequent sections.  Values can be added or modified in these
   registries per Specification Required [RFC5226].

6.1.  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|
   |                 | 128-255 | Reserved for private use         |
   +-----------------+---------+----------------------------------+


6.2.  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] |
   |               | 2-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 including zero.





Sheffer, et al.          Expires January 7, 2010               [Page 17]


Internet-Draft             The EAP-EKE Method                  July 2009


6.3.  Keyed Message Digest Registry

   This section defines an IANA registry for keyed message digest
   algorithms:


   +---------------+---------+-------------------------------------+
   | Name          | Value   | Definition                          |
   +---------------+---------+-------------------------------------+
   | Reserved      | 0       |                                     |
   | PRF_HMAC_SHA1 | 1       | HMAC SHA-1, as defined in [RFC2104] |
   |               | 2-127   | Available for allocation via IANA   |
   |               | 128-255 | Reserved for private use            |
   +---------------+---------+-------------------------------------+


6.4.  Diffie-Hellman Group Registry

   This section defines an IANA registry for Diffie-Hellman groups:


+----------------+---------+-------------------------------------------+
| Name           | Value   | Definition                                |
+----------------+---------+-------------------------------------------+
| Reserved       | 0       |                                           |
| DHGROUP_EKE_14 | 1       | 2048-bit MODP Group defined in this       |
|                |         | document                                  |
|                | 2-127   | Available for allocation via IANA         |
|                | 128-255 | Reserved for private use                  |
+----------------+---------+-------------------------------------------+


6.5.  Identity Type Registry

   In addition, an identity type registry is defined:
















Sheffer, et al.          Expires January 7, 2010               [Page 18]


Internet-Draft             The EAP-EKE Method                  July 2009


   +-----------+---------+---------------------------------------------+
   | Name      | Value   | Definition                                  |
   +-----------+---------+---------------------------------------------+
   | Reserved  | 0       |                                             |
   | ID_OPAQUE | 1       | A printable string whose format is          |
   |           |         | undefined                                   |
   | ID_NAI    | 2       | A Network Access Identifier, as defined in  |
   |           |         | [RFC4282] (mandatory to implement)          |
   | 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 (mandatory to |
   |           |         | implement)                                  |
   |           | 6-127   | Available for allocation via IANA           |
   |           | 128-255 | Reserved for private use                    |
   +-----------+---------+---------------------------------------------+


6.6.  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.

6.7.  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.6.  All
   values up to 0xff000000 are available for allocation via IANA.  The
   remaining values up to 0xffffffff are available for private use.


7.  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.

   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



Sheffer, et al.          Expires January 7, 2010               [Page 19]


Internet-Draft             The EAP-EKE Method                  July 2009


      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
          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



Sheffer, et al.          Expires January 7, 2010               [Page 20]


Internet-Draft             The EAP-EKE Method                  July 2009


          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 MSK, EMSK.  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].
   4.  Key hierarchy: MSKs and EMSKs are derived from the secret values
       generated during the protocol run, using a negotiated pseudo-
       random function.
   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.
       *  Confidentiality: none of the messages sent in this protocol
          are encrypted.




Sheffer, et al.          Expires January 7, 2010               [Page 21]


Internet-Draft             The EAP-EKE Method                  July 2009


       *  Integrity protection: all messages in this protocol are
          integrity protected.
       *  Channel binding: this protocol does not enable the exchange of
          integrity-protected channel information that can be compared
          with values communicated via out-of-band mechanisms.
       *  Fast reconnect: this protocol does not provide a fast
          reconnect capability.
       *  Cryptographic binding: this protocol is not a tunneled EAP
          method and therefore has no cryptographic information to bind.
       *  Identity protection: the EAP-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.

7.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.

7.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, DHComponent_S values
   based on a password guess, and if they decrypt to a value which in
   not a valid public value, they know that the password guess was
   incorrect.

   For MODP groups, Section 5.7 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 version of this 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.



Sheffer, et al.          Expires January 7, 2010               [Page 22]


Internet-Draft             The EAP-EKE Method                  July 2009


7.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.


8.  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 and Steve Bellovin 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.


9.  References

9.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 January 7, 2010               [Page 23]


Internet-Draft             The EAP-EKE Method                  July 2009


9.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-04 (work in
              progress), June 2009.

   [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-00
              (work in progress), June 2009.

   [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
              Schemes", Proceedings of the 1997 IEEE Symposium on
              Security and Privacy , 1997.




Sheffer, et al.          Expires January 7, 2010               [Page 24]


Internet-Draft             The EAP-EKE Method                  July 2009


   [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.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC5114]  Lepinski, M. and S. Kent, "Additional Diffie-Hellman
              Groups for Use with IETF Standards", RFC 5114,
              January 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

A.1.  -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.2.  -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.





Sheffer, et al.          Expires January 7, 2010               [Page 25]


Internet-Draft             The EAP-EKE Method                  July 2009


A.3.  -00

   Initial version.


Appendix B.  Design Options

B.1.  Number of Round Trips

   We have looked at three options: 2 round trips, 3 round trips, and a
   normal run of 2 round trips with an optional third.  Some of the
   decision factors include:

   o  Performance (latency).
   o  Crypto-agility, the ability to negotiate cryptographic algorithms.
      Ideally this applies to both the symmetric and asymmetric
      algorithms.
   o  Complexity of the protocol state machine, when some messages are
      optional.
   o  Dependence on a higher-level protocol sending the peer's identity
      before EAP-EKE starts, so that the correct password can be used.

   The initial version of this protocol has 3 round trips, primarily for
   simplicity.

B.2.  Fragmentation

   While similar documents ( [I-D.harkins-emu-eap-pwd]) provide
   fragmentation support at the level of the EAP method, we have decided
   that such support is unnecessary given the expected size of messages
   in EAP-EKE.


Authors' Addresses

   Yaron Sheffer
   Check Point Software Technologies Ltd.
   5 Hasolelim St.
   Tel Aviv  67897
   Israel

   Email: yaronf@checkpoint.com









Sheffer, et al.          Expires January 7, 2010               [Page 26]


Internet-Draft             The EAP-EKE Method                  July 2009


   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 January 7, 2010               [Page 27]