Internet DRAFT - draft-cakulev-emu-eap-ibake

draft-cakulev-emu-eap-ibake






Network Working Group                                         V. Cakulev
Internet-Draft                                            Alcatel Lucent
Intended status: Informational                               I. Broustis
Expires: February 21, 2013                            AT&T Labs Research
                                                         August 20, 2012


 An EAP Authentication Method Based on Identity-Based Authenticated Key
                                Exchange
                   draft-cakulev-emu-eap-ibake-03.txt

Abstract

   The Extensible Authentication Protocol (EAP) is an authentication
   framework which supports multiple authentication methods.  This
   document defines an authentication method for EAP called EAP-IBAKE,
   which is based on the Identity-Based Authenticated Key Exchange
   (IBAKE) protocol.  The IBAKE method provides mutual authentication
   through the use of identity-based encryption.  In addition to mutual
   authentication this method also provides perfect forward and
   backwards secrecy.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on February 21, 2013.

Copyright Notice

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

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



Cakulev & Broustis      Expires February 21, 2013               [Page 1]

Internet-Draft            The EAP-IBAKE Method               August 2012


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.














































Cakulev & Broustis      Expires February 21, 2013               [Page 2]

Internet-Draft            The EAP-IBAKE Method               August 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  5
     2.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Message Flows  . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Protocol Sequence  . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  IBAKE-ID Exchange  . . . . . . . . . . . . . . . . . . . .  9
     4.2.  EAP-Request/IBAKE-Challenge  . . . . . . . . . . . . . . .  9
     4.3.  EAP-Response/IBAKE-Challenge . . . . . . . . . . . . . . . 10
     4.4.  EAP-Request/IBAKE-Confirm  . . . . . . . . . . . . . . . . 10
     4.5.  EAP-Response/IBAKE-Confirm . . . . . . . . . . . . . . . . 11
     4.6.  MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1.  EAP-IBAKE Header . . . . . . . . . . . . . . . . . . . . . 13
     5.2.  EAP-IBAKE Payloads . . . . . . . . . . . . . . . . . . . . 14
       5.2.1.  The IBAKE-ID Payload . . . . . . . . . . . . . . . . . 14
       5.2.2.  The IBAKE-Challenge Payload  . . . . . . . . . . . . . 15
       5.2.3.  The IBAKE-Confirm Payload  . . . . . . . . . . . . . . 16
       5.2.4.  The IBAKE-Failure Payload  . . . . . . . . . . . . . . 17
       5.2.5.  Channel Binding Values . . . . . . . . . . . . . . . . 18
   6.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . . . . 20
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
     7.1.  Elliptic Curve Registry  . . . . . . . . . . . . . . . . . 21
     7.2.  Pseudo Random Function Registry  . . . . . . . . . . . . . 21
     7.3.  Identity Type Registry . . . . . . . . . . . . . . . . . . 22
     7.4.  EAP-IBAKE Channel Binding Type Registry  . . . . . . . . . 22
     7.5.  Exchange Registry  . . . . . . . . . . . . . . . . . . . . 23
     7.6.  Failure-Code Registry  . . . . . . . . . . . . . . . . . . 23
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
     8.1.  Identity Protection  . . . . . . . . . . . . . . . . . . . 24
     8.2.  Mutual Authentication  . . . . . . . . . . . . . . . . . . 24
     8.3.  Key Derivation . . . . . . . . . . . . . . . . . . . . . . 24
     8.4.  Brute-Force and Dictionary Attacks . . . . . . . . . . . . 24
     8.5.  Protection, Replay Protection, and Confidentiality . . . . 25
     8.6.  Trust Model  . . . . . . . . . . . . . . . . . . . . . . . 25
     8.7.  Forward Secrecy  . . . . . . . . . . . . . . . . . . . . . 26
     8.8.  Reflection Attacks . . . . . . . . . . . . . . . . . . . . 26
     8.9.  Negotiation Attacks  . . . . . . . . . . . . . . . . . . . 27
   9.  Security Claims  . . . . . . . . . . . . . . . . . . . . . . . 28
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     10.2. Informative References . . . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31




Cakulev & Broustis      Expires February 21, 2013               [Page 3]

Internet-Draft            The EAP-IBAKE Method               August 2012


1.  Introduction

   The Extensible Authentication Protocol (EAP) [RFC3748] provides a
   standard mechanism for unified support of different authentication
   methods.  EAP has been defined for use with different lower-layer
   transport methods, such as Point-to-Point Protocol (PPP) [RFC1661],
   Protocol for Carrying Authentication for Network Access (PANA)
   [RFC5191], IEEE 802 wired networks [IEEE-802.1X], as well as wireless
   technologies such as IEEE 802.11 [IEEE-802.11] and IEEE 802.16
   [IEEE-802.16].  This document defines a new authentication method for
   EAP called EAP-Identity Based Authenticated Key Exchange (EAP-IBAKE).

   IBAKE is a protocol for mutual authentication and key agreement
   between two or more endpoints.  It is structured as a public-key
   based authentication mechanism, where each message is encrypted with
   the public key of the corresponding endpoint, as per the Identity
   Based Encryption (IBE) principles [RFC5091].  As a result of the
   IBAKE protocol successful execution, a shared symmetric key is
   generated by each endpoint, which can further be used for securing
   the communication between the endpoints.  IBAKE may be applied in a
   plurality of deployment scenarios that require generation of a common
   symmetric key.  Hence, IBAKE may be used e.g. for establishing end-
   to-end secure sessions between peers [RFC6267], or for mutually
   authenticating a peer with a server and deriving a common key.  IBAKE
   offers multiple benefits in terms of facilitating a simplified
   public-key based mutual authentication and key agreement procedure,
   which does not depend on the existence of public key infrastructures
   and the incurred complexities thereof [RFC6267].  IBAKE achieves
   secure mutual authentication between the participants, escrow-free
   key agreement, as well as perfect forward and backwards secrecy
   [I-D.cakulev-ibake].

   This document specifies IBAKE as a method for the Extensible
   Authentication Protocol (EAP) [RFC3748].  In the EAP setting that is
   considered in this document, IBAKE is executed between an EAP peer
   and an EAP server.  While IBAKE may be used for mutual authentication
   and key agreement between more than two participants, such scenarios
   are outside the scope of this document.













Cakulev & Broustis      Expires February 21, 2013               [Page 4]

Internet-Draft            The EAP-IBAKE Method               August 2012


2.  Terminology

2.1.  Requirements notation

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

2.2.  Abbreviations

   IBE         Identity Based Encryption

   IBAKE       Identity Based Authenticated Key Exchange

   IDp         Peer's Identity

   IDs         Server's Identity

   K_PR        Private Key

   K_PUB       Public Key

2.3.  Conventions

   o  E is an elliptic curve over a finite field F

   o  P is a point on E of large prime order

   o  [x]P denotes point multiplication on an elliptic curve, i.e.
      adding a point P to itself total of x times

   o  H1 is a known hash function that takes a string and assigns it to
      a point on the elliptic curve, i.e., H1(A) = QA on E, where A is
      usually based on the identity.

   o  Encr(k, A) denotes that A is IBE-encrypted with the key k

   o  s||t denotes concatenation of the strings s and t

   o  K_PUBx denotes Public Key of x











Cakulev & Broustis      Expires February 21, 2013               [Page 5]

Internet-Draft            The EAP-IBAKE Method               August 2012


3.  Protocol Description

   EAP is a two-party protocol that takes place between an EAP peer and
   an EAP server (also know as authenticator).  An EAP method defines
   the specific authentication protocol being used by EAP.  This
   document defines IBAKE as the EAP method, i.e., it defines the
   messages sent between the EAP server and the EAP peer for the
   purposes of authentication and key derivation.

   The peer and the server are attempting to mutually authenticate each
   other and agree on a key using EAP-IBAKE.  This specification assumes
   that the peer and the server trust a third party, the Key Generation
   Function (KGF).  Rather than a single KGF, several different KGFs may
   be involved, e.g. one for the peer and one for the server.  The peer
   and the server do not share any credentials prior to execution of
   EAP-IBAKE.  This specification also assumes that the peer and the
   server have securely obtained their respective Private Keys from
   their respective KGFs prior to EAP-IBAKE message exchange.  In
   addition, the peer and the server obtained or are able to obtain a
   set of publicly available parameters of each other's KGF.  The
   procedures needed to obtain the private keys and public parameters
   are outside of scope of this specification.  The details for these
   procedures can be found in [RFC5091] and [RFC5408].

3.1.  Message Flows

   A successful run of EAP-IBAKE consists of up to three message
   exchanges: an Identity exchange, a Challenge exchange and a Confirm
   exchange.  This is shown in Figure 1.

   The peer and the server use the EAP-IBAKE Identity exchange to obtain
   each other's identities and to agree upon a ciphersuite to use in the
   subsequent exchanges.  In the Challenge exchange the peer and the
   server exchange information to authenticate each other and also to
   generate a shared key.  In the Confirm exchange the peer and the
   server complete the authentication by proving the knowledge of valid
   identity-based private keys.














Cakulev & Broustis      Expires February 21, 2013               [Page 6]

Internet-Draft            The EAP-IBAKE Method               August 2012


            +--------+                                     +--------+
            |        |                EAP-Request/IBAKE-ID |        |
            |  EAP   |<------------------------------------|  EAP   |
            |  peer  |                                     | server |
            |  (P)   | EAP-Response/IBAKE-ID               |   (S)  |
            |        |------------------------------------>|        |
            |        |                                     |        |
            |        |          EAP-Request/IBAKE-Challenge|        |
            |        |<------------------------------------|        |
            |        |                                     |        |
            |        | EAP-Response/IBAKE-Challenge        |        |
            |        |------------------------------------>|        |
            |        |                                     |        |
            |        |           EAP-Request/IBAKE-Confirm |        |
            |        |<------------------------------------|        |
            |        |                                     |        |
            |        | EAP-Response/IBAKE-Confirm          |        |
            |        |------------------------------------>|        |
            |        |                                     |        |
            |        |          EAP-Success                |        |
            |        |<------------------------------------|        |
            +--------+                                     +--------+


                  Figure 1: Successful EAP-IBAKE Exchange

   The IBAKE exchange, also described in [I-D.cakulev-ibake] is a three-
   step exchange as follows:


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

   Encr(K_PUBs, IDp || IDs || [Rp]P) ->

                 <- Encr(K_PUBp, IDp || IDs || [Rp]P || [Rs]P)

   Encr(K_PUBs, IDp || IDs || [Rs]P) ->


   Where:

   o  K_PUBp and K_PUBs are the public keys of peer and server,
      respectively.  These public keys are derived from their
      corresponding identities as follows K_PUBp/s = H1(IDp/s).

   o  Rp and Rs are random integers, chosen by Peer and Server,
      respectively.



Cakulev & Broustis      Expires February 21, 2013               [Page 7]

Internet-Draft            The EAP-IBAKE Method               August 2012


   The EAP-IBAKE method extends the basic IBAKE protocol such that the
   regular successful EAP-IBAKE exchange takes place as follows.


      Message                   Server                       Peer
     ---------                 --------                     ------
   ID/Request          IDs, CryptoProposals ->

   ID/Response             <- Encr(K_PUBs,IDp), CryptoProposal

   Challenge/Request   Encr(K_PUBp, IDs || IDp || [Rs]P) ->

   Challenge/Response      <- Encr(K_PUBp, IDs || IDp || [Rs]P || [Rp]P)

   Confirm/Request     Encr(K_PUBp, IDs || IDp || [Rp]P), Auth_S ->

   Confirm/Response                                         <- Auth_P

   As shown in the exchange above, the following information elements
   have been added to the original protocol: exchange of identity values
   for both protocol parties (IDs, IDp), negotiation of cryptographic
   protocols, signature fields to protect the integrity of the
   negotiated parameters (Auth_S, Auth_P), and the last message to
   complete the four-way handshake.

   Detailed protocol description is provided in the next section while
   message formats are provided in Section 5.
























Cakulev & Broustis      Expires February 21, 2013               [Page 8]

Internet-Draft            The EAP-IBAKE Method               August 2012


4.  Protocol Sequence

   This section describes the sequence of messages for the ID, Challenge
   and Confirm exchanges, and lists the operations performed by the
   server and the peer.

4.1.  IBAKE-ID Exchange

   Initially, the server issues EAP-Request/IBAKE-ID, including its
   identity (IDs) in the Identity payload and optionally ciphersuite
   proposals in the Proposal payload.  Upon receiving the EAP-Request/
   IBAKE-ID message the peer uses the received server's identity to
   generate the server's public key as follows


           K_PUBs = H1(IDs).

   The peer then encrypts its identity as follows


          Encr(K_PUBs, IDp),

   and includes it in the Identity payload of the EAP-Response/IBAKE-ID
   message.

   Finally, if the EAP-Request/IBAKE-ID contains Proposals payload, the
   Peer chooses most preferred proposal, and includes it in the Proposal
   payload of the EAP-Response/IBAKE-ID message.

4.2.  EAP-Request/IBAKE-Challenge

   Upon receiving EAP-Response/IBAKE-ID message, the server SHALL first
   decrypt the message as specified in [RFC5091] and [RFC5408], and
   obtain the identity of the peer.  The server then selects a random Rs
   and computes its Elliptic curve Diffie-Hellman value, [Rs]P. The
   server MUST use a fresh, random value for Rs on each run of the
   protocol.  The server uses the identity of the peer obtained in
   IBAKE-ID exchange to generate the IBE public key of the peer as
   follows


           K_PUBp = H1(IDp).

   The server then computes the encrypted field (see Section 5.2.2)


          ECDHComponent_S = Encr(K_PUBp, IDs || IDp || [Rs]P).




Cakulev & Broustis      Expires February 21, 2013               [Page 9]

Internet-Draft            The EAP-IBAKE Method               August 2012


   Finally, the server sends EAP-Request/IBAKE-Challenge message to the
   peer.

4.3.  EAP-Response/IBAKE-Challenge

   Upon receiving EAP-Request/IBAKE-Challenge message, the peer SHALL
   first decrypt the message as specified in [RFC5091] and [RFC5408],
   and obtain [Rs]P. The peer then selects a random Rp and computes its
   Elliptic curve Diffie-Hellman value, [Rp]P. The peer MUST use a
   fresh, random value for Rp on each run of the protocol.

   The peer then computes the encrypted field (see Section 5.2.2)


          ECDHComponent_P = Encr(K_PUBs, IDs || IDp || [Rs]P || [Rp]P).

   Finally, the peer sends EAP-Response/IBAKE-Challenge message to the
   server.

   At this point both the Server and Peer can generate the session key
   [Rs][Rp]P using exchanged Elliptic Curve Diffie-Hellman values.  The
   session key as a point on an elliptic curve is then converted into
   the octet string as specified in [SEC1].  This octet string,
   K_Session, is then used to generate MSK, EMSK and keys used for
   protection of IBAKE-Confirm exchange.

4.4.  EAP-Request/IBAKE-Confirm

   Upon receiving EAP-Response/IBAKE-Challenge message, the server SHALL
   first decrypt the message as specified in [RFC5091] and [RFC5408],
   and obtain [Rs]P and [Rp]P. The server MUST verify that the received
   [Rs]P is the same as the one sent in EAP-Request/IBAKE-Challenge
   message.  If it is not the same, the server MUST abort the protocol
   with an "Authentication Failure" code.  Upon successful verification
   of the received [Rs]P, the server computes the encrypted field


          ECDHComponent_S = Encr(K_PUBp, IDs || IDp || [Rp]P).

   The server then computes:


         Ka = prf(K_Session, "EAP-IBAKE Ka" || IDs || IDp)

   whose length is the preferred key length of the negotiated pseudo-
   random function (see Section 5.2).  It then constructs:





Cakulev & Broustis      Expires February 21, 2013              [Page 10]

Internet-Draft            The EAP-IBAKE Method               August 2012


        Auth_S = prf(Ka, "EAP-IBAKE server" || EAP-Request/IBAKE-ID ||
                 EAP-Response/IBAKE-ID || EAP-Request/IBAKE-Challenge ||
                 EAP-Response/IBAKE-Challenge).

   The messages in Auth_S computation are included in full, starting
   with the EAP header, and including any possible future extensions.

   The server then constructs and sends EAP-Request/IBAKE-Confirm
   message to the peer.

4.5.  EAP-Response/IBAKE-Confirm

   Upon receiving EAP-Request/IBAKE-Confirm message, the peer SHALL
   first decrypt the message as specified in [RFC5091] and [RFC5408],
   and obtain [Rp]P. The peer MUST verify that the received [Rp]P is the
   same as the one sent in EAP-Response/IBAKE-Challenge message.  If it
   is not the same, the peer MUST abort the protocol with an
   "Authentication Failure" code.  The peer also MUST verify the
   correctness of the Auth_S value, and MUST abort the protocol if
   incorrect, with an "Authentication Failure" code.

   Upon successful verification of the received [Rp]P and correctness of
   the Auth_S value, the peer computes Ka as described above, and
   constructs:


        Auth_P = prf(Ka, "EAP-IBAKE peer" || EAP-Request/IBAKE-ID ||
                 EAP-Response/IBAKE-ID || EAP-Request/IBAKE-Challenge ||
                 EAP-Response/IBAKE-Challenge).

   The peer sends verification message EAP-Response/IBAKE-Confirm to
   complete the four-way handshake, including AUTH_P value.  Upon
   receiving the message, the server MUST verify the correctness of the
   Auth_P value, and MUST abort the protocol if incorrect, with an
   "Authentication Failure" code.

4.6.  MSK and EMSK

   The authenticated key exchange of EAP-IBAKE generates a shared and
   authenticated key, K_Session.  EAP-IBAKE must export two 512-bit
   keys, MSK and EMSK.  Therefore, following the last message of the
   protocol, both sides compute and export the shared keys, each 512
   bits in length:


       MSK || EMSK = prf(K_Session, "EAP-IBAKE Exported Keys" ||
                     IDs || IDp)




Cakulev & Broustis      Expires February 21, 2013              [Page 11]

Internet-Draft            The EAP-IBAKE Method               August 2012


   At this point, both protocol participants MUST discard all
   intermediate cryptographic values, including Rs and Rp.  Similarly,
   both parties MUST immediately discard these values whenever the
   protocol terminates with a failure code or as a result of timeout.















































Cakulev & Broustis      Expires February 21, 2013              [Page 12]

Internet-Draft            The EAP-IBAKE Method               August 2012


5.  Message Formats

   EAP-IBAKE defines new message types, with 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.

   All multi-octet strings MUST be laid out in network byte order.

5.1.  EAP-IBAKE Header

   The EAP-IBAKE header consists of the standard EAP header (see Section
   4 of [RFC3748]), followed by an EAP-IBAKE 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      |L|M| IBAKE-Exch|          Total-Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Data                              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 2:  EAP-IBAKE Header

   The Code, Identifier, Length, and Type fields are all part of the EAP
   header as defined in [RFC3748].  The Type field in the EAP header is
   [TBD by IANA] for EAP-IBAKE version 1.

   L and M bits: The L bit (Length included) is set to indicate the
   presence of the two-octet Total-Length field, and MUST be set for the
   first fragment of a fragmented EAP-IBAKE message or set of messages.
   The M bit (more fragments) is set on all but the last fragment.

   The IBAKE-Exch (IBAKE Exchange) field identifies the type of EAP-
   IBAKE payload encapsulated in the Data field.  This document defines
   the following values for the IBAKE-Exch field:

   o  0x00: Reserved

   o  0x01: IBAKE-ID exchange

   o  0x02: IBAKE-Challenge exchange




Cakulev & Broustis      Expires February 21, 2013              [Page 13]

Internet-Draft            The EAP-IBAKE Method               August 2012


   o  0x03: IBAKE-Confirm exchange

   o  0x04: IBAKE-Failure message

   Further values of this IBAKE-Exch field are available via IANA
   registration.

   Total-Length: The Total-Length field is two octets in length, and is
   present only if the L bit is set.  This field provides the total
   length of the EAP-IBAKE message or set of messages that is being
   fragmented.

5.2.  EAP-IBAKE Payloads

   EAP-IBAKE messages all contain the EAP-IBAKE header and information
   encoded in a single payload, which differs for each message.  This
   section defines payloads for EAP-IBAKE messages.

5.2.1.  The IBAKE-ID Payload


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | NumProposals  |   Reserved    |           Proposal           ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ...    Proposal                  |    IDType     |  Identity    ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                        Figure 3:  IBAKE-ID Payload

   The IBAKE-ID payload contains the following fields:

   o  NumProposals: The NumProposals field contains the number of
      Proposal fields subsequently contained in the payload.  If in the
      IBAKE-ID/Request the NumProposals field is set to zero (0) then it
      is out of scope of this specification how the server and the peer
      negotiate the elliptic curve and PRF used in the rest of EAP-IBAKE
      exchange.  Otherwise, if in the IBAKE-ID/Request the NumProposals
      field is not set to zero (0), then in the IBAKE-ID/Response
      message the NumProposals field MUST be set to one (1).  The
      offered proposals in the Request are listed in priority order,
      with the most preferable appearing first.  The selected proposal
      in the Response MUST be fully identical with one of the offered
      proposals.





Cakulev & Broustis      Expires February 21, 2013              [Page 14]

Internet-Draft            The EAP-IBAKE Method               August 2012


   o  Proposal: Each proposal consists of three fields, in this order:

      *  Elliptic Curve Description: This field's value is taken from
         the IANA registry for Elliptic curves defined in Section 7.1.
         The length of this field is one octet.

      *  PRF: This field's value is taken from the IANA registry for
         pseudo random functions defined in Section 7.2.  The length of
         this field is one octet.

      *  P: This field contains the 2-dimensional coordinates of the
         selected point P on the Elliptic Curve.  The length of each
         coordinate in octets depends on the chosen Elliptic Curve.

   o  Reserved: By default, this field MUST be sent as zero, and MUST be
      ignored by the recipient.

   o  IDType: Denotes the Identity Type.  This is taken from the IANA
      registry defined in Section 7.3.  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.

   o  Identity: The meaning of the Identity field depends on the values
      of the Code and IDType fields.

      *  IBAKE-ID/Request: server ID

      *  IBAKE-ID/Response: peer ID

      The length of the Identity field MUST be computed from the Length
      field in the EAP header.  This field, like all other fields in
      this specification, MUST be octet-aligned.

5.2.2.  The IBAKE-Challenge Payload

   This payload allows both parties send their encrypted ephemeral keys.

   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 in
   IBAKE-Challenge exchange unprotected, but is verified when it is
   signed by the Auth_S/Auth_P payloads of the IBAKE-Confirm exchange.










Cakulev & Broustis      Expires February 21, 2013              [Page 15]

Internet-Draft            The EAP-IBAKE Method               August 2012


  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
 |                        ECDHComponent_S                        ~     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
 |                        ECDHComponent_P                        ~     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
 |          CBValue (zero or more occurrences)                   ~     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
 ~                                                               ~     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
                                                                       |
                                                            Encrypted  |
                                                              fields

                    Figure 4:  IBAKE-Challenge Payload

   The IBAKE-Challenge payload contains the following fields:

   o  ECDHComponent_S/ECDHComponent_P: This field contains Server's/
      Peer's IBE-encrypted Elliptic Curve Diffie-Hellman value.  The
      peer's Elliptic Curve Diffie-Hellman value DHComponent_P is
      included only in the response message (i.e.  EAP-Response/
      IBAKE-Challenge).  ECDHComponent field contains the identities of
      the server and the peer, as exchanged in IBAKE-ID exchange.

   o  CBValue: This structure MAY be included both in the request and in
      the response, and MAY be repeated multiple times in a single
      payload (see Section 5.2.5).  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.

   Note that as shown in Figure 4, Identity fields and ECDHComponent
   fields are IBE-Encrypted.

5.2.3.  The IBAKE-Confirm Payload

   Using this payload, both parties complete the authentication by
   mutually authenticating each other and generating key material for
   the EAP consumer protocol.










Cakulev & Broustis      Expires February 21, 2013              [Page 16]

Internet-Draft            The EAP-IBAKE Method               August 2012


  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
 |                        ECDHComponent_P                        ~     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
 |                         Auth_S/Auth_P                         ~     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
 ~                                                               ~     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
                                                                       |
                                                            Encrypted  |
                                                              fields

                      Figure 5: IBAKE-Confirm Payload

   The IBAKE-Confirm payload contains the following fields:

   o  ECDHComponent_P: This field contains the peer's IBE-encrypted
      Elliptic Curve Diffie-Hellman value.  The peer's Elliptic Curve
      Diffie-Hellman value DHComponent_P is included only in the request
      message (i.e.  EAP-Request/IBAKE-Confirm).  ECDHComponent field
      contains the identities of the server and the peer, as exchanged
      in IBAKE-ID exchange.

   o  Auth_S/Auth_P: This field contains a signature of the preceding
      messages, including the Identity and the negotiated fields.  This
      prevents various possible attacks, such as algorithm-downgrade
      attacks.  Auth_S is included only in the request message (i.e.
      EAP-Request/IBAKE-Confirm), while Auth_P is included only in the
      response message (i.e.  EAP-Response/IBAKE-Confirm).

5.2.4.  The IBAKE-Failure Payload

   The EAP-EKE-Failure payload format is defined as follows:


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Failure-Code                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 6: IBAKE-Failure Payload

   The payload's size is always exactly 4 octets.

   The following Failure-Code values are defined:




Cakulev & Broustis      Expires February 21, 2013              [Page 17]

Internet-Draft            The EAP-IBAKE Method               August 2012


   +------------+----------------+-------------------------------------+
   | Value      | Name           | Meaning                             |
   +------------+----------------+-------------------------------------+
   | 0x00000000 | Reserved       |                                     |
   | 0x00000001 | No Error       | This code is used for failure       |
   |            |                | acknowledgement, see below.         |
   | 0x00000002 | Protocol Error | A failure to parse or understand a  |
   |            |                | protocol message or one of its      |
   |            |                | payloads.                           |
   | 0x00000003 | Authentication | Failure in the cryptographic        |
   |            | Failure        | computation.                        |
   | 0x00000004 | Authorization  | While the cryptographic computation |
   |            | Failure        | is correct, the user is not         |
   |            |                | authorized to connect.              |
   | 0x00000005 | No Proposal    | The peer is unwilling to select any |
   |            | Chosen         | of the cryptographic proposals      |
   |            |                | offered by the server.              |
   +------------+----------------+-------------------------------------+

   Additional values of this field are available via IANA registration.

   When the peer encounters an error situation, it MUST send IBAKE-
   Failure.  The server MUST reply with an EAP-Failure message to end
   the exchange.

   When the server encounters an error situation, it MUST send IBAKE-
   Failure.  The peer MUST send back IBAKE-Failure message containing a
   "No Error" failure code.  Then the server MUST send an EAP-Failure
   message to end the exchange.

5.2.5.  Channel Binding Values

   This protocol allows higher level protocols that are using it to
   transmit opaque information between the peer and the server.  This
   information is integrity protected but not encrypted, and MAY be used
   to ensure that protocol participants are identical at different
   protocol layers.  See Section 7.15 of [RFC3748] for more details on
   its use.

   EAP-IBAKE 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 IBAKE-Confirm exchange
   (specifically, it is integrity protected through the use of the
   Auth_S, Auth_P payloads).  Consequently, it MUST NOT be relied upon
   in case an error occurs at the EAP-IBAKE level.

   An unknown Channel Binding Value SHOULD be ignored by the recipient.




Cakulev & Broustis      Expires February 21, 2013              [Page 18]

Internet-Draft            The EAP-IBAKE Method               August 2012


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

   Each Channel Binding Value is encoded using a simple TLV structure:


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          CBType               |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Value                                               ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 7: Channel Binding Value

   o  CBType: This is the Channel Binding Value's type.  This document
      defines the value 0x0000 as reserved.  Other values are available
      for IANA allocation.

   o  Length: This field is the total length in octets of the structure,
      including the CBType and Length fields.



























Cakulev & Broustis      Expires February 21, 2013              [Page 19]

Internet-Draft            The EAP-IBAKE Method               August 2012


6.  Fragmentation

   EAP [RFC3748] is a request-response protocol.  The server sends
   requests and the peer responds to those requests.  These request and
   response messages are assumed to be limited to at most 1020 bytes.
   Messages in EAP-IBAKE can be larger than 1020 bytes and therefore
   require support for fragmentation and reassembly.

   Since EAP is a simple ACK-NAK protocol, fragmentation support can be
   added as follows.  In EAP, fragments that are lost or damaged in
   transit will be retransmitted, and sequencing information is provided
   by the Identifier field in EAP.

   EAP-IBAKE fragmentation support is provided through addition of a
   "flags" octet within the EAP-Response and EAP-Request packets, as
   well as a Total-Length field of four octets.  Flags include the
   Length included (L) and More fragments (M) bits.  The L flag is set
   to indicate the presence of the two-octet Total-Length field, and
   MUST be set for the first fragment of a fragmented EAP-IBAKE message
   or set of messages.  The M flag is set on all but the last fragment.
   The Total-Length field is two octets, and provides the total length
   of the EAP-IBAKE message or set of messages that is being fragmented;
   this simplifies buffer allocation.

   When an EAP-IBAKE peer receives an EAP-Request packet with the M bit
   set, it MUST respond with an EAP-Response with EAP-Type=EAP-IBAKE and
   no data.  This serves as a fragment ACK.  The EAP server MUST wait
   until it receives the EAP-Response before sending another fragment.
   In order to prevent errors in processing of fragments, the EAP server
   MUST increment the Identifier field for each fragment contained
   within an EAP-Request, and the peer MUST include this Identifier
   value in the fragment ACK contained within the EAP-Response.
   Retransmitted fragments will contain the same Identifier value.

   Similarly, when the EAP server receives an EAP-Response with the M
   bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-IBAKE
   and no data.  This serves as a fragment ACK.  The EAP peer MUST wait
   until it receives the EAP-Request before sending another fragment.
   In order to prevent errors in the processing of fragments, the EAP
   server MUST increment the Identifier value for each fragment ACK
   contained within an EAP-Request, and the peer MUST include this
   Identifier value in the subsequent fragment contained within an EAP-
   Response.








Cakulev & Broustis      Expires February 21, 2013              [Page 20]

Internet-Draft            The EAP-IBAKE Method               August 2012


7.  IANA Considerations

   IANA shall allocate the EAP method type TBD from the range 1-191, for
   "EAP-IBAKE Version 1".

   This document requests that IANA create the registries described in
   the following sub-sections.

7.1.  Elliptic Curve Registry

   IANA is to create and maintain Elliptic Curve Registry.  Registry
   consists of an ECC curve and its associated value.  Values in the
   range 1-239 SHOULD be approved by the process of Specification
   Required, values in the range 240-254 are for Private Use, and the
   values 0 and 255 are Reserved according to [RFC5226].  The initial
   contents of the registry should be as follows [SEC2], [FIPS186-2]:


           Value    ECC curve
           -------  ------------------------------------
           0        Reserved
           1        ECPRGF192Random  / P-192 / secp192r1
           2        EC2NGF163Random  / B-163 / sect163r2
           3        EC2NGF163Koblitz / K-163 / sect163k1
           4        EC2NGF163Random2 / none  / sect163r1
           5        ECPRGF224Random  / P-224 / secp224r1
           6        EC2NGF233Random  / B-233 / sect233r1
           7        EC2NGF233Koblitz / K-233 / sect233k1
           8        ECPRGF256Random  / P-256 / secp256r1
           9        EC2NGF283Random  / B-283 / sect283r1
           10       EC2NGF283Koblitz / K-283 / sect283k1
           11       ECPRGF384Random  / P-384 / secp384r1
           12       EC2NGF409Random  / B-409 / sect409r1
           13       EC2NGF409Koblitz / K-409 / sect409k1
           14       ECPRGF521Random  / P-521 / secp521r1
           15       EC2NGF571Random  / B-571 / sect571r1
           16       EC2NGF571Koblitz / K-571 / sect571k1
           17-239   Unassigned
           240-254  Private Use
           255      Reserved

7.2.  Pseudo Random Function Registry

   This section defines an IANA registry for pseudo random function
   algorithms:






Cakulev & Broustis      Expires February 21, 2013              [Page 21]

Internet-Draft            The EAP-IBAKE Method               August 2012


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

7.3.  Identity Type Registry

   In addition, an identity type registry is defined:


   +-----------+---------+---------------------------------------------+
   | 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                                       |
   | ID_DN     | 6       | An LDAP Distinguished Name formatted as a   |
   |           |         | string, as defined in [RFC4514]             |
   |           | 7-127   | Available for allocation via IANA           |
   |           | 128-255 | Reserved for private use                    |
   +-----------+---------+---------------------------------------------+

   An example of an 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 [RFC5891], for example "xn--tmonesimerkki-
   bfbb.example.net".

7.4.  EAP-IBAKE Channel Binding Type Registry

   This section defines an IANA registry for the Channel Binding Type
   registry, a 16-bit long code.  The value 0x0000 has been defined as
   Reserved.  All other values up to and including 0xfeff are available
   for allocation via IANA.  The remaining values up to and including
   0xffff are available for private use.






Cakulev & Broustis      Expires February 21, 2013              [Page 22]

Internet-Draft            The EAP-IBAKE Method               August 2012


7.5.  Exchange Registry

   This section defines an IANA registry for the EAP-IBAKE Exchange
   registry, an 8-bit long code.  Initial values are defined in
   Section 5.1.  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.

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




































Cakulev & Broustis      Expires February 21, 2013              [Page 23]

Internet-Draft            The EAP-IBAKE Method               August 2012


8.  Security Considerations

   This section discusses the claimed security properties of EAP-IBAKE
   as well as vulnerabilities and security recommendations.

8.1.  Identity Protection

   EAP-IBAKE includes identity privacy support that protects the privacy
   of the subscriber identity against passive eavesdropping.  Observe
   that in all the messages, the identity of the peer is sent in the
   encrypted part of the payload, therefore an attacker cannot discover
   user identities by snooping authentication traffic.

8.2.  Mutual Authentication

   Payloads in the protocol exchange are encrypted using IBE.  In
   particular, only the peer can decrypt the contents of the
   ECDHComponent_S payload sent by the server, and similarly only the
   server can decrypt the contents of the ECDHComponent_P and the
   encrypted part of the EAP-Response/IBAKE-ID payload sent by the peer.
   Moreover, upon receiving EAP-Response/IBAKE-Challenge, the server can
   verify the authenticity of the peer, since [Rs]P could have been sent
   in EAP-Response/IBAKE-Challenge only after decryption of the contents
   of EAP-Request/IBAKE-Challenge by the peer.  Similarly, upon
   receiving EAP-Request/IBAKE-Confirm, the peer can verify the
   authenticity of the server, since [Rp]P could have been sent back in
   EAP-Request/IBAKE-Confirm only after correctly decrypting the
   contents of EAP-Response/IBAKE-Challenge and this is possible only by
   the server.  In other words, the protocol provides mutual
   authentication based on Identity Based Encryption.

8.3.  Key Derivation

   EAP-IBAKE supports key derivation with 512-bit effective key
   strength.  The key hierarchy is specified in Section 4.

   The transient EAP key used to protect EAP-IBAKE packets (Ka), the
   Master Session Keys, and the Extended Master Session Keys are
   cryptographically separate.  An attacker cannot derive any non-
   trivial information about any of these keys based on the other keys.

8.4.  Brute-Force and Dictionary Attacks

   The effective strength of EAP-IBAKE values is 512 bits, and there are
   no known, computationally feasible brute-force attacks to date.
   Because IBAKE is not a password protocol (the private keys are not a
   passphrase, or derived from a passphrase), EAP-IBAKE is not
   vulnerable to dictionary attacks.



Cakulev & Broustis      Expires February 21, 2013              [Page 24]

Internet-Draft            The EAP-IBAKE Method               August 2012


8.5.  Protection, Replay Protection, and Confidentiality

   ECDHComponent and Auth payloads are used to provide integrity,
   replay, and confidentiality protection for EAP-IBAKE Requests and
   Responses.  Integrity protection with Auth includes the EAP header.
   Integrity protection (Auth) is based on a keyed message
   authentication code.  Confidentiality (ECDHComponent) is based on
   Identity Based Encryption.

   Because the session key is not available in the beginning of the EAP
   method, the Auth payload cannot be used for protecting EAP/IBAKE-ID
   and EAP/IBAKE-Challenge messages.  However, the EAP/IBAKE-ID and EAP/
   IBAKE-Challenge exchanges are integrity protected through the Auth
   payloads exchanged in the Confirm exchange.

   Confidentiality protection is applied only to a part of the protocol
   fields.  Section 4 describes in detail which fields are
   confidentiality protected.  Identity protection is discussed in
   Section 8.1.

   Because EAP-IBAKE is not a tunneling method, EAP-Request/
   Notification, EAP-Response/Notification, EAP-Success, or EAP-Failure
   packets are not confidentiality protected, integrity protected, or
   replay protected.  On physically insecure networks, this may enable
   an attacker to mount denial-of-service attacks by spoofing these
   packets.  However, the peer will only accept EAP-Success after the
   peer successfully authenticates the server.  Hence, the attacker
   cannot force the peer to believe that successful mutual
   authentication has occurred before the peer successfully
   authenticates the server, or after the peer fails to authenticate the
   server.

   An eavesdropper will see the EAP Notification, EAP-Success and EAP-
   Failure packets sent in the clear.  With EAP-IBAKE, confidential
   information MUST NOT be transmitted in EAP Notification packets.

8.6.  Trust Model

   It is assumed that the KGFs that are used for deriving IBE private
   keys are secure, not compromised, trusted, and will not engage in
   launching active attacks independently or in a collaborative
   environment.  However, any malicious insider could potentially launch
   passive attacks (by decryption of one or more message exchanges
   offline).  While it is in the best interest of administrators to
   prevent such threats, it is hard to eliminate this problem.  Hence,
   it is assumed that such problems will persist, and hence the session
   key agreement protocols are designed to protect participants from
   passive adversaries.



Cakulev & Broustis      Expires February 21, 2013              [Page 25]

Internet-Draft            The EAP-IBAKE Method               August 2012


   The EAP peer and the EAP server need to trust their respective KGF
   entities.  Such a KGF may be owned/operated by third parties; in such
   cases, the peer and the server need to maintain trust relationships
   with those third parties.  Note here that in scenarios where the EAP
   peer and the EAP server are associated with the same KGF, while such
   a KGF is owned by the server owner (or operator), there is no
   implicit or explicit trust to third parties.

   In addition, it is assumed that the communication between
   participants and their respective KGFs is secure.  Therefore, in any
   implementation of the protocols described in this document,
   administrators of any KGF have to ensure that communication with
   participants is secure and not compromised.

8.7.  Forward Secrecy

   The MSK and EMSK are extracted from the session key, K_Session, which
   is derived from exchanged Elliptic Curve Diffie-Hellman values.  The
   peer and the server choose random values with each run of the
   protocol.  Hence, even if an attacker is able to somehow obtain the
   session key from an earlier run, the attacker will be unable to
   determine any future session keys, or the MSK or EMSK.  In other
   words, EAP-IBAKE provides perfect forward secrecy.

8.8.  Reflection Attacks

   The use of identities within the encrypted payload is intended to
   eliminate some basic reflection attacks.  For instance, suppose that
   identities were not used as part of the encrypted payload, in EAP-
   Request/IBAKE-Challenge message.  Furthermore, assume an adversary
   who has access to the conversation between the server and peer and
   can actively snoop into packets and drop/modify them before routing
   them to the destination.  As an example, consider the case where the
   IP source address and destination address can be modified by the
   adversary.  After the EAP-Request/IBAKE-Challenge message is sent by
   the server (to the peer), the adversary can take over and trap the
   packet.  Next, the adversary can modify the IP source address to
   include the adversary's IP address, before routing it onto the
   responder.  The peer will assume that the request for an IBAKE
   session came from the adversary, and will send EAP-Response/
   IBAKE-Challenge, but encrypt it using the adversary's public key.
   The above message can be decrypted by the adversary (and only by the
   adversary).  In particular, since the EAP-Request/IBAKE-Challenge
   message includes the challenge sent by the server to the peer, the
   adversary will now learn the challenge sent by the server.  Following
   this, the adversary can carry on a conversation with the server
   "pretending" to be the peer.  This attack is eliminated with EAP-
   IBAKE, since identities are used as part of the encrypted payload.



Cakulev & Broustis      Expires February 21, 2013              [Page 26]

Internet-Draft            The EAP-IBAKE Method               August 2012


8.9.  Negotiation Attacks

   EAP-IBAKE does not protect the EAP-Response/Nak packet.  Given that
   EAP-IBAKE does not protect the EAP method negotiation, EAP method
   downgrading attacks may be possible.  In addition, EAP-IBAKE does not
   support EAP-IBAKE protocol version negotiation.

   EAP-IBAKE supports ciphersuite negotiation through the use of
   Proposal payload during IBAKE-ID exchange.  The ciphersuite proposal
   made by the server is not protected from tampering by an active
   attacker.  However, the Proposal payload in EAP-Response/IBAKE-ID
   message containing the peers choice of ciphersuite is sent in the
   encrypted part of the message.  Furthermore, 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.


































Cakulev & Broustis      Expires February 21, 2013              [Page 27]

Internet-Draft            The EAP-IBAKE Method               August 2012


9.  Security Claims

   This section provides the security claims required by [RFC3748].

   Authentication Mechanism: EAP-IBAKE is based on the IBAKE mechanism,
   which is an authentication and key agreement mechanism based on
   Identity Based Encryption.

   Ciphersuite negotiation: Yes

   Mutual authentication: Yes (Section 8.2)

   Integrity protection: Yes (Section 8.5)

   Replay protection: Yes (Section 8.5)

   Confidentiality: Yes, except method-specific failure indications
   (Section 8.5)

   Key derivation: Yes

   Key strength: EAP-IBAKE supports key derivation with 512-bit
   effective key strength.

   Description of key hierarchy: Please see Section 4.

   Dictionary attack protection: N/A (Section 8.4)

   Fast reconnect: No

   Cryptographic binding: Yes

   Session independence: Yes (Section 8.7)

   Fragmentation: Yes (Section 6)

   Channel binding: Yes

   Indication of vulnerabilities: Vulnerabilities are discussed in
   Section 8.











Cakulev & Broustis      Expires February 21, 2013              [Page 28]

Internet-Draft            The EAP-IBAKE Method               August 2012


10.  References

10.1.  Normative References

   [FIPS186-2]
              NIST, "Digital Signature Standard", FIPS 186-2, 2000.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC5091]  Boyen, X. and L. Martin, "Identity-Based Cryptography
              Standard (IBCS) #1: Supersingular Curve Implementations of
              the BF and BB1 Cryptosystems", RFC 5091, December 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5408]  Appenzeller, G., Martin, L., and M. Schertler, "Identity-
              Based Encryption Architecture and Supporting Data
              Structures", RFC 5408, January 2009.

   [SEC1]     Standards for Efficient Cryptography Group, "Elliptic
              Curve Cryptography", September 2000.

   [SHA]      Standards for Efficient Cryptography Group, "Secure Hash
              Standard", Federal Information  Processing Standards
              Publication 180-2, August 2002, with Change Notice 1,
              February 2004.

10.2.  Informative References

   [I-D.cakulev-ibake]
              Cakulev, V., Sundaram, G., and I. Broustis, "IBAKE:
              Identity-Based Authenticated Key Exchange",
              draft-cakulev-ibake-06 (work in progress), November 2011.

   [IEEE-802.11]
              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific Requirements Part
              11:  Wireless LAN Medium Access Control (MAC) and Physical
              Layer (PHY) Specifications", IEEE Standard 802.11-2007,
              2007.

   [IEEE-802.16]
              Institute of Electrical and Electronics Engineers, "IEEE



Cakulev & Broustis      Expires February 21, 2013              [Page 29]

Internet-Draft            The EAP-IBAKE Method               August 2012


              Standard for Local and Metropolitan Area Networks: Part
              16: Air Interface for Fixed and Mobile Broadband Wireless
              Access Systems: Amendment for Physical and Medium Access
              Control Layers for Combined Fixed and Mobile Operations in
              Licensed Bands", IEEE 802.16e, August 2005.

   [IEEE-802.1X]
              Institute of Electrical and Electronics Engineers, "Local
              and Metropolitan Area Networks: Port-Based Network Access
              Control", IEEE Standard 802.1X-2004, December 2004.

   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
              RFC 1661, July 1994.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5191]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", RFC 5191, May 2008.

   [RFC6267]  Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based
              Authenticated Key Exchange (IBAKE) Mode of Key
              Distribution in Multimedia Internet KEYing (MIKEY)",
              RFC 6267, June 2011.

   [SEC2]     Standards for Efficient Cryptography Group, "SEC 2 -
              Recommended Elliptic Curve Domain Parameters",
              September 2000.






















Cakulev & Broustis      Expires February 21, 2013              [Page 30]

Internet-Draft            The EAP-IBAKE Method               August 2012


Authors' Addresses

   Violeta Cakulev
   Alcatel Lucent
   600 Mountain Ave.
   3D-517
   Murray Hill, NJ  07974
   US

   Phone: +1 908 582 3207
   Email: violeta.cakulev@alcatel-lucent.com


   Ioannis Broustis
   AT&T Labs Research
   180 Park Ave.
   Building 103, Room E243
   Florham Park, NJ  07986
   US

   Phone: +1 973 360 7131
   Email: broustis@research.att.com





























Cakulev & Broustis      Expires February 21, 2013              [Page 31]