--- 1/draft-ietf-hokey-erp-aak-03.txt 2011-03-14 08:14:13.000000000 +0100 +++ 2/draft-ietf-hokey-erp-aak-04.txt 2011-03-14 08:14:13.000000000 +0100 @@ -1,24 +1,24 @@ Network Working Group Z. Cao Internet-Draft H. Deng Intended status: Standards Track China Mobile -Expires: May 12, 2011 Y. Wang +Expires: September 15, 2011 Y. Wang Q. Wu Huawei Technologies Co., Ltd. G. Zorn Network Zen - November 8, 2010 + March 14, 2011 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) - draft-ietf-hokey-erp-aak-03 + draft-ietf-hokey-erp-aak-04 Abstract The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple 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,25 +38,25 @@ 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 May 12, 2011. + This Internet-Draft will expire on September 15, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -67,28 +67,29 @@ 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 . . . . . . . . . . . . . . . . . . . . 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 + 5.4. TV/TLV and sub-TLV Attributes . . . . . . . . . . . . . . 10 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 11 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 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 @@ -123,103 +124,99 @@ EA Abbreviation for "ERP/AAK"; used in figures MH Mobile Host 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 + keying materials on a single 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. It is assumed that the peer has previously completed full EAP authentication. Figure 1 shows the general protocol exchange by - which the keying material is established on the CAP(s). + which the keying material is established on the CAP. This document + only discusses the case of distributing the key to a single CAP. - +------+ +-----+ +-----+ +-----+ +-----------+ - | Peer | | SAP | |CAP1 | |CAPx | | EA Server | - +--+---+ +--+--+ +--+--+ +--+--+ +-----+-----+ - | | | | | + +------+ +-----+ +-----+ +-----------+ + | Peer | | SAP | | CAP | | EA Server | + +--+---+ +--+--+ +--+--+ +-----+-----+ + | | | | 1. | [EAP-Initiate/ | | | | Re-auth-start | | | - | (E-flag) | | | | - |<----------| | | | - | | | | | + | (E-flag) | | | + |<---------------| | | + | | | | 2. | EAP-Initiate/ | | | - | Re-auth | | | | - | (E-flag) | | | | - |---------->| | | | + | Re-auth | | | + | (E-flag) | | | + |--------------->| | | 3. | | AAA (EAP-Initiate/Re-auth(E-flag))| - | |---------------------------------->| - | | | | | - | | | | +---------+---------+ - | | | | | CA authorized & | - 4. | | | | | authenticated; | - | | | | | EA keying | - | | | | | materials derived | - | | | | +---------+---------+ - | | | | | - 5. | | | | AAA(pMSKx) | - | | |AAA(pMSK1)|<----------->| - | | |<---------------------->| - | | | | | + | |--------------------------------->| + | | | +---------+---------+ + | | | | CA authorized & | + 4. | | | | authenticated; | + | | | | EA keying | + | | | | materials derived | + | | | +---------+---------+ + 5. | | | | + | | | AAA(pMSK) | + | | |<----------------->| + | | | | 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. The peer sends an early-authentication request message (EAP-Initiate/ Re-auth with the 'E' flag set) containing the keyName-NAI, the NAS- Identifier, rIK and sequence number. The realm in the keyName-NAI field is used to locate the peer's ERP/AAK server. The NAS- - Identifier is used to identify the CAP(s). The rIK is used to - protect the message. The sequence number is used for replay - protection. To avoid the same pre-established Master Session Key - (pMSK) being derived for multiple CAPs, the sequence number MUST be - unique for each CAP. + Identifier is used to identify the CAP. The rIK is used to protect + the message. The sequence number is used for replay protection. To + avoid the same pre-established Master Session Key (pMSK) being + derived for multiple CAPs, the sequence number MUST be unique for + each CAP. The SAP encapsulates the early-authentication message into a AAA message and sends it to the peer's ERP/AAK server in the realm indicated in the keyName-NAI field. Upon receiving the message, the ERP/AAK server first checks its - integrity and freshness, then authenticates and authorizes the CAP(s) - presented in the NAS-Identifier TLV(s). After the CAP(s) is + integrity and freshness, then authenticates and authorizes the CAP + presented in the NAS-Identifier TLV(s). After the CAP is authenticated and authorized successfully, the ERP/AAK server derives - the pRK and the subsequent pMSK for each CAP. + the pRK and the subsequent pMSK for the CAP. The ERP/AAK server transports the pMSK to the authenticated and - authorized CAP(s) via AAA as described in Section 7. After the - keying materials are delivered, the ERP/AAK server should determine - each CA whether accepts the pMSK and whether the peer could be - attached to. + authorized CAP(s) via AAA as described in Section 7. - At last, the ERP/AAK server sends the early-authentication finish + Finally, the ERP/AAK server sends the early-authentication finish message (EAP-Finish/Re-auth with E-flag set) containing the - determinate CAP(s) to the peer via the SAP. + determinated CAP to the peer via the SAP. 4. ERP/AAK Key Hierarchy As an optimization of ERP, ERP/AAK uses key hierarchy similar to that of ERP. The EMSK is used to derive the ERP/AAK pre-established Root Key (pRK). Similarly, the ERP/AAK pre-established Integrity Key (pIK) and the pre-established Master Session Key (pMSK) are derived from the pRK. The pMSK is established for the CAP(s) when the peer early authenticates to the network. The pIK is established for the peer to re-authenticate the network after handover. The hierarchy @@ -325,23 +323,24 @@ 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 identify the peer. The realm part of the NAI is the peer's home domain name or the domain to which the peer is currently attached. Exactly one keyName-NAI attribute SHALL be present in an EAP- Initiate/Re-auth packet. NAS-Identifier: As defined in RFC 5296 [RFC5296], it is carried in a - TLV payload. It is used to indicate the identifier of a CAP. One or - more NAS-Identifier may be included in the EAP-Initiate/Re-auth - packet. + TLV payload. It is used to indicate the identifier of a CAP. Though + this document only introduces the case of a single CAP, two or more + NAS-Identifier may be included in the EAP-Initiate/Re-auth packet to + identify multiple CAPs. Sequence number: It is carried in a TV payload. The Type is TBD (which is lower than 128). It is used in the derivation of the pMSK for each CAP to avoid multiple CAP using the same pMSK. Each NAS- Identifier in the packet MUST be associated with a unique sequence number. Cryptosuite This field indicates the integrity algorithm used for ERP/AAK. Key @@ -494,73 +493,131 @@ 7. AAA Transport Considerations AAA transport of ERP/AAK messages is the same as AAA transport of the 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. + This section provides an analysis of the protocol in accordance with + the AAA key management requirements specified in [RFC4962] + + o Cryptographic algorithm independence: ERP-AAK satisfies this + requirement. The algorithm chosen by the peer is indicated in the + EAP-Initiate/Re-auth message. If the chosen algorithm is + unacceptable, the EAP server returns an EAP- Finish/Re-auth + message with Failure indication + + 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 + always derived on-demand when the peer requires a key with a new + CAP. The derivation ensures that the compromise of one pMSK does + 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 + well defined. The pRK is used to derive the pIK and pMSK for the + CAP. Different sequence numbers for each CAP MUST be used to + derive the unique pMSK. + + o Replay detection mechanism: For replay protection of ERP-AAK + messages, a sequence number associated with the pMSK is used. + + o Authenticate all parties: The EAP Re-auth Protocol provides mutual + authentication of the peer and the server. The peer and SAP are + authenticated via ERP. The CAP is authenticated and trusted by + the SAP. + + o Peer and authenticator authorization: The sequence number is + maintained by the peer and the server, and incremented by them + synchronously. + + o Keying material confidentiality: The peer and the server derive + the keys independently using parameters known to each entity. + + o Uniquely named keys: All keys produced within the ERP context can + be referred to uniquely as specified in this document. + + o Prevent the domino effect: Different sequence numbers for each CAP + MUST be used to derive the unique pMSK. So the compromise of one + pMSK does not hurt any other CAP. + + o Bind key to its context: the pMSK are binded to the context where + the sequence numbers are transmitted. + + o Confidentiality of identity: this is the same with ERP protocol as + analyzed in [RFC5296]. + + o Authorization restriction: All the keys derived are limited in + lifetime by that of the parent key or by server policy. Any + domain-specific keys are further restricted for use only in the + domain for which the keys are derived. Any other restrictions of + session keys may be imposed by the specific lower layer and are + out of scope for this specification. 9. IANA Considerations New TLV types: - NAS-Identifier - Sequence number ERP/AAK-Key New sub-TLV types: - NAS-Identifier - pRK Lifetime pMSK Lifetime - List of Cryptosuites +10. Acknowledgement -10. References + In writing this document, we have received reviews from many experts + in IETF, including Tom Taylor, Tena Zou, Tim Polk. We apologize if + we miss some names that have helped us. -10.1. Normative References +11. References + +11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008. -10.2. Informative References +11.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-08 (work in progress), October 2010. [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. + [RFC4962] Housley, R. and B. Aboba, "Guidance + for Authentication, Authorization, and + Accounting (AAA) Key Management", + BCP 132, RFC 4962, July 2007. + [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