draft-ietf-hokey-erp-aak-11.txt   rfc6630.txt 
Network Working Group Z. Cao Internet Engineering Task Force (IETF) Z. Cao
Internet-Draft H. Deng Request for Comments: 6630 H. Deng
Intended status: Standards Track China Mobile Category: Standards Track China Mobile
Expires: November 3, 2012 Q. Wu ISSN: 2070-1721 Q. Wu
Huawei Huawei
G. Zorn, Ed. G. Zorn, Ed.
Network Zen Network Zen
May 2, 2012 June 2012
EAP Re-authentication Protocol Extensions for Authenticated Anticipatory EAP Re-authentication Protocol Extensions
Keying (ERP/AAK) for Authenticated Anticipatory Keying (ERP/AAK)
draft-ietf-hokey-erp-aak-11
Abstract Abstract
The Extensible Authentication Protocol (EAP) is a generic framework The Extensible Authentication Protocol (EAP) is a generic framework
supporting multiple types of authentication methods. supporting multiple types of authentication methods.
The EAP Re-authentication Protocol (ERP) specifies extensions to EAP The EAP Re-authentication Protocol (ERP) specifies extensions to EAP
and the EAP keying hierarchy to support an EAP method-independent and the EAP keying hierarchy to support an EAP method-independent
protocol for efficient re-authentication between the peer and an EAP protocol for efficient re-authentication between the peer and an EAP
re-authentication server through any authenticator. re-authentication server through any authenticator.
Authenticated Anticipatory Keying (AAK) is a method by which Authenticated Anticipatory Keying (AAK) is a method by which
cryptographic keying material may be established upon one or more cryptographic keying material may be established upon one or more
candidate attachment points (CAPs) prior to handover. AAK uses the Candidate Attachment Points (CAPs) prior to handover. AAK uses the
AAA infrastructure for key transport. AAA infrastructure for key transport.
This document specifies the extensions necessary to enable AAK This document specifies the extensions necessary to enable AAK
support in ERP. support in ERP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 3, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6630.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ERP/AAK Description . . . . . . . . . . . . . . . . . . . . . 4 3. ERP/AAK Description . . . . . . . . . . . . . . . . . . . . . 4
4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7 4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7
4.1. Derivation of the pRK and pMSK . . . . . . . . . . . . . . 8 4.1. Derivation of the pRK and pMSK . . . . . . . . . . . . . . 8
5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 9 5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 9
5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 9 5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 9
5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 10 5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 10
5.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 12 5.3. EAP-Finish/Re-auth Packet and TLV Extension . . . . . . . 12
5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 14 5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 14
6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 15 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 15
7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 15 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP) [RFC3748] is a generic The Extensible Authentication Protocol (EAP) [RFC3748] is a generic
framework supporting multiple types of authentication methods. In framework supporting multiple types of authentication methods. In
systems where EAP is used for authentication, it is desirable to not systems where EAP is used for authentication, it is desirable not to
repeat the entire EAP exchange with another authenticator. The EAP repeat the entire EAP exchange with another authenticator. The EAP
Re-authentication Protocol (ERP) [RFC5296] specifies extensions to Re-authentication Protocol (ERP) [RFC5296] specifies extensions to
EAP and the EAP keying hierarchy to support an EAP method-independent EAP and the EAP keying hierarchy to support an EAP method-independent
protocol for efficient re-authentication between the EAP re- protocol for efficient re-authentication between the EAP
authentication peer and an EAP re-authentication server through any re-authentication peer and an EAP re-authentication server through
authenticator. The re-authentication server may be in the home any authenticator. The re-authentication server may be in the home
network or in the local network to which the mobile host (i.e., the network or in the local network to which the mobile host (i.e., the
EAP re-authentication peer) is connecting. EAP re-authentication peer) is connecting.
Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by
which cryptographic keying materials may be established prior to which cryptographic keying material may be established upon one or
handover upon one or more candidate attachment points (CAPs). AAK more Candidate Attachment Points (CAPs) prior to handover. AAK
utilizes the AAA infrastructure for key transport. utilizes the AAA infrastructure for key transport.
This document specifies the extensions necessary to enable AAK This document specifies the extensions necessary to enable AAK
support in ERP. support in ERP.
2. Terminology 2. Terminology
2.1. Standards Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Acronyms 2.2. Acronyms
The following acronyms are used in this document; see the references The following acronyms are used in this document; see the references
for more details. for more details.
AAA AAA
Authentication, Authorization and Accounting [RFC3588] Authentication, Authorization, and Accounting [RFC3588]
CAP CAP
Candidate Attachment Point [RFC5836] Candidate Attachment Point [RFC5836]
DSRK
Domain-Specific Root Key [RFC5295]
EA EA
Abbreviation for "ERP/AAK" Abbreviation for "ERP/AAK"
EA Peer EA Peer
An EAP peer that supports the ERP/AAK. Note that all references An EAP peer that supports the ERP/AAK. Note that all
to "peer" in this document imply an EA peer, unless specifically references to "peer" in this document imply an EA peer,
noted otherwise. unless specifically noted otherwise.
NAI
Network Access Identifier [RFC4282]
pMSK
pre-established Master Session Key
pRK
pre-established Root Key
rIK
re-authentication Integrity Key [RFC5296]
rRK
re-authentication Root Key [RFC5296]
SAP SAP
Serving Attachment Point [RFC5836] Serving Attachment Point [RFC5836]
3. ERP/AAK Description 3. ERP/AAK Description
ERP/AAK is intended to allow the establishment of cryptographic ERP/AAK is intended to allow (upon request by the peer) the
keying materials on a single Candidate Attachment Point prior to the establishment of cryptographic keying materials on a single Candidate
arrival of the peer at the Candidate Access Network (CAN) upon Attachment Point prior to the arrival of the peer at the Candidate
request by the peer. Access Network (CAN).
In this document, ERP/AAK support by the peer is assumed. Also it is In this document, ERP/AAK support by the peer is assumed. Also, it
assumed that the peer has previously completed full EAP is assumed that the peer has previously completed full EAP
authentication and that either the peer or SAP knows the identities authentication and that either the peer or the SAP knows the
of neighboring attachment points. Note that the behavior of a peer identities of neighboring attachment points. Note that the behavior
that does not support the ERP-AAK scheme defined in this of a peer that does not support the ERP-AAK scheme defined in this
specification is out of the scope of this document. Figure 1 shows specification is out of the scope of this document. Figure 1 shows
the general protocol exchange by which the keying material is the general protocol exchange by which the keying material is
established on the CAP. established on the CAP.
+------+ +-----+ +-----+ +-----------+ +------+ +-----+ +-----+ +-----------+
| Peer | | SAP | | CAP | | EA Server | | Peer | | SAP | | CAP | | EA Server |
+--+---+ +--+--+ +--+--+ +-----+-----+ +--+---+ +--+--+ +--+--+ +-----+-----+
| | | | | | | |
a. | [EAP-Initiate/ | | | a. | [EAP-Initiate/ | | |
| Re-auth-start | | | | Re-auth-start | | |
| (E-flag)] | | | | (E flag)] | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
b. | EAP-Initiate/ | | | b. | EAP-Initiate/ | | |
| Re-auth | | | | Re-auth | | |
| (E-flag) | | | | (E flag) | | |
|--------------->| | | |--------------->| | |
c. | | AAA(EAP-Initiate/Re-auth(E-flag))| c. | | AAA(EAP-Initiate/Re-auth(E flag))|
| |--------------------------------->| | |--------------------------------->|
| | | +---------+---------+ | | | +---------+---------+
| | | | CA authorized & | | | | | CA authorized & |
d. | | | | and EA Keying | d. | | | | and EA Keying |
| | | | Distribution | | | | | Distribution |
| | | +---------+---------+ | | | +---------+---------+
| | | | | | | |
| | | | | | | |
f. | | AAA (EAP-Finish/Re-auth(E-flag)) | f. | | AAA (EAP-Finish/Re-auth(E flag)) |
| |<---------------------------------| | |<---------------------------------|
g. | EAP-Finish/ | | | g. | EAP-Finish/ | | |
| Re-auth(E-flag)| | | | Re-auth(E flag)| | |
|<---------------| | | |<---------------| | |
| | | | | | | |
Figure 1: ERP/AAK Exchange Figure 1: ERP/AAK Exchange
+-----------+ +---------+ +-----------+ +---------+
| | | | | | | |
| EA Server | | CAP | | EA Server | | CAP |
| | | | | | | |
+-----|-----+ +----|----+ +-----|-----+ +----|----+
| | | |
| | | |
| AAA Request(pMSK) | | AAA Request (pMSK) |
e.1|------------------------->| e.1|------------------------->|
| | | |
| | | |
| | | |
| AAA Response (Success) | | AAA Response (Success) |
e.2|<-------------------------| e.2|<-------------------------|
| | | |
| | | |
| | | |
Figure 2: Key Distribution for ERP/AAK Figure 2: Key Distribution for ERP/AAK
ERP/AAK re-uses the packet format defined by ERP, but specifies a new ERP/AAK reuses the packet format defined by ERP, but specifies a new
flag to differentiate EAP early-authentication from EAP re- flag to differentiate EAP early authentication from EAP
authentication. The peer initiates ERP/AAK itself, or does so in re-authentication. The peer initiates ERP/AAK without an external
response to an EAP-Initiate/Re-Auth-Start message from the SAP. trigger, or initiates ERP/AAK in response to an EAP-Initiate/
Re-Auth-Start message from the SAP.
In the latter case, the SAP MAY send the identity of one or more In the latter case, the SAP MAY send the identity of one or more
Candidate Attachment Points to which the SAP is adjacent to the peer Candidate Attachment Points to which the SAP is adjacent to the peer
in the EAP-Initiate/Re-auth-Start message (see a. in Figure 1). The in the EAP-Initiate/Re-auth-Start message (see step a in Figure 1).
Peer SHOULD override the identity of CAP(s) carried in EAP-Initiate/ The peer SHOULD override the identity of CAP(s) carried in the
Re-auth-Start message by sending EAP-Initiate/Re-auth with the 'E' EAP-Initiate/Re-auth-Start message by sending EAP-Initiate/Re-auth
flag set if it knows to which CAP it will move. If the EAP-Initiate/ with the E flag set if it knows to which CAP it will move. If the
Re-auth-Start packet is not supported by the peer, it MUST be EAP-Initiate/Re-auth-Start packet is not supported by the peer, it
silently discarded. MUST be silently discarded.
If the peer initiates ERP/AAK, the peer MAY send an early- If the peer initiates ERP/AAK, the peer MAY send an early-
authentication request message (EAP-Initiate/Re-auth with the 'E' authentication request message (EAP-Initiate/Re-auth with the E flag
flag set) containing the keyName-NAI, the CAP-Identifier, rIK and set) containing the keyName-NAI, the CAP-Identifier, rIK, and
sequence number (see b. in Figure 1). The realm in the keyName-NAI sequence number (see step b in Figure 1). The realm in the keyName-
field is used to locate the peer's ERP/AAK server. The CAP- NAI field is used to locate the peer's ERP/AAK server. The CAP-
Identifier is used to identify the CAP. The rIK is defined in Identifier is used to identify the CAP. The re-authentication
Narayanan & Dondeti [RFC5296] and used to protect the integrity of Integrity Key (rIK) is defined by Narayanan & Dondeti in [RFC5296]
the message. The sequence number is used for replay protection. and is used to protect the integrity of the message. The sequence
number is used for replay protection.
The SAP SHOULD verify the integrity of thus message at step b. If The SAP SHOULD verify the integrity of this message at step b. If
this verification fails, the SAP MUST send an EAP-Finish/Re-auth this verification fails, the SAP MUST send an EAP-Finish/Re-auth
message with the Result flag set to '1' (Failure). If the message with the Result flag set to '1' (Failure). If the
verification succeeds, the SAP SHOULD encapsulate the early- verification succeeds, the SAP SHOULD encapsulate the early-
authentication message into a AAA message and send it to the peer's authentication message into a AAA message and send it to the peer's
ERP/AAK server in the realm indicated in the keyName-NAI field (see ERP/AAK server in the realm indicated in the keyName-NAI field (see
c. in Figure 1). step c in Figure 1).
Upon receiving the message, the ERP/AAK server MUST first use the Upon receiving the message, the ERP/AAK server MUST first use the
keyName indicated in the keyName-NAI to look up the rIK and check the keyName indicated in the keyName-NAI to look up the rIK and check the
integrity and freshness of the message. Then the ERP/AAK server MUST integrity and freshness of the message. Then, the ERP/AAK server
verify the identity of the peer by checking the username portion of MUST verify the identity of the peer by checking the username portion
the KeyName-NAI. If any of the checks fail, the server MUST send an of the KeyName-NAI. If any of the checks fail, the server MUST send
early- authentication finish message (EAP-Finish/Re-auth with E-flag an early-authentication finish message (EAP-Finish/Re-auth with E
set) with the Result flag set to '1'. Next, the server MUST flag set) with the Result flag set to '1'. Next, the server MUST
authorize the CAP specified in the CAP-Identifier TLV. In the authorize the CAP specified in the CAP-Identifier TLV. In the
success case, the server MUST derive a pMSK from the pRK for the CAP success case, the server MUST derive a pMSK from the pRK for the CAP
carried in the the CAP-Identifier field using the sequence number carried in the CAP-Identifier field using the sequence number
associated with CAP-Identifier as an input to the key derivation. associated with CAP-Identifier as an input to the key derivation.
(see d. in Figure 1). (see step d in Figure 1).
Then the ERP/AAK server MUST transport the pMSK to the authorized CAP Then, the ERP/AAK server MUST transport the pMSK to the authorized
via AAA Section 7 as illustrated above (see e.1 and e.2 in Figure 2). CAP via AAA (see Section 7) as illustrated above (see steps e.1 and
Note that key distribution in Figure 2 is one part of step d. in e.2 in Figure 2). Note that key distribution in Figure 2 is one part
Figure 1. of step d in Figure 1.
Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK
server SHOULD send the early-authentication finish message (EAP- server SHOULD send the early-authentication finish message (EAP--
Finish/ Re-auth with E-flag set) containing the identity of the -Finish/Re-auth with E flag set) containing the identity of the
authorized CAP to the peer via the SAP along with the lifetime of the authorized CAP to the peer via the SAP along with the lifetime of the
pMSK. If the peer also requests the rRK lifetime, the ERP/AAK server pMSK. If the peer also requests the rRK Lifetime, the ERP/AAK server
SHOULD send the rRK lifetime in the EAP-Finish/Re-auth message. (see SHOULD send the rRK Lifetime in the EAP-Finish/Re-auth message (see
f. and g. in Figure 1). steps f and g in Figure 1).
4. ERP/AAK Key Hierarchy 4. ERP/AAK Key Hierarchy
ERP/AAK uses a key hierarchy similar to that of ERP. The ERP/AAK ERP/AAK uses a key hierarchy similar to that of ERP. The ERP/AAK
pre-established Root Key (pRK) is derived from either the EMSK or the pre-established Root Key (pRK) is derived from either the EMSK or the
DSRK as specified below (see Section 4.1). In general, the pRK is DSRK as specified below (see Section 4.1). In general, the pRK is
derived from the EMSK if the peer is located in the home AAA realm derived from the EMSK if the peer is located in the home AAA realm
and derived from the DRSK if the peer is in a visited realm. The and derived from the DSRK if the peer is in a visited realm. The
DSRK is delivered from the EAP server to the ERP/AAK server as DSRK is delivered from the EAP server to the ERP/AAK server as
specified in [I-D.ietf-dime-local-keytran]. If the peer has specified in [KEYTRAN]. If the peer has previously been
previously been authenticated by means of ERP or ERP/AAK, the DSRK authenticated by means of ERP or ERP/AAK, the DSRK SHOULD be directly
SHOULD be directly re-used. reused.
DSRK EMSK DSRK EMSK
| | | |
+---+---+---+---+ +---+---+---+---+
| |
pRK ... pRK ...
Figure 3: ERP/AAK Root Key Derivation Figure 3: ERP/AAK Root Key Derivation
Similarly, the pre-established Master Session Key (pMSK) is derived Similarly, the pre-established Master Session Key (pMSK) is derived
from the pRK. The pMSK is established for the CAP when the peer from the pRK. The pMSK is established for the CAP when the peer
early authenticates to the network. The hierarchy relationship is early authenticates to the network. The hierarchy relationship is
illustrated Figure 4, illustrated Figure 4, below.
pRK pRK
| |
+--------+--------+ +--------+--------+
| |
pMSK ... pMSK ...
Figure 4: ERP/AAK Key Hierarchy Figure 4: ERP/AAK Key Hierarchy
below.
4.1. Derivation of the pRK and pMSK 4.1. Derivation of the pRK and pMSK
The rRK is derived as specified in [RFC5295]. The rRK is derived as specified in [RFC5295].
pRK = KDF (K, S), where pRK = KDF (K, S), where
K = EMSK or K = DSRK and K = EMSK or K = DSRK and
S = pRK Label | "\0" | length S = pRK Label | "\0" | length
The pRK Label is an IANA-assigned 8-bit ASCII string: The pRK Label is an IANA-assigned 8-bit ASCII string:
EAP Early-Authentication Root Key@ietf.org EAP Early-Authentication Root Key@ietf.org
assigned from the "USRK key labels" name space in accordance with assigned from the "User Specific Root Keys (USRK) Key Labels" name
Salowey, et al. [RFC5295]. The KDF and algorithm agility for the space in accordance with Salowey, et al. [RFC5295]. The KDF and
KDF are also defined in RFC 5295. The KDF algorithm is indicated in algorithm agility for the KDF are also defined in RFC 5295. The KDF
the cryptosuit field or list of cryptosuits TLV payload as specified algorithm is indicated in the cryptosuite field or list of
in the section 5.2 and section 5.3. cryptosuites TLV payload as specified in Sections 5.2 and 5.3.
The pMSK uses the same PDF as pRK and is derived as follows: The pMSK uses the same KDF as pRK and is derived as follows:
pMSK = KDF (K, S), where pMSK = KDF (K, S), where
K = pRK and K = pRK and
S = pMSK label | "\0" | SEQ | length S = pMSK label | "\0" | SEQ | length
The pMSK label is the 8-bit ASCII string: The pMSK label is the 8-bit ASCII string:
EAP Early-Authentication Master Session Key@ietf.org EAP Early-Authentication Master Session Key@ietf.org
The length field refers to the length of the pMSK in octets encoded The length field refers to the length of the pMSK in octets encoded
as specified in RFC 5295. SEQ is sent by either the peer or the as specified in RFC 5295. SEQ is sent by either the peer or the
server in the ERP/AAK message using the SEQ field or the Sequence server in the ERP/AAK message using the SEQ field or the Sequence
number TLV and encoded as an 16-bit number as specified in number TLV. It is encoded as a 16-bit number as specified in
Section 5.2 and Section 5.3. Sections 5.2 and 5.3.
5. Packet and TLV Extension 5. Packet and TLV Extension
This section describes the packet and TLV extensions for the ERP/AAK This section describes the packet and TLV extensions for the ERP/AAK
exchange. exchange.
5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension 5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension
Figure 5 shows the new parameters contained in the EAP-Initiate/ Figure 5 shows the new parameters contained in the EAP-Initiate/
Re-auth-Start packet defined in RFC 5296 [RFC5296]. Re-auth-Start packet defined in [RFC5296].
0 1 2 3 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 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 | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |E| Reserved | 1 or more TVs or TLVs ~ | Type |E| Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Figure 5: EAP-Initiate/Re-auth-Start Extension
Flags Flags
'E' - The E flag is used to indicate early-authentication. This 'E' - The E flag is used to indicate early authentication. This
field MUST be set to '1' if early authentication is in use and MUST field MUST be set to '1' if early authentication is in use, and it
be set to '0' otherwise. MUST be set to '0' otherwise.
The rest of the 7 bits (Reserved ) MUST be set to 0 and ignored on The rest of the 7 bits (Reserved) MUST be set to 0 and ignored on
reception. reception.
TVs and TLVs Type/Values (TVs) and TLVs
CAP-Identifier: Carried in a TLV payload. The format is identical to CAP-Identifier: Carried in a TLV payload. The format is identical to
that of a DiameterIdentity [RFC3588]. It is used by the SAP to that of a DiameterIdentity [RFC3588]. It is used by the SAP to
advertise the identity of the CAP to the peer. Exactly one CAP- advertise the identity of the CAP to the peer. Exactly one
Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start CAP-Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start
packet if the SAP has performed CAP discovery. packet if the SAP has performed CAP discovery.
If the EAP-Initiate/Re-auth-Start packet is not supported by the If the EAP-Initiate/Re-auth-Start packet is not supported by the
peer, it SHOULD be discarded silently. peer, it SHOULD be discarded silently.
5.2. EAP-Initiate/Re-auth Packet and TLV Extension 5.2. EAP-Initiate/Re-auth Packet and TLV Extension
Figure 6 illustrates the new parameters contained in the EAP- Figure 6 illustrates the new parameters contained in the
Initiate/Re-auth packet defined in RFC 5296 [RFC5296]. EAP-Initiate/Re-auth packet defined in [RFC5296].
0 1 2 3 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 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 | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|x|L|E|Resved | SEQ | | Type |R|x|L|E|Resved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~ | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~ | Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Figure 6: EAP-Initiate/Re-auth Extension
Flags Flags
'x' - The x flag is reserved. It MUST be ignored on receipt. 'x' - The x flag is reserved. It MUST be ignored on receipt.
'L' - As defined in section 5.3.2 of [RFC5296], this bit is used to 'L' - As defined in Section 5.3.2 of [RFC5296], this bit is used to
request the key lifetimes from the server. request the key lifetimes from the server.
'E' - The E flag is used to indicate early-authentication. 'E' - The E flag is used to indicate early authentication.
The first bit(R) and final 4 bits (Resved) MUST be set to 0 and The first bit(R) and final 4 bits (Resved) MUST be set to 0 and
ignored on reception. ignored on reception.
SEQ SEQ
As defined in Section 5.3.2 of [RFC5296],this field is 16-bit As defined in Section 5.3.2 of [RFC5296], this field is 16-bit
sequence number and used for replay protection. sequence number and used for replay protection.
TVs and TLVs TVs and TLVs
keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a keyName-NAI: As defined in [RFC5296], this is carried in a TLV
TLV payload. The Type is 1. The NAI is variable in length, not payload. The Type is 1. The NAI is variable in length, not
exceeding 253 octets. The username part of the NAI is the EMSKname exceeding 253 octets. The username part of the NAI is the EMSKname
used to identify the peer. The realm part of the NAI is the peer's used to identify the peer. The realm part of the NAI is the peer's
home domain name if the peer communicates with the home EA server or home domain name if the peer communicates with the home EA server or
the domain to which the peer is currently attached (i.e., local the domain to which the peer is currently attached (i.e., local
domain name) if the peer communicates with a local EA server. The domain name) if the peer communicates with a local EA server. The
SAP knows whether the KeyName-NAI carries the local domain name by SAP knows whether the KeyName-NAI carries the local domain name by
comparing the domain name carried in KeyName-NAI with the local comparing the domain name carried in the KeyName-NAI with the local
domain name which is associated with the SAP. Exactly one keyName- domain name that is associated with the SAP. Exactly one keyName-NAI
NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet and attribute SHALL be present in an EAP-Initiate/Re-auth packet and the
the realm part of it SHOULD follow the use of internationalized realm part of it SHOULD follow the use of internationalized domain
domain names defined in RFC5890 [RFC5890]. names defined in [RFC5890].
CAP-Identifier: Carried in a TLV payload.The Type is TBD (less than CAP-Identifier: Carried in a TLV payload. The Type is 11. This
128). This field is used to indicate the FQDN of a CAP. The value field is used to indicate the Fully Qualified Domain Name (FQDN) of a
field MUST be encoded as specified in Section 8 of RFC 3315 CAP. The value field MUST be encoded as specified in Section 8 of
[RFC3315]. Exactly one instance of the CAP-Identifier TLV MUST be [RFC3315]. Exactly one instance of the CAP-Identifier TLV MUST be
present in the ERP/AAK-Key TLV. present in the ERP/AAK-Key TLV.
Sequence number: The Type is TBD (less than 128). The value field is Sequence number: The Type is 7. The value field is a 16-bit field
a 16-bit field and used in the derivation of the pMSK for a CAP. and used in the derivation of the pMSK for a CAP.
Cryptosuite Cryptosuite
This field indicates the integrity algorithm used for ERP/AAK. Key This field indicates the integrity algorithm used for ERP/AAK. Key
lengths and output lengths are either indicated or obvious from the lengths and output lengths are either indicated or obvious from the
cryptosuite name, e.g., HMAC-SHA256-128 denotes HMAC computed using cryptosuite name, e.g., HMAC-SHA256-128 denotes Hashed Message
the SHA-256 function [RFC4868] with 256-bit key length and the output Authentication Code (HMAC) computed using the SHA-256 function
truncated to 128 bits [RFC2104]. We specify some cryptosuites below: [RFC4868] with 256-bit key length and the output truncated to 128
bits [RFC2104]. We specify some cryptosuites below:
0-1 RESERVED 0-1 RESERVED
2 HMAC-SHA256-128 2 HMAC-SHA256-128
3 HMAC-SHA256-256 3 HMAC-SHA256-256
HMAC-SHA256-128 is REQUIRED to implement and SHOULD be enabled in the HMAC-SHA256-128 is REQUIRED to implement, and it SHOULD be enabled in
default configuration. the default configuration.
Authentication Tag Authentication Tag
This field contains an integrity checksum over the ERP/AAK packet This field contains an integrity checksum over the ERP/AAK packet
from the first bit of the Code field to the last bit of the from the first bit of the Code field to the last bit of the
Cryptosuite field, excluding the Authentication Tag field itself. Cryptosuite field, excluding the Authentication Tag field itself.
The value field is calculated using the integrity algorithm indicated The value field is calculated using the integrity algorithm indicated
in the Cryptosuite field and rIK specified in [RFC5296] as the secret in the Cryptosuite field and rIK specified in [RFC5296] as the secret
key. The length of the field is indicated by the Cryptosuite. key. The length of the field is indicated by the Cryptosuite.
skipping to change at page 12, line 9 skipping to change at page 12, line 16
not included in the message, the message SHOULD be discarded not included in the message, the message SHOULD be discarded
silently. silently.
If the EAP-Initiate/Re-auth packet is not supported by the SAP, it If the EAP-Initiate/Re-auth packet is not supported by the SAP, it
SHOULD be discarded silently. The peer MUST maintain retransmission SHOULD be discarded silently. The peer MUST maintain retransmission
timers for reliable transport of the EAP-Initiate/Re-auth message. timers for reliable transport of the EAP-Initiate/Re-auth message.
If there is no response to the EAP-Initiate/Re-auth message from the If there is no response to the EAP-Initiate/Re-auth message from the
server after the necessary number of retransmissions (see Section 6), server after the necessary number of retransmissions (see Section 6),
the peer MUST assume that ERP/AAK is not supported by the SAP. the peer MUST assume that ERP/AAK is not supported by the SAP.
5.3. EAP-Finish/Re-auth packet and TLV extension 5.3. EAP-Finish/Re-auth Packet and TLV Extension
Figure 7 shows the new parameters contained in the EAP-Finish/Re-auth Figure 7 shows the new parameters contained in the EAP-Finish/Re-auth
packet defined in [RFC5296]. packet defined in [RFC5296].
0 1 2 3 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 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 | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|x|L|E|Resved | SEQ | | Type |R|x|L|E|Resved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~ | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~ | Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 Figure 7: EAP-Finish/Re-auth Extension
Flags Flags
'R' - As defined in Section 5.3.3 of [RFC5296], this bit is used to 'R' - As defined in Section 5.3.3 of [RFC5296], this bit is used as
used as the Result flag. This field MUST be set to '1' if indicates the Result flag. This field MUST be set to '1' to indicate success,
success and MUST be set to '0' otherwise. and it MUST be set to '0' otherwise.
'x' - The x flag is reserved. It MUST be ignored on receipt. 'x' - The x flag is reserved. It MUST be ignored on receipt.
'L' - As defined in section 5.3.3 of [RFC5296], this bit is used to 'L' - As defined in Section 5.3.3 of [RFC5296], this bit is used to
request the key lifetimes from the server. request the key lifetimes from the server.
'E' - The E flag is used to indicate early-authentication. 'E' - The E flag is used to indicate early authentication.
The final 4 bits (Resved) MUST be set to 0 and ignored on reception. The final 4 bits (Resved) MUST be set to 0 and ignored on reception.
SEQ SEQ
As defined in Section 5.3.3 of [RFC5296], this field is a 16-bit As defined in Section 5.3.3 of [RFC5296], this field is a 16-bit
sequence number and used for replay protection. sequence number and is used for replay protection.
TVs and TLVs TVs and TLVs
keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a keyName-NAI: As defined in [RFC5296], this is carried in a TLV
TLV payload. The Type is 1. The NAI is variable in length, not payload. The Type is 1. The NAI is variable in length, not
exceeding 253 octets. Exactly one keyName-NAI attribute SHALL be exceeding 253 octets. Exactly one keyName-NAI attribute SHALL be
present in an EAP-Finish/Re-auth packet. present in an EAP-Finish/Re-auth packet.
ERP/AAK-Key: Carried in a TLV payload for the key container. The ERP/AAK-Key: Carried in a TLV payload for the key container. The
type is TBD. Exactly one ERP/AAK-key SHALL only be present in an Type is 8. Exactly one ERP/AAK-key SHALL be present in an
EAP-Finish/Re-auth packet. EAP-Finish/Re-auth packet.
ERP/AAK-Key ::= ERP/AAK-Key ::=
{ sub-TLV: CAP-Identifier } { sub-TLV: CAP-Identifier }
{ sub-TLV: pMSK-lifetime } { sub-TLV: pMSK Lifetime }
{ sub-TLV: pRK-lifetime } { sub-TLV: pRK Lifetime }
{ sub-TLV: Cryptosuites } { sub-TLV: Cryptosuites }
CAP-Identifier CAP-Identifier
Carried in a sub-TLV payload. The Type is TBD (less than 128). Carried in a sub-TLV payload. The Type is 11 (less than 128).
This field is used to indicate the identifier of the candidate This field is used to indicate the identifier of the candidate
authenticator. The value field MUST be encoded as specified in authenticator. The value field MUST be encoded as specified in
Section 8 of RFC 3315 [RFC3315]. There at least one instance of Section 8 of [RFC3315]. At least one instance of the CAP-
the CAP-Identifier TLV MUST be present in the ERP/AAK-Key TLV. Identifier TLV MUST be present in the ERP/AAK-Key TLV.
pMSK-lifetime pMSK Lifetime
Carried in a sub-TLV payload of the EAP-Finish/Re-auth message. Carried in a sub-TLV payload of the EAP-Finish/Re-auth message.
The Type is TBD. The value field is an unsigned 32-bit field and The Type is 10. The value field is an unsigned 32-bit field and
contains the lifetime of the pMSK in seconds. This value is contains the lifetime of the pMSK in seconds. This value is
calculated by the server after pRK-lifetime computation upon calculated by the server after performing the pRK Lifetime
receiving the EAP-Initiate/Re-auth message. The rIK SHOULD share computation upon receiving the EAP-Initiate/Re-auth message. The
the same lifetime as the pMSK. If the 'L' flag is set, the pMSK- rIK SHOULD share the same lifetime as the pMSK. If the 'L' flag
Lifetime attribute MUST be present. is set, the pMSK Lifetime attribute MUST be present.
pRK-lifetime pRK Lifetime
Carried in a sub-TLV payload of EAP-Finish/Re-auth message. The Carried in a sub-TLV payload of EAP-Finish/Re-auth message. The
Type is TBD. The value field is an unsigned 32-bit field and Type is 9. The value field is an unsigned 32-bit field and
contains the lifetime of the pRK in seconds. This value is contains the lifetime of the pRK in seconds. This value is
calculated by the server before pMSK-lifetime computation upon calculated by the server before performing the pMSK Lifetime
receiving a EAP-Initiate/Re-auth message. If the 'L' flag is set, computation upon receiving a EAP-Initiate/Re-auth message. If the
the pRK-Lifetime attribute MUST be present. 'L' flag is set, the pRK Lifetime attribute MUST be present.
List of Cryptosuites List of Cryptosuites
Carried in a sub-TLV payload. The Type is 5 [RFC5296]. The value Carried in a sub-TLV payload. The Type is 5 [RFC5296]. The value
field contains a list of cryptosuites (at least one cryptosuite field contains a list of cryptosuites (at least one cryptosuite
SHOULD be included), each 1 octet in length. The allowed SHOULD be included), each 1 octet in length. The allowed
cryptosuite values are as specified in Section 5.2, above. The cryptosuite values are as specified in Section 5.2. The server
server SHOULD include this attribute if the cryptosuite used in SHOULD include this attribute if the cryptosuite used in the
the EAP-Initiate/Re-auth message was not acceptable and the EAP-Initiate/Re-auth message was not acceptable and the message is
message is being rejected. The server MAY include this attribute being rejected. The server MAY include this attribute in other
in other cases. The server MAY use this attribute to signal to cases. The server MAY use this attribute to signal its
the peer about its cryptographic algorithm capabilities. cryptographic algorithm capabilities to the peer.
Cryptosuite Cryptosuite
This field indicates the integrity algorithm and PRF used for ERP/ This field indicates the integrity algorithm and PRF used for ERP/
AAK. HMAC-SHA256-128 is REQUIRED to implement and SHOULD be enabled AAK. HMAC-SHA256-128 is REQUIRED to implement, and it SHOULD be
in the default configuration. Key lengths and output lengths are enabled in the default configuration. Key lengths and output lengths
either indicated or obvious from the cryptosuite name. are either indicated or obvious from the cryptosuite name.
Authentication Tag Authentication Tag
This field contains the integrity checksum over the ERP/AAK packet This field contains the integrity checksum over the ERP/AAK packet
from the first bit of the Code field to the last bit of the from the first bit of the Code field to the last bit of the
Cryptosuite field excluding the Authentication Tag field itself. The Cryptosuite field, excluding the Authentication Tag field itself.
value field is calculated using the integrity algorithm indicated in The value field is calculated using the integrity algorithm indicated
the Cryptosuite field and the rIK [RFC5296] as the integrity key. in the Cryptosuite field and the rIK [RFC5296] as the integrity key.
The length of the field is indicated by the corresponding The length of the field is indicated by the corresponding
Cryptosuite. Cryptosuite.
The peer uses the authentication tag to determine the validity of the The peer uses the authentication tag to determine the validity of the
EAP-Finish/Re-auth message from a server. EAP-Finish/Re-auth message from a server.
If the message doesn't pass verification or the authentication tag is If the message doesn't pass verification or the authentication tag is
not included in the message, the message SHOULD be discarded not included in the message, the message SHOULD be discarded
silently. silently.
If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is
discarded silently. The peer MUST maintain retransmission timers for discarded silently. The peer MUST maintain retransmission timers for
reliable transport of EAP-Initiate/Re-auth message. If there is no reliable transport of the EAP-Initiate/Re-auth message. If there is
response to the EAP-Initiate/Re-auth message from the server after no response to the EAP-Initiate/Re-auth message from the server after
the necessary number of retransmissions (See Section 6), the peer the necessary number of retransmissions (see Section 6), the peer
MUST assume that ERP/AAK is not supported by the SAP. MUST assume that ERP/AAK is not supported by the SAP.
5.4. TV and TLV Attributes 5.4. TV and TLV Attributes
With the exception of the rRK-Lifetime and rMSK-Lifetime TV payloads, With the exception of the rRK Lifetime and rMSK Lifetime TV payloads,
the attributes specified in Section 5.3.4 of [RFC5296] also apply to the attributes specified in Section 5.3.4 of [RFC5296] also apply to
this document. In this document, new attributes which may be present this document. In this document, new attributes that may be present
in the EAP-Initiate and EAP-Finish messages are defined as below: in the EAP-Initiate and EAP-Finish messages are defined as below:
o Sequence number: This is a TV payload. The type is 7. o Sequence number: This is a TV payload. The Type is 7.
o ERP/AAK-Key: This is a TLV payload. The type is 8. o ERP/AAK-Key: This is a TLV payload. The Type is 8.
o pRK-Lifetime: This is a TV payload. The type is 9. o pRK Lifetime: This is a TV payload. The Type is 9.
o pMSK-Lifetime: This is a TV payload. The type is 10. o pMSK Lifetime: This is a TV payload. The Type is 10.
o CAP-Identifier: This is a TLV payload. The type is 11. o CAP-Identifier: This is a TLV payload. The Type is 11.
6. Lower Layer Considerations 6. Lower-Layer Considerations
Similar to ERP, some lower layer specifications may need to be Similar to ERP, some lower-layer specifications may need to be
revised to support ERP/AAK; refer to Section 6 of [RFC5296] for revised to support ERP/AAK; refer to Section 6 of [RFC5296] for
additional guidance. additional guidance.
7. AAA Transport Considerations 7. AAA Transport Considerations
The AAA transport of ERP/AAK messages is the same as that of the ERP The AAA transport of ERP/AAK messages is the same as that of the ERP
message [RFC5296]. In addition, this document requires AAA transport message [RFC5296]. In addition, this document requires AAA transport
of the ERP/AAK keying materials delivered by the ERP/AAK server to of the ERP/AAK keying materials delivered by the ERP/AAK server to
the CAP. Hence, a new AAA message for the ERP/AAK application should the CAP. Hence, a new AAA message for the ERP/AAK application should
be specified to transport the keying materials. be specified to transport the keying materials.
8. Security Considerations 8. Security Considerations
This section provides an analysis of the protocol in accordance with This section provides an analysis of the protocol in accordance with
the AAA key management requirements specified in RFC 4962 [RFC4962]. the AAA key management requirements specified in [RFC4962].
o Cryptographic algorithm independence: ERP-AAK satisfies this o Cryptographic algorithm independence: ERP-AAK satisfies this
requirement. The algorithm chosen by the peer for calculating the requirement. The algorithm chosen by the peer for calculating the
authentication tag is indicated in the EAP-Initiate/Re-auth authentication tag is indicated in the EAP-Initiate/Re-auth
message. If the chosen algorithm is unacceptable, the EAP server message. If the chosen algorithm is unacceptable, the EAP server
returns an EAP-Finish/Re-auth message with a Failure indication. returns an EAP-Finish/Re-auth message with a Failure indication.
o Strong, fresh session keys: ERP-AAK results in the derivation of o Strong, fresh session keys: ERP-AAK results in the derivation of
strong, fresh keys that are unique for the given CAP. An pMSK is strong, fresh keys that are unique for the given CAP. A pMSK is
always derived on-demand when the peer requires a key with a new always derived on demand when the peer requires a key with a new
CAP. The derivation ensures that the compromise of one pMSK does CAP. The derivation ensures that the compromise of one pMSK does
not result in the compromise of a different pMSK at any time. not result in the compromise of a different pMSK at any time.
o Limit key scope: The scope of all the keys derived by ERP-AAK is o Limit key scope: The scope of all the keys derived by ERP-AAK is
well defined. The pRK is used to derive the pMSK for the CAP. well defined. The pRK is used to derive the pMSK for the CAP.
Different sequence numbers for each CAP MUST be used to derive a Different sequence numbers for each CAP MUST be used to derive a
unique pMSK. unique pMSK.
o Replay detection mechanism: For replay protection a sequence o Replay detection mechanism: For replay protection, a sequence
number associated with the pMSK is used.The peer increments the number associated with the pMSK is used. The peer increments the
sequence number by one after it sends an ERP/AAK message. The sequence number by one after it sends an ERP/AAK message. The
server sets the expected sequence number to the received sequence server sets the expected sequence number to the received sequence
number plus one after verifying the validity of the received number plus one after verifying the validity of the received
message and responds to the message. message, and it responds to the message.
o Authenticate all parties: The EAP Re-auth Protocol provides mutual o Authenticate all parties: The EAP Re-authentication Protocol
authentication of the peer and the server. The peer and SAP are provides mutual authentication of the peer and the server. The
authenticated via ERP. The CAP is authenticated and trusted by peer and SAP are authenticated via ERP. The CAP is authenticated
the SAP. and trusted by the SAP.
o Peer and authenticator authorization: The peer and authenticator o Peer and authenticator authorization: The peer and authenticator
demonstrate possession of the same keying material without demonstrate possession of the same keying material without
disclosing it, as part of the lower layer secure authentication disclosing it, as part of the lower-layer secure authentication
protocol. protocol.
o Keying material confidentiality: The peer and the server derive o Keying material confidentiality: The peer and the server derive
the keys independently using parameters known to each entity. the keys independently using parameters known to each entity.
o Uniquely named keys: All keys produced within the ERP context can o Uniquely named keys: All keys produced within the ERP context can
be referred to uniquely as specified in this document. be referred to uniquely as specified in this document.
o Prevent the domino effect: Different sequence numbers for each CAP o Prevent the domino effect: Different sequence numbers for each CAP
MUST be used to derive the unique pMSK. So the compromise of one MUST be used to derive the unique pMSK so that the compromise of
pMSK does not hurt any other CAP. one pMSK does not hurt any other CAP.
o Bind key to its context: the pMSK are bound to the context in o Bind key to its context: The pMSKs are bound to the context in
which the sequence numbers are transmitted. which the sequence numbers are transmitted.
o Confidentiality of identity: this is the same as with the ERP o Confidentiality of identity: This is the same as with ERP
protocol [RFC5296]. [RFC5296].
o Authorization restriction: All the keys derived are limited in o Authorization restriction: All the keys derived are limited in
lifetime by that of the parent key or by server policy. Any lifetime by that of the parent key or by server policy. Any
domain-specific keys are further restricted to be used only in the domain-specific keys are further restricted to be used only in the
domain for which the keys are derived. Any other restrictions of domain for which the keys are derived. Any other restrictions of
session keys may be imposed by the specific lower layer and are session keys may be imposed by the specific lower layer and are
out of scope for this specification. out of scope for this specification.
9. IANA Considerations 9. IANA Considerations
IANA is requested to assign five TLV type values from the registry of IANA has assigned five TLVs from the registry of EAP Initiate and
EAP Initiate and Finish Attributes maintained at Finish Attributes maintained at
http://www.iana.org/assignments/eap-numbers/eap-numbers.xml. http://www.iana.org/assignments/eap-numbers/ with the following
with the following numbers: numbers:
o Sequence number: This is a TV payload. The type is 7. o Sequence number: This is a TV payload. The Type is 7.
o ERP/AAK-Key: This is a TLV payload. The type is 8. o ERP/AAK-Key: This is a TLV payload. The Type is 8.
o pRK Lifetime: This is a TLV payload. The type is 9. o pRK Lifetime: This is a TLV payload. The Type is 9.
o pMSK Lifetime: This is a TLV payload. The type is 10. o pMSK Lifetime: This is a TLV payload. The Type is 10.
o CAP-Identifier: This is a TLV payload. The type is 11. o CAP-Identifier: This is a TLV payload. The Type is 11.
This document reuses the crytosuites have already created for 'Re- This document reuses the cryptosuites that were created for
authentication Cryptosuites' in [RFC5296]. "Re-authentication Cryptosuites" in [RFC5296].
Further, this document instructs IANA to add a new label in the User Further, IANA has added a new label in the "User Specific Root Keys
Specific Root Keys (USRK) Key Labels of the Extended Master Session (USRK) Key Labels" sub-registry of the "Extended Master Session Key
Key (EMSK) Parameters registry, as follows: (EMSK) Parameters" registry, as follows:
EAP Early-Authentication Root Key@ietf.org EAP Early-Authentication Root Key@ietf.org
This document creates a new registry for the flags in the EAP A new registry for the flags in the EAP Initiate/Re-auth-Start
Initiate/Re-auth-Start message called the "EAP Initiate/Re-auth-Start message called the "EAP Initiate/Re-auth-Start Flags" has been
Flags" and assigns a new flag (E) as follows: created and a new flag (E) has been assigned as follows:
(E) 0x80 (E) 0x80
The rest of the values in the 8-bit field are reserved. New values The rest of the values in the 8-bit field are reserved. New values
can be assigned by Standards Action or IESG approval. can be assigned by Standards Action or IESG Approval [RFC5226].
This document also creates a new registry for the flags in the EAP A new registry for the flags in the EAP Initiate/Re-auth message
Initiate/Re-auth message called the "EAP Initiate/Re-auth Flags". called the "EAP Initiate/Re-auth Flags" has also been created. The
The following flag are reserved: following flags are reserved:
(R) 0x80 [RFC5296] (R) 0x80 [RFC5296]
(B) 0x40 [RFC5296] (B) 0x40 [RFC5296]
(L) 0x20 [RFC5296] (L) 0x20 [RFC5296]
This document assigns a new flag (E) as follows: This document assigns a new flag (E) as follows:
(E) 0x10 (E) 0x10
The rest of the values in the 8-bit field are reserved. New values The rest of the values in the 8-bit field are reserved. New values
can be assigned by Standards Action or IESG approval. can be assigned by Standards Action or IESG Approval.
Further,this document creates a new registry for the flags in the EAP Further, this document creates a new registry for the flags in the
Finish/Re-auth message called the "EAP Finish/Re-auth Flags". The EAP Finish/Re-auth message called the "EAP Finish/Re-auth Flags".
following values are reserved. The following values are assigned.
(R) 0x80 [RFC5296] (R) 0x80 [RFC5296]
(B) 0x40 [RFC5296] (B) 0x40 [RFC5296]
(L) 0x20 [RFC5296] (L) 0x20 [RFC5296]
This document assigns a new flag (E) as follows: This document assigns a new flag (E) as follows:
(E) 0x10 (E) 0x10
The rest of the values in the 8-bit field are reserved. New values The rest of the values in the 8-bit field are reserved. New values
can be assigned by Standards Action or IESG approval. can be assigned by Standards Action or IESG approval.
10. Acknowledgement 10. Acknowledgements
In writing this document, Yungui Wang contributed to early versions In writing this document, Yungui Wang contributed to early versions
of this document and we have received reviews from many experts in of this document and we have received reviews from many experts in
the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang, Semyon the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang, Semyon
Mizikovsky, Stephen Farrell, Radia Perlman, Miguel A. Garcia and Mizikovsky, Stephen Farrell, Radia Perlman, Miguel A. Garcia, and
Sujing Zhou. We apologize if we miss some of those who have helped Sujing Zhou. We apologize if we miss some of those who have helped
us. us.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
RFCs to Indicate Requirement Levels", Requirement Levels", BCP 14, RFC 2119, March 1997.
BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Lemon, T., Perkins, C., and M. Carney, and M. Carney, "Dynamic Host Configuration Protocol for
"Dynamic Host Configuration Protocol IPv6 (DHCPv6)", RFC 3315, July 2003.
for IPv6 (DHCPv6)", RFC 3315,
July 2003.
[RFC5295] Salowey, J., Dondeti, L., Narayanan, [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
V., and M. Nakhjiri, "Specification Network Access Identifier", RFC 4282, December 2005.
for the Derivation of Root Keys from
an Extended Master Session Key
(EMSK)", August 2008.
[RFC5296] Narayanan, V. and L. Dondeti, "EAP [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Extensions for EAP Re-authentication IANA Considerations Section in RFCs", BCP 26, RFC 5226,
Protocol (ERP)", RFC 5296, May 2008.
August 2008.
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an
Extended Master Session Key (EMSK)", RFC 5295,
August 2008.
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP
Re-authentication Protocol (ERP)", RFC 5296, August 2008.
11.2. Informative References 11.2. Informative References
[I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev, [KEYTRAN] Zorn, G., Wu, W., and V. Cakulev, "Diameter Attribute-
"Diameter Attribute-Value Pairs for Value Pairs for Cryptographic Key Transport", Work
Cryptographic Key Transport", in Progress, August 2011.
draft-ietf-dime-local-keytran-14 (work
in progress), August 2011.
[RFC2104] Krawczyk, H., Bellare, M., and R. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Canetti, "HMAC: Keyed-Hashing for Hashing for Message Authentication", RFC 2104,
Message Authentication", RFC 2104, February 1997.
February 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
E., Zorn, G., and J. Arkko, "Diameter Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
Base Protocol", RFC 3588,
September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Carlson, J., and H. Levkowetz, Levkowetz, "Extensible Authentication Protocol (EAP)",
"Extensible Authentication Protocol RFC 3748, June 2004.
(EAP)", RFC 3748, June 2004.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
SHA-256, HMAC-SHA-384, and HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
512 with IPsec", RFC 4868, May 2007.
[RFC4962] Housley, R. and B. Aboba, "Guidance [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
for Authentication, Authorization, and Authorization, and Accounting (AAA) Key Management",
Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
BCP 132, RFC 4962, July 2007.
[RFC5836] Ohba, Y., Wu, Q., and G. Zorn, [RFC5836] Ohba, Y., Wu, Q., and G. Zorn, "Extensible Authentication
"Extensible Authentication Protocol Protocol (EAP) Early Authentication Problem Statement",
(EAP) Early Authentication Problem RFC 5836, April 2010.
Statement", RFC 5836, April 2010.
[RFC5890] Klensin, J., "Internationalized Domain [RFC5890] Klensin, J., "Internationalized Domain Names for
Names for Applications (IDNA): Applications (IDNA): Definitions and Document Framework",
Definitions and Document Framework", RFC 5890, August 2010.
RFC 5890, August 2010.
Authors' Addresses Authors' Addresses
Zhen Cao Zhen Cao
China Mobile China Mobile
53A Xibianmennei Ave., Xuanwu District 53A Xibianmennei Ave., Xuanwu District
Beijing, Beijing 100053 Beijing, Beijing 100053
P.R. China P.R. China
EMail: zehn.cao@gmail.com EMail: zehn.cao@gmail.com
skipping to change at page 20, line 4 skipping to change at page 20, line 22
EMail: zehn.cao@gmail.com EMail: zehn.cao@gmail.com
Hui Deng Hui Deng
China Mobile China Mobile
53A Xibianmennei Ave., Xuanwu District 53A Xibianmennei Ave., Xuanwu District
Beijing, Beijing 100053 Beijing, Beijing 100053
P.R. China P.R. China
EMail: denghui02@gmail.com EMail: denghui02@gmail.com
Qin Wu Qin Wu
Huawei Huawei
Floor 12, HuiHong Mansion, No.91 BaiXia Rd. Floor 12, HuiHong Mansion, No. 91 BaiXia Rd.
Nanjing, Jiangsu 210001 Nanjing, Jiangsu 210001
P.R. China P.R. China
Phone: +86 25 56623633 Phone: +86 25 56623633
EMail: sunseawq@huawei.com EMail: sunseawq@huawei.com
Glen Zorn (editor) Glen Zorn (editor)
Network Zen Network Zen
227/358 Thanon Sanphawut 227/358 Thanon Sanphawut
Bang Na, Bangkok 10260 Bang Na, Bangkok 10260
 End of changes. 133 change blocks. 
281 lines changed or deleted 288 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/