Internet DRAFT - draft-hao-hokey-eep
draft-hao-hokey-eep
Network Working Group H. Wang, Ed.
Internet-Draft Y. Shi, Ed.
Intended status: Standards Track Hangzhou H3C Tech. Co., Ltd.
Expires: April 21, 2011 T. Tsou
Huawei Technologies
October 18, 2010
EAP Extensions for EAP Early Authentication Protocol (EEP)
draft-hao-hokey-eep-00
Abstract
The Extensible Authentication Protocol (EAP) is a generic framework
supporting multiple types of authentication methods.
Based on the EAP Early Authentication Model defined by RFC5836, this
document specifies the extensions of EAP to support both intra-AAA-
realm and inter-AAA-realm handover.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Wang, et al. Expires April 21, 2011 [Page 1]
Internet-Draft EEP October 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Message Flow of EAP Early Authentication . . . . . . . . . . . 4
3.1. Intra-AAA-Realm Handover . . . . . . . . . . . . . . . . . 4
3.2. Inter-AAA-Realm Handovers . . . . . . . . . . . . . . . . 5
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Protocol Message Flow . . . . . . . . . . . . . . . . . . . . 9
7.1. Intra-AAA-Realm Handovers . . . . . . . . . . . . . . . . 9
7.2. Inter-AAA-Realm Handovers(Full trust relationship) . . . . 10
7.3. Inter-AAA-Realm Handovers(Semi trust relationship) . . . . 12
7.4. Release authentication session . . . . . . . . . . . . . . 14
8. EEP Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 17
8.1.1. pRK Derivation . . . . . . . . . . . . . . . . . . . . 17
8.1.2. pIK Derivation . . . . . . . . . . . . . . . . . . . . 17
8.1.3. pMSK Derivation . . . . . . . . . . . . . . . . . . . 17
9. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 17
9.1. EAP Initiate/Re-auth-Start Packet Extension . . . . . . . 18
9.2. EAP Initiate/Pre-Early-auth . . . . . . . . . . . . . . . 19
9.3. EAP Finish/Pre-Early-auth . . . . . . . . . . . . . . . . 21
9.4. EAP Initiate/Post-Early-auth . . . . . . . . . . . . . . . 24
9.5. EAP Finish/Post-Early-auth . . . . . . . . . . . . . . . . 25
9.6. EAP Initiate/Early-auth Action . . . . . . . . . . . . . . 27
9.7. EAP Finish/Early-auth Action . . . . . . . . . . . . . . . 30
10. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 33
11. AAA Transport Considerations . . . . . . . . . . . . . . . . . 33
12. Security Considerations . . . . . . . . . . . . . . . . . . . 33
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
15.1. Normative References . . . . . . . . . . . . . . . . . . . 34
15.2. Informative References . . . . . . . . . . . . . . . . . . 34
Wang, et al. Expires April 21, 2011 [Page 2]
Internet-Draft EEP October 2010
1. Introduction
The Extensible Authentication Protocol (EAP) [RFC3748] is a generic
framework supporting multiple types of authentication methods. In
systems where EAP is used for authentication, the handover process
often requires authentication and authorization for acquisition or
modification of resources assigned to the mobile device. In most
cases, these authentications and authorizations require interaction
with a central authority in a realm. In some cases, the central
authority may be distant from the mobile device. The delay
introduced due to such an authentication and authorization procedure
adds to the handover latency and consequently affects ongoing
application sessions.
In the problem statement [RFC5836], it suggests that optimized
solutions for secure inter-authenticator handovers can be seen either
as security context transfer (e.g., using the EAP Extensions for EAP
Re-authentication Protocol (ERP)) [RFC5296], or as EAP Early
Authentication.
This document specifies EAP Extensions for Early Authentication
Model. The protocol that uses these extensions itself is referred to
as the EAP Early Authentication Protocol (EEP). A peer does EAP
method-independent Early Authentication before it attaches to a CAP.
The protocol and the key hierarchy required for EAP Early
Authentication are described in this document.
Note that to support EEP, lower-layer specifications may need to be
revised to allow carrying EAP messages that have a code value more
than 4 and to accommodate the peer-initiated nature of EEP.
Specifically, the IEEE802.1x specification must be revised and RFC
4306 must be updated to carry EEP messages.
2. Terminology
2.1. Standards Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]
2.2. Acronyms
The following acronyms are used in this document; see the references
for more details.
Wang, et al. Expires April 21, 2011 [Page 3]
Internet-Draft EEP October 2010
AAA Authentication, Authorization and Accounting [RFC3588]
CAP Candidate Attachment Point [RFC5836]
MH Mobile Host
SAP Serving Attachment Point [RFC5836]
3. Message Flow of EAP Early Authentication
Based on the functional elements of EAP Early Authentication
[RFC5836], the following sections introduce the general message flow
of Inter-AAA-Realm and Intra-AAA-Realm handovers. The figures below
are to give an overview of EAP Early Authentication.
It is assumed that the MH has previously completed full EAP
authentication with Home AAA.
3.1. Intra-AAA-Realm Handover
In intra-AAA-realm handover scenario, SAP and CAP belong to a same
AAA realm.
+------+ +-----+ +-------+ +--------+
| MH | | SAP | | CAP | |Home AAA|
+--+---+ +--+--+ +---+---+ +----+---+
| | | |
| Early Authentication |
|<--------->|<---------|------------>|
| | | |
| | | |
| Attach to the CAP | |
|-----------|--------->|------------>|
| | | |
| | | pMSK |
| | |<------------|
| | | |
Figure 1: Intra-AAA-Realm Handover
Before MH (peer) performs handover from SAP to CAP, it does early
authentication with Home AAA.
Since SAP and CAP belong to the same Home AAA, the complete EAP
method exchange is not required in early authentication. The MH
informs Home AAA of the NAS-id of CAPs and each CAP's sequence
number. Home AAA will derive the pMSK from EMSK and sequence number.
Wang, et al. Expires April 21, 2011 [Page 4]
Internet-Draft EEP October 2010
Sequence number must be unique for each CAP to derive a unique pMSK.
After handover, MH attaches to the CAP. MH request to change from
early authenticated state to fully authorized and authenticated
state. Its Home AAA is not changed. And then Home AAA distribute
the pMSK to CAP.
3.2. Inter-AAA-Realm Handovers
In inter-AAA-realm scenario, as the first step, Home AAA and CAP-AAA
need to establish a trust relationship.
There are two cases for this step.
In first case, Home AAA and CAP-AAA belong to a same operator. In
this case, a full trust relationship may be established. That means
security context transfer between AAA servers is permitted.
+------+ +-----+ +-------+ +--------+ +-----+ +-------+
| MH | | SAP | |SAP-AAA| |Home AAA| | CAP | |CAP-AAA|
+--+---+ +--+--+ +---+---+ +----+---+ +--+--+ +---+---+
| | | | | |
| | |Establish Trust Relationship Between AAAs
| | | |<--------|-------->|
| | | | | |
| Early Authentication Early Authentication|
|<--------->|<--------->|<---------->|<--------|-------->|
| | | | | |
| | | | DSRK, EMSK Name |
| | | |<--------|-------->|
| | | | | |
| | Attach to the CAP | | |
|-----------|-----------|------------|-------->|-------->|
| | | | | |
| | | | | pMSK |
| | | | |<--------|
| | | | | |
Figure 2: Inter-AAA-Realm Handovers(Full trust relationship)
Before MH (peer) performs handover from SAP to CAP, it does early
authentication with CAP-AAA, and messages will be forwarded by SAP,
SAP-AAA and Home AAA to CAP-AAA.
Since Home AAA and CAP-AAA belong to the same operator, the complete
EAP method exchange is not required in early authentication. The
Wang, et al. Expires April 21, 2011 [Page 5]
Internet-Draft EEP October 2010
CAP-AAA will get DSRK and EMSK Name from Home AAA and derive pMSK
from DSRK directly.
After handover, MH attaches to the CAP. Its Home AAA is not changed
and CAP-AAA becomes the new local AAA server(SAP-AAA).
In second case, Home AAA and CAP-AAA belong to different operators.
In this case, a semi trust relationship may be established. That
means two AAA servers can recognize each other based on domain name
and communicate each other. But the security context transfer is not
permitted.
+------+ +-----+ +-------+ +--------+ +-----+ +-------+
| MH | | SAP | |SAP-AAA| |Home AAA| | CAP | |CAP-AAA|
+--+---+ +--+--+ +---+---+ +----+---+ +--+--+ +---+---+
| | | | | |
| | |Establish Trust Relationship Between AAAs
| | | |<--------|-------->|
| | | | | |
| Early Authentication Early Authentication|
|<--------->|<--------->|<---------->|<--------|-------->|
| | | | | |
| | EAP Method Exchange | |
|<----------|-----------|------------|---------|-------->|
| | | | | |
| | Attach to the CAP | |
|-----------|-----------|------------|-------->|-------->|
| | | | | |
| | | | | pMSK |
| | | | |<--------|
| | | | | |
Figure 3: Inter-AAA-Realm Handovers(Semi trust relationship)
Since Home AAA and CAP-AAA belong to the different operators,
usually, a complete EAP method exchange will be done in early
authentication. MSK and EMSK will be derived in full EAP
authentication. CAP-AAA will use the MSK as the pMSK.
After handover, MH attaches to the CAP, its Home AAA is changed and
CAP-AAA acts as a new Home AAA.
4. Problem Statement
According to the general message flow of Intra-AAA-Realm and Inter-
AAA-Realm handovers, the following problems need to be resolved for
Early Authentication Model.
Wang, et al. Expires April 21, 2011 [Page 6]
Internet-Draft EEP October 2010
1) How to establish a trust relationship between Home AAA and CAP-
AAA?
It is an important issue but the solution is out of the scope of
this document.
2) How does MH knows whether a complete EAP method exchange is
required?
A method is required for MH to negotiate this issue with CAP-AAA
when it request to start the early authentication.
3) How does MH get CAP's status and capability information in
advance?
CAPs are discovered through EAP Lower layer. But early
authentication is done through EAP layer. MH needs to know
whether the discovered CAPs can be early authenticated through
Home AAA or not. If MH can't get such knowledge before the early
authentication, it is evident that the handover experience will be
inefficient.
4) How to forward the EEP message between MH and CAP-AAA?
Unlike normal EAP authentication, The SAP-AAA and Home AAA should
forward EAP early authentication packets to CAP-AAA instead of
processing them locally. So the SAP-AAA and Home AAA should know
the domain name of CAP-AAA and when the early authentication is
started.
5) How to handle the frequent MH handover?
AAA server needs to maintain early authentication sessions, while
frequent MH handover may lead to redundant obsolete early
authentication sessions on AAA servers. A mechanism is required
to settle this situation.
6) How to ensure the information consistent between MH and CAP-AAA?
It is a high possibility of information inconsistency between MH
and CAP-AAA. For example, after handover, MH starts to use pMSK
for EAP lower layer key derivation. But the early authentication
session on CAP-AAA has just been expired without notifying MH.
Wang, et al. Expires April 21, 2011 [Page 7]
Internet-Draft EEP October 2010
5. Solution
Similiar to ERP protocol, a trigger message is required by SAP to
infom MH of its capability to support early authentication. To avoid
redundant trigger message, EAP Initiate/Re-auth-Start [RFC5296] is
reused and one E flag is added to indicate whether EEP is supported.
EAP Codes 5(EAP Initiate) and 6(EAP Finish) defined in the protocol
of ERP [RFC5296] is reused.
New EAP Initiate/Pre-early-auth and EAP Finish/Pre-early-auth
messages are defined to start the early authentication and negotiate
whether full EAP authentication is required.
New EAP Initiate/Post-early-auth and EAP Finish/Post-early-auth
messages are defined to confirm the early authentication information
and change the state from early authenticated to fully authorized and
authenticated.
Early auth action message is defined for below functionality.
- Probe whether the early authentication is supported for sepecified
CAP.
- Release the early authentication session to avoid redudant resource
assumption.
- Request to change from fully authenticated state to early
authenticated state.
6. Assumptions
For the solution, it is assumed that:
- The trust relationship has been established between Home AAA server
and CAP-AAA server.
- EEP server has co-located with the AAA server.
- The authenticator act as a pass-through entity for early
authentication protocol in a manner similar to that of an EAP
authenticator described in RFC3748.
- The entity which support EEP can also support ERP [RFC5296]. So MH
can use ERP message to obtain the local domain name.
- MH has fully authenticated with Home AAA before handover.
Wang, et al. Expires April 21, 2011 [Page 8]
Internet-Draft EEP October 2010
7. Protocol Message Flow
Based on the Section 3 and Section 5, the below figures show the
protocol message flow of EEP protocol.
7.1. Intra-AAA-Realm Handovers
+---+ +-----+ +-----+ +---------+
|MH | | SAP | | CAP | |Home AAA |
+-+-+ +--+--+ +--+--+ +----+----+
| | | |
1.| EAP Initiate/ | | |
| Pre-Early-auth | AAA(EAP Initiate/Pre-Early-auth) |
|---------------->|--------------------|---------------->|
| | | |
| | | |
2.| EAP Finish/ | | |
| Pre-Early-auth | AAA(EAP Finish/Pre-Early-auth) |
|<----------------|<-------------------|-----------------|
| | | |
3.| | | AAA(EAP Init/ |
| EAP Initiate/Post-Early-auth | Post-Early-auth)|
|-----------------|------------------->|---------------->|
| | | |
| | | |--------------|
| | | |CA Authorized |
| | | | & |
| | | |Authenticated;|
| | | | Keying |
| | | | material |
| | | | derived |
| | | |--------------|
| | | |
| | | AAA(pMSK) |
| | |<----------------|
| | | |
4.| | | AAA(EAP Finish/ |
| EAP Finish/Post-Early-auth | Post-Early-auth)|
|<----------------|--------------------|<----------------|
| | | |
Figure 4: Intra-AAA-Realm Handovers
Wang, et al. Expires April 21, 2011 [Page 9]
Internet-Draft EEP October 2010
1) MH request to start the early authentication
MH starts the early authentication using EAP Initiate/
Pre-Early-auth message. In Pre-Early-auth message, the NAS-id of
CAP and sequence number is included. EAP Initiate/Pre-Early-auth
is protected by pIK for middle man attack.
2) Home AAA respond with early authentication result
When Home AAA receive the request from MH, it verify the
availability of CAP's NAS-id. And check whether EEP is supported
by this CAP. Home AAA respond with early authentication result
using EAP Finish/Pre-Early-auth message. pMSK will be derived from
EMSK and sequence number and will be kept in early authentication
session.
3) MH request to change its state
After handover, MH request to change its state from early
authenticated state to fully authorized and authenticated state.
In EAP Initiate/Post-Early-auth message, the NAS-id of CAP and
EMSK name is included.
4) Home AAA confirm the state change
Home AAA confirm the NAS-id and key name, and then respond with
state changing result using EAP Finish/Post-Early-auth message.
Home AAA distribute the pMSK to the CAP.
7.2. Inter-AAA-Realm Handovers(Full trust relationship)
It is assumed that SAP-AAA act as the Home AAA server.
Wang, et al. Expires April 21, 2011 [Page 10]
Internet-Draft EEP October 2010
+---+ +-----+ +-------+ +-----+ +-------+
|MH | | SAP | |SAP-AAA| | CAP | |CAP-AAA|
+-+-+ +--+--+ +---+---+ +--+--+ +---+---+
| | | | |
1.| EAP Initiate/ | AAA(EAP Initiate/| AAA(EAP Initiate/ |
| Pre-Early-auth | Pre-Early-auth) | Pre-Early-auth) |
|---------------->|----------------->|--------------------->|
| | | | |
2.| | | AAA(DSRK Request) |
| | |<---------------------|
| | | | |
| | |AAA(DSRK, EMSK Name) |
| | |--------------------->|
| | | | |
3.| EAP Finish/ | AAA(EAP Finish/| AAA(EAP Finish/ |
| Pre-Early-auth | Pre-Early-auth)| Pre-Early-auth) |
|<----------------|<-----------------|<---------------------|
| | | | |
4.| | | AAA(EAP Init/ |
| EAP Initiate/Post-Early-auth | Post-Early-auth) |
|-----------------|------------------|-------->|----------->|
| | | | |
| | | | |--------------|
| | | | |CA Authorized |
| | | | | & |
| | | | |Authenticated;|
| | | | | Keying |
| | | | | material |
| | | | | derived |
| | | | |--------------|
| | | | |
| | | | AAA(pMSK) |
| | | |<-----------|
| | | | |
5.| | | AAA(EAP Finish/|
| EAP Finish/Post-Early-auth | Post-Early-auth)|
|<----------------|------------------|---------|<-----------|
| | | | |
Figure 5: Intra-AAA-Realm Handovers(Full trust relationship)
1) MH request to start the early authentication
MH starts the early authentication using EAP Initiate/
Pre-Early-auth message. In Pre-Early-auth message, the NAS-id-NAI
of CAP and sequence number is included. Based on the realm part
of NAS-id-NAI, the SAP-AAA will forward the Pre-Early-auth message
Wang, et al. Expires April 21, 2011 [Page 11]
Internet-Draft EEP October 2010
to the corresponding CAP-AAA. if the CAP-AAA can not be found or
trust relationship has not been established, SAP-AAA will directly
reject the early authentication request.
2) CAP-AAA request DSRK and EMSK Name from SAP-AAA
After receiving the ealy authentication request, CAP-AAA find that
the full trust relationship has been established between SAP-AAA
and CAP-AAA. So CAP-AAA request DSRK and EMSK name from SAP-
AAA(Home AAA).
3) CAP-AAA respond with early authentication result
Home AAA respond with early authentication result using EAP
Finish/Pre-Early-auth message. pMSK will be derived from DSRK and
sequence number and will be kept in early authentication entry.
4) MH request to change its state
After handover, MH request to change its state from early
authenticated state to fully authorized and authenticated state.
5) Home AAA confirm the state change
Home AAA respond with state changing result using EAP Finish/
Post-Early-auth message. Home AAA distribute the pMSK to the CAP.
7.3. Inter-AAA-Realm Handovers(Semi trust relationship)
It is assumed that SAP-AAA act as the Home AAA server.
Wang, et al. Expires April 21, 2011 [Page 12]
Internet-Draft EEP October 2010
+---+ +-----+ +-------+ +-----+ +-------+
|MH | | SAP | |SAP-AAA| | CAP | |CAP-AAA|
+-+-+ +--+--+ +---+---+ +--+--+ +---+---+
| | | | |
1.| EAP Initiate/ | AAA(EAP Initiate/ | AAA(EAP Initiate/ |
| Pre-Early-auth | Pre-Early-auth) | Pre-Early-auth) |
|----------------->|-------------------->|------------------->|
| | | | |
2.| EAP Finish/ | AAA(EAP Finish/ | AAA(EAP Finish/ |
| Pre-Early-auth | Pre-Early-auth) | Pre-Early-auth) |
|<-----------------|<--------------------|<-------------------|
| | | | |
3.|EAP Authentication| AAA(EAP Authentication) |
|<---------------->|<------------------->|<------------------>|
| | | | |
4.| | | AAA(EAP Init/ |
| EAP Initiate/Post-Early-auth | Post-Early-auth)|
|------------------|---------------------|------->|---------->|
| | | | |
| | | | |-------------|
| | | | |CA Authorized|
| | | | | & |
| | | | |Authenticated|
| | | | | Keying |
| | | | | material |
| | | | | derived |
| | | | |-------------|
| | | | |
| | | | AAA(pMSK) |
| | | |<----------|
| | | | |
5.| | | AAA(EAP Finish/|
| EAP Finish/Post-Early-auth | Post-Early-auth)|
|<-----------------|---------------------|--------|<----------|
| | | | |
Figure 6: Inter-AAA-Realm Handovers(Semi trust relationship)
1) MH request to start the early authentication
MH starts the early authentication using EAP Initiate/
Pre-Early-auth message. In Pre-Early-auth message, the NAS-id-NAI
of CAP and sequence number is included. Based on the realm part
of NAS-id-NAI, the SAP-AAA will forward the Pre-Early-auth message
to the corresponding CAP-AAA. if the CAP-AAA can not be found or
trust relationship has not been established, SAP-AAA will directly
reject the early authentication request.
Wang, et al. Expires April 21, 2011 [Page 13]
Internet-Draft EEP October 2010
2) CAP-AAA respond with early authentication result
After receiving the ealy authentication request, CAP-AAA find that
the semi trust relationship has been established between SAP-AAA
and CAP-AAA. Home AAA respond with early authentication result
using EAP Finish/Pre-Early-auth message. And in the message, Home
AAA inform MH that full EAP authentication is required.
3) MH do full EAP authentication with CAP-AAA
MH do eap authentication with CAP-AAA with full authentication
method exchange. SAP-AAA will forward the EAP authentication
message to CAP-AAA and reponse message to MH.
4) MH request to change its state
After handover, MH request to change its state from early
authenticated state to fully authorized and authenticated state.
5) Home AAA confirm the state change
Home AAA respond with state changing result using EAP Finish/
Post-Early-auth message. Home AAA distribute the pMSK to the CAP.
7.4. Release authentication session
Wang, et al. Expires April 21, 2011 [Page 14]
Internet-Draft EEP October 2010
+---+ +-----+ +-------+ +-----+ +-------+
|MH | | SAP | |SAP-AAA| | CAP2| |CAP-AAA|
+-+-+ +--+--+ +---+---+ +--+--+ +---+---+
| | | | |
1.| EAP Initiate/ | AAA(EAP Initiate/ | AAA(EAP Initiate/ |
|Early-auth Action/| Early-auth Action/ | Early-auth Action/ |
| De-Pre-auth | De-Pre-auth | De-Pre-auth |
|----------------->|-------------------->|------------------->|
| | | | |
2.| EAP Initiate/ | AAA(EAP Initiate/ | | |
|Early-auth Action/| Early-auth Action/ | | |
| De-Post-auth | De-Post-auth | | |
|----------------->|-------------------->| | |
| | | | |
3.| | | AAA(EAP Init/ |
| EAP Initiate/Post-Early-auth | Post-Early-auth)|
|------------------|---------------------|------->|---------->|
| | | | |
| | | | |-------------|
| | | | |CA Authorized|
| | | | | & |
| | | | |Authenticated|
| | | | | Keying |
| | | | | material |
| | | | | derived |
| | | | |-------------|
| | | | |
| | | | AAA(pMSK) |
| | | |<----------|
| | | | |
4.| | | AAA(EAP Finish/|
| EAP Finish/Post-Early-auth | Post-Early-auth)|
|<-----------------|---------------------|--------|<----------|
| | | | |
Figure 7
1) MH release the early authentication session with CAP1
MH sends EAP Initiate/Early-auth Action/De-Pre-auth to inform CAP-
AAA release early authentication session for CAP1.
2) MH release the full authentication session with SAP
MH sends EAP Initiate/Early-auth Action/De-Post-auth to inform
SAP-AAA to change its state from full authorized and authenticated
state to early authenticated state.
Wang, et al. Expires April 21, 2011 [Page 15]
Internet-Draft EEP October 2010
3) MH request to change its state
After handover, MH request to change its state from early
authenticated state to fully authorized and authenticated state.
4) Home AAA confirm the state change
Home AAA respond with state changing result using EAP Finish/
Post-Early-auth message. Home AAA distribute the pMSK to the
CAP2.
8. EEP Key Hierarchy
EEP uses key hierarchy similar to that of ERP [RFC5296]. The EMSK is
used to derive the EEP pre-established Root Key (pRK). Similarly,
the EEP pre-established Integrity Key (pIK) and the pre-established
Master Session Key (pMSK) is derived from the pRK. The pMSK is
established for the CAP(s) when the peer early authenticates to the
network. The pIK is established for the peer to do post early
authentication after handover. The hierarchy relationship is
illustrated in Figure 8, below.
(inter-AAA-realm) (intra-AAA-realm)
DSRK EMSK
| |
+-------+-------+-------+-------+
| | |
pRK rRK ...
Figure 8
The EMSK and DSRK both can be used to derive the pRK. In general,
the pRK is derived from the EMSK in case of the peer moving in the
Home AAA realm and derived from the DRSK in case of the peer moving
in the visited AAA realm. The DSRK is delivered from the EAP server
to the EEP server as specified in [I-D.ietf-dime-local-keytran]. if
the peer has previously authenticated by means of EEP, the DSRK
SHOULD be directly re-used.
pRK
|
+-----------+-----------+
| | |
pIK pMSK ...
Figure 9
The pRK is used to derive the pIK and pMSK for the CAP(s). Different
Wang, et al. Expires April 21, 2011 [Page 16]
Internet-Draft EEP October 2010
sequence numbers for each CAP MUST be used to derive the unique
pMSK(s).
8.1. Key Derivation
As specified in [I-D.ietf-hokey-erp-aak], the key derivation method
is given below.
8.1.1. pRK Derivation
pRK = KDF (K, S), where K = EMSK or DSRK and S = pRK Label | "\0" |
length
The pRK Label is an IANA-assigned 8-bit ASCII string:
EAP Early authentication Root Key@ietf.org
8.1.2. pIK Derivation
pIK = KDF (K, S), where K = pRK and S = pIK Label | "\0" |
cryptosuite | length
The pIK Label is the 8-bit ASCII string:
Early authentication Integrity Key@ietf.org
8.1.3. pMSK Derivation
pMSK = KDF (K, S), where K = pRK and S = pMSK label | "\0" | SEQ |
length
The pMSK label is the 8-bit ASCII string:
Early authentication Master Session Key@ietf.org
9. Packet and TLV Extension
EEP reuse EAP Codes 5(EAP Initiate) and 6(EAP Finish) defined in the
protocol of ERP [RFC5296]. The packet format for these messages
follows the EAP packet format defined in RFC 3748.
Wang, et al. Expires April 21, 2011 [Page 17]
Internet-Draft EEP October 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: EAP Packet
Code
5 Initiate
6 Finish
Identifier
Refer to [RFC5296] Section 5.3
Type
This field indicates that this is an EEP exchange. Three new Type
values are defined for the purpose of early authentication.
3 Pre-Early-auth
4 Post-Early-auth
5 Early-auth Action
Type-Data
The Type-Data field varies with the Type of early authentication
packet.
9.1. EAP Initiate/Re-auth-Start Packet Extension
One E flag bit is added in EAP Initiate/Re-auth-Start message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |E| Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wang, et al. Expires April 21, 2011 [Page 18]
Internet-Draft EEP October 2010
Figure 11: EAP Initiate/Re-auth-Start Packet
Code = 5(EAP Initiate)
Identifier
Refer to [RFC5296] Section 5.3
Type = 1(Re-auth-Start)
Flags
'E' - The E flag is used to indicate whether EEP is supported or not.
If E Bit is set to 1, it indicate that EEP is supported by the
authenticator and the MH can start the early authentication. If E
Bit is set to 0, MH can not start early authentication using EEP.
Reserved: MUST be set to 0.
TVs or TLVs: refer to ERP [RFC5296].
To avoid redundant trigger message at the beginning, No new early
authentication start message is defined.
9.2. EAP Initiate/Pre-Early-auth
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|S|A|C|Reserved| SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: EAP Initiate/Pre-Early-auth Packet
Code = 5(EAP Initiate)
Identifier
Refer to [RFC5296] Section 5.3
Type = 3(Pre-Early-auth)
Wang, et al. Expires April 21, 2011 [Page 19]
Internet-Draft EEP October 2010
Flags
'R' - The value of result flag MUST be zero and ignored on reception.
'S' - The value of secure flag indicate whether cryptosuite and
authentication tag is appended.
0 Cryptosuite and Authentication Tag are not appended.
1 Cryptosuite and Authentication Tag are appended at the end of
message.
When the EAP Initiate/Early-auth action message is transferred
between SAP-AAA and Home-AAA, S Bit = 0.
'A' - Authentication flag:
0 MH do not request to do full EAP authentication.
1 MH request to do full EAP authentication.
'C' - Continue flag:
0 This is a normal Pre-Early-auth message.
1 This message is used to extend the lifetime of Pre-Early-auth
session.
SEQ
A 16-bit sequence number is used for replay protection.
TVs and TLVs
NAS-Identifier: This is a TLV payload, type is 4. Exactly one NAS-
Identifier or NAS-Identifier-NAI TLV SHOULD be included in the EAP
Initiate/Pre-Early-auth message.
NAS-Identifier-NAI: This is a TLV payload, type is TBD. Exactly one
NAS-Identifier or NAS-Identifier-NAI TLV SHOULD be included in the
EAP Initiate/Pre-Early-auth message.
List of cryptosuites: This is a TLV payload, type is 5. Exactly one
List of cryptosuites TLV SHOULD be included in the EAP Initiate/
Pre-Early-auth message.
KeyName-NAI: This is a TLV payload. Type = 1. When the S Bit is set
to 1, exactly one KeyName-NAI attribute SHOULD be present in an EAP
Wang, et al. Expires April 21, 2011 [Page 20]
Internet-Draft EEP October 2010
Initiate/Pre-Early-auth packet.
Sequence Number: It is carried in a TV payload. The Type is TBD
(which is lower than 128). When the C flag is set to 1, exactly one
sequence number SHOULD be present in an EAP Initiate/Pre-Early-auth
packet.
Cryptosuite: This field indicates the integrity algorithm and the PRF
used for EEP. Key lengths and output lengths are either indicated or
obvious from the cryptosuite name.
We specify some cryptosuites below:
* 0 RESERVED
* 1 HMAC-SHA256-64
* 2 HMAC-SHA256-128
* 3 HMAC-SHA256-256
HMAC-SHA256-128 is mandatory to implement and should be enabled in
the default configuration.
Authentication Tag: This field contains the integrity checksum over
the EEP packet, excluding the authentication tag field itself. The
length of the field is indicated by the Cryptosuite.
Authentication Tag is calculated using pIK derived from EMSK or DS-
pIK derived from DSRK.
9.3. EAP Finish/Pre-Early-auth
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|S|A|C|Reserved| SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: EAP Finish/Pre-Early-auth Packet
Code = 6(EAP Finish)
Wang, et al. Expires April 21, 2011 [Page 21]
Internet-Draft EEP October 2010
Identifier
Refer to [RFC5296] Section 5.3
Type = 3(Pre-Early-auth)
Flags
'R' - Result flag, value 0 Indicate success, 1 Indicate failure.
'S' - The value of secure flag indicate whether cryptosuite and
authentication tag is appended.
0 Cryptosuite and Authentication Tag are not appended.
1 Cryptosuite and Authentication Tag are appended at the end of
message.
'A' - Authentication flag, value:
0 Full EAP authentication is not required.
1 Full EAP authentication is required.
If MH set A flag to 1 in EAP Initiate/Pre-Early-auth message, the AAA
server either rejects the early authentication or set A flag to 1 in
EAP Finish/Pre-Early-auth message.
'C' - Continue flag:
0 This is a normal Pre-Early-auth message.
1 This message is used to extend the lifetime of Pre-Early-auth
session.
SEQ
A 16-bit sequence number is used for replay protection.
TVs and TLVs
pMSK Lifetime: This is a TV payload. The value field is a 32-bit
field and contains the lifetime of pMSK generated in early
authentication.
Wang, et al. Expires April 21, 2011 [Page 22]
Internet-Draft EEP October 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | pMSK Lifetime ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: pMSK Lifetime
Type = TBD
The life time is calculated after the pMSK has been generated. That
is to say, if full authentication is require, the life time is
started after EAP authentication. If the pMSK life time expired, the
MH should do Pre-Early-auth again and Post-Early-auth will be
rejected.
pRK Lifetime: This is a TV payload. The value field is a 32-bit
field and contains the lifetime of pRK generated in early
authentication.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | pRK Lifetime ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: pRK Lifetime
Type = TBD
Result Code: When R flag is set to 1, this TV payload MAY be included
in EAP Finish/Pre-Early-auth message.
List of cryptosuites: This is a TLV payload, type is 5. Exactly one
List of cryptosuites TLV SHOULD be included in the EAP Finish/
Pre-Early-auth message. It will help MH to select proper crypto
suite to do key verification in Post-Early-auth phase.
KeyName-NAI: This is a TLV payload. Type = 1. When the S flag is
set to 1, exactly one KeyName-NAI attribute SHOULD be present in an
EAP Finish/Pre-Early-auth packet.
Cryptosuite: This field indicates the integrity algorithm and the PRF
used for EEP. Key lengths and output lengths are either indicated or
are obvious from the Cryptosuite name.
Authentication Tag: This field contains the integrity checksum over
the EEP packet, excluding the authentication tag field itself. The
Wang, et al. Expires April 21, 2011 [Page 23]
Internet-Draft EEP October 2010
length of the field is indicated by the Cryptosuite.
Authentication Tag is calculated using pIK derived from EMSK or DS-
pIK derived from DSRK.
9.4. EAP Initiate/Post-Early-auth
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|S|A|Reserved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: EAP Initiate/Post-Early-auth Packet
Code = 5(EAP Initiate)
Identifier
Refer to [RFC5296] Section 5.3
Type = 4(Post-Early-auth)
Flags
'R' - Result flag, Value MUST be zero and ignored on reception.
'S' - Secure flag, value MUST be 1 and Cryptosuite and Authentication
Tag must be appended at the end of message.
'A' - Authentication flag, value MUST Be 0 and full EAP
authentication is not required.
SEQ
A 16-bit sequence number is used for replay protection.
TVs and TLVs
NAS-Identifier: This is a TLV payload, type is 4. Exactly one NAS-
Identifier or NAS-Identifier-NAI TLV SHOULD be included in the EAP
Initiate/Post-Early-auth message.
Wang, et al. Expires April 21, 2011 [Page 24]
Internet-Draft EEP October 2010
NAS-Identifier-NAI: This is a TLV payload, type is TBD. Exactly one
NAS-Identifier or NAS-Identifier-NAI TLV SHOULD be included in the
EAP Initiate/Post-Early-auth message.
KeyName-NAI: This is a TLV payload. Type = 1. Exactly one KeyName-
NAI attribute MUST be present in an EAP Finish/Post-Early-auth
packet.
Cryptosuite: This field indicates the integrity algorithm and the PRF
used for EEP. Key lengths and output lengths are either indicated or
are obvious from the Cryptosuite name.
Authentication Tag: This field contains the integrity checksum over
the EEP packet, excluding the authentication tag field itself. The
length of the field is indicated by the Cryptosuite.
Authentication Tag is calculated using pIK derived from EMSK or DS-
pIK derived from DSRK.
9.5. EAP Finish/Post-Early-auth
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|S|A|Reserved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: EAP Finish/Post-Early-auth Packet
Code = 6(EAP Finish)
Identifier
Refer to [RFC5296] Section 5.3
Type = 4(Post-Early-auth)
Flags
'R' - Result flag, value 0 Indicate success, 1 Indicate failure.
'S' - The value of secure flag indicate whether cryptosuite and
Wang, et al. Expires April 21, 2011 [Page 25]
Internet-Draft EEP October 2010
authentication tag is appended.
0 Cryptosuite and Authentication Tag are not appended.
1 Cryptosuite and Authentication Tag are appended at the end of
message.
'A' - Authentication flag, value:
0 Full EAP authentication is not required.
1 Full EAP authentication is required.
If MH set A flag to 1 in EAP Initiate/Pre-Early-auth message, the AAA
server either rejects the early authentication or set A flag to 1 in
EAP Finish/Pre-Early-auth message.
SEQ
A 16-bit sequence number is used for replay protection.
TVs and TLVs
Result Code: When R flag is set to 1, this TV payload MAY be included
in EAP Finish/Post-Early-auth message.
List of cryptosuites: This is a TLV payload, type is 5. If the
Result Code is 2 (crypto cipher suite is not supported). This TLV
should be included in the EAP Finish/Post-Early-auth message.
KeyName-NAI: This is a TLV payload. Type = 1. If the Result Code is
3 (key is not found), the TLV should not be included in the EAP
Finish/Post-Early-auth message and S Bit should be set to 0. When
the S flag is set to 1, exactly one KeyName-NAI attribute SHOULD be
present in an EAP Finish/Post-Early-auth packet.
Cryptosuite: This field indicates the integrity algorithm and the PRF
used for EEP. Key lengths and output lengths are either indicated or
are obvious from the Cryptosuite name.
Authentication Tag: This field contains the integrity checksum over
the EEP packet, excluding the authentication tag field itself. The
length of the field is indicated by the Cryptosuite.
Authentication Tag is calculated using pIK derived from EMSK or DS-
pIK derived from DSRK.
Wang, et al. Expires April 21, 2011 [Page 26]
Internet-Draft EEP October 2010
9.6. EAP Initiate/Early-auth Action
The functionality of message EAP Initiate/Early-auth Action message
is based on its sub type. The detailed information refers to the
description of sub type field.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|S| Reserved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: EAP Initiate/Early-auth Action Packet
Code = 5(EAP Initiate).
Identifier
Refer to [RFC5296] Section 5.3
Type = 5(Early-auth Action).
Flags
'R' - The value of result flag MUST be zero and ignored on reception.
'S' - The value of secure flag indicate whether cryptosuite and
authentication tag is appended.
0 Cryptosuite and Authentication Tag are not appended.
1 Cryptosuite and Authentication Tag are appended at the end of
message.
When the EAP Initiate/Early-auth action message is transferred
between SAP-AAA and Home-AAA, S Bit = 0.
SEQ
A 16-bit sequence number is used for replay protection.
Sub Type
Wang, et al. Expires April 21, 2011 [Page 27]
Internet-Draft EEP October 2010
1 Early authentication Probe message. The message is sent by MH to
SAP to probe whether the early authentication for specified CAP is
supported.
2 De-Pre-Early-auth message. The message is sent by MH to SAP to
release the early authentication with specified CAP.
To avoid obsolete early authentication session, MH may release its
established early authentication session before it disconnecting from
the network.
3 De-Post-Early-auth message. The message is sent by MH to SAP to
change the current fully authenticated state to early authenticated
state.
This message is used to adapt to the situation where MH keep moving
between 2 AAA realms.
TVs and TLVs
NAS-Identifier: As defined in [RFC5296], it is carried in a TLV
payload. It is used to indicate the identifier of a CAP. One or
more NAS-identifier MAY be included in EAP Initiate/Early-auth Action
message sent by MH. The Local Domain is considered as the AAA realm
for this CAP.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | NAS-Identifier ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: NAS-Identifier
Type = 4
Length >= 1
NAS-Identifier-NAI:
The NAI is variable in length, not exceeding 253 octets. The NAS-
identifier is in the username part of the NAI. The realm part of the
NAI is the visited domain name. One or more NAS-identifier-NAI MAY
be included in EAP Initiate/Early-auth Action message sent by MH.
Wang, et al. Expires April 21, 2011 [Page 28]
Internet-Draft EEP October 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | NAS-Identifier-NAI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: NAS-Identifier-NAI
Type = TBD
Length >= 1
KeyName-NAI: This is a TLV payload. The NAI is variable in length,
not exceeding 253 octets. The EMSK name is in the username part of
the NAI and is encoded in hexadecimal values. The EMSK name is 64
bits in length and so the username portion takes up 128 octets. The
realm part of the NAI is the visited domain name. When the S Bit is
set to 1, exactly one KeyName-NAI attribute SHOULD be present in an
EAP Initiate/Early-auth Action packet.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | KeyName-NAI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: KeyName-NAI
Type = 1
Length >= 1
The authenticator uses the realm in the KeyName-NAI field to send the
message to the appropriate EEP server.
Cryptosuite: This field indicates the integrity algorithm and the PRF
used for EEP. Key lengths and output lengths are either indicated or
are obvious from the Cryptosuite name.
Authentication Tag: This field contains the integrity checksum over
the EEP packet, excluding the authentication tag field itself. The
length of the field is indicated by the Cryptosuite.
Authentication Tag is calculated using pIK derived from EMSK or DS-
pIK derived from DSRK.
Wang, et al. Expires April 21, 2011 [Page 29]
Internet-Draft EEP October 2010
9.7. EAP Finish/Early-auth Action
EAP Finish/Early-auth Action is sent by SAP-AAA through SAP to inform
MH the action results. For De-Pre-Early-auth and De-Post-Early-auth,
reply message is not required. So corresponding sub type is not
defined.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|S| Reserved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub Type | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: EAP Finish/Early-auth Action Packet
Code = 5(EAP Initiate)
Identifier
Refer to [RFC5296] Section 5.3
Type = 5(Early-auth Action)
Flags
'R' - Result flag, value 0 Indicate success, 1 Indicate failure.
'S' - The value of secure flag indicate whether cryptosuite and
authentication tag is appended.
0 Cryptosuite and Authentication Tag are not appended.
1 Cryptosuite and Authentication Tag are appended at the end of
message.
SEQ
A 16-bit sequence number is used for replay protection.
Sub Type
1 Early authentication Probe message.
Wang, et al. Expires April 21, 2011 [Page 30]
Internet-Draft EEP October 2010
TVs and TLVs
Result Code: When R Bit is set to 1, this TV payload MAY be included
in EAP Finish/Early-auth Action message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Result code ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Result Code
Type = TBD
Result code
0 Success
1 Unspecified failure
2 Cryptosuite is not supported
3 Key is not found
4 Fail to verify the authentication tag
5~9 Reserved
10 Early authentication is not supported
11~20 Reserved
21 Early authentication session is not found for this CAP
Probe Result: This is TLV payload. If the Result Code is 0
(success), The number of Probe Results in EAP Finish/Early- auth
action message should be identical to the number of NAS-ids and NAS-
id-NAIs in EAP Initiate/Early-auth Action message.
Wang, et al. Expires April 21, 2011 [Page 31]
Internet-Draft EEP October 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | NAS-Id or NAS-Id-NAI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+
Figure 24: Probe Result
Type = TBD
Length >= 2
Status Code:
0 EEP is supported for this CAP
1 EEP is not supported for this CAP
List of cryptosuites: This is a TLV payload. If the Result Code is
2, crypto cipher suite is not supported. This TLV MAY be included in
the EAP Finish/Early-auth Action message.
The value field contains a list of crypto suites, each of size 1
octet. The SAP-AAA include this attribute in the EAP Finish/
Early-auth Action message to signal to the MH about its cryptographic
algorithm capabilities. The Cryptosuite values are as specified:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | crypto suite1 | crypto suite2 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: List of cryptosuites
Type = 5
Length >= 1
Crypto suite
0 RESERVED
1 HMAC-SHA256-64
2 HMAC-SHA256-128 (Mandatory to implement and should be enabled in
Wang, et al. Expires April 21, 2011 [Page 32]
Internet-Draft EEP October 2010
the default configuration)
3 HMAC-SHA256-256
KeyName-NAI: This is a TLV payload. Type = 1. If the S flag is set
to 1, exactly one KeyName-NAI TLV should be included in EAP Finish/
Early-auth Action message. If R flag is set to 1 and the Result Code
is 3 (key is not found), the TLV should not be included in the EAP
Finish/Early-auth Action message and S flag should be set to 0.
Cryptosuite: This field indicates the integrity algorithm and the PRF
used for EEP. Key lengths and output lengths are either indicated or
are obvious from the Cryptosuite name.
Authentication Tag: This field contains the integrity checksum over
the EEP packet, excluding the authentication tag field itself. The
length of the field is indicated by the Cryptosuite.
Authentication Tag is calculated using pIK derived from EMSK or DS-
pIK derived from DSRK.
10. Lower Layer Considerations
Similar to ERP, some lower layer specifications may need to be
revised to support EEP; refer to section 6 of [RFC5296] for
additional guidance.
11. AAA Transport Considerations
AAA transport of EEP messages is the same as AAA transport of the ERP
message [RFC5296]. In addition, the document requires AAA transport
of the EEP keying materials delivered by the EEP server to the CAP.
Hence, a new Diameter EEP application message should be specified to
transport the keying materials.
12. Security Considerations
TBD.
13. IANA Considerations
New TLV types:
NAS-Identifier
Sequence number
Wang, et al. Expires April 21, 2011 [Page 33]
Internet-Draft EEP October 2010
NAS-Identifier-NAI
pMSK lifetime
pRK lifetime
Result code
Probe result
14. Acknowledgements
Thanks to Qin Wu for guiding some technique solution and helpful
comments on this document.
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, March 1997.
[RFC5296] Narayanan, V. and L. Dondeti, "EAP
Extensions for EAP Re-authentication
Protocol (ERP)", RFC 5296,
August 2008.
15.2. Informative References
[I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev,
"Diameter Attribute-Value Pairs for
Cryptographic Key Transport",
draft-ietf-dime-local-keytran-08 (work
in progress), October 2010.
[I-D.ietf-hokey-erp-aak] Cao, Z., Deng, H., Wang, Y., Wu, W.,
and G. Zorn, "EAP Re-authentication
Protocol Extensions for Authenticated
Anticipatory Keying (ERP/AAK)",
draft-ietf-hokey-erp-aak-02 (work in
progress), May 2010.
[RFC3588] Calhoun, P., Loughney, J., Guttman,
E., Zorn, G., and J. Arkko, "Diameter
Base Protocol", RFC 3588,
September 2003.
Wang, et al. Expires April 21, 2011 [Page 34]
Internet-Draft EEP October 2010
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J.,
Carlson, J., and H. Levkowetz,
"Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC5836] Ohba, Y., Wu, Q., and G. Zorn,
"Extensible Authentication Protocol
(EAP) Early Authentication Problem
Statement", RFC 5836, April 2010.
Authors' Addresses
Hao Wang (editor)
Hangzhou H3C Tech. Co., Ltd.
H3C, Digital Technology Plaza, Shangdi 9 Street, Haidian District
Beijing
China(100085)
Phone: +86 010 82774462
EMail: hwang@h3c.com
Yang Shi (editor)
Hangzhou H3C Tech. Co., Ltd.
H3C, Digital Technology Plaza, Shangdi 9 Street, Haidian District
Beijing
China(100085)
Phone: +86 010 82775276
EMail: young@h3c.com
Tina Tsou
Huawei Technologies
BHuawei Technologies,
Bantian, Longgang District
Shenzhen
China(518129)
EMail: tena@huawei.com
Wang, et al. Expires April 21, 2011 [Page 35]
