HOKEYP BOF Z. Cao Internet-Draft Peking University Intended status: Standards Track H. Deng Expires: April 4, 2007 Y. Ma Hitachi (China) Oct 2006 Security Association Derivation between Access Nodes draft-cao-hokeyp-sa-derivation-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 April 4, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Cao, et al. Expires April 4, 2007 [Page 1] Internet-Draft SA Derivation Oct 2006 Abstract This document specifies a mechanism to establish Security Associations (SAs) between Access Nodes in the handover keying architecture. The proposed mechanism negotiates the SA with the help of existing SAs between Access Nodes and Access Domain Controller, and between Access Domain Controller and AAA server as well. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Scenario One: within one Access Domain . . . . . . . . . . 5 3.2. Scenario Two: across different Access Domains . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 11 6.2. Informative Reference . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Cao, et al. Expires April 4, 2007 [Page 2] Internet-Draft SA Derivation Oct 2006 1. Introduction The handover keying problem statement document [I.D.aaa-hokey-ps] gives a problem statement for handover keying and intends to provides the first insight into developing a comprehensive handover keying solutions deals with various types of handovers within IETF. In addition, it specifies a wireless handover keying architecture in which various security association (SA) between entities are described. But it leaves behind the problem of investigating the possible trust relationship between the Access Nodes (ANs). This SA will be important when ANs are transmiting certain security information with each other such as what is specified in [I-D.handover-keys-aaa]. In this document, we specify a mechanism to derive security associations between the Access Nodes. The SAs between ANs that belong to the same Access Domain are negotiated with the help of Access Domain Controller (ADC), while the SAs between ANs that belong to different Access Domain are negotiated with the help of both the ADC and AAA server. Cao, et al. Expires April 4, 2007 [Page 3] Internet-Draft SA Derivation Oct 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. Multiple Access Nodes MAY be grouped under one Access Domain Controller. Cao, et al. Expires April 4, 2007 [Page 4] Internet-Draft SA Derivation Oct 2006 3. Proposed Solution To establish a security association between ANs, one AN initiates a Diffie-Hellman key exchange procedure with the other one. Because the ANs do not have pre-shared secrets or other credentials to authenticate the DH public values in order to defend against the MITM attack, we need the help of other entities in the architecture to protect the DH public values. The security associations between the AN and ADC and between the ADC and AAA server can be suitable to take this responsibility. The proposed solution will be specified respectively in two different scenarios: o Scenario One: ANs reside in the same Access Domain. o Scenario Two: ANs reside in different Access Domains. The protocol operations in these two scenarios will be described in the following two subsections in details. 3.1. Scenario One: within one Access Domain In this scenario, AN1 and AN2 are under the control of the same Access Domain Controller (ADC), e.g. ADC1. AN1 initiates the Diffie-Hellman procedure by sending a SA request (SAReq) message to the ADC1. SAReq message contain the identifier of AN1 and AN2, the ciphersuites supported by AN1, the DH public value of AN1 (g^i), and a nonce value (Ni). Further more, SAReq message is authenticated and encrypted by the existing SA between AN1 and ADC1. On receiving the SAReq message from AN1, ADC1 decrypts and authenticates the message. Successful authentication leads ADC1 to send an SA request delegation message (SAReq-Dele) to AN2, which is authenticated and encrypted of the raw content of SAReq by the existing SA between ADC1 adn AN2. AN2 decrypts and authenticates the SAReq-Dele message, from which it knows that AN1 wants to establish a SA with itself. Then AN2 construct a SA response message (SAResp) containing the identifier of AN2 and AN1, a chosen ciphersuite support by AN2, the DH public value of AN2 (g^r), and a nonce value (Nr). This message is authenticated and encrypted by the existing SA between AN2 and ADC1. After decrypting and authenticating the SAResp message from AN2, ADC1 construct and send a SA response delegation message (SAResp-Dele) to AN1, which is authenticated and encrypted with the existing SA between ADC1 and AN1. Cao, et al. Expires April 4, 2007 [Page 5] Internet-Draft SA Derivation Oct 2006 Completing the DH public value exchange, AN1 and AN2 will be able to derive the shared key Ks and use it to secure subsequent communications between them. When AN1 validates the SAResp-Dele message, it confirms AN2 by sending a SA-Conf message to AN2, including the nonce value generated by AN2 (Nr) to avoid potential Denial of Service attacks, and this message is authenticated with the newly derived shared key Ks. The shared key Ks is computed as follows: Ks = prf(g^ir, Ni|Nr) AN1 ADC1 AN2 | SAReq | | |---------------->| SAReq-Dele | | |---------------->| | | | | | SAResp | | |<----------------| | SAResp-Dele | | |<----------------| | | | | | SA-Conf | |---------------------------------->| |<=========SA Establishment========>| Figure 1: Protocol Operations when ANs reside in the same AD 3.2. Scenario Two: across different Access Domains When the ANs who want to establish a security association reside in different ADCs, it further needs the help of AAA server to complete the Diffie-Hellman procedure in a secure manner. AN1 initiates the Diffie-Hellman procedure by sending a SAReq message to ADC1, including the identifier of AN1, AN2, the ciphersuits supported by the AN1, and the DH public value of AN1 (g^i), and a nonce value (Ni). This message is authenticated and encrypted with the existing SA between AN1 and ADC1. Then ADC1, AAA server and ADC2 take turns to delegate the SAReq message to AN2 in the end. SAReq-Dele1, SAReq-Dele2 and SAReq-Dele3 are authenticated and encrypted with the existing SAs between ADC1 and AAA, AAA and ADC2, ADC2 and AN2. Cao, et al. Expires April 4, 2007 [Page 6] Internet-Draft SA Derivation Oct 2006 On receiving and successfully authenticating the SAReq message delegated by ADC2, AN2 constructs and sends out a SA Response (SAResp) message including the identifier of AN2, AN1, and a chosen ciphersuite supported by AN2, its DH public value (g^r) and a nonce value (Nr). The SAResp message is delegated by ADC2, AAA, and ADC1 in the reversed direction of SAReq message. When AN1 receives the SAResp message delegated by ADC1, it decrypts and authenticates that message using the existing SA between AN1 and ADC1. Completing the DH public value exchage, AN1 and AN2 are able to derive the shared key Ks and use it to secure subsequent communications between them. When AN1 validates the SAResp-Dele2 message, it confirms AN2 by sending a SA-Conf message to AN2, including the nonce value generated by AN2 (Nr) to avoid potential Denial of Service attacks, and this message is authenticated with the newly derived shared key Ks. The shared key Ks is computed as follows: Ks = prf(g^ir, Ni|Nr) AN1 ADC1 AAA ADC2 AN2 | SAReq | | | | |----------->| SAReq-Dele1 | | | | |------------>| SAReq-Dele2| | | | |----------->| SAReq-Dele3| | | | |----------->| | | | | | | | | | SAResp | | | |SAResp-Dele1|<-----------| | |SAResp-Dele2 |<-----------| | |SAResp-Dele3|<------------| | | |<-----------| | | | | | | | | | SA-Conf | |--------------------------------------------------->| |<================ SA Establishement ===============>| Figure 2: Protocol Operations when ANs reside in the same AD Given that there is a security association between ADCs, the procedure of AN SA establishment can be redured to six messages without the help of AAA server. We neglect the details here for they Cao, et al. Expires April 4, 2007 [Page 7] Internet-Draft SA Derivation Oct 2006 are very similar to what has been elaborated above. Note that although the handover keying problem statement document [I.D.aaa-hokey-ps] does not point out the SA between ADCs, we assert that these SAs MAY exist in the realistic development. If necessary, we can establish the SA between ADCs with the help of the SA between ADC and AAA server, take advantage of the similar mechanism proposed in this document. AN1 ADC1 ADC2 AN2 | SAReq | | | |----------->| SAReq-Dele1 | | | |------------>| SAReq-Dele2| | | |----------->| | | | | | | | | | | | SAResp | | |SAResp-Dele1 |<-----------| |SAResp-Dele2|<------------| | |<-----------| | | | | | | | SA-Conf | |-------------------------------------->| |<======== SA Establishement ==========>| Figure 3: Protocol Operations simplified with SA between ADCs Cao, et al. Expires April 4, 2007 [Page 8] Internet-Draft SA Derivation Oct 2006 4. Security Considerations The suggested proposal does not create nor enhance any new and/or existing threats. In particular, launching a man-in-the middle attack against the protocol is not possible as long as the attacker is not able to compromise the SA between AN and ADC, or the SA between ADC and AAA Server. The confidentiality and authenticity of the tranported message is protected by encrypting the message and computing a authenticator based on the existing SAs. Since attackers can not spoof the SA request and SA response message with correct authenticators, denial of service attacks towards the ANs by cheating them into Diffie- Hellman computation are not possible. The suggested proposal DOES NOT guard against compromise of the Access Domain Controll or AAA Server. If the corresponding ADC or AAA in SA delegation is compromised, the man-in-the-middle attack can be launched for the Diffie-Hellman exchange. Cao, et al. Expires April 4, 2007 [Page 9] Internet-Draft SA Derivation Oct 2006 5. 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 April 4, 2007 [Page 10] Internet-Draft SA Derivation Oct 2006 6. References 6.1. Normative Reference [I.D.aaa-hokey-ps] Nakhjiri, M., Parthasarathy, M., and al. et, "AAA based Keying for Wireless Handovers: Problem Statement", May 2005, . 6.2. Informative Reference [I-D.handover-keys-aaa] Narayanan, V., Venkitaraman, N., and et. al, "Handover Keys Using AAA", . [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Cao, et al. Expires April 4, 2007 [Page 11] Internet-Draft SA Derivation Oct 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 Hui Deng Hitachi (China) Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: hdeng@hitachi.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 Cao, et al. Expires April 4, 2007 [Page 12] Internet-Draft SA Derivation Oct 2006 Full 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Cao, et al. Expires April 4, 2007 [Page 13]