draft-ietf-hokey-erp-aak-09.txt   draft-ietf-hokey-erp-aak-10.txt 
Network Working Group Z. Cao Network Working Group Z. Cao
Internet-Draft H. Deng Internet-Draft H. Deng
Intended status: Standards Track China Mobile Intended status: Standards Track China Mobile
Expires: August 15, 2012 Q. Wu Expires: August 20, 2012 Q. Wu
Huawei Huawei
G. Zorn, Ed. G. Zorn, Ed.
Network Zen Network Zen
February 12, 2012 February 17, 2012
EAP Re-authentication Protocol Extensions for Authenticated Anticipatory EAP Re-authentication Protocol Extensions for Authenticated Anticipatory
Keying (ERP/AAK) Keying (ERP/AAK)
draft-ietf-hokey-erp-aak-09 draft-ietf-hokey-erp-aak-10
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.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2012. This Internet-Draft will expire on August 20, 2012.
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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 2.1. Standards 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 . . . . . . 9 5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 10
5.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 14 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 15
7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 14 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 18
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 to not
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 re-
skipping to change at page 5, line 11 skipping to change at page 5, line 11
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 & |
skipping to change at page 8, line 36 skipping to change at page 8, line 36
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 "USRK key labels" name space in accordance with
Salowey, et al. [RFC5295]. The KDF and algorithm agility for the Salowey, et al. [RFC5295]. The KDF and algorithm agility for the
KDF are also defined in RFC 5295. KDF are also defined in RFC 5295. The KDF algorithm is indicated in
the cryptosuit field or list of cryptosuits TLV payload as specified
in the section 5.2 and section 5.3.
The pMSK is derived as follows: The pMSK uses the same PDF 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:
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 and encoded as an 16-bit number as specified in
Section 5.2 and Section 5.3. Section 5.2 and Section 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 changed 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 RFC 5296 [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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 49 skipping to change at page 10, line 7
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 CAP-
Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start 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 changed parameters contained in the EAP- Figure 6 illustrates the new parameters contained in the EAP-
Initiate/Re-auth packet defined in RFC 5296 [RFC5296]. Initiate/Re-auth packet defined in RFC 5296 [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
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
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 first bit(R) and final 4 bits (Resved) MUST be set to 0 and
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 RFC 5296 [RFC5296], this is carried in a
TLV payload. The Type is 1. The NAI is variable in length, not TLV payload. The Type is 1. The NAI is variable in length, not
skipping to change at page 11, line 50 skipping to change at page 12, line 11
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 changed parameters contained in the EAP-Finish/ Figure 7 shows the new parameters contained in the EAP-Finish/Re-auth
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
Flags Flags
'R' - As defined in Section 5.3.3 of [RFC5296], this bit is used to
used as the Result flag. This field MUST be set to '1' if indicates
success and 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
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.2 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 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 RFC 5296 [RFC5296], this is carried in a
TLV payload. The Type is 1. The NAI is variable in length, not TLV 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
skipping to change at page 13, line 43 skipping to change at page 14, line 8
cryptosuite values are as specified in Section 5.2, above. The cryptosuite values are as specified in Section 5.2, above. The
server SHOULD include this attribute if the cryptosuite used in server SHOULD include this attribute if the cryptosuite used in
the EAP-Initiate/Re-auth message was not acceptable and the the EAP-Initiate/Re-auth message was not acceptable and the
message is being rejected. The server MAY include this attribute message is being rejected. The server MAY include this attribute
in other cases. The server MAY use this attribute to signal to in other cases. The server MAY use this attribute to signal to
the peer about its cryptographic algorithm capabilities. the peer about its cryptographic algorithm capabilities.
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 mandatory to implement and SHOULD be enabled AAK. HMAC-SHA256-128 is REQUIRED to implement and SHOULD be enabled
in the default configuration. Key lengths and output lengths are in the default configuration. Key lengths and output lengths are
either indicated or obvious from the cryptosuite name. 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. The
value field is calculated using the integrity algorithm indicated in value field is calculated using the integrity algorithm indicated in
the Cryptosuite field and the rIK [RFC5296] as the integrity key. the Cryptosuite field and the rIK [RFC5296] as the integrity key.
skipping to change at page 14, line 37 skipping to change at page 14, line 51
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.
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
skipping to change at page 16, line 33 skipping to change at page 16, line 48
with the following numbers: with the following 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.
This document reuses the crytosuites have already created for 'Re- This document reuses the crytosuites have already created for 'Re-
authentication Cryptosuites' in [RFC5296]. authentication Cryptosuites' in [RFC5296].
Further, this document instructs IANA to add a new label in the User Further, this document instructs IANA to add a new label in the User
Specific Root Keys (USRK) Key Labels of the Extended Master Session Specific Root Keys (USRK) Key Labels of the Extended Master Session
Key (EMSK) Parameters registry, as follows: Key (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
Initiate/Re-auth-Start message called the "EAP Initiate/Re-auth-Start
Flags" and assigns a new flag (E) as follows:
(E) 0x80
The rest of the values in the 8-bit field are reserved. New values
can be assigned by Standards Action or IESG approval.
This document also creates a new registry for the flags in the EAP
Initiate/Re-auth message called the "EAP Initiate/Re-auth Flags".
The following flag are reserved:
(B) 0x40 [RFC5296]
(L) 0x20 [RFC5296]
This document assigns a new flag (E) as follows:
(E) 0x10
The rest of the values in the 8-bit field are reserved. New values
can be assigned by Standards Action or IESG approval.
Further,this document creates a new registry for the flags in the EAP
Finish/Re-auth message called the "EAP Finish/Re-auth Flags". The
following values are reserved.
(R) 0x80 [RF5296]
(B) 0x40 [RFC5296]
(L) 0x20 [RFC5296]
This document assigns a new flag (E) as follows:
(E) 0x10
The rest of the values in the 8-bit field are reserved. New values
can be assigned by Standards Action or IESG approval.
10. Acknowledgement 10. Acknowledgement
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
 End of changes. 23 change blocks. 
23 lines changed or deleted 81 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/