INTERNET DRAFT Category: Standards Mohamed Khalil Title: draft-mkhalil-mobileip-ipv6-sap-00.txt Haseeb Akhtar Date: March 2001 Emad Qaddoura Expires: August 2001 Nortel Networks Dynamic Security Association Establishment Protcol For IPv6 Status of this Memo This document is an individual contribution for consideration by the AAA Working Group of the Internet Engineering Task Force. Comments should be submitted to the diameter@ipass.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract A protocol is proposed to allow a fast establishment of Security Association between the Mobile Node (MN) and Correspondent Node (CN). Once this Security Association is established, it can be used to Khalil et al. expires August 2001 [Page 1] INTERNET DRAFT March 2001 authenticate any Binding Update between the MN and the CN. Khalil et al. expires August 2001 [Page 2] INTERNET DRAFT March 2001 Table of Contents 1.0 Introduction 1.1 Copyright Statement 1.2 Requirements language 1.3 Terminology 2.0 Dynamic Security Establishment Protocol 2.1 Diffie-Hellman Approach 2.2 Simple Generation of SSK Approach 3.0 Message Extensions 3.1 The Transform Sub-option 3.2 The Key Payload Sub-option 3.3 The Authentication Sub-option 3.4 The Notification Payload Sub-option 3.4 11.0 References 12.0 Acknowledgements 13.0 Author Information 14.0 Full Copyright Statement Khalil et al. expires August 2001 [Page 3] INTERNET DRAFT March 2001 1.0 Introduction This draft outlines a protocol that allows a fast establishment of Security Association between the MN and the CN. A man-in-the-middle attack such as insertion, deletion, replay, or modification of messages might occur during the Security Establishment. This protocol allows a the mobile node to detect such types of attacks, if it occurs between the MN and the CN, or between the CN and the MN's Home Agent (HA). 1.1 Copyright Statement Copyright (C) The Internet Society 1999. All Rights Reserved. 1.2 Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [13]. 1.3 Terminology This document frequently uses the following terms: SA (Security Association) An SA (Security Association) is a relationship between two or more nodes that allows those nodes to communicate between each other over any public or private IP based network wihtout compromising integrity of any of the packets transferred. MIMA (Man-In-the-Middle-Attack) A malicious node in the network posing as a MN or a CN. 2.0 Dynamic Security Establishment Protocol In this section two approaches are described to establish an SA between the MN and the CN. The first approach provides PFS (Private Forward Security) using Diffie-Hellman while the second approach provides more efficiency at the cost of the PFS feature. 2.1 Diffie-Hellman Approach In this approach the MN creates a pair of private/public keys. The MN then sends a control message (e.g. Binding Warning [1]) to the CNs. Khalil et al. expires August 2001 [Page 4] INTERNET DRAFT March 2001 This control message carries a Key Payload sub-option containing the MN's public key, and the Transform sub-option containing the proposed SPI and hash function type. CN private key +-----+ -------------------> | | MN public key | D-H | -------------------> | | +-----+ | Shared Secret Key | V CN public key +-----+ -------------------> | | MN public Key | | -------------------> | Hash| Hash Type & SPI | | -------------------> | | +-----+ | Authenticator | V Figure 1: Correspondent Node Operation for Diffie-Hellman Approach When the CN receives the control message from the MN (e.g. Binding Warning), it too generates a pair of public/private keys. The CN then calculates a Shared Secret Key (SSK) to be used with the MN using the MN's public key and the CN's private key as defined by Diffie-Hellman algorithm. The CN next calculates an authenticator over the MN's public key, the CN's public key, hash type, SPI and the SSK using the hash function proposed by the mobile node (Figure 1). The calculated authenticator is inserted in an Authenticator sub-option. The CN then forms a control message (e.g. Binding Request [1]) destined to the MN's home IP address. The control message (e.g. Binding Request) carries the Key Payload sub-option containing the CN's public key, the Transform sub-option, and the Authentication sub-option containing the authenticator previously calculated. Figure 1 shows the CN operation when it receives the control message (e.g. Binding Warning) from the MN. Khalil et al. expires August 2001 [Page 5] INTERNET DRAFT March 2001 MN public key | V +---------+ -----------------> | | Not match (MIMA) MN public key |compare |----> obtained from | | control message +---------+ | match V CN private key +-----+ -------------------> | | MN public key | D-H | -------------------> | | +-----+ | Shared Secret Key | V CN public key +-----+ -------------------> | | MN public Key | | -------------------> | Hash| Hash Type & SPI | | -------------------> | | +-----+ | Authenticator | V +--------+ -----------------> | | not match (MIMA) Authenticator from |compare |-------> Control Message | | +--------+ | | match | Figure 2: Mobile Node Operation for Diffie-Hellman Approach The MN's HA intercepts the control message destined to the MN and tunnels it back to the MN. When the MN receives the tunneled control message (e.g. Binding Request) it compares the MN's public key received in the control message against its own public key. If they match, the MN then calculates a SSK to be used with the CN using the MN's private key and the CN's public key as defined by Diffie-Hellman algorithm (Figure 2). The MN re-calculates the authenticator over the Khalil et al. expires August 2001 [Page 6] INTERNET DRAFT March 2001 received MN's public key, the CN's public key, hash type, SPI, and the calculated SSK. The result is then compared with the received authenticator. If there is a match, the MN and the CN would have communicated the SSK securely and a SA has been established. Figure 2 shows the MN operation when it receives the tunneled control message from MN's HA. This established SA between the MN and the CN is used to authenticate any future Binding Updates between the two nodes. 2.2 Simple Generation of SSK Approach The MN creates a pair of private/public keys. The MN sends a control message (e.g. Binding Warning [1]) with the Transform and Key Payload sub-option. The transform sub-option specifies the hash function and the SPI proposed by the MN to the CN, and the Key sub-option contains the MN's public key. +------------+ CN IP Address -----> | | MN home IP address-> | calculate | Random Number------> | secret key | MN public Key-----> | | +------------+ | Shared Secret Key | V +--------+ MN Public Key | | -----------------> |Encrypt | | | +--------+ | Encrypted Key (using MN public key) | V MN public Key +------+ ------------------->| | Hash Type & SPI | Hash | ------------------> | | +------+ | Authenticator | V Figure 3: Correspondent Node Operation Khalil et al. expires August 2001 [Page 7] INTERNET DRAFT March 2001 When the CN receives the control message from a MN (e.g. Binding Warning [1]) the CN generates a SSK as shown in Figure 3. The CN calculates an authenticator using the MN's public key, hash type, SPI and the SSK. The CN then forms a control message (e.g. Binding Request [1]) destined to the MN's home IP address. The control message (e.g. Binding Request[1]) carries the Key Payload sub-option containing an the encrypted SSK (Figure 3),the Transform sub-option, and the Authentication sub-option containing the previously calculated authenticator (Figure 3). Khalil et al. expires August 2001 [Page 8] INTERNET DRAFT March 2001 MN public key | V +---------+ -----------------> | | Not match (MIMA) MN public key |compare |----> from control | | message +---------+ | match | Encrypted Key (from received control message) | V +----------+ MN Public Private Key| | -------------------> | Decrypt | | | +----------+ | Decrypted Key (using MN private key) | V MN public Key +------+ ------------------->| | Hash Type & SPI | Hash | ------------------->| | +------+ | Authenticator | V +--------+ -----------------> | | not match (MIMA) Authenticator from |compare |-------> Control Message | | +--------+ | | match | Figure 4: Mobile Node Operation The MN's HA intercepts the control message and tunnels it back to the MN. When the MN receives the tunneled control message (e.g. Binding Request [1] it compares the MN's public key received in the control message against its own public key. If they match, the MN decrypts the SSK to be used with the CN using the MN's private key. The MN Khalil et al. expires August 2001 [Page 9] INTERNET DRAFT March 2001 re-calculates the authenticator over the received MN's public key, hash type, SPI, and the decrypted SSK. The resulted authenticator is then compared with the received authenticator as shown in Figure 4. If there is a match, the MN and the CN would have communicated the SSK securely and a SA has been established. The established Security Association between the MN and the MN is used to authenticate any future Binding Updates between the two nodes. 3.0 Message Extensions This section describes the message extensions to be used for the protocol. 3.1 The Transform Sub-option This sub-option is used to define the hash function type and the SPI involved in the Security Association. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Hash Type | rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option not including the type and length fields in units of 8 octets. Hash Type 0 MD5 (default) rsv reserved and MUST set to 0 SPI Security Parameter Index used index the Security Association defined between two nodes such as mobile node and correpondent node. 3.2 The Key Payload Sub-option Khalil et al. expires August 2001 [Page 10] INTERNET DRAFT March 2001 Key Payload Sub-option contains data Data required to generate a secret key or it might contain a public key. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | sub-type | key data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option not including the type and length fields in units of 8 octets. Sub-type 0 MN-CN secret key 1 MN public key 2 CN public key Key info the secret or public key 3.3 The Authentication Sub-option The Authentication Sub-option data is generated by the hash function (selected during the SA establishment exchange), over some part of the message. This payload may be used to verify the integrity of the data in an ISAKMP message or/and for authentication of the negotiating entities. Khalil et al. expires August 2001 [Page 11] INTERNET DRAFT March 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub Type | rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | authenticator +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Sub Type this field is 0 Length The length of the option in units of 8 octets not including the type and length field. SPI Security Parameter Index. authenticator (variable length) - Data that results from applying the hash routine to certain field of the message. 3.4 The Notification Payload Sub-option The Notification Payload can contain status or error informatio resulted from the Security Association negotiation. Khalil et al. expires August 2001 [Page 12] INTERNET DRAFT March 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | status | Notification data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option not including the type and length fields in units of 8 octets. status contains error or status code information Notification Data (variable length) - Informational or error data. 4.0 References [1] Charlie Perkins, Binding Key Establishment for Mobile IPv6 11.0 Acknowledgements 13.0 Author Information: Mohamed Khalil Nortel Networks Inc. 2201 Lakeside Blvd Richardson, TX 75082-4399 Phone: +1 972 685-0564 E-mail: mkhalil@nortelnetworks.com Haseeb Akhtar Nortel Networks Inc. 2201 Lakeside Blvd Richardson, TX 75082-4399 Phone: +1 972 684-8850 E-mail: haseeb@nortelnetworks.com Emad Qaddoura Nortel Networks Inc 2201 Lakeside Blvd Richardson, TX 75082-4399 Phone: +1 972 684-2705 E-mail: emadq@nortelnetworks.com 14.0 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, Khalil et al. expires August 2001 [Page 13] INTERNET DRAFT March 2001 published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Inter- net organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permis- sions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Khalil et al. expires August 2001 [Page 14]