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

1.  Introduction

The Extensible Authentication Protocol (EAP) [RFC3748] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.) 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] (Ohba, Y., Wu, Q., and G. Zorn, “Extensible Authentication Protocol (EAP) Early Authentication Problem Statement,” April 2010.), 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119]

2.2.  Acronyms

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

AAA

Authentication, Authorization and Accounting [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.)

CAP

Candidate Attachment Point [RFC5836] (Ohba, Y., Wu, Q., and G. Zorn, “Extensible Authentication Protocol (EAP) Early Authentication Problem Statement,” April 2010.)

MH

Mobile Host

SAP

Serving Attachment Point [RFC5836] (Ohba, Y., Wu, Q., and G. Zorn, “Extensible Authentication Protocol (EAP) Early Authentication Problem Statement,” April 2010.)

3.  Message Flow of EAP Early Authentication

Based on the functional elements of EAP Early Authentication [RFC5836] (Ohba, Y., Wu, Q., and G. Zorn, “Extensible Authentication Protocol (EAP) Early Authentication Problem Statement,” April 2010.), 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     |
   |           |          |<------------|
   |           |          |             |

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

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

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.

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.

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] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) 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] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) 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] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.). So MH can use ERP message to obtain the local domain name.

- MH has fully authenticated with Home AAA before handover.

7.  Protocol Message Flow

Based on the Section 3 (Message Flow of EAP Early Authentication) and Section 5 (Solution), 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)|
  |<----------------|--------------------|<----------------|
  |                 |                    |                 |

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.

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

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.

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.

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

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.

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

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

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.

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] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.). 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             ...

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

8.1.  Key Derivation

As specified in [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),” May 2010.), 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] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.). The packet format for these messages follows the EAP packet format defined in RFC 3748.

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

Code

5 Initiate

6 Finish

Identifier

Refer to [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) 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     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code = 5(EAP Initiate)

Identifier

Refer to [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) 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] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.).

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

Code = 5(EAP Initiate)

Identifier

Refer to [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) Section 5.3

Type = 3(Pre-Early-auth)

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

Code = 6(EAP Finish)

Identifier

Refer to [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) 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.

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

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

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

Code = 5(EAP Initiate)

Identifier

Refer to [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) 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.

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

Code = 6(EAP Finish)

Identifier

Refer to [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) 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 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.

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

Code = 5(EAP Initiate).

Identifier

Refer to [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) 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

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] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.), 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          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.

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

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

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.

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

Code = 5(EAP Initiate)

Identifier

Refer to [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) 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.

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

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.

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

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

Type = 5

Length >= 1

Crypto suite

0 RESERVED

1 HMAC-SHA256-64

2 HMAC-SHA256-128 (Mandatory to implement and should be enabled in 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] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) for additional guidance.

11.  AAA Transport Considerations

AAA transport of EEP messages is the same as AAA transport of the ERP message [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.). 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

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

15.2. Informative References

Authors' Addresses