--- 1/draft-ietf-hokey-erp-aak-00.txt 2010-04-27 09:12:10.000000000 +0200 +++ 2/draft-ietf-hokey-erp-aak-01.txt 2010-04-27 09:12:11.000000000 +0200 @@ -1,24 +1,24 @@ Network Working Group Z. Cao Internet-Draft H. Deng Intended status: Standards Track China Mobile -Expires: October 11, 2010 Y. Wang +Expires: October 29, 2010 Y. Wang Q. Wu Huawei Technologies Co., Ltd. G. Zorn, Ed. Network Zen - April 9, 2010 + April 27, 2010 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory - Keying - draft-ietf-hokey-erp-aak-00 + Keying (ERP/AAK) + draft-ietf-hokey-erp-aak-01 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 October 11, 2010. + This Internet-Draft will expire on October 29, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -62,87 +62,77 @@ 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 - 4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 6 - 5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 7 - 5.1. EAP-Initiate/Re-auth-Start Packet Extension . . . . . . . 7 - 5.2. EAP-Initiate/Re-auth Packet Extension . . . . . . . . . . 8 + 4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 5 + 5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 6 + 5.1. EAP-Initiate/Re-auth-Start Packet Extension . . . . . . . 6 + 5.2. EAP-Initiate/Re-auth Packet Extension . . . . . . . . . . 7 5.3. EAP-Finish/Re-auth extension . . . . . . . . . . . . . . . 9 5.4. TV/TLV and sub-TLV Attributes . . . . . . . . . . . . . . 11 - 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 12 - 7. AAA Transport Consideration . . . . . . . . . . . . . . . . . 12 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 11 + 7. AAA Transport Consideration . . . . . . . . . . . . . . . . . 11 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 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 peer and an EAP re-authentication server through any authenticator. The re- authentication server may be in the home network or in the local network to which the peer is connecting. - Authenticated Anticipatory Keying (AAK) [I-D.ietf-hokey-preauth-ps] - is a method by which cryptographic keying material may be established - prior to handover upon one or more candidate attachment points - (CAPs). AAK utilizes the AAA infrastructure for key transport. + Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by + which cryptographic keying material may be established prior to + handover upon one or more candidate attachment points (CAPs). AAK + utilizes the AAA infrastructure for key transport. This document specifies the extensions necessary to enable AAK support in ERP. 2. Terminology 2.1. Standards Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 2.2. Acronyms The following acronyms are used in this document; see the references for more details. - AAA - Authentication, Authorization and Accounting [RFC3588] - - CAP - Candidate Attachment Point [I-D.ietf-hokey-preauth-ps] - - EA + AAA Authentication, Authorization and Accounting [RFC3588] - Abbreviation for "ERP/AAK"; used in figures + CAP Candidate Attachment Point [RFC5836] - ERP/AAK - EAP Re-authentication Protocol Extensions for Authenticated - Anticipatory Keying + EA Abbreviation for "ERP/AAK"; used in figures - MH - Mobile Host + MH Mobile Host - SAP - Serving Attachment Point [I-D.ietf-hokey-preauth-ps] + SAP Serving Attachment Point [RFC5836] 3. ERP/AAK Overview ERP/AAK is intended to allow the establishment of cryptographic keying materials on one or more Candidate Attachment Points prior to the arrival of the MH at the Candidate Access Network (CAN). The document also specifies a method by which the SAP may send the identities of neighboring attachment points to the peer in the EAP- Initiate/Re-auth-Start message. @@ -162,36 +152,35 @@ 2. | EAP-Initiate/ | | | | Re-auth | | | | | (E-flag) | | | | |---------->| | | | 3. | | AAA (EAP-Initiate/Re-auth(E-flag))| | |---------------------------------->| | | | | | | | | | +---------+---------+ | | | | | CA authorized & | 4. | | | | | authenticated; | - | | | | | EA keying | + | | | | | EE keying | | | | | | materials derived | | | | | +---------+---------+ | | | | | - 5. | | | AAA (pMSK) | - | | | |<----------->| + 5. | | | | AAA(pMSKx) | + | | |AAA(pMSK1)|<----------->| | | |<---------------------->| | | | | | 6. | | AAA (EAP-Finish/Re-auth(E-flag)) | | |<----------------------------------| | | | | | 7. | EAP-Finish/ | | | | Re-auth(E-flag) | | | |<----------| | | | | | | | | - Figure 1: ERP/AAK Operation ERP/AAK re-uses the packet format defined by ERP, but specifies a new flag to differentiate EAP early-authentication from EAP re- authentication. The peer initiates ERP/AAK itself, or does so in response to an EAP-Initiate/Re-Auth-Start message from the SAP. In this document, it is required that the SAP should support ERP/AAK. If either the peer or the SAP does not support ERP/AAK, it should fall back to full EAP authentication. @@ -499,25 +487,24 @@ 6. Lower Layer Considerations Similar to ERP, the lower layer specifications may need to be revised to support ERP/AAK. Refer to section 6 of [RFC5296] for additional guidance. 7. AAA Transport Consideration AAA transport of ERP/AAK message is the same as AAA transport of the - ERP message specified ERP [RFC5296]. In addition, the document - requires AAA transport of the ERP/AAK keying materials delivered by - the ERP/AAK server to the CAP. Hence, a new Diameter ERP/AAK - application message should be specified to transport the keying - materials. + ERP message [RFC5296]. In addition, the document requires AAA + transport of the ERP/AAK keying materials delivered by the ERP/AAK + server to the CAP. Hence, a new Diameter ERP/AAK application message + should be specified to transport the keying materials. 8. Security Considerations TBD. 9. IANA Considerations New TLV types: NAS-Identifier @@ -550,46 +537,44 @@ August 2008. 10.2. Informative References [I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev, "Diameter Attribute-Value Pairs for Cryptographic Key Transport", draft-ietf-dime-local-keytran-02 (work in progress), March 2010. - [I-D.ietf-hokey-preauth-ps] Ohba, Y., Wu, Q., and G. Zorn, - "Extensible Authentication Protocol - (EAP) Early Authentication Problem - Statement", - draft-ietf-hokey-preauth-ps-12 (work - in progress), December 2009. - [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. + [RFC5836] Ohba, Y., Wu, Q., and G. Zorn, + "Extensible Authentication Protocol + (EAP) Early Authentication Problem + Statement", RFC 5836, April 2010. + Authors' Addresses Zhen Cao China Mobile 53A Xibianmennei Ave., Xuanwu District Beijing, Beijing 100053 P.R. China - EMail: caozhen@chinamobile.com + EMail: zehn.cao@gmail.com Hui Deng China Mobile 53A Xibianmennei Ave., Xuanwu District Beijing, Beijing 100053 P.R. China EMail: denghui02@gmail.com Yungui Wang