Network Working Group Z. Cao Internet-Draft Peking University Expires: December 21, 2006 Y. Ma H. Deng Hitachi (China) Q. Li BeiHang University June 19, 2006 Handover Key Hierarchy based on Extended Master Session Key (EMSK) Derivation draft-cao-hoakey-hierarchical-hokey-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Extensible Authentication Protocol (EAP) provides a framework supporting various authentication protocols known as EAP methods. To avoid a full EAP authentication exchange when there is a handover Cao, et al. Expires December 21, 2006 [Page 1] Internet-Draft Handover Key Hierarchy from EMSK June 2006 across EAP authenticators, a handover key hierarchy should be specified. This document specifies how to derive a handover key hierarchy from the Extended Master Session Key (EMSK). In our mechanism, both intra and inter-authenticator handovers can be supported. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Network Handover Topology . . . . . . . . . . . . . . . . . . 6 4. Handover Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7 4.1. rRK Derivation and Naming . . . . . . . . . . . . . . . . 8 4.2. R0-Key Derivation and Naming . . . . . . . . . . . . . . . 9 4.3. R1-Key Derivation and Naming . . . . . . . . . . . . . . . 9 4.4. TSK Derivation and Naming . . . . . . . . . . . . . . . . 10 5. Key Derivation Function . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 9. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Intra-ADC Handover . . . . . . . . . . . . . . . . . 16 Appendix B. Inter-ADC Handover . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Cao, et al. Expires December 21, 2006 [Page 2] Internet-Draft Handover Key Hierarchy from EMSK June 2006 1. Introduction With the proliferation of wireless technology and mobile service, the need for seamless handover in such scenario is becoming incresingly important. When there is a handover across EAP authenticators, a full EAP re-authentication exchange will inevitably cause unacceptable network latency. Therefore it is urgent to design a effective mechanism which makes use of previous EAP authentication results for fast handover across authenticators. The Extensible Authentication Protocol (EAP) provides a framework supporting various authentication protocols known as EAP methods [RFC3748]. Two keys, a Mater Session Key (MSK) and an Extended Master Session Key (EMSK) are produced by EAP methods. EAP keying framework [I-D.ietf-eap-keying] leaves behind the question of EMSK usage specifications, while [I-D.eap-emsk-deriv] specifies how to derive USRK from EMSK for different kinds of usages. In this document, we specify the derivation of a re-authentication root key (rRK) from EMSK for re-authentication purpose. From the rRK, a three level handover key hierarchy is derived to support both intra and inter-authenticator handover. The handover scenario concerned in this document is based on the problem statement given by [I.D.aaa-hokey-ps]. Cao, et al. Expires December 21, 2006 [Page 3] Internet-Draft Handover Key Hierarchy from EMSK June 2006 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. The following new terminology and abbreviations are introduced in this document and all the other general mobility related terms as defined in [I-D.ietf-eap-keying] and [I.D.aaa-hokey-ps] Access Node (AN) The access node is the entity (layer 2 or layer 3) residing at the edge of network and is responsible for providing access link to the peer. The access node typically is a R1-Key Holder holding R1-Key to derive the Transient Session Key (TEK). Multiple Access Nodes MAY be grouped under one Access Domain Controller. Access Node Identifier (AN-ID) The 16 octet identifier that is advertised by an Access Node to differentiate different ANs. Access Domain Controller (ADC) Entity responsible for keying needs within an Access Domain. ADC typically is a R0-Key Holder that holds a per-ADC specific R0-Key for the authentication domain and uses this R0-Key to derive R1- Key for different ANs under its control. Access Domain (AD) A logical entity whose authentication (with the backend EAP/AAA server) and key management goes through the same ADC. Access Domain Identifier (AD-ID) The 16 octet identifier that is advertised by an Access Domain to differentiate different ADs. Key Holder The functional entity that holds a root key/s and can perform further key derivation using that root key. There may be multiple Key Holders in the network (e.g. at the AAA server or ADC). rRK Cao, et al. Expires December 21, 2006 [Page 4] Internet-Draft Handover Key Hierarchy from EMSK June 2006 The re-authentication root key derived from EMSK. The rRK is a kind of USRK for re-authentication purpose, and is used to derive R0-Key. R0-Key The first level key in the handover key hierarchy shared between the supplicant and R0 key holder used to derive R1-Key. R0Name A 16 octet identifier used to identify the R0-Key. R1-Key The second level key in the handover key hierarchy shared between the supplicant and R1 key holder used to derive R2-Key. R1Name A 16 octet identifier used to identify the R1-Key. Supplicant Address (SPA) The link layer address of the EAP supplicant, i.e. the mobile node. TSKName A 16 octet identifier used to identify the TSK Cao, et al. Expires December 21, 2006 [Page 5] Internet-Draft Handover Key Hierarchy from EMSK June 2006 3. Network Handover Topology (R1-Key) +-+-+-+-+-+ +-+-+-+ | MN/ |-----| AN1 |---+ (R0-Key) |EAP Peer | +-+-+-+ | +--------------+ +-+-+-+-+-+ +-----| ADC1(R0_KH1) |---+ | +--------------+ | (rRK) | | +-+-+-+-+-+ +-+-+-+ | | | AAA/EAP | | AN2 |---+ +-+---| Server | +-+-+-+ | +---------+ (R0-Key) | +-+-+-+ +--------------+ | | AN3 |---------| ADC2(R0_KH2) |-----+ +-+-+-+ +--------------+ Figure 1: Network Handover Topology From the network handover topology shown in Figure 1, we can have a base knowledge of intra and inter-ADC handovers. A detailed description is also available in [I.D.aaa-hokey-ps]. o Intra-ADC Handover: the handover from one Access Node to another one within the same ADC, e.g. mobile node roams from AN1 to AN2 in Figure 1. o Inter-ADC Handover: the handover from one Access Node to another one under a different ADC, e.g. mobile node roams from AN2 to AN3 in Figure 1. Both intra and inter-ADC handover are supported by the handover key hierarchy proposed in this document. Example senarios are described in Appendix A and Appendix B. Cao, et al. Expires December 21, 2006 [Page 6] Internet-Draft Handover Key Hierarchy from EMSK June 2006 4. Handover Key Hierarchy A three level key hierarchy is introduced to ensure cryptographical seperation of different level keys, and also expedites the distribution of keys between network entities prior to or during a handover. +-------+ | EMSK | +-------+ | V +-------+ | rRK | +-------+ | V +-----------------------+ | | V V +-------+ +-------+ |R0-Key1| ... |R0-Keyn| +-------+ +-------+ | | V V +-----------+ +-----------+ | | | | V V V V +-------+ +-------+ +-------+ +-------+ |R1-Key1|...|R1-Keyn| |R1-Key1|...|R1-Keym| +-------+ +-------+ +-------+ +-------+ | | | | V V V V +-------+ +-------+ +-------+ +-------+ | TSK1 |...| TSKn | | TSK1 |...| TSKm | +-------+ +-------+ +-------+ +-------+ Figure 2: Fast Handover Key Hierarchy Key derivation in this hierarchy MUST ensure that compromise of such keying material is isolated to only that branch of the hierarchy. As shown in Figure 2, the key hierarchy consists of three levels (between the EMSK and TSK) whose keys are derived using the KDF (Key Derivation Function) described in Section 5. Cao, et al. Expires December 21, 2006 [Page 7] Internet-Draft Handover Key Hierarchy from EMSK June 2006 o rRK: the re-authentication root key which is a kind of USRK for roaming. The rRK is mutually derived by the supplicant and the EAP server, and is never shared with a third party. o R0-Key: the fist level of the handover key hierarchy; this key is derived as a function of the rRK and AD-ID and stored by the Access Domain Controller (ADC). This key is mutually derived by the supplicant and the ADC. This key is named by the SPA and AD-ID. o R1-Key: the second level of the key hierarchy; this key is mutually derived by the supplicant and the AN. This key is named by the SPA, AN-ID and AD-ID. o TSK: the last level of the key hierarchy that defines the EAP lower layer protection keys. The TSK is the negotiation result of the Secure Association Protocol. This key is named by SNonce, ANonce, SPA, AN-ID and AD-ID. 4.1. rRK Derivation and Naming The rRK is mutually derived by the supplicant and EAP server using the methods specified in [I-D.eap-emsk-deriv]. That is: rRK = KDF-USRK(EMSK, key label, optional data, length) where: - KDF-USRK is the Key Derivation Function as defined in [I-D.eap- emsk-deriv] - key label MAY be a string like "handover@domain". The key label is intended to provide global uniqueness. Rules for the allocation of these labels are given in [I-D.eap-emsk-deriv]. - the optional data, with which the KDF-USRK MUST be capable of processing at least 2048 opaque octets. Here we define the optional data to "Roaming USRK Derivation" - The length is a 2 byte unsigned integer in network byte order. As RECOMMENDED in [I-D.eap-emsk-deriv], the rRK is 64 octets long. rRK is named and referenced as follows: rRK-Name = prf-64( EAP Session-ID, key-label ). where prf-64 is the first 64 bits from the output. Cao, et al. Expires December 21, 2006 [Page 8] Internet-Draft Handover Key Hierarchy from EMSK June 2006 The use of names based on the Session-ID in [I-D.ietf-eap-keying] is RECOMMENDED. 4.2. R0-Key Derivation and Naming The R0-Key is the top level 256 bit keying material used to derive the next level keys (R1-Keys). R0-Key binds the SPA and Access Domain Identifier. R0-Key = KDF-256(rRK, "R0 Key Derivation", AD-ID || SPA) where: - KDF-256 is the KDF function as defined in Section 5 used to generate a 256 bit key. - "R0 Key derivation" is the literal string consisting of the sequence of letters 'R', '0', ' ', 'K', 'e','y',' ', 'd', 'e', 'r', 'i', 'v', 'a', 't', 'i', 'o', and 'n' (no null terminator). - AD-ID: The 16 octet identifier that is advertised by an Access Node to differentiate itself from other ANs. - SPA: The link layer address of the Supplicant. We can truncate rRK to 256 bit to meet the requirement of the KDF defined in Section 5. R0-Key is named and referenced as follows: R0Name = Truncate-128(SHA-256(R0-Key || "R0 Key Name" || AD-ID || SPA)) where Truncate-128(-) returns the first 128 bits of its argument, and securely destroys the remainder. The entity that holds this key typically an Access Domain Controller (ADC) that is identified by a 16 octet string referred to as the AD-ID. The advertisement of AD-ID is outside the scope of this document. 4.3. R1-Key Derivation and Naming The second level handover key hierarchy. R1-Key is a 256 bit key used to derive the Transient Session Keys (TSK). R1-Key binds the SPA, top level and second level key holders. Cao, et al. Expires December 21, 2006 [Page 9] Internet-Draft Handover Key Hierarchy from EMSK June 2006 R1-Key = KDF-256(R0-Key, "R1 Key Derivation", AD-ID || AN-ID || SPA) where: - KDF-256 is the KDF function as defined in Section 5 used to generate a 256 bit key. - "R1 Key derivation" is the literal string consisting of the sequence of letters 'R', '1', ' ', 'K', 'e','y',' ', 'd', 'e', 'r', 'i', 'v', 'a', 't', 'i', 'o', and 'n' (no null terminator). - AD-ID: The 16 octet identifier that is advertised by an Access Node to differentiate itself from other ANs. - AN-ID: The 16 octet identifier that is advertised by an Access Domain to differentiate itself from other ADs. - SPA: The link layer address of the Supplicant. R1-Key is named and referenced as follows: R1Name = Truncate-128(SHA-256(R0Name || AD-ID || AN-ID || SPA)) where Truncate-128(-) returns the first 128 bits of its argument, and securely destroys the remainder. The entity that holds this key typically an Access Node that is identified by a 16 octet string referred to as the AN-ID. The advertisement of AN-ID is outside the scope of this document. 4.4. TSK Derivation and Naming The last level handover key hierarchy. TSK is derived from R1-Key and used to protect data exchanged after EAP authentication has successfully completed, using the ciphersuite negotiated between the supplicant and authenticator as a result of Secure Association Protocol (SAP) such as 802.11i [802.11i]. TSK = KDF-TSKLen(R1-Key, "TSK Key derivation", SNonce || ANonce || AD-ID || AN-ID || SPA) where: - KDF-TSKLen is the KDF function as defined in Section 5 used to generate a TSK of length TSKLen. Cao, et al. Expires December 21, 2006 [Page 10] Internet-Draft Handover Key Hierarchy from EMSK June 2006 - TSKlen is the total number of bits to derive, e.g. number of bits of the TSK. The length is dependent on the negotiated ciphersuites by SAP. - "TSK Key derivation" is the literal string consisting of the sequence of letters 'T', 'S', 'K', ' ', 'K', 'e','y',' ', 'd', 'e', 'r', 'i', 'v', 'a', 't', 'i', 'o', and 'n' (no null terminator). - SNonce is a 256 bit random bit string contributed by the supplicant in the SAP. - ANonce is a 256 bit random bit string contributed by the authenticator in the SAP. The TSK is named and referenced as follows: TSKName = Truncate-128(SHA-256(R1Name || AD-ID || AN-ID ||SNonce || ANonce || SPA)) where Truncate-128(-) returns the first 128 bits of its argument, and securely destroys the remainder. Cao, et al. Expires December 21, 2006 [Page 11] Internet-Draft Handover Key Hierarchy from EMSK June 2006 5. Key Derivation Function The definition of the KDF (Key Derivation Function) is taken from 802.11r [802.11r]. Algorithm kdf: Output = KDF-Length (K, label, Context) Input: - K, a 256 bit key derivation key - label, a string identifying the purpose of the keys derived using this KDF - Context, a bit string that provides context to identify the derived key - Length, the length of the derived key in bits Output: a length-bit derived key. result = "" iterations = (Length+159)/160 do i = 1 to iterations result = result || HMAC-SHA1(K, i || label || 0x00 || Context || Length) od return first Length bits of result, and securely delete all unused bits Cao, et al. Expires December 21, 2006 [Page 12] Internet-Draft Handover Key Hierarchy from EMSK June 2006 6. Security Considerations This document specifies a handover key hierarchy derived from EMSK. Both the key lifetime, key scope in the hierarchy MUST comply with EAP keying framework [I-D.ietf-eap-keying]. When the handover solutions are based on the hierarchy proposed in this document, they MUST also meet the security requirements present in [I.D.aaa-hokey-ps]. Cao, et al. Expires December 21, 2006 [Page 13] Internet-Draft Handover Key Hierarchy from EMSK June 2006 7. IANA Considerations This specification does not request the creation of any new parameter registries, nor does it require any other IANA assignments. Cao, et al. Expires December 21, 2006 [Page 14] Internet-Draft Handover Key Hierarchy from EMSK June 2006 8. Acknowledgement TBD. 9. Reference [802.11i] Institute of Electrical and Electronics Engineer, "IEEE Standard for Information technology!a Telecommunications and information exchange between systems!aLocal and metropolitan area networks!aSpecific requirements. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications. Amendment 6: Medium Access Control (MAC) Security Enhancements", July 2004, . [802.11r] Institute of Electrical and Electronics Engineer, "Draft Amendment to STANDARD FOR Information Technology - Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements. Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Amendment 2: Fast BSS Transition", May 2006, . [I-D.eap-emsk-deriv] Salowey, J. and et. al, "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", . [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", . [I.D.aaa-hokey-ps] Nakhjiri, M., Parthasarathy, M., and al. et, "AAA based Keying for Wireless Handovers: Problem Statement", May 2005, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Cao, et al. Expires December 21, 2006 [Page 15] Internet-Draft Handover Key Hierarchy from EMSK June 2006 Appendix A. Intra-ADC Handover Following and for the sake of clarity, we first explain an intra Access Domain Controller (ADC) handover example. The example is based on Figure 1 explained in Section 3. Initially, when the MN connects to the access network for the first time (through AN1), it can use EAP to authenticate to the access network. This EAP authentication generates EMSK which in turn is to derive the handover root key (rRK) specified in Section 4.1. The AAA server generates the R0-Keys and then forwards them to the Access Domain Controllers in different Access Domains (AD). The ADC then generates R1-Keys and distributes them to different Access Nodes on the lower layer of the hierarchy. In the end, the MN and AN1 mutually derive the TSK for data protection between the MN and AN1. When the MN handovers to another Access Node (e.g. AN2) under the control of ADC1 , a new security association SHOULD be established before any application data communication occurs. If the R0-Key from the previous authentication does not expire, the MN SHALL associate with AN2 and mutually derive R1-Key from R0-Key. Mutual proof of possession of R1-Key and mutual derivation of TSK from R1-Key are both provided by the Secure Asscociation Protocol (SAP). In this way new SA is established without another EAP exchange. If the R0-Key from the previous authentication expires, the MN MUST authenticate to the access network through AN2 with a full EAP exchange. Cao, et al. Expires December 21, 2006 [Page 16] Internet-Draft Handover Key Hierarchy from EMSK June 2006 Appendix B. Inter-ADC Handover Following and for the sake of clarity, we then explain an inter Access Domain Controller (ADC) handover example. The example is based on Figure 1 explained in Section 3. Initially, the MN connects the AN1 under control of ADC1, the same things happen as described in Appendix A. This time, the MN handovers to AN3 that is under control of ADC2. If the R0-Key associated with ADC2 does not expire, the Secure Association Protocol will take the responsibility of the establishment of the new SA between the MN and AN3. If the R0-Key from the previous authentication expires, the MN MUST authenticate to the access network through AN3 with a full EAP exchange. Cao, et al. Expires December 21, 2006 [Page 17] Internet-Draft Handover Key Hierarchy from EMSK June 2006 Authors' Addresses Zhen Cao Peking University No.1 Science Building Room 1534 5 Yi He Yuan Lu Hai Dian District Beijing 100871 China Email: caozhen@pku.edu.cn Yuanchen Ma Hitachi (China) Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: ycma@hitachi.cn Hui Deng Hitachi (China) Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: hdeng@hitachi.cn Qin Li BeiHang University Department of Computer Science Beijing 100083 China Email: quinn.liqin@gmail.com Cao, et al. Expires December 21, 2006 [Page 18] Internet-Draft Handover Key Hierarchy from EMSK June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Cao, et al. Expires December 21, 2006 [Page 19]