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]