--- 1/draft-ietf-hokey-erp-aak-09.txt 2012-02-17 12:13:59.998671237 +0100 +++ 2/draft-ietf-hokey-erp-aak-10.txt 2012-02-17 12:14:00.034671240 +0100 @@ -1,23 +1,23 @@ Network Working Group Z. Cao Internet-Draft H. Deng Intended status: Standards Track China Mobile -Expires: August 15, 2012 Q. Wu +Expires: August 20, 2012 Q. Wu Huawei G. Zorn, Ed. Network Zen - February 12, 2012 + February 17, 2012 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) - draft-ietf-hokey-erp-aak-09 + draft-ietf-hokey-erp-aak-10 Abstract The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. @@ -38,21 +38,21 @@ 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 August 15, 2012. + This Internet-Draft will expire on August 20, 2012. Copyright Notice Copyright (c) 2012 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 @@ -66,31 +66,31 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. ERP/AAK Description . . . . . . . . . . . . . . . . . . . . . 4 4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7 4.1. Derivation of the pRK and pMSK . . . . . . . . . . . . . . 8 5. 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.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 11 + 5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 10 + 5.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 12 5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 14 - 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 14 - 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 14 + 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 15 + 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 + 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 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, it is desirable to not repeat the entire EAP exchange with another authenticator. The EAP Re-authentication Protocol (ERP) [RFC5296] specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the EAP re- @@ -152,21 +152,21 @@ specification is out of the scope of this document. Figure 1 shows the general protocol exchange by which the keying material is established on the CAP. +------+ +-----+ +-----+ +-----------+ | Peer | | SAP | | CAP | | EA Server | +--+---+ +--+--+ +--+--+ +-----+-----+ | | | | a. | [EAP-Initiate/ | | | | Re-auth-start | | | - | (E-flag) | | | + | (E-flag)] | | | |<---------------| | | | | | | b. | EAP-Initiate/ | | | | Re-auth | | | | (E-flag) | | | |--------------->| | | c. | | AAA(EAP-Initiate/Re-auth(E-flag))| | |--------------------------------->| | | | +---------+---------+ | | | | CA authorized & | @@ -305,48 +305,50 @@ K = EMSK or K = 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 assigned from the "USRK key labels" name space in accordance with 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 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 + EAP Early-Authentication Master Session Key@ietf.org 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 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 Section 5.2 and Section 5.3. 5. Packet and TLV Extension This section describes the packet and TLV extensions for the ERP/AAK exchange. 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]. 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -367,44 +369,48 @@ that of a DiameterIdentity [RFC3588]. It is used by the SAP to advertise the identity of the CAP to the peer. Exactly one CAP- Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start packet if the SAP has performed CAP discovery. If the EAP-Initiate/Re-auth-Start packet is not supported by the peer, it SHOULD be discarded silently. 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]. 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|x|L|E|Resved | SEQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 or more TVs or TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cryptosuite | Authentication Tag ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 Flags '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. - 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 As defined in Section 5.3.2 of [RFC5296],this field is 16-bit sequence number and used for replay protection. TVs and TLVs 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 @@ -464,48 +470,55 @@ If the EAP-Initiate/Re-auth packet is not supported by the SAP, it SHOULD be discarded silently. The peer MUST maintain retransmission 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 server after the necessary number of retransmissions (see Section 6), the peer MUST assume that ERP/AAK is not supported by the SAP. 5.3. EAP-Finish/Re-auth packet and TLV extension - Figure 7 shows the changed parameters contained in the EAP-Finish/ - Re-auth packet defined in [RFC5296]. + Figure 7 shows the new parameters contained in the EAP-Finish/Re-auth + packet defined in [RFC5296]. 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|x|L|E|Resved | SEQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 or more TVs or TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cryptosuite | Authentication Tag ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 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. + '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. The final 4 bits (Resved) MUST be set to 0 and ignored on reception. 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. TVs and TLVs 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 exceeding 253 octets. Exactly one keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth packet. ERP/AAK-Key: Carried in a TLV payload for the key container. The @@ -549,21 +562,21 @@ cryptosuite values are as specified in Section 5.2, above. The server SHOULD include this attribute if the cryptosuite used in the EAP-Initiate/Re-auth message was not acceptable and the message is being rejected. The server MAY include this attribute in other cases. The server MAY use this attribute to signal to the peer about its cryptographic algorithm capabilities. Cryptosuite 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 either indicated or obvious from the cryptosuite name. Authentication Tag 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 Cryptosuite field excluding the Authentication Tag field itself. The value field is calculated using the integrity algorithm indicated in the Cryptosuite field and the rIK [RFC5296] as the integrity key. @@ -592,20 +605,22 @@ 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 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 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 Similar to ERP, some lower layer specifications may need to be revised to support ERP/AAK; refer to Section 6 of [RFC5296] for additional guidance. 7. AAA Transport Considerations The AAA transport of ERP/AAK messages is the same as that of the ERP message [RFC5296]. In addition, this document requires AAA transport @@ -683,29 +698,72 @@ with the following numbers: 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 pRK Lifetime: This is a TLV payload. The type is 9. 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- authentication Cryptosuites' in [RFC5296]. Further, this document instructs IANA to add a new label in the User Specific Root Keys (USRK) Key Labels of the Extended Master Session Key (EMSK) Parameters registry, as follows: 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 In writing this document, Yungui Wang contributed to early versions of this document and we have received reviews from many experts in the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang, Semyon Mizikovsky, Stephen Farrell, Radia Perlman, Miguel A. Garcia and Sujing Zhou. We apologize if we miss some of those who have helped us. 11. References