Internet DRAFT - draft-hao-hokey-eep

draft-hao-hokey-eep






Network Working Group                                       H. Wang, Ed.
Internet-Draft                                               Y. Shi, Ed.
Intended status: Standards Track            Hangzhou H3C Tech. Co., Ltd.
Expires: April 21, 2011                                          T. Tsou
                                                     Huawei Technologies
                                                        October 18, 2010


       EAP Extensions for EAP Early Authentication Protocol (EEP)
                         draft-hao-hokey-eep-00

Abstract

   The Extensible Authentication Protocol (EAP) is a generic framework
   supporting multiple types of authentication methods.

   Based on the EAP Early Authentication Model defined by RFC5836, this
   document specifies the extensions of EAP to support both intra-AAA-
   realm and inter-AAA-realm handover.

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 April 21, 2011.

Copyright Notice

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

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



Wang, et al.             Expires April 21, 2011                 [Page 1]

Internet-Draft                     EEP                      October 2010


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Standards Language . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Message Flow of EAP Early Authentication . . . . . . . . . . .  4
     3.1.  Intra-AAA-Realm Handover . . . . . . . . . . . . . . . . .  4
     3.2.  Inter-AAA-Realm Handovers  . . . . . . . . . . . . . . . .  5
   4.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Solution . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Protocol Message Flow  . . . . . . . . . . . . . . . . . . . .  9
     7.1.  Intra-AAA-Realm Handovers  . . . . . . . . . . . . . . . .  9
     7.2.  Inter-AAA-Realm Handovers(Full trust relationship) . . . . 10
     7.3.  Inter-AAA-Realm Handovers(Semi trust relationship) . . . . 12
     7.4.  Release authentication session . . . . . . . . . . . . . . 14
   8.  EEP Key Hierarchy  . . . . . . . . . . . . . . . . . . . . . . 16
     8.1.  Key Derivation . . . . . . . . . . . . . . . . . . . . . . 17
       8.1.1.  pRK Derivation . . . . . . . . . . . . . . . . . . . . 17
       8.1.2.  pIK Derivation . . . . . . . . . . . . . . . . . . . . 17
       8.1.3.  pMSK Derivation  . . . . . . . . . . . . . . . . . . . 17
   9.  Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 17
     9.1.  EAP Initiate/Re-auth-Start Packet Extension  . . . . . . . 18
     9.2.  EAP Initiate/Pre-Early-auth  . . . . . . . . . . . . . . . 19
     9.3.  EAP Finish/Pre-Early-auth  . . . . . . . . . . . . . . . . 21
     9.4.  EAP Initiate/Post-Early-auth . . . . . . . . . . . . . . . 24
     9.5.  EAP Finish/Post-Early-auth . . . . . . . . . . . . . . . . 25
     9.6.  EAP Initiate/Early-auth Action . . . . . . . . . . . . . . 27
     9.7.  EAP Finish/Early-auth Action . . . . . . . . . . . . . . . 30
   10. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 33
   11. AAA Transport Considerations . . . . . . . . . . . . . . . . . 33
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 34
     15.2. Informative References . . . . . . . . . . . . . . . . . . 34









Wang, et al.             Expires April 21, 2011                 [Page 2]

Internet-Draft                     EEP                      October 2010


1.  Introduction

   The Extensible Authentication Protocol (EAP) [RFC3748] is a generic
   framework supporting multiple types of authentication methods.  In
   systems where EAP is used for authentication, the handover process
   often requires authentication and authorization for acquisition or
   modification of resources assigned to the mobile device.  In most
   cases, these authentications and authorizations require interaction
   with a central authority in a realm.  In some cases, the central
   authority may be distant from the mobile device.  The delay
   introduced due to such an authentication and authorization procedure
   adds to the handover latency and consequently affects ongoing
   application sessions.

   In the problem statement [RFC5836], it suggests that optimized
   solutions for secure inter-authenticator handovers can be seen either
   as security context transfer (e.g., using the EAP Extensions for EAP
   Re-authentication Protocol (ERP)) [RFC5296], or as EAP Early
   Authentication.

   This document specifies EAP Extensions for Early Authentication
   Model.  The protocol that uses these extensions itself is referred to
   as the EAP Early Authentication Protocol (EEP).  A peer does EAP
   method-independent Early Authentication before it attaches to a CAP.
   The protocol and the key hierarchy required for EAP Early
   Authentication are described in this document.

   Note that to support EEP, lower-layer specifications may need to be
   revised to allow carrying EAP messages that have a code value more
   than 4 and to accommodate the peer-initiated nature of EEP.
   Specifically, the IEEE802.1x specification must be revised and RFC
   4306 must be updated to carry EEP messages.

2.  Terminology

2.1.  Standards Language

   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 RFC 2119 [RFC2119]

2.2.  Acronyms

   The following acronyms are used in this document; see the references
   for more details.






Wang, et al.             Expires April 21, 2011                 [Page 3]

Internet-Draft                     EEP                      October 2010


   AAA Authentication, Authorization and Accounting [RFC3588]

   CAP Candidate Attachment Point [RFC5836]

   MH  Mobile Host

   SAP Serving Attachment Point [RFC5836]

3.  Message Flow of EAP Early Authentication

   Based on the functional elements of EAP Early Authentication
   [RFC5836], the following sections introduce the general message flow
   of Inter-AAA-Realm and Intra-AAA-Realm handovers.  The figures below
   are to give an overview of EAP Early Authentication.

   It is assumed that the MH has previously completed full EAP
   authentication with Home AAA.

3.1.  Intra-AAA-Realm Handover

   In intra-AAA-realm handover scenario, SAP and CAP belong to a same
   AAA realm.


               +------+    +-----+   +-------+    +--------+
               |  MH  |    | SAP |   |  CAP  |    |Home AAA|
               +--+---+    +--+--+   +---+---+    +----+---+
                  |           |          |             |
                  |       Early  Authentication        |
                  |<--------->|<---------|------------>|
                  |           |          |             |
                  |           |          |             |
                  |    Attach to the CAP |             |
                  |-----------|--------->|------------>|
                  |           |          |             |
                  |           |          |    pMSK     |
                  |           |          |<------------|
                  |           |          |             |

                    Figure 1: Intra-AAA-Realm Handover

   Before MH (peer) performs handover from SAP to CAP, it does early
   authentication with Home AAA.

   Since SAP and CAP belong to the same Home AAA, the complete EAP
   method exchange is not required in early authentication.  The MH
   informs Home AAA of the NAS-id of CAPs and each CAP's sequence
   number.  Home AAA will derive the pMSK from EMSK and sequence number.



Wang, et al.             Expires April 21, 2011                 [Page 4]

Internet-Draft                     EEP                      October 2010


   Sequence number must be unique for each CAP to derive a unique pMSK.

   After handover, MH attaches to the CAP.  MH request to change from
   early authenticated state to fully authorized and authenticated
   state.  Its Home AAA is not changed.  And then Home AAA distribute
   the pMSK to CAP.

3.2.  Inter-AAA-Realm Handovers

   In inter-AAA-realm scenario, as the first step, Home AAA and CAP-AAA
   need to establish a trust relationship.

   There are two cases for this step.

   In first case, Home AAA and CAP-AAA belong to a same operator.  In
   this case, a full trust relationship may be established.  That means
   security context transfer between AAA servers is permitted.


   +------+    +-----+    +-------+   +--------+  +-----+  +-------+
   |  MH  |    | SAP |    |SAP-AAA|   |Home AAA|  | CAP |  |CAP-AAA|
   +--+---+    +--+--+    +---+---+   +----+---+  +--+--+  +---+---+
      |           |           |            |         |         |
      |           |           |Establish Trust Relationship Between AAAs
      |           |           |            |<--------|-------->|
      |           |           |            |         |         |
      |         Early  Authentication     Early  Authentication|
      |<--------->|<--------->|<---------->|<--------|-------->|
      |           |           |            |         |         |
      |           |           |            |  DSRK, EMSK Name  |
      |           |           |            |<--------|-------->|
      |           |           |            |         |         |
      |           |   Attach to the CAP    |         |         |
      |-----------|-----------|------------|-------->|-------->|
      |           |           |            |         |         |
      |           |           |            |         |   pMSK  |
      |           |           |            |         |<--------|
      |           |           |            |         |         |

       Figure 2: Inter-AAA-Realm Handovers(Full trust relationship)


   Before MH (peer) performs handover from SAP to CAP, it does early
   authentication with CAP-AAA, and messages will be forwarded by SAP,
   SAP-AAA and Home AAA to CAP-AAA.

   Since Home AAA and CAP-AAA belong to the same operator, the complete
   EAP method exchange is not required in early authentication.  The



Wang, et al.             Expires April 21, 2011                 [Page 5]

Internet-Draft                     EEP                      October 2010


   CAP-AAA will get DSRK and EMSK Name from Home AAA and derive pMSK
   from DSRK directly.

   After handover, MH attaches to the CAP.  Its Home AAA is not changed
   and CAP-AAA becomes the new local AAA server(SAP-AAA).

   In second case, Home AAA and CAP-AAA belong to different operators.
   In this case, a semi trust relationship may be established.  That
   means two AAA servers can recognize each other based on domain name
   and communicate each other.  But the security context transfer is not
   permitted.


   +------+    +-----+    +-------+   +--------+  +-----+  +-------+
   |  MH  |    | SAP |    |SAP-AAA|   |Home AAA|  | CAP |  |CAP-AAA|
   +--+---+    +--+--+    +---+---+   +----+---+  +--+--+  +---+---+
      |           |           |            |         |         |
      |           |           |Establish Trust Relationship Between AAAs
      |           |           |            |<--------|-------->|
      |           |           |            |         |         |
      |         Early  Authentication      Early Authentication|
      |<--------->|<--------->|<---------->|<--------|-------->|
      |           |           |            |         |         |
      |           |        EAP Method Exchange       |         |
      |<----------|-----------|------------|---------|-------->|
      |           |           |            |         |         |
      |           |        Attach to the CAP         |         |
      |-----------|-----------|------------|-------->|-------->|
      |           |           |            |         |         |
      |           |           |            |         |   pMSK  |
      |           |           |            |         |<--------|
      |           |           |            |         |         |

       Figure 3: Inter-AAA-Realm Handovers(Semi trust relationship)

   Since Home AAA and CAP-AAA belong to the different operators,
   usually, a complete EAP method exchange will be done in early
   authentication.  MSK and EMSK will be derived in full EAP
   authentication.  CAP-AAA will use the MSK as the pMSK.

   After handover, MH attaches to the CAP, its Home AAA is changed and
   CAP-AAA acts as a new Home AAA.

4.  Problem Statement

   According to the general message flow of Intra-AAA-Realm and Inter-
   AAA-Realm handovers, the following problems need to be resolved for
   Early Authentication Model.



Wang, et al.             Expires April 21, 2011                 [Page 6]

Internet-Draft                     EEP                      October 2010


   1) How to establish a trust relationship between Home AAA and CAP-
   AAA?

      It is an important issue but the solution is out of the scope of
      this document.

   2) How does MH knows whether a complete EAP method exchange is
   required?

      A method is required for MH to negotiate this issue with CAP-AAA
      when it request to start the early authentication.

   3) How does MH get CAP's status and capability information in
   advance?

      CAPs are discovered through EAP Lower layer.  But early
      authentication is done through EAP layer.  MH needs to know
      whether the discovered CAPs can be early authenticated through
      Home AAA or not.  If MH can't get such knowledge before the early
      authentication, it is evident that the handover experience will be
      inefficient.

   4) How to forward the EEP message between MH and CAP-AAA?

      Unlike normal EAP authentication, The SAP-AAA and Home AAA should
      forward EAP early authentication packets to CAP-AAA instead of
      processing them locally.  So the SAP-AAA and Home AAA should know
      the domain name of CAP-AAA and when the early authentication is
      started.

   5) How to handle the frequent MH handover?

      AAA server needs to maintain early authentication sessions, while
      frequent MH handover may lead to redundant obsolete early
      authentication sessions on AAA servers.  A mechanism is required
      to settle this situation.

   6) How to ensure the information consistent between MH and CAP-AAA?

      It is a high possibility of information inconsistency between MH
      and CAP-AAA.  For example, after handover, MH starts to use pMSK
      for EAP lower layer key derivation.  But the early authentication
      session on CAP-AAA has just been expired without notifying MH.








Wang, et al.             Expires April 21, 2011                 [Page 7]

Internet-Draft                     EEP                      October 2010


5.  Solution

   Similiar to ERP protocol, a trigger message is required by SAP to
   infom MH of its capability to support early authentication.  To avoid
   redundant trigger message, EAP Initiate/Re-auth-Start [RFC5296] is
   reused and one E flag is added to indicate whether EEP is supported.

   EAP Codes 5(EAP Initiate) and 6(EAP Finish) defined in the protocol
   of ERP [RFC5296] is reused.

   New EAP Initiate/Pre-early-auth and EAP Finish/Pre-early-auth
   messages are defined to start the early authentication and negotiate
   whether full EAP authentication is required.

   New EAP Initiate/Post-early-auth and EAP Finish/Post-early-auth
   messages are defined to confirm the early authentication information
   and change the state from early authenticated to fully authorized and
   authenticated.

   Early auth action message is defined for below functionality.

   - Probe whether the early authentication is supported for sepecified
   CAP.

   - Release the early authentication session to avoid redudant resource
   assumption.

   - Request to change from fully authenticated state to early
   authenticated state.

6.  Assumptions

   For the solution, it is assumed that:

   - The trust relationship has been established between Home AAA server
   and CAP-AAA server.

   - EEP server has co-located with the AAA server.

   - The authenticator act as a pass-through entity for early
   authentication protocol in a manner similar to that of an EAP
   authenticator described in RFC3748.

   - The entity which support EEP can also support ERP [RFC5296].  So MH
   can use ERP message to obtain the local domain name.

   - MH has fully authenticated with Home AAA before handover.




Wang, et al.             Expires April 21, 2011                 [Page 8]

Internet-Draft                     EEP                      October 2010


7.  Protocol Message Flow

   Based on the Section 3 and Section 5, the below figures show the
   protocol message flow of EEP protocol.

7.1.  Intra-AAA-Realm Handovers


    +---+            +-----+              +-----+         +---------+
    |MH |            | SAP |              | CAP |         |Home AAA |
    +-+-+            +--+--+              +--+--+         +----+----+
      |                 |                    |                 |
    1.| EAP Initiate/   |                    |                 |
      | Pre-Early-auth  |    AAA(EAP Initiate/Pre-Early-auth)  |
      |---------------->|--------------------|---------------->|
      |                 |                    |                 |
      |                 |                    |                 |
    2.|   EAP Finish/   |                    |                 |
      | Pre-Early-auth  |    AAA(EAP Finish/Pre-Early-auth)    |
      |<----------------|<-------------------|-----------------|
      |                 |                    |                 |
    3.|                 |                    | AAA(EAP Init/   |
      |  EAP Initiate/Post-Early-auth        | Post-Early-auth)|
      |-----------------|------------------->|---------------->|
      |                 |                    |                 |
      |                 |                    |          |--------------|
      |                 |                    |          |CA Authorized |
      |                 |                    |          |      &       |
      |                 |                    |          |Authenticated;|
      |                 |                    |          |    Keying    |
      |                 |                    |          |   material   |
      |                 |                    |          |    derived   |
      |                 |                    |          |--------------|
      |                 |                    |                 |
      |                 |                    |    AAA(pMSK)    |
      |                 |                    |<----------------|
      |                 |                    |                 |
    4.|                 |                    | AAA(EAP Finish/ |
      |  EAP Finish/Post-Early-auth          | Post-Early-auth)|
      |<----------------|--------------------|<----------------|
      |                 |                    |                 |


                    Figure 4: Intra-AAA-Realm Handovers







Wang, et al.             Expires April 21, 2011                 [Page 9]

Internet-Draft                     EEP                      October 2010


   1) MH request to start the early authentication

      MH starts the early authentication using EAP Initiate/
      Pre-Early-auth message.  In Pre-Early-auth message, the NAS-id of
      CAP and sequence number is included.  EAP Initiate/Pre-Early-auth
      is protected by pIK for middle man attack.

   2) Home AAA respond with early authentication result

      When Home AAA receive the request from MH, it verify the
      availability of CAP's NAS-id.  And check whether EEP is supported
      by this CAP.  Home AAA respond with early authentication result
      using EAP Finish/Pre-Early-auth message. pMSK will be derived from
      EMSK and sequence number and will be kept in early authentication
      session.

   3) MH request to change its state

      After handover, MH request to change its state from early
      authenticated state to fully authorized and authenticated state.
      In EAP Initiate/Post-Early-auth message, the NAS-id of CAP and
      EMSK name is included.

   4) Home AAA confirm the state change

      Home AAA confirm the NAS-id and key name, and then respond with
      state changing result using EAP Finish/Post-Early-auth message.
      Home AAA distribute the pMSK to the CAP.

7.2.  Inter-AAA-Realm Handovers(Full trust relationship)

   It is assumed that SAP-AAA act as the Home AAA server.



















Wang, et al.             Expires April 21, 2011                [Page 10]

Internet-Draft                     EEP                      October 2010


    +---+            +-----+           +-------+  +-----+     +-------+
    |MH |            | SAP |           |SAP-AAA|  | CAP |     |CAP-AAA|
    +-+-+            +--+--+           +---+---+  +--+--+     +---+---+
      |                 |                  |         |            |
    1.| EAP Initiate/   | AAA(EAP Initiate/|  AAA(EAP Initiate/   |
      | Pre-Early-auth  | Pre-Early-auth)  |  Pre-Early-auth)     |
      |---------------->|----------------->|--------------------->|
      |                 |                  |         |            |
    2.|                 |                  |  AAA(DSRK Request)   |
      |                 |                  |<---------------------|
      |                 |                  |         |            |
      |                 |                  |AAA(DSRK, EMSK Name)  |
      |                 |                  |--------------------->|
      |                 |                  |         |            |
    3.|   EAP Finish/   |   AAA(EAP Finish/|  AAA(EAP Finish/     |
      | Pre-Early-auth  |   Pre-Early-auth)|  Pre-Early-auth)     |
      |<----------------|<-----------------|<---------------------|
      |                 |                  |         |            |
    4.|                 |                  |      AAA(EAP Init/   |
      |   EAP Initiate/Post-Early-auth     |     Post-Early-auth) |
      |-----------------|------------------|-------->|----------->|
      |                 |                  |         |            |
      |                 |                  |         | |--------------|
      |                 |                  |         | |CA Authorized |
      |                 |                  |         | |      &       |
      |                 |                  |         | |Authenticated;|
      |                 |                  |         | |    Keying    |
      |                 |                  |         | |   material   |
      |                 |                  |         | |    derived   |
      |                 |                  |         | |--------------|
      |                 |                  |         |            |
      |                 |                  |         | AAA(pMSK)  |
      |                 |                  |         |<-----------|
      |                 |                  |         |            |
    5.|                 |                  |       AAA(EAP Finish/|
      |   EAP Finish/Post-Early-auth       |      Post-Early-auth)|
      |<----------------|------------------|---------|<-----------|
      |                 |                  |         |            |


       Figure 5: Intra-AAA-Realm Handovers(Full trust relationship)

   1) MH request to start the early authentication

      MH starts the early authentication using EAP Initiate/
      Pre-Early-auth message.  In Pre-Early-auth message, the NAS-id-NAI
      of CAP and sequence number is included.  Based on the realm part
      of NAS-id-NAI, the SAP-AAA will forward the Pre-Early-auth message



Wang, et al.             Expires April 21, 2011                [Page 11]

Internet-Draft                     EEP                      October 2010


      to the corresponding CAP-AAA. if the CAP-AAA can not be found or
      trust relationship has not been established, SAP-AAA will directly
      reject the early authentication request.

   2) CAP-AAA request DSRK and EMSK Name from SAP-AAA

      After receiving the ealy authentication request, CAP-AAA find that
      the full trust relationship has been established between SAP-AAA
      and CAP-AAA.  So CAP-AAA request DSRK and EMSK name from SAP-
      AAA(Home AAA).

   3) CAP-AAA respond with early authentication result

      Home AAA respond with early authentication result using EAP
      Finish/Pre-Early-auth message. pMSK will be derived from DSRK and
      sequence number and will be kept in early authentication entry.

   4) MH request to change its state

      After handover, MH request to change its state from early
      authenticated state to fully authorized and authenticated state.

   5) Home AAA confirm the state change

      Home AAA respond with state changing result using EAP Finish/
      Post-Early-auth message.  Home AAA distribute the pMSK to the CAP.

7.3.  Inter-AAA-Realm Handovers(Semi trust relationship)

   It is assumed that SAP-AAA act as the Home AAA server.





















Wang, et al.             Expires April 21, 2011                [Page 12]

Internet-Draft                     EEP                      October 2010


   +---+             +-----+              +-------+ +-----+    +-------+
   |MH |             | SAP |              |SAP-AAA| | CAP |    |CAP-AAA|
   +-+-+             +--+--+              +---+---+ +--+--+    +---+---+
     |                  |                     |        |           |
   1.|   EAP Initiate/  |   AAA(EAP Initiate/ |  AAA(EAP Initiate/ |
     |  Pre-Early-auth  |    Pre-Early-auth)  |   Pre-Early-auth)  |
     |----------------->|-------------------->|------------------->|
     |                  |                     |        |           |
   2.|   EAP Finish/    |   AAA(EAP Finish/   |   AAA(EAP Finish/  |
     |  Pre-Early-auth  |   Pre-Early-auth)   |   Pre-Early-auth)  |
     |<-----------------|<--------------------|<-------------------|
     |                  |                     |        |           |
   3.|EAP Authentication|            AAA(EAP Authentication)       |
     |<---------------->|<------------------->|<------------------>|
     |                  |                     |        |           |
   4.|                  |                     |    AAA(EAP Init/   |
     |   EAP Initiate/Post-Early-auth         |    Post-Early-auth)|
     |------------------|---------------------|------->|---------->|
     |                  |                     |        |           |
     |                  |                     |        | |-------------|
     |                  |                     |        | |CA Authorized|
     |                  |                     |        | |      &      |
     |                  |                     |        | |Authenticated|
     |                  |                     |        | |    Keying   |
     |                  |                     |        | |   material  |
     |                  |                     |        | |    derived  |
     |                  |                     |        | |-------------|
     |                  |                     |        |           |
     |                  |                     |        | AAA(pMSK) |
     |                  |                     |        |<----------|
     |                  |                     |        |           |
   5.|                  |                     |     AAA(EAP Finish/|
     |   EAP Finish/Post-Early-auth           |    Post-Early-auth)|
     |<-----------------|---------------------|--------|<----------|
     |                  |                     |        |           |


       Figure 6: Inter-AAA-Realm Handovers(Semi trust relationship)

   1) MH request to start the early authentication

      MH starts the early authentication using EAP Initiate/
      Pre-Early-auth message.  In Pre-Early-auth message, the NAS-id-NAI
      of CAP and sequence number is included.  Based on the realm part
      of NAS-id-NAI, the SAP-AAA will forward the Pre-Early-auth message
      to the corresponding CAP-AAA. if the CAP-AAA can not be found or
      trust relationship has not been established, SAP-AAA will directly
      reject the early authentication request.



Wang, et al.             Expires April 21, 2011                [Page 13]

Internet-Draft                     EEP                      October 2010


   2) CAP-AAA respond with early authentication result

      After receiving the ealy authentication request, CAP-AAA find that
      the semi trust relationship has been established between SAP-AAA
      and CAP-AAA.  Home AAA respond with early authentication result
      using EAP Finish/Pre-Early-auth message.  And in the message, Home
      AAA inform MH that full EAP authentication is required.

   3) MH do full EAP authentication with CAP-AAA

      MH do eap authentication with CAP-AAA with full authentication
      method exchange.  SAP-AAA will forward the EAP authentication
      message to CAP-AAA and reponse message to MH.

   4) MH request to change its state

      After handover, MH request to change its state from early
      authenticated state to fully authorized and authenticated state.

   5) Home AAA confirm the state change

      Home AAA respond with state changing result using EAP Finish/
      Post-Early-auth message.  Home AAA distribute the pMSK to the CAP.

7.4.  Release authentication session


























Wang, et al.             Expires April 21, 2011                [Page 14]

Internet-Draft                     EEP                      October 2010


   +---+             +-----+              +-------+ +-----+    +-------+
   |MH |             | SAP |              |SAP-AAA| | CAP2|    |CAP-AAA|
   +-+-+             +--+--+              +---+---+ +--+--+    +---+---+
     |                  |                     |        |           |
   1.|   EAP Initiate/  |  AAA(EAP Initiate/  |  AAA(EAP Initiate/ |
     |Early-auth Action/| Early-auth Action/  | Early-auth Action/ |
     |    De-Pre-auth   |    De-Pre-auth      |     De-Pre-auth    |
     |----------------->|-------------------->|------------------->|
     |                  |                     |        |           |
   2.|   EAP Initiate/  |  AAA(EAP Initiate/  |        |           |
     |Early-auth Action/| Early-auth Action/  |        |           |
     |   De-Post-auth   |    De-Post-auth     |        |           |
     |----------------->|-------------------->|        |           |
     |                  |                     |        |           |
   3.|                  |                     |    AAA(EAP Init/   |
     |   EAP Initiate/Post-Early-auth         |    Post-Early-auth)|
     |------------------|---------------------|------->|---------->|
     |                  |                     |        |           |
     |                  |                     |        | |-------------|
     |                  |                     |        | |CA Authorized|
     |                  |                     |        | |      &      |
     |                  |                     |        | |Authenticated|
     |                  |                     |        | |    Keying   |
     |                  |                     |        | |   material  |
     |                  |                     |        | |    derived  |
     |                  |                     |        | |-------------|
     |                  |                     |        |           |
     |                  |                     |        | AAA(pMSK) |
     |                  |                     |        |<----------|
     |                  |                     |        |           |
   4.|                  |                     |     AAA(EAP Finish/|
     |   EAP Finish/Post-Early-auth           |    Post-Early-auth)|
     |<-----------------|---------------------|--------|<----------|
     |                  |                     |        |           |


                                 Figure 7

   1) MH release the early authentication session with CAP1

      MH sends EAP Initiate/Early-auth Action/De-Pre-auth to inform CAP-
      AAA release early authentication session for CAP1.

   2) MH release the full authentication session with SAP

      MH sends EAP Initiate/Early-auth Action/De-Post-auth to inform
      SAP-AAA to change its state from full authorized and authenticated
      state to early authenticated state.



Wang, et al.             Expires April 21, 2011                [Page 15]

Internet-Draft                     EEP                      October 2010


   3) MH request to change its state

      After handover, MH request to change its state from early
      authenticated state to fully authorized and authenticated state.

   4) Home AAA confirm the state change

      Home AAA respond with state changing result using EAP Finish/
      Post-Early-auth message.  Home AAA distribute the pMSK to the
      CAP2.

8.  EEP Key Hierarchy

   EEP uses key hierarchy similar to that of ERP [RFC5296].  The EMSK is
   used to derive the EEP pre-established Root Key (pRK).  Similarly,
   the EEP pre-established Integrity Key (pIK) and the pre-established
   Master Session Key (pMSK) is derived from the pRK.  The pMSK is
   established for the CAP(s) when the peer early authenticates to the
   network.  The pIK is established for the peer to do post early
   authentication after handover.  The hierarchy relationship is
   illustrated in Figure 8, below.

                     (inter-AAA-realm) (intra-AAA-realm)
                            DSRK            EMSK
                             |               |
                     +-------+-------+-------+-------+
                     |               |               |
                    pRK             rRK             ...

                                 Figure 8

   The EMSK and DSRK both can be used to derive the pRK.  In general,
   the pRK is derived from the EMSK in case of the peer moving in the
   Home AAA realm and derived from the DRSK in case of the peer moving
   in the visited AAA realm.  The DSRK is delivered from the EAP server
   to the EEP server as specified in [I-D.ietf-dime-local-keytran]. if
   the peer has previously authenticated by means of EEP, the DSRK
   SHOULD be directly re-used.

                                    pRK
                                     |
                         +-----------+-----------+
                         |           |           |
                        pIK         pMSK        ...

                                 Figure 9

   The pRK is used to derive the pIK and pMSK for the CAP(s).  Different



Wang, et al.             Expires April 21, 2011                [Page 16]

Internet-Draft                     EEP                      October 2010


   sequence numbers for each CAP MUST be used to derive the unique
   pMSK(s).

8.1.  Key Derivation

   As specified in [I-D.ietf-hokey-erp-aak], the key derivation method
   is given below.

8.1.1.  pRK Derivation

   pRK = KDF (K, S), where K = EMSK or DSRK and S = pRK Label | "\0" |
   length

   The pRK Label is an IANA-assigned 8-bit ASCII string:

   EAP Early authentication Root Key@ietf.org

8.1.2.  pIK Derivation

   pIK = KDF (K, S), where K = pRK and S = pIK Label | "\0" |
   cryptosuite | length

   The pIK Label is the 8-bit ASCII string:

   Early authentication Integrity Key@ietf.org

8.1.3.  pMSK Derivation

   pMSK = KDF (K, S), where K = pRK and S = pMSK label | "\0" | SEQ |
   length

   The pMSK label is the 8-bit ASCII string:

   Early authentication Master Session Key@ietf.org

9.  Packet and TLV Extension

   EEP reuse EAP Codes 5(EAP Initiate) and 6(EAP Finish) defined in the
   protocol of ERP [RFC5296].  The packet format for these messages
   follows the EAP packet format defined in RFC 3748.











Wang, et al.             Expires April 21, 2011                [Page 17]

Internet-Draft                     EEP                      October 2010


      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     |   Type-Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 10: EAP Packet

   Code

   5 Initiate

   6 Finish

   Identifier

   Refer to [RFC5296] Section 5.3

   Type

   This field indicates that this is an EEP exchange.  Three new Type
   values are defined for the purpose of early authentication.

   3 Pre-Early-auth

   4 Post-Early-auth

   5 Early-auth Action

   Type-Data

   The Type-Data field varies with the Type of early authentication
   packet.

9.1.  EAP Initiate/Re-auth-Start Packet Extension

   One E flag bit is added in EAP Initiate/Re-auth-Start message.

      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      |E| Reserved    |     1 or more TVs or TLVs     ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Wang, et al.             Expires April 21, 2011                [Page 18]

Internet-Draft                     EEP                      October 2010


               Figure 11: EAP Initiate/Re-auth-Start Packet

   Code = 5(EAP Initiate)

   Identifier

   Refer to [RFC5296] Section 5.3

   Type = 1(Re-auth-Start)

   Flags

   'E' - The E flag is used to indicate whether EEP is supported or not.
   If E Bit is set to 1, it indicate that EEP is supported by the
   authenticator and the MH can start the early authentication.  If E
   Bit is set to 0, MH can not start early authentication using EEP.

   Reserved: MUST be set to 0.

   TVs or TLVs: refer to ERP [RFC5296].

   To avoid redundant trigger message at the beginning, No new early
   authentication start message is defined.

9.2.  EAP Initiate/Pre-Early-auth

      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    |R|S|A|C|Reserved|           SEQ                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    1 or more TVs or TLVs                    ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cryptosuite |            Authentication Tag                 ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 12: EAP Initiate/Pre-Early-auth Packet

   Code = 5(EAP Initiate)

   Identifier

   Refer to [RFC5296] Section 5.3

   Type = 3(Pre-Early-auth)




Wang, et al.             Expires April 21, 2011                [Page 19]

Internet-Draft                     EEP                      October 2010


   Flags

   'R' - The value of result flag MUST be zero and ignored on reception.

   'S' - The value of secure flag indicate whether cryptosuite and
   authentication tag is appended.

   0 Cryptosuite and Authentication Tag are not appended.

   1 Cryptosuite and Authentication Tag are appended at the end of
   message.

   When the EAP Initiate/Early-auth action message is transferred
   between SAP-AAA and Home-AAA, S Bit = 0.

   'A' - Authentication flag:

   0 MH do not request to do full EAP authentication.

   1 MH request to do full EAP authentication.

   'C' - Continue flag:

   0 This is a normal Pre-Early-auth message.

   1 This message is used to extend the lifetime of Pre-Early-auth
   session.

   SEQ

   A 16-bit sequence number is used for replay protection.

   TVs and TLVs

   NAS-Identifier: This is a TLV payload, type is 4.  Exactly one NAS-
   Identifier or NAS-Identifier-NAI TLV SHOULD be included in the EAP
   Initiate/Pre-Early-auth message.

   NAS-Identifier-NAI: This is a TLV payload, type is TBD.  Exactly one
   NAS-Identifier or NAS-Identifier-NAI TLV SHOULD be included in the
   EAP Initiate/Pre-Early-auth message.

   List of cryptosuites: This is a TLV payload, type is 5.  Exactly one
   List of cryptosuites TLV SHOULD be included in the EAP Initiate/
   Pre-Early-auth message.

   KeyName-NAI: This is a TLV payload.  Type = 1.  When the S Bit is set
   to 1, exactly one KeyName-NAI attribute SHOULD be present in an EAP



Wang, et al.             Expires April 21, 2011                [Page 20]

Internet-Draft                     EEP                      October 2010


   Initiate/Pre-Early-auth packet.

   Sequence Number: It is carried in a TV payload.  The Type is TBD
   (which is lower than 128).  When the C flag is set to 1, exactly one
   sequence number SHOULD be present in an EAP Initiate/Pre-Early-auth
   packet.

   Cryptosuite: This field indicates the integrity algorithm and the PRF
   used for EEP.  Key lengths and output lengths are either indicated or
   obvious from the cryptosuite name.

   We specify some cryptosuites below:

   * 0 RESERVED

   * 1 HMAC-SHA256-64

   * 2 HMAC-SHA256-128

   * 3 HMAC-SHA256-256

   HMAC-SHA256-128 is mandatory to implement and should be enabled in
   the default configuration.

   Authentication Tag: This field contains the integrity checksum over
   the EEP packet, excluding the authentication tag field itself.  The
   length of the field is indicated by the Cryptosuite.

   Authentication Tag is calculated using pIK derived from EMSK or DS-
   pIK derived from DSRK.

9.3.  EAP Finish/Pre-Early-auth

      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     |R|S|A|C|Reserved|           SEQ                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   1 or more TVs or TLVs                     ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cryptosuite |            Authentication Tag                 ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 13: EAP Finish/Pre-Early-auth Packet

   Code = 6(EAP Finish)



Wang, et al.             Expires April 21, 2011                [Page 21]

Internet-Draft                     EEP                      October 2010


   Identifier

   Refer to [RFC5296] Section 5.3

   Type = 3(Pre-Early-auth)

   Flags

   'R' - Result flag, value 0 Indicate success, 1 Indicate failure.

   'S' - The value of secure flag indicate whether cryptosuite and
   authentication tag is appended.

   0 Cryptosuite and Authentication Tag are not appended.

   1 Cryptosuite and Authentication Tag are appended at the end of
   message.

   'A' - Authentication flag, value:

   0 Full EAP authentication is not required.

   1 Full EAP authentication is required.

   If MH set A flag to 1 in EAP Initiate/Pre-Early-auth message, the AAA
   server either rejects the early authentication or set A flag to 1 in
   EAP Finish/Pre-Early-auth message.

   'C' - Continue flag:

   0 This is a normal Pre-Early-auth message.

   1 This message is used to extend the lifetime of Pre-Early-auth
   session.

   SEQ

   A 16-bit sequence number is used for replay protection.

   TVs and TLVs

   pMSK Lifetime: This is a TV payload.  The value field is a 32-bit
   field and contains the lifetime of pMSK generated in early
   authentication.







Wang, et al.             Expires April 21, 2011                [Page 22]

Internet-Draft                     EEP                      October 2010


      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     |                pMSK Lifetime                  ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 14: pMSK Lifetime

   Type = TBD

   The life time is calculated after the pMSK has been generated.  That
   is to say, if full authentication is require, the life time is
   started after EAP authentication.  If the pMSK life time expired, the
   MH should do Pre-Early-auth again and Post-Early-auth will be
   rejected.

   pRK Lifetime: This is a TV payload.  The value field is a 32-bit
   field and contains the lifetime of pRK generated in early
   authentication.

      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     |                 pRK Lifetime                  ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 15: pRK Lifetime

   Type = TBD

   Result Code: When R flag is set to 1, this TV payload MAY be included
   in EAP Finish/Pre-Early-auth message.

   List of cryptosuites: This is a TLV payload, type is 5.  Exactly one
   List of cryptosuites TLV SHOULD be included in the EAP Finish/
   Pre-Early-auth message.  It will help MH to select proper crypto
   suite to do key verification in Post-Early-auth phase.

   KeyName-NAI: This is a TLV payload.  Type = 1.  When the S flag is
   set to 1, exactly one KeyName-NAI attribute SHOULD be present in an
   EAP Finish/Pre-Early-auth packet.

   Cryptosuite: This field indicates the integrity algorithm and the PRF
   used for EEP.  Key lengths and output lengths are either indicated or
   are obvious from the Cryptosuite name.

   Authentication Tag: This field contains the integrity checksum over
   the EEP packet, excluding the authentication tag field itself.  The



Wang, et al.             Expires April 21, 2011                [Page 23]

Internet-Draft                     EEP                      October 2010


   length of the field is indicated by the Cryptosuite.

   Authentication Tag is calculated using pIK derived from EMSK or DS-
   pIK derived from DSRK.

9.4.  EAP Initiate/Post-Early-auth

      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      |R|S|A|Reserved |             SEQ               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    1 or more TVs or TLVs                    ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cryptosuite |             Authentication Tag                ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 16: EAP Initiate/Post-Early-auth Packet

   Code = 5(EAP Initiate)

   Identifier

   Refer to [RFC5296] Section 5.3

   Type = 4(Post-Early-auth)

   Flags

   'R' - Result flag, Value MUST be zero and ignored on reception.

   'S' - Secure flag, value MUST be 1 and Cryptosuite and Authentication
   Tag must be appended at the end of message.

   'A' - Authentication flag, value MUST Be 0 and full EAP
   authentication is not required.

   SEQ

   A 16-bit sequence number is used for replay protection.

   TVs and TLVs

   NAS-Identifier: This is a TLV payload, type is 4.  Exactly one NAS-
   Identifier or NAS-Identifier-NAI TLV SHOULD be included in the EAP
   Initiate/Post-Early-auth message.



Wang, et al.             Expires April 21, 2011                [Page 24]

Internet-Draft                     EEP                      October 2010


   NAS-Identifier-NAI: This is a TLV payload, type is TBD.  Exactly one
   NAS-Identifier or NAS-Identifier-NAI TLV SHOULD be included in the
   EAP Initiate/Post-Early-auth message.

   KeyName-NAI: This is a TLV payload.  Type = 1.  Exactly one KeyName-
   NAI attribute MUST be present in an EAP Finish/Post-Early-auth
   packet.

   Cryptosuite: This field indicates the integrity algorithm and the PRF
   used for EEP.  Key lengths and output lengths are either indicated or
   are obvious from the Cryptosuite name.

   Authentication Tag: This field contains the integrity checksum over
   the EEP packet, excluding the authentication tag field itself.  The
   length of the field is indicated by the Cryptosuite.

   Authentication Tag is calculated using pIK derived from EMSK or DS-
   pIK derived from DSRK.

9.5.  EAP Finish/Post-Early-auth

      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      |R|S|A|Reserved |             SEQ               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    1 or more TVs or TLVs                    ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cryptosuite |             Authentication Tag                ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 17: EAP Finish/Post-Early-auth Packet

   Code = 6(EAP Finish)

   Identifier

   Refer to [RFC5296] Section 5.3

   Type = 4(Post-Early-auth)

   Flags

   'R' - Result flag, value 0 Indicate success, 1 Indicate failure.

   'S' - The value of secure flag indicate whether cryptosuite and



Wang, et al.             Expires April 21, 2011                [Page 25]

Internet-Draft                     EEP                      October 2010


   authentication tag is appended.

   0 Cryptosuite and Authentication Tag are not appended.

   1 Cryptosuite and Authentication Tag are appended at the end of
   message.

   'A' - Authentication flag, value:

   0 Full EAP authentication is not required.

   1 Full EAP authentication is required.

   If MH set A flag to 1 in EAP Initiate/Pre-Early-auth message, the AAA
   server either rejects the early authentication or set A flag to 1 in
   EAP Finish/Pre-Early-auth message.

   SEQ

   A 16-bit sequence number is used for replay protection.

   TVs and TLVs

   Result Code: When R flag is set to 1, this TV payload MAY be included
   in EAP Finish/Post-Early-auth message.

   List of cryptosuites: This is a TLV payload, type is 5.  If the
   Result Code is 2 (crypto cipher suite is not supported).  This TLV
   should be included in the EAP Finish/Post-Early-auth message.

   KeyName-NAI: This is a TLV payload.  Type = 1.  If the Result Code is
   3 (key is not found), the TLV should not be included in the EAP
   Finish/Post-Early-auth message and S Bit should be set to 0.  When
   the S flag is set to 1, exactly one KeyName-NAI attribute SHOULD be
   present in an EAP Finish/Post-Early-auth packet.

   Cryptosuite: This field indicates the integrity algorithm and the PRF
   used for EEP.  Key lengths and output lengths are either indicated or
   are obvious from the Cryptosuite name.

   Authentication Tag: This field contains the integrity checksum over
   the EEP packet, excluding the authentication tag field itself.  The
   length of the field is indicated by the Cryptosuite.

   Authentication Tag is calculated using pIK derived from EMSK or DS-
   pIK derived from DSRK.





Wang, et al.             Expires April 21, 2011                [Page 26]

Internet-Draft                     EEP                      October 2010


9.6.  EAP Initiate/Early-auth Action

   The functionality of message EAP Initiate/Early-auth Action message
   is based on its sub type.  The detailed information refers to the
   description of sub type field.

      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    |R|S| Reserved  |            SEQ                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   SubType   |              1 or more TVs or TLVs            ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cryptosuite |              Authentication Tag               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 18: EAP Initiate/Early-auth Action Packet

   Code = 5(EAP Initiate).

   Identifier

   Refer to [RFC5296] Section 5.3

   Type = 5(Early-auth Action).

   Flags

   'R' - The value of result flag MUST be zero and ignored on reception.

   'S' - The value of secure flag indicate whether cryptosuite and
   authentication tag is appended.

   0 Cryptosuite and Authentication Tag are not appended.

   1 Cryptosuite and Authentication Tag are appended at the end of
   message.

   When the EAP Initiate/Early-auth action message is transferred
   between SAP-AAA and Home-AAA, S Bit = 0.

   SEQ

   A 16-bit sequence number is used for replay protection.

   Sub Type



Wang, et al.             Expires April 21, 2011                [Page 27]

Internet-Draft                     EEP                      October 2010


   1 Early authentication Probe message.  The message is sent by MH to
   SAP to probe whether the early authentication for specified CAP is
   supported.

   2 De-Pre-Early-auth message.  The message is sent by MH to SAP to
   release the early authentication with specified CAP.

   To avoid obsolete early authentication session, MH may release its
   established early authentication session before it disconnecting from
   the network.

   3 De-Post-Early-auth message.  The message is sent by MH to SAP to
   change the current fully authenticated state to early authenticated
   state.

   This message is used to adapt to the situation where MH keep moving
   between 2 AAA realms.

   TVs and TLVs

   NAS-Identifier: As defined in [RFC5296], it is carried in a TLV
   payload.  It is used to indicate the identifier of a CAP.  One or
   more NAS-identifier MAY be included in EAP Initiate/Early-auth Action
   message sent by MH.  The Local Domain is considered as the AAA realm
   for this CAP.

      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    |       NAS-Identifier          ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 19: NAS-Identifier

   Type = 4

   Length >= 1

   NAS-Identifier-NAI:

   The NAI is variable in length, not exceeding 253 octets.  The NAS-
   identifier is in the username part of the NAI.  The realm part of the
   NAI is the visited domain name.  One or more NAS-identifier-NAI MAY
   be included in EAP Initiate/Early-auth Action message sent by MH.







Wang, et al.             Expires April 21, 2011                [Page 28]

Internet-Draft                     EEP                      October 2010


      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    |      NAS-Identifier-NAI       ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 20: NAS-Identifier-NAI

   Type = TBD

   Length >= 1

   KeyName-NAI: This is a TLV payload.  The NAI is variable in length,
   not exceeding 253 octets.  The EMSK name is in the username part of
   the NAI and is encoded in hexadecimal values.  The EMSK name is 64
   bits in length and so the username portion takes up 128 octets.  The
   realm part of the NAI is the visited domain name.  When the S Bit is
   set to 1, exactly one KeyName-NAI attribute SHOULD be present in an
   EAP Initiate/Early-auth Action packet.

      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    |         KeyName-NAI           ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 21: KeyName-NAI

   Type = 1

   Length >= 1

   The authenticator uses the realm in the KeyName-NAI field to send the
   message to the appropriate EEP server.

   Cryptosuite: This field indicates the integrity algorithm and the PRF
   used for EEP.  Key lengths and output lengths are either indicated or
   are obvious from the Cryptosuite name.

   Authentication Tag: This field contains the integrity checksum over
   the EEP packet, excluding the authentication tag field itself.  The
   length of the field is indicated by the Cryptosuite.

   Authentication Tag is calculated using pIK derived from EMSK or DS-
   pIK derived from DSRK.






Wang, et al.             Expires April 21, 2011                [Page 29]

Internet-Draft                     EEP                      October 2010


9.7.  EAP Finish/Early-auth Action

   EAP Finish/Early-auth Action is sent by SAP-AAA through SAP to inform
   MH the action results.  For De-Pre-Early-auth and De-Post-Early-auth,
   reply message is not required.  So corresponding sub type is not
   defined.

      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    |R|S| Reserved  |            SEQ                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Sub Type   |          1 or more TVs or TLVs                ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Cryptosuite |            Authentication Tag                 ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 22: EAP Finish/Early-auth Action Packet

   Code = 5(EAP Initiate)

   Identifier

   Refer to [RFC5296] Section 5.3

   Type = 5(Early-auth Action)

   Flags

   'R' - Result flag, value 0 Indicate success, 1 Indicate failure.

   'S' - The value of secure flag indicate whether cryptosuite and
   authentication tag is appended.

   0 Cryptosuite and Authentication Tag are not appended.

   1 Cryptosuite and Authentication Tag are appended at the end of
   message.

   SEQ

   A 16-bit sequence number is used for replay protection.

   Sub Type

   1 Early authentication Probe message.



Wang, et al.             Expires April 21, 2011                [Page 30]

Internet-Draft                     EEP                      October 2010


   TVs and TLVs

   Result Code: When R Bit is set to 1, this TV payload MAY be included
   in EAP Finish/Early-auth Action message.


      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     |                 Result code                   ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 23: Result Code

   Type = TBD

   Result code

   0 Success

   1 Unspecified failure

   2 Cryptosuite is not supported

   3 Key is not found

   4 Fail to verify the authentication tag

   5~9 Reserved

   10 Early authentication is not supported

   11~20 Reserved

   21 Early authentication session is not found for this CAP

   Probe Result: This is TLV payload.  If the Result Code is 0
   (success), The number of Probe Results in EAP Finish/Early- auth
   action message should be identical to the number of NAS-ids and NAS-
   id-NAIs in EAP Initiate/Early-auth Action message.











Wang, et al.             Expires April 21, 2011                [Page 31]

Internet-Draft                     EEP                      October 2010


      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    |      NAS-Id or NAS-Id-NAI     ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Status Code |
      +-+-+-+-+-+-+-+

                          Figure 24: Probe Result

   Type = TBD

   Length >= 2

   Status Code:

   0 EEP is supported for this CAP

   1 EEP is not supported for this CAP

   List of cryptosuites: This is a TLV payload.  If the Result Code is
   2, crypto cipher suite is not supported.  This TLV MAY be included in
   the EAP Finish/Early-auth Action message.

   The value field contains a list of crypto suites, each of size 1
   octet.  The SAP-AAA include this attribute in the EAP Finish/
   Early-auth Action message to signal to the MH about its cryptographic
   algorithm capabilities.  The Cryptosuite values are as specified:

      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    | crypto suite1 | crypto suite2 ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 25: List of cryptosuites

   Type = 5

   Length >= 1

   Crypto suite

   0 RESERVED

   1 HMAC-SHA256-64

   2 HMAC-SHA256-128 (Mandatory to implement and should be enabled in



Wang, et al.             Expires April 21, 2011                [Page 32]

Internet-Draft                     EEP                      October 2010


   the default configuration)

   3 HMAC-SHA256-256

   KeyName-NAI: This is a TLV payload.  Type = 1.  If the S flag is set
   to 1, exactly one KeyName-NAI TLV should be included in EAP Finish/
   Early-auth Action message.  If R flag is set to 1 and the Result Code
   is 3 (key is not found), the TLV should not be included in the EAP
   Finish/Early-auth Action message and S flag should be set to 0.

   Cryptosuite: This field indicates the integrity algorithm and the PRF
   used for EEP.  Key lengths and output lengths are either indicated or
   are obvious from the Cryptosuite name.

   Authentication Tag: This field contains the integrity checksum over
   the EEP packet, excluding the authentication tag field itself.  The
   length of the field is indicated by the Cryptosuite.

   Authentication Tag is calculated using pIK derived from EMSK or DS-
   pIK derived from DSRK.

10.  Lower Layer Considerations

   Similar to ERP, some lower layer specifications may need to be
   revised to support EEP; refer to section 6 of [RFC5296] for
   additional guidance.

11.  AAA Transport Considerations

   AAA transport of EEP messages is the same as AAA transport of the ERP
   message [RFC5296].  In addition, the document requires AAA transport
   of the EEP keying materials delivered by the EEP server to the CAP.
   Hence, a new Diameter EEP application message should be specified to
   transport the keying materials.

12.  Security Considerations

   TBD.

13.  IANA Considerations

   New TLV types:

      NAS-Identifier

      Sequence number





Wang, et al.             Expires April 21, 2011                [Page 33]

Internet-Draft                     EEP                      October 2010


      NAS-Identifier-NAI

      pMSK lifetime

      pRK lifetime

      Result code

      Probe result

14.  Acknowledgements

   Thanks to Qin Wu for guiding some technique solution and helpful
   comments on this document.

15.  References

15.1.  Normative References

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

   [RFC5296]                      Narayanan, V. and L. Dondeti, "EAP
                                  Extensions for EAP Re-authentication
                                  Protocol (ERP)", RFC 5296,
                                  August 2008.

15.2.  Informative References

   [I-D.ietf-dime-local-keytran]  Zorn, G., Wu, W., and V. Cakulev,
                                  "Diameter Attribute-Value Pairs for
                                  Cryptographic Key Transport",
                                  draft-ietf-dime-local-keytran-08 (work
                                  in progress), October 2010.

   [I-D.ietf-hokey-erp-aak]       Cao, Z., Deng, H., Wang, Y., Wu, W.,
                                  and G. Zorn, "EAP Re-authentication
                                  Protocol Extensions for Authenticated
                                  Anticipatory Keying (ERP/AAK)",
                                  draft-ietf-hokey-erp-aak-02 (work in
                                  progress), May 2010.

   [RFC3588]                      Calhoun, P., Loughney, J., Guttman,
                                  E., Zorn, G., and J. Arkko, "Diameter
                                  Base Protocol", RFC 3588,
                                  September 2003.




Wang, et al.             Expires April 21, 2011                [Page 34]

Internet-Draft                     EEP                      October 2010


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

   [RFC5836]                      Ohba, Y., Wu, Q., and G. Zorn,
                                  "Extensible Authentication Protocol
                                  (EAP) Early Authentication Problem
                                  Statement", RFC 5836, April 2010.

Authors' Addresses

   Hao Wang (editor)
   Hangzhou H3C Tech. Co., Ltd.
   H3C, Digital Technology Plaza, Shangdi 9 Street, Haidian District
   Beijing
   China(100085)

   Phone: +86 010 82774462
   EMail: hwang@h3c.com


   Yang Shi (editor)
   Hangzhou H3C Tech. Co., Ltd.
   H3C, Digital Technology Plaza, Shangdi 9 Street, Haidian District
   Beijing
   China(100085)

   Phone: +86 010 82775276
   EMail: young@h3c.com


   Tina Tsou
   Huawei Technologies
   BHuawei Technologies,
   Bantian, Longgang District
   Shenzhen
   China(518129)

   EMail: tena@huawei.com











Wang, et al.             Expires April 21, 2011                [Page 35]