Network Working Group                                            Y. Ohba
Internet-Draft                                                   Toshiba
Expires: September 4, 2007                                        S. Das
                                                               Telcordia
                                                                R. Lopez
                                                         Univ. of Murcia
                                                           March 3, 2007


               An EAP Method for EAP Extension (EAP-EXT)
                    draft-ohba-hokey-emu-eap-ext-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

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

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

   This Internet-Draft will expire on September 4, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).











Ohba, et al.            Expires September 4, 2007               [Page 1]

Internet-Draft               EAP-EXT Method                   March 2007


Abstract

   This document describes an EAP method that is used for extending EAP
   functionality.  The extended functionality includes HOKEY re-
   authentication and MSK channel binding.  The proposed EAP method
   (EAP-EXT) also allows sequencing of multiple EAP methods within
   itself.  EAP-EXT can generate MSK (Master Session Key) and EMSK
   (Extended Master Session Key) in cases where inner method(s)
   implementations generate MSK but do not generate EMSK.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Specification of Requirements  . . . . . . . . . . . . . .  3
   2.  EAP-EXT Overview . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Error Handling . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  MSK and EMSK exported from EAP-EXT . . . . . . . . . . . .  8
     4.2.  EAP-EXT-AUTH-KEY . . . . . . . . . . . . . . . . . . . . .  8
     4.3.  EAP-EXT-ENC-KEY  . . . . . . . . . . . . . . . . . . . . .  8
     4.4.  HOKEY-REAUTH-KEY . . . . . . . . . . . . . . . . . . . . .  9
   5.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  EAP-EXT TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Method TLV . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  AUTH TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.3.  Peer-ID TLV  . . . . . . . . . . . . . . . . . . . . . . . 13
     6.4.  Server-ID TLV  . . . . . . . . . . . . . . . . . . . . . . 13
     6.5.  Reauth-Key-Lifetime TLV  . . . . . . . . . . . . . . . . . 13
     6.6.  PRF TLV  . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.7.  Channel-Binding-Mechanism TLV  . . . . . . . . . . . . . . 14
     6.8.  Channel-Binding-Data TLV . . . . . . . . . . . . . . . . . 14
     6.9.  Encryption-Algorithm TLV . . . . . . . . . . . . . . . . . 14
     6.10. Integrity-Algorithm TLV  . . . . . . . . . . . . . . . . . 15
     6.11. Encrypted TLV  . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     10.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23








Ohba, et al.            Expires September 4, 2007               [Page 2]

Internet-Draft               EAP-EXT Method                   March 2007


1.  Introduction

   EAP (Extensible Authentication Protocol) is an authentication
   protocol which supports multiple authentication algorithms known as
   "EAP methods" [RFC3748].  In EAP, an EAP peer and an EAP server
   generates EAP keying material, i.e., MSK (Master Session Key) and
   EMSK (Extended Master Session Key) upon successful authentication.  A
   detailed framework for the generation, transport and usage of MSK is
   described in [I-D.ietf-eap-keying].

   Additional functionalities such as HOKEY re-authentication
   [I-D.vidya-eap-er] and MSK channel binding [I-D.ietf-eap-keying] can
   be supported by extending EAP functionality.  There can be two
   approaches for extending EAP functionality.  One approach is to
   define new EAP Codes to realize the extended EAP functionality in
   addition to the existing ones, i.e., Request, Response, Success and
   Failure.  This approach, however, requires changes to [RFC3748] and
   may also require changes to authenticators and lower layer protocols.
   The other approach is to define a new EAP method to realize the
   extended functionality.  For both approaches, it may be desirable
   that these extended functionalities are backward compatible.  In such
   cases, a mechanism for negotiating the capabilities on the extended
   functionalities between an EAP peer and an EAP server may be needed.

   This document describes an EAP method that is used for extending EAP
   functionality.  The extended functionality includes HOKEY re-
   authentication and MSK channel binding.  The proposed EAP method
   (EAP-EXT) also allows sequencing of multiple EAP methods within
   itself.  EAP-EXT can generate MSK and EMSK in cases where inner
   method(s) implementations generate MSK but do not generate EMSK.

1.1.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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].













Ohba, et al.            Expires September 4, 2007               [Page 3]

Internet-Draft               EAP-EXT Method                   March 2007


2.  EAP-EXT Overview

   EAP-EXT provides capabilities exchange.  One bit (R-bit) is used for
   indicating HOKEY re-authentication capability.  One bit (C-bit) is
   used for indicating channel binding capability.

   When EAP-EXT is used, the precedent EAP-Identity exchange MAY be
   omitted if the identity of the peer is known to the server before the
   server sends the first EAP-Request.  Out of band mechanisms for
   providing the identity of the peer may be used e.g., transferring the
   identity of the peer between authenticators and servers.

   In EAP-EXT, extended EAP capabilities such as HOKEY re-authentication
   and MSK channel binding are exchanged between the peer and the
   server.  At the same time, at least one EAP method (e.g., EAP-TLS) is
   run inside EAP-EXT for authenticating the peer.  Inner method(s) are
   carried in Method TLVs (Type-Length-Values).  Until an inner method
   generates EAP keying material, no AUTH TLV is included and the
   capabilities are non-protected.  Hence, if there is only one inner
   EAP method, additional EAP-EXT exchange(s) with an AUTH TLV need(s)
   to be performed after completion of the inner method and before
   sending an EAP-Success or an EAP-Failure message.

   After an inner EAP method generates EAP keying material, EAP-EXT
   messages MUST be protected with an AUTH TLV.  AUTH TLVs in EAP-EXT
   messages MUST be computed using EAP-EXT-KEY generated from EAP keying
   material of the latest successful inner method.  This means that if
   there are multiple inner EAP methods that are sequentially run inside
   EAP-EXT, a new EAP-EXT-KEY is generated each time an inner EAP method
   in the sequence generates EAP keying material.  Any inner EAP method
   MUST be capable of generating EAP keying material.

   At the end of a successful EAP-EXT run, EAP keying material is
   derived from the MSK generated by the last successful inner EAP
   method and is exported to the EAP layer.  The pseudo random function
   used for deriving the EAP keying material and USRKs (Usage Specific
   Root Keys) [I-D.salowey-eap-emsk-deriv] MAY be negotiated within EAP-
   EXT using PRF TLVs.  F-bit is used for indicating the end of EXP-EXT
   exchange.

   Figure 1 shows an example of EAP-EXT message sequence with a single
   inner EAP method and with PRF negotiation.  Figure 2 shows an example
   of EAP-EXT message sequence with multiple inner EAP methods and
   without PRF negotiation.







Ohba, et al.            Expires September 4, 2007               [Page 4]

Internet-Draft               EAP-EXT Method                   March 2007


           Peer                                                Server
            |  EAP-Request/Identity (optional)                   |
            |<---------------------------------------------------|
            |  EAP-Response/Identity (optional)                  |
            |--------------------------------------------------->|
            |  EAP-Request/EXT{Cap.(R,C),PRF(1,2),Method(Type X),|
            |                  CBM(1,2),CBD,IAL(x)}              |
            |<---------------------------------------------------|
            |  EAP-Response/EXT{Cap.(R,C),PRF(1),Method(Type X), |
            |                   CBM(1)}                          |
            |--------------------------------------------------->|
            |                  ...                               |
            |  EAP-Request/EXT{F,Cap.(R,C),PRF(1,2),Enc(Peer-ID, |
            |                  Server-ID,Reauth-Key-Lifetime),   |
            |                  CBM(1,2),CBD,IAL(x),AUTH}         |
            |<---------------------------------------------------|
            |  EAP-Response/EXT{F,Cap.(R,C),PRF(2),CBM(1),       |
            |                   AUTH}                            |
            |--------------------------------------------------->|
            |  EAP-Success                                       |
            |<---------------------------------------------------|

        F: F-bit is set
        Cap.(R,C): R-bit and C-bit of Capabilities field are set
        PRF(1,2): PRF TLV carrying PRF numbers 1 and 2
        PRF(1):   PRF TLV carrying PRF numbers 1
        Method(Type X): Method TLV carrying method Type X
        Peer-ID: Peer-ID TLV
        Server-ID: Server-ID TLV
        Reauth-Key-Lifetime: Reauth-Key-Lifetime TLV
        AUTH: AUTH TLV
        CBM(1,2): Channel-Binding-Mechanism TLV with
                  channel binding mechanism numbers 1 and 2
        CBM(1):   Channel-Binding-Mechanism TLV with
                  channel binding mechanism number 1
        CBD: Channel-Binding-Data TLV
        IAL(x): Intergrity-Algorithm TLV with algorithm x.
        Enc(...): Encrypted TLV

   Figure 1: EAP-EXT message sequence with a single inner method and PRF
                                negotiation










Ohba, et al.            Expires September 4, 2007               [Page 5]

Internet-Draft               EAP-EXT Method                   March 2007


           Peer                                                Server
            |  EAP-Request/Identity (optional)                    |
            |<----------------------------------------------------|
            |  EAP-Response/Identity (optional)                   |
            |---------------------------------------------------->|
            |  EAP-Request/EXT{Cap.(R,C),Method(Type=X),CBM(1,2), |
            |                  CBD,IAL(x)}                        |
            |<----------------------------------------------------|
            |  EAP-Response/EXT{Cap.(R,C),Method(Type=X),CBM(2),  |
            |                   CBD}                              |
            |---------------------------------------------------->|
            |                      ....                           |
            |  EAP-Request/EXT{Cap.(R,C),Method(Type=Y),          |
            |                  CBM(1,2),CBD,IAL(x),AUTH}          |
            |<----------------------------------------------------|
            |  EAP-Response/EXT{Cap.(R,C),Method(Type=Y),         |
            |                   CBM(2),CBD,AUTH}                  |
            |---------------------------------------------------->|
            |                      ....                           |
            |  EAP-Request/EXT{F,Cap.(R,C),Method(Type=Y),        |
            |                  Enc(Peer-ID, Server-ID,            |
            |                  Reauth-Key-Lifetime), CBM(1,2),    |
            |                  CBD,IAL(x),AUTH}                   |
            |<----------------------------------------------------|
            |  EAP-Response/EXT{F,Cap.(R,C),Method(Type=Y),       |
            |                   CBM(2),CBD,AUTH}                  |
            |---------------------------------------------------->|
            |  EAP-Success                                        |
            |<----------------------------------------------------|

        F: F-bit is set
        Cap.(R,C): R-bit and C-bit of Capabilities field are set
        Method(Type-X): Method TLV carrying method Type X
        Method(Type-Y): Method TLV carrying method Type Y
        Peer-ID: Peer-ID TLV
        Server-ID: Server-ID TLV
        Reauth-Key-Lifetime: Reauth-Key-Lifetime TLV
        AUTH: AUTH TLV
        CBM(1,2): Channel-Binding-Mechanism TLV with
                  channel binding mechanism numbers 1 and 2
        CBM(2):   Channel-Binding-Mechanism TLV with
                  channel binding mechanism number 2
        CBD: Channel-Binding-Data TLV
        IAL(x): Intergrity-Algorithm TLV with algorithm x.
        Enc(...): Encrypted TLV

    Figure 2: EAP-EXT message sequence with multiple inner methods and
                          without PRF negotiation



Ohba, et al.            Expires September 4, 2007               [Page 6]

Internet-Draft               EAP-EXT Method                   March 2007


3.  Error Handling

   An error may happen for several reasons, e.g., due to failure of
   inner EAP method authentication or a malformed, unknown or missing
   EAP-EXT TLV.  An error may be detected either by the peer or by the
   server.  An EAP-EXT message that caused an error is referred to as an
   erroneous message.  EAP-EXT messages with E-bit set are used for
   error indications.  These messages are referred to as error
   indications.  An error indication MUST contain an AUTH TLV, and
   SHOULD NOT contain other TLVs.

   Any erroneous message (including an erroneous error indication)
   without a valid AUTH TLV MUST be silently discarded.

   For an erroneous Request with a valid AUTH TLV, the peer sends an
   error indication Response.  For an erroneous Response with a valid
   AUTH TLV, the server sends an error indication Request which is
   responded by the peer with an error indication Response.  The server
   returns an EAP-Failure message in response to an error indication
   Response with a valid AUTH TLV.































Ohba, et al.            Expires September 4, 2007               [Page 7]

Internet-Draft               EAP-EXT Method                   March 2007


4.  Keys

   EAP-EXT defines the following types of keys.

4.1.  MSK and EMSK exported from EAP-EXT

   A set of 64-octet MSK and 64-octet EMSK to be exported from EAP-EXT
   is derived from MSK_i, the MSK generated by the last successful inner
   EAP method, using the KDF defined in [I-D.salowey-eap-emsk-deriv] in
   the following way.

   (MSK, EMSK) = KDF(MSK_i, "EAP-EXT-EAP-Keying-Material", 128)

4.2.  EAP-EXT-AUTH-KEY

   EAP-EXT-AUTH-KEY is used for computing AUTH TLVs for integrity
   protecting EAP-EXT messages.  EAP-EXT-AUTH-KEY is used within EAP-EXT
   only and is never exported.  The EAP-EXT-AUTH-KEY is derived from the
   MSK generated by the last successful inner EAP method (MSK_i), using
   the prf+ defined in [RFC4306] in the following way.

   EAP-EXT-AUTH-KEY = prf+(MSK_i, "EAP-EXT-Authentication-Key",length);

   The default hash algorithm for prf+ is PRF_HMAC_SHA2_256.

   The field length will depend upon the integrity algorithm selected by
   the EAP Server during the EAP-EXT exchange.  When HMAC-SHA-256
   [sha256] is used for the integrity algorithm, length=32.

4.3.  EAP-EXT-ENC-KEY

   EAP-EXT-ENC-KEY is used for ciphering the content of Encrypted TLVs.
   It is derived from MSK_i, the MSK generated by the last successful
   inner EAP method, using the KDF defined in
   [I-D.salowey-eap-emsk-deriv] in the following way.

   EAP-EXT-ENC-KEY = prf+(MSK_i, "EAP-EXT-Encryption-Key",length);

   The PRF used to generate EAP-EXT-AUTH-KEY is determined by the
   integrity algorithm selected by the EAP server during the EAP-EXT
   exchange.  The default hash algorithm for prf+ is PRF_HMAC_SHA2_256.

   The field length will depend upon the negotiated encryption algorithm
   negotiated during EAP-EXT exchange.  For example, when AES-CBC-128 is
   used, length=16.






Ohba, et al.            Expires September 4, 2007               [Page 8]

Internet-Draft               EAP-EXT Method                   March 2007


4.4.  HOKEY-REAUTH-KEY

   HOKEY-REAUTH-KEY is used as the pre-shared key required for the HOKEY
   re-authentication mechanism [I-D.vidya-eap-er].  The length of HOKEY-
   REAUTH-KEY depends on the HOKEY re-authentication mechanism.  The
   HOKEY-REAUTH-KEY is derived from the EMSK exported from EAP-EXT using
   the USRK derivation algorithm defined in [I-D.salowey-eap-emsk-deriv]
   as follows.

   HOKEY-REAUTH-KEY = KDF(EMSK, "EAP-EXT-Reauthentication-Key", length)









































Ohba, et al.            Expires September 4, 2007               [Page 9]

Internet-Draft               EAP-EXT Method                   March 2007


5.  Message Format

   EAP-EXT uses EAP Type XX (To be assigned by IANA).  The message
   format including the common EAP fields (i.e., Code, Identifier,
   Length and Type) defined in [RFC3748] is shown below.

    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      |    Version    |F|E| Reserved  | Capabilities  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        TLV(s) (optional)  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   F

      This bit MUST be set to indicate that this is the last EAP-EXT
      message from the sender.  Otherwise, this bit MUST NOT be set.

   E

      This bit is set when the message is an error indication.  When
      this bit is set, F-bit MUST also be set.  See Section 3 for
      detailed description on error indications.

   Version

      This 8-bit field indicates the version of the EAP-EXT method.
      This document defines Version 1.

   Reserved

      This 6-bit field is reserved for future extensions.  This field
      MUST be set to zero by the sender and the recipient MUST ignore
      this field.

   Capabilities

      This field The Capabilities field contains extended EAP
      capabilities.  The Capabilities field the following format.

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |R C r r r r r r|
   +-+-+-+-+-+-+-+-+




Ohba, et al.            Expires September 4, 2007              [Page 10]

Internet-Draft               EAP-EXT Method                   March 2007


      Each bit corresponds to a particular capability.  The semantics of
      each bit is as follows.

      R

         This bit is set to indicate that the sender supports HOKEY re-
         authentication [I-D.vidya-eap-er].  When this bit is set in the
         final Request/EXT message (i.e., the Request/EXT with F-bit is
         set), the message MUST include a Server-ID TLV and a Peer-ID
         TLV and MAY include a Reauth-Key-Lifetime AVP.  If this bit is
         set in the final Request/EXT and Response/EXT exchange, the
         peer and the server MUST generate an HOKEY-REAUTH-KEY.  The
         Server-ID and Peer-ID contained in the Server-ID and Peer-ID
         TLVs and the HOKEY-REAUTH-KEY is used for HOKEY re-
         authentication.

      C

         This bit is set to indicate that the sender supports a channel
         binding mechanism for MSK.  When this bit is set in a Request/
         EXT message, one Channel-Binding-Mechanism TLV MUST also be
         included to indicate the channel binding mechanism(s) supported
         by the server.  If the peer supports and wants to enable one of
         the channel binding mechanism(s) supported by the server, it
         sends a Response/EXT message with this bit set and one Channel-
         Binding-Mechanism TLV containing the selected channel binding
         mechanism.  If this bit is set in the final Request/EXT and
         Response/EXT exchange with successful negotiation of one
         channel binding mechanism and the EAP-EXT method completes with
         success, the peer and the server MUST enable the negotiated
         channel binding mechanism.

      Other bits are reserved for future use, and MUST be set to zero by
      the sender and MUST be ignored by the recipient.

   TLV

      Zero, one or more TLVs (Type-Length-Value's).  The TLV format of
      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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-




Ohba, et al.            Expires September 4, 2007              [Page 11]

Internet-Draft               EAP-EXT Method                   March 2007


      Type

         This field indicates the type of this TLV.

      Length

         This field indicates the length of this TLV in octets,
         including the Type and Length fields of the TLV.

      Value

         This field contains data specific to the TLV Type.







































Ohba, et al.            Expires September 4, 2007              [Page 12]

Internet-Draft               EAP-EXT Method                   March 2007


6.  EAP-EXT TLVs

   The following TLVs are defined.

6.1.  Method TLV

   The Method TLV (Type 1) contains an EAP Method payload starting from
   Type field.

6.2.  AUTH TLV

   The AUTH TLV (Type 2) contains integrity data used for protecting
   EAP-EXT messages.  The EAP-EXT-KEY is used for computing AUTH TLVs.
   The TLV-Value field is computed over the entire EAP message including
   this field.  Before computing the integrity data, this field MUST be
   initialized to all zeros.  The length of this field depends on the
   integrity algorithm in use.  When the integrity check fails, the
   message MUST be silently discarded.  The default integrity algorithm
   is HMAC-SHA-256 [sha256].

6.3.  Peer-ID TLV

   The Peer-ID TLV (Type 3) contains the identity of the peer used for
   HOKEY re-authentication.

6.4.  Server-ID TLV

   The Server-ID TLV (Type 4) contains the identity of the server used
   for HOKEY re-authentication.

6.5.  Reauth-Key-Lifetime TLV

   The Reauth-Key-Lifetime TLV (Type 5) contains the lifetime of HOKEY-
   REAUTH-KEY in seconds.

6.6.  PRF TLV

   The PRF TLV (Type 6) contains one or more one-octet PRF numbers
   defined in [I-D.salowey-eap-emsk-deriv].  When this TLV is carried in
   a Request, it indicates the PRF number(s) supported by the server.
   When this TLV is carried in a Request/EXT message, the corresponding
   Response/EXT message MAY contain this TLV.  A PRF TLV in a Response/
   EXT message MUST contain exactly one PRF number that is supported and
   selected by the peer among the PRF numbers in the Request/EXT
   message.  If the PRF number is successfully negotiated using the PRF
   TLV exchange described above, the negotiated PRF number is used for
   KDF to derive EAP keying material to be exported by EAP-EXT and
   USRKs.  Otherwise, the default PRF specified in



Ohba, et al.            Expires September 4, 2007              [Page 13]

Internet-Draft               EAP-EXT Method                   March 2007


   [I-D.salowey-eap-emsk-deriv] is used for KDF.

6.7.  Channel-Binding-Mechanism TLV

   The Channel-Binding-Mechanism TLV (Type 7) contains one or more one-
   octet channel binding mechanism numbers.  When this TLV is carried in
   a Request/EXT message, it indicates the channel binding mechanism
   number(s) supported by the server.  When this TLV is carried in a
   Request/EXT message, the corresponding Response/EXT message MAY
   contain this TLV.  A Channel-Binding-Mechanism TLV in a Response/EXT
   message MUST contain exactly one channel binding mechanism number
   that is supported and selected by the peer among the channel binding
   mechanism numbers in the Request/EXT message.  If the channel binding
   mechanism is successfully negotiated using the Channel-Binding-
   Mechanism TLV exchange described above, the negotiated channel
   binding mechanism is enabled.

   The following channel binding mechanism numbers are defined in this
   document.

        1  [I-D.ohba-eap-channel-binding]

        2  [arkko-eap-service-identity-auth]

   For channel binding mechanism 1, the default hash algorithm for prf+
   is PRF_HMAC_SHA2_256.

   For channel binding mechanism 2, an additional Channel-Binding-Data
   TLV is carried in Requests and Responses.

6.8.  Channel-Binding-Data TLV

   The Channel-Binding-Data TLV (Type 8) contains octet string data used
   for [arkko-eap-service-identity-auth].

6.9.  Encryption-Algorithm TLV

   The Encryption-Algorithm TLV allows negotiation of encryption
   algorithms used for ciphering Encrypted TLVs.  When this TLV is
   carried in a Request/EXT, it indicates the cryptographic algorithms
   supported by the EAP server.  When this TLV is carried in a Request/
   EXT message, the corresponding Response/EXT message MAY contain this
   TLV.  An Encryption-Algorithm TLV in a Response/EXT message MUST
   contain exactly one encryption algorithm number supported and
   selected by the peer among the options in the Encryption-Algorithm
   TLV contained in the Request/EXT message.  Note that the EAP Server
   MAY force the EAP Peer to use the default encryption algorithm (AES-
   CBC-128).  In such a case, the EAP peer does not include the



Ohba, et al.            Expires September 4, 2007              [Page 14]

Internet-Draft               EAP-EXT Method                   March 2007


   Encryption-Algorithm TLV in the Request/EXT message and, in the same
   way, the EAP peer does not include it in the Response/EXT either.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=Encr-Algorithm TLV     |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Encryption Algorithms ...                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   It contains one or more one-octet numbers defined in the following
   list:

          0 Reserved
          1 AES-CBC-128 (default)
          2 AES-CBC-256
          3 3DES
          4 IDEA

   Note that if the algorithms are not successfully negotiated using the
   Encryption-Algorithm TLV, the default encryption algorithm is used
   instead.

6.10.  Integrity-Algorithm TLV

   The EAP-EXT method does not allow integrity algorithm negotiation for
   simplicity and in order to avoid bidding-down attacks.  However, the
   EAP server can select from different integrity algorithms and inform
   the EAP peer about this selection through the Integrity-Algorithm
   TLV.  If the EAP server does not include this TLV the default value
   is HMAC-SHA-256.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=Intgr-Algorithm TLV    |           Length=1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Intgr.Algorithm|
      +-+-+-+-+-+-+-+-+

   It contains one or more one-octet numbers defined in the following
   list:








Ohba, et al.            Expires September 4, 2007              [Page 15]

Internet-Draft               EAP-EXT Method                   March 2007


          0  Reserved
          1  HMAC-SHA-1
          2  HMAC-SHA-224
          3  HMAC-SHA-256 (default)
          4  HMAC-SHA-384
          5  HMAC-SHA-512

6.11.  Encrypted TLV

   The Encrypted TLV (Type 10) contains one or more plaintext TLVs
   encrypted with EAP-EXT-ENC-KEY.  The length of this field depends on
   the encryption algorithm in use.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Type=Encrypted TLV      |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                            IV                                 |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    Encrypted Data...                          |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   It contains one or more one-octet numbers defined in the following
   list:

   Type

      (10) Encrypted TLV

   Length

      4 + IV Length + Encrypted Data Length.

   IV

      The IV is an Octet string of random bits, most significant bit
      first.  The length of IV depends on the encryption algorithm in
      use.  For example, for AES-CBC-128 the IV is 16 bytes (128 bits).







Ohba, et al.            Expires September 4, 2007              [Page 16]

Internet-Draft               EAP-EXT Method                   March 2007


   Encrypted Data

      Encrypted TLV of variable length.  The encrypted data consists of
      one or more plaintext TLVs ciphered with EAP-EXT-ENC-KEY.  Note
      that depending on the encryption algorithm and the length of
      plaintext data, padding data may be added to the plaintext data
      before the ciphering operation.












































Ohba, et al.            Expires September 4, 2007              [Page 17]

Internet-Draft               EAP-EXT Method                   March 2007


7.  Security Considerations

   Capability exchange before an inner EAP method exports EAP keying
   material is unprotected.  Hence, additional protected message
   exchange after creation of EAP keying material is mandated to avoid
   the capabilities information to be altered by an attacker without
   being detected by the peer and the server.

   EAP-EXT allows sequencing of multiple EAP methods inside it.  It is
   known that a compound authentication method that consists of multiple
   nested or sequential authentication methods without cryptographically
   binding them has a vulnerability to man-in-the-middle attack.  EAP-
   EXT is able to create the required cryptographically binding by
   protecting each inner EAP method together with the outer EAP method
   (i.e., EAP-EXT) with a key generated by its precedent successful
   inner method in the sequence and finally exporting EAP keying
   material derived from that is generated by the last successful inner
   EAP method.  In order to achieve cryptographic binding, EAP-EXT
   requires inner EAP methods to be capable of generating EAP keying
   material.

   This method exports MSK and EMSK that are computed from MSK of an
   inner method.  Therefore, the strength of exported MSK and EMSK
   altogether is the same as that of the MSK of the inner method.



























Ohba, et al.            Expires September 4, 2007              [Page 18]

Internet-Draft               EAP-EXT Method                   March 2007


8.  IANA Considerations

   TBD.
















































Ohba, et al.            Expires September 4, 2007              [Page 19]

Internet-Draft               EAP-EXT Method                   March 2007


9.  Acknowledgments

   The authors would like to thank Bernard Aboba and Jari Arkko for
   their valuable inputs.















































Ohba, et al.            Expires September 4, 2007              [Page 20]

Internet-Draft               EAP-EXT Method                   March 2007


10.  References

10.1.  Normative References

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

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

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

   [I-D.ietf-eap-keying]
              Aboba, B., "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying-18 (work in
              progress), February 2007.

   [I-D.vidya-eap-er]
              Narayanan, V. and L. Dondeti, "EAP Extensions for
              Efficient Re-authentication", draft-vidya-eap-er-02 (work
              in progress), January 2007.

   [I-D.ohba-eap-channel-binding]
              Ohba, Y., "Channel Binding Mechanism based on Parameter
              Binding in Key Derivation",
              draft-ohba-eap-channel-binding-02 (work in progress),
              December 2006.

   [I-D.salowey-eap-emsk-deriv]
              Salowey, J., "Specification for the Derivation of Usage
              Specific Root Keys (USRK) from an  Extended Master Session
              Key (EMSK)", draft-salowey-eap-emsk-deriv-01 (work in
              progress), June 2006.

   [sha256]   National Institute of Standards and Technology, "Secure
              Hash Standard", August 2002.

10.2.  Informative References

   [arkko-eap-service-identity-auth]
              Arkko, J. and P. Eronen, "Authenticated Service
              Information for the Extensible Authentication Protocol
              (EAP)",  http://tools.ietf.org/html/
              draft-arkko-eap-service-identity-auth-04, October 2005.





Ohba, et al.            Expires September 4, 2007              [Page 21]

Internet-Draft               EAP-EXT Method                   March 2007


Authors' Addresses

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscateway, NJ  08854
   USA

   Phone: +1 732 699 5365
   Email: yohba@tari.toshiba.com


   Subir Das
   Telcordia
   1 Telcordia Drive
   Piscateway, NJ  08854
   USA

   Phone: +1 732 699 2483
   Email: subir@research.telcordia.com


   Rafael Marin Lopez
   Faculty of Computer Science
   University of Murcia
   Murcia  30100
   Spain

   Phone: +34968398501
   Email: rafa@dif.um.es





















Ohba, et al.            Expires September 4, 2007              [Page 22]

Internet-Draft               EAP-EXT Method                   March 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Ohba, et al.            Expires September 4, 2007              [Page 23]