--- 1/draft-ietf-hokey-erp-aak-07.txt 2012-02-08 14:14:00.414671726 +0100 +++ 2/draft-ietf-hokey-erp-aak-08.txt 2012-02-08 14:14:00.450671186 +0100 @@ -1,23 +1,23 @@ Network Working Group Z. Cao Internet-Draft H. Deng Intended status: Standards Track China Mobile -Expires: July 20, 2012 Q. Wu +Expires: August 11, 2012 Q. Wu Huawei G. Zorn Network Zen - January 17, 2012 + February 8, 2012 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) - draft-ietf-hokey-erp-aak-07 + draft-ietf-hokey-erp-aak-08 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 July 20, 2012. + This Internet-Draft will expire on August 11, 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 @@ -61,21 +61,21 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. ERP/AAK Overview . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. ERP/AAK Description . . . . . . . . . . . . . . . . . . . . . 4 4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 6 4.1. pRK, pMSK derivation . . . . . . . . . . . . . . . . . . . 7 5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 8 5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 8 5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 8 5.3. EAP-Finish/Re-auth packet and TLV extension . . . . . . . 10 5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 13 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 13 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 @@ -122,25 +122,26 @@ AAA Authentication, Authorization and Accounting [RFC3588] CAP Candidate Attachment Point [RFC5836] EA Abbreviation for "ERP/AAK"; used in figures MH Mobile Host SAP Serving Attachment Point [RFC5836] -3. ERP/AAK Overview +3. ERP/AAK Description ERP/AAK is intended to allow the establishment of cryptographic keying materials on a single Candidate Attachment Points prior to the - arrival of the MH at the Candidate Access Network (CAN). + arrival of the MH at the Candidate Access Network (CAN) upon request + by the peer. In this document, ERP/AAK support for the peer is assumed. Also it is assumed that the peer has previously completed full EAP authentication and the peer or SAP knows the identities of neighboring attachment points. Note that the behavior of the peer that does not support the ERP-AAK scheme defined in this 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. @@ -214,43 +215,44 @@ RFC5296 and used to protect the integrity of the message. The sequence number is used for replay protection. The SAP SHOULD verify the integrity of the message at step b. If This verifications fail, the SAP MUST send an EAP- Finish/Re-auth message with the Result flag set to '1' (Failure).In success case, the SAP SHOULD encapsulate the early-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 c. in the figure 1). - Upon receiving the message, the ERP/AAK server first uses the keyName - indicated in the keyName-NAI to look up the rIK and checks the - integrity and freshness of the message, then verifies the identity of - the peer by checking the username portion of the KeyName-NAI. If any - of the checks fail, the server SHOULD send an early- authentication - finish message (EAP-Finish/Re-auth with E-flag set) with the Result - flag set to '1'. Next, the server SHOULD authorize the CAP specified - in the CAP-Identifier TLV. In success case, the server derives a - pMSK from the pRK for each CAP carried in the the CAP-Identifier - field using the sequence number associated with CAP-Identifier as an - input to the key derivation. (see d. in the figure 1) + Upon receiving the message, the ERP/AAK server MUST first use the + keyName indicated in the keyName-NAI to look up the rIK and MUST + check the integrity and freshness of the message. Then the ERP/AAK + server MUST verify the identity of the peer by checking the username + portion of the KeyName-NAI. If any of the checks fail, the server + MUST send an early- authentication finish message (EAP-Finish/Re-auth + with E-flag set) with the Result flag set to '1'. Next, the server + MUST authorize the CAP specified in the CAP-Identifier TLV. In + success case, the server MUST derive a pMSK from the pRK for each CAP + carried in the the CAP-Identifier field using the sequence number + associated with CAP-Identifier as an input to the key derivation. + (see d. in the figure 1) - Then The ERP/AAK server transports the pMSK to the authorized CAP via - AAA Section 7 as described in figure 2 (see e.1,e.2 in the figure 2). - Note that key distribution in the figure 2 is one part of step d. in - the figure 1. + Then The ERP/AAK server MUST transport the pMSK to the authorized CAP + via AAA Section 7 as described in figure 2 (see e.1,e.2 in the figure + 2). Note that key distribution in the figure 2 is one part of step + d. in the figure 1. Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK - server sends the early-authentication finish message (EAP-Finish/ - Re-auth with E-flag set) containing the identity of the authorized - CAP to the peer via the SAP and associated lifetime of pMSK, - Optionally, if the peer also requests the server for the rRK - lifetime, the EA server SHOULD send the rRK lifetime in the EAP- + server SHOULD send the early-authentication finish message (EAP- + Finish/ Re-auth with E-flag set) containing the identity of the + authorized CAP to the peer via the SAP and associated lifetime of + pMSK, OPTIONALLY, if the peer also requests the server for the rRK + lifetime, the ERP/AAK server SHOULD send the rRK lifetime in the EAP- Finish/Re-auth message. (see f.,g. in the figure 1). 4. ERP/AAK Key Hierarchy As an extension of ERP, ERP/AAK uses a key hierarchy similar to that of ERP. The ERP/AAK pre-established Root Key (pRK) is derived from either EMSK or DSRK as specified in the section 4.1. In general, the pRK is derived from the EMSK in case of the peer moving in the home AAA realm and derived from the DRSK in case of the peer moving in a visited realm. The DSRK is delivered from the EAP server to the ERP/ @@ -347,21 +349,21 @@ TVs and TLVs CAP-Identifier: Carried in a TLV payload. The format is identical 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- 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 is discarded silently. + 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- 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 | @@ -391,30 +393,32 @@ 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. The username part of the NAI is the EMSKname 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 the domain to which the peer is currently attached (i.e., local domain name) if the peer communicates with the local EA server. The - SAP knows if the KeyName-NAI carry local domain name by comparing the - domain name carried in KeyName-NAI with local domain name which is - associated with the SAP and SAP has already known. Exactly one - keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth - packet and The realm part of it SHOULD follows the use of - internationalized domain names defined in the RFC5890 [RFC5890]. + SAP knows whether the KeyName-NAI carries the local domain name by + comparing the domain name carried in KeyName-NAI with local domain + name which is associated with the SAP and SAP has already known. + Exactly one keyName-NAI attribute SHALL be present in an EAP- + Initiate/Re-auth packet and The realm part of it SHOULD follows the + use of internationalized domain names defined in the RFC5890 + [RFC5890]. CAP-Identifier: Carried in a TLV payload.The Type is TBD (less than 128). This field is used to indicate the FQDN of a CAP. The value field MUST be encoded as specified in Section 8 of RFC 3315 + [RFC3315]. There at least one instance of the CAP-Identifier TLV MUST be present in the ERP/AAK-Key TLV. Sequence number: The Type is TBD (less than 128). The value field is a 16-bit field and used in the derivation of the pMSK for a CAP. If multiple CAP-Identifiers are carried,each CAP-Identifier in the packet MUST be associated with a unique sequence number and followed by that sequence number. Cryptosuite @@ -425,39 +429,39 @@ the SHA-256 function [RFC4868] and with the 256 bit key length and output truncated to 128 bits [RFC2104]. We specify some cryptosuites below: 0~1 RESERVED 2 HMAC-SHA256-128 3 HMAC-SHA256-256 - HMAC-SHA256-128 is mandatory to implement and should be enabled in - the default configuration. + HMAC-SHA256-128 is REQUIRED to implement and SHOULD be enabled in the + default configuration. Authentication Tag This field contains the integrity checksum over the ERP/AAK packet, excluding the authentication tag field itself. The value field is calculated using the integrity algorithm indicated in the Cryptosuite field and rIK specified in [RFC5296] as the secret key. The length of the field is indicated by the Cryptosuite. The peer uses authentication tag to determine the validity of the EAP-Finish/Re-auth message originates at a server. If the message doesn't pass verification or authentication tag is not included in the message, the message SHOULD be discarded silently. - If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is - discarded silently. + If the EAP-Initiate/Re-auth packet is not supported by the SAP, it + SHOULD be discarded silently. 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]. 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 | @@ -482,23 +486,22 @@ 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 - exceeding 253 octets. The realm part of the NAI is the home domain - name. Exactly one keyName-NAI attribute SHALL be present in an EAP- - Finish/Re-auth packet. + 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 type is TBD. Exactly one ERP/AAK-key SHALL only be present in an EAP-Finish/Re-auth packet. ERP/AAK-Key ::= { sub-TLV: CAP-Identifier } { sub-TLV: pMSK-lifetime } { sub-TLV: pRK-lifetime } { sub-TLV: Cryptosuites } @@ -667,22 +670,23 @@ 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. This document reuses the crytosuites we have already created for 'Re- authentication Cryptosuites' in [RFC5296]. - Further, this document registers a Early authentication usage label - from the "USRK Key Labels" name space with a value: + 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 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 and Semyon Mizikovsky, Stephen Farrell,Sujing Zhou. We apologize if we miss some of those who have helped us.