INTERNET DRAFT Category: Standards Mohamed Khalil Title: draft-mkhalil-mobileip-ipv6-sap-01.txt Haseeb Akhtar Date: April 2001 Emad Qaddoura Expires: October 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 October 2001 [Page 1] INTERNET DRAFT April 2001 authenticate any control message exchanged between these two nodes (e.g. Binding Update and Binding Acknowledgement). Khalil et al. expires October 2001 [Page 2] INTERNET DRAFT April 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 Overall Protocol Description 2.2 Primary Mode 2.3 Secondary Mode 3.0 Re-Establishment Of MN-CN Security Association 4.0 Security Features 4.1 Denial of Service (DoS) Attack Protection 4.2 Replay Protection 4.3 Non-repudiation 4.4 Message Integrity 5.0 Message Extensions 5.1 The Transform Sub-option 5.2 The Key Payload Sub-option 5.3 The HAsh Sub-option 5.4 The Notification Payload Sub-option 5.5 The Digital Signature (DIGSIG) Sub-option 5.6 The Nonce (NONCE) Sub-option 5.7 The FQDN Sub-option 6.0 References 7.0 Acknowledgements 8.0 Author Information 9.0 Full Copyright Statement Khalil et al. expires October 2001 [Page 3] INTERNET DRAFT April 2001 1.0 Introduction This draft outlines a protocol that allows a dynamic establishment of Security Association (SA) between two nodes: the initiator (e.g. MN) and the responder (e.g. cCN). The proposed protocol doesn't depend on its operation on a global or centralized PKI (Public Key Infrastructure) or KDC (Key Distribution Center). The proposed protocol uses two control messages to establish the SA. Its security features are discussed in details in section 4.0. 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 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. y It indicates that "x" is encrypted with the key "y". [x]y It indicates that "x" is decrypted with the key "y". CM_x Control message sent by the node x. CM_b Body of the control message. prf(key,msg) It is the keyed pseudo-random function used to generate a deterministic output that appears pesudo-random. It is used for key derivation, and for authentication (i.e. as a keyed MAC) [3]. Khalil et al. expires October 2001 [Page 4] INTERNET DRAFT April 2001 [x] It indicates that x is optional. N_x Nonce generated by node x. DIGSIG_x It is a data signed by the node x private key. IIP Initiator's IP address. RIP Responder's IP address. PFS Perfect Forward Security. PBk_x Diffie-Hellman's public key generated by node x. PRk_x Diffie-Hellman's private key generated by node x. Xid X node identification. HASH_x Hash calculated by x. RAND_x Random number generated by x. FQDN_x The Fully Qualified Domain Name for node x. It is in the form a.b.c.d 2.0 Dynamic Security Establishment Protocol In this section two modes (primary and secondary) are described to establish a SA between the initiator (e.g. MN) and a responder (e.g. CN). The primary mode provides PFS (Private Forward Security) using Diffie-Hellman while the secondary mode provides more efficiency at the cost of the PFS feature. 2.1 Overall Protocol Description The Security Establishment protocol is a protocol to establish an SA between any two nodes (e.g. a MN and CN for Mobile IP). The protocol Khalil et al. expires October 2001 [Page 5] INTERNET DRAFT April 2001 goes through the following steps: 2.1.1 The Initiator Starts SA Establishment: The initiator (e.g.MN) starts the SA establishment by sending a SA request message (e.g. Binding Warning [1]) to responder (e.g. a CN). During this step the initiator uses a pair of PrivateKey_i/PublicKey_i. The SA request message carries a DIGSIG_i which contains basically a N_i, the initatior identity Iid and some other information described in sections 2.2 and 2.3. 2.1.2 The Responder Receives the SA Request Message When the responder (e.g. the CN) receives the SA request message (e.g. Binding Warning) from the initiator (e.g. MN), it decrypts the initiator's digital signature DIGSIG_i using the initiator's public key (PublicKey_i). Then the responder verifies the initiator's idenity by comparing a locally created one and the one recovered from the digital signature of the initiator (DIGSIG_i). If the verification is successful, the responder generates a pair of Privatekey_r/PublicKey_r. The responder then calculates a Shared Secret Key (SSK) to be used with the initaitor according to the mode described in section 2.2 and 2.3. The responder then forms a SA response message (e.g. Binding Request) destined to the initator containing the PublicKey_r, DIGSIG_r, and AUTH. The PublicKey_r, DIGSIG_r, and HASH_r is calculated according to the rules described in section 2.2 and 2.3. In case of Mobile IP the CN forms a control message (such as a Binding Request) containing the previous described field that is destined to the MN's home address. The home agent then intercepts this packet and tunnells it to the MN[2]. 2.1.3 Initiator Receives a SA Response Message when the initiator receives a SA response message (e.g. Binding Request) from the responder it verifie the identity of the responder by decrypting the respnder digital signature (DIGSIG_r), restoring the responder identity (Rid) and comparing this identity with a locally created one. if comparison is successful the initiator then calculates the SSK according to the modes covered by sections 2.2, 2.3. Subsequent control messages between the initiator and responder (e.g. Binding Update and Binding Acknowledgment) MUST contain the DIGSIG_x field and authenticated by including HASH_x field which was Khalil et al. expires October 2001 [Page 6] INTERNET DRAFT April 2001 calculated using the SA established before. The HASH_x field MUST be calculated as follows: HASH_x = prf (SSK,CM_b) where CM is a control message body such as Binding Update (BU) or Binding Acknowledgement (BA). Example: MN CN BU: BU_b, DIGSIG_mn, HASH_MN -----> <----- BA:BU_b, DIGSIG_cn, HASH_CN 2.2 Primary Mode This Primary Mode follows the protocol framework mentioned in section 2.1. The Primary Mode is based on Diffie-Hellman to provide PFS at the cost of efficiency. The initiator (e.g. MN) starts the SA establishment by sending a SA request message (e.g. Bingding Warning) to the responder. The initiator calculates the DIGSIG_i when it sends a SA response message to the responder (e.g. Binding Request) as follows: DIGSIG_i = < N_i | PBk_i | Iid > PrivateKey_i Iid = HASH (IIP | RIP | Pubkey_i) When the responder receives a SA Request message from the initiator, it performs the same steps defined for receiving a SA request message from the initiator defined in section 2.1.2. The responder then calculates SSK, AUTH_r, and DIGSIG_r as follows: SSK = prf (g^(PRk_r X PBk_i), N_i | N_r) HASH_r = prf (N_i | N_r, g^PBk_i | g^PBk_r | PublicKey_i | PublicKey_r | DIGSIG_r | SPI | HASH_type) DIGSIG_r = < N_r | PBk_r | Rid > PrivateKey_r Rid = HASH (IIP | RIP | PublicKey_i ) When the initiator receives the SA Response message from the Khalil et al. expires October 2001 [Page 7] INTERNET DRAFT April 2001 responder it follows the same steps defined in section 2.3 that are performed after receiving a SA response message from the responder. The initiator calculates the SSK as follows: SSK = prf (g^(PRk_i X PBk_r), N_i | N_r) The Primary Mode is summarized as follows: Initiator Responder CMi: PublicKey_i, HASH_Type, SPI, [FQDN_i,] DIGSIG_i, [HASH_i ] ----> <---- CMr: PublicKey_i, PublicKey_r, HASH_Type,SPI, [FQDN_r,] DIGSIG_r, HASH_r 2.3 The Secondary Mode The Secondary Mode follows the protocol framework mentioned in section 2.1. The Secondary Mode is efficient in execution time but does not provide PFS. The initiator starts the SA establishment by sending an SA request message (e.g. Binding Warning [1]) to the responder. The initiator calculates the DGSIG_i when it sends an SA request message to the responder as follows: DIGSIG_i = < N_i | Iid > PrivateKey_i Iid = HASH (IIP | RIP | Pubkey_i) When the responder receives a SA request message (e.g. Binding Warning) from the initiator, it follows the same steps as defined in section 2.1.2 for receiving a SA request message from the initiator. The responder calculates SSK, AUTH_r, and DIGSIG_r as follows: SSK = prf (HASH (N_i | N_r | RAND_r), IIP | RIP | PublicKey_i | PublicKey_r) HASH_r = prf (SSK, PublicKey_i | PublicKey_r | DIGSIG_r | SPI | HASH_type | [FQDN_r]) DIGSIG_r = < < RAND_r > PublicKey_i | N_r | Rid > PrivateKey_r Khalil et al. expires October 2001 [Page 8] INTERNET DRAFT April 2001 Rid = HASH (IIP | RIP | PublicKey_r) When the initiator receives the SA Response message from the responder it follows the same steps defined in section 2.3 for receiving a control message from the responder. The initiator calculates the SSK as follows: SSK = prf (N_i | N_r,MNIP | CNIP | PublicKey_i | PublicKey_r) The Secondary Mode is summarized as follows: Initiator Responder CMi : PublicKey_i, HASH_Type, SPI, [ FQDN_i, ] DIGSIG_i, [ HASH_i ] ----> <---- CMr: PublicKey_i, PublicKey_r, HASH_Type, SPI, [ FQDN_r ], DIGSIG_r, HASH_r 3.0 Re-Establishment Of MN-CN Security Association When the SA between the two nodes (e.g. MN and a CN) is about to expire,the initiator (e.g. MN) MAY start to re-establish the SA with the other node (e.g. CN). One of two modes described in section 2.2 and 2.3 MAY be used as follows: a - Primary Mode: SA request and SA response messages are exchanged according to the guidelines defined in section 2.2. The exchange of these messages is described as follows: Initiator Responder CMi: PublicKey_i, HASH_Type, SPI,[ FQDN_i ], DIGSIG_i, HASH_i ----> <---- CMr: PublicKey_i, PublicKey_r, HASH_Type, SPI, [ FQDN_r, ] DIGSIG_r, HASH_r Khalil et al. expires October 2001 [Page 9] INTERNET DRAFT April 2001 HASH_i = prf(SSK, g^PBk_i | PublicKey_i | DIGSIG_i | SPI | HASH_type |[ FQDN_i ]) HASH_r = prf(SSK, g^PBk_i | g^PBk_r | PublicKey_i | PublicKey_r | DIGSIG_r | SPI | HASH_type | [ FQDN_r ]) b - Secondary Mode: SA Request and SA Response messages are exchanged according to the guidelines described in section 2.3. The exchange of these messages is described as follows: Initiator Responder CMi: PublicKey_i, HASH_Type, SPI, FQDN_i DIGSIG_i, HASH_i ----> <---- CMr: PublicKey_i, PublicKey_r, HASH_Type, SPI, [ FQDN_r ] DIGSIG_r, HASH_r HASH_i = prf(SSK, PublicKey_i | DIGSIG_i | SPI | HASH_type | [ FQDN_i ]) HASH_r = prf(SSK,PublicKey_i | PublicKey_r | DIGSIG_r | SPI | HASH_type | [ FQDN_r ]) 4.0 Security Features This section discusses some of the security features provided by this protocol. 4.1 Denial Of Service Attack (DoS) Protection In this type of attacks the opponent forges the source address of a legitimate user and sends a public Diffie-Hellman key to the victim. The victim then performs a modular exponentiation to compute the secret key. Repeated messages like this can clog the victim's system with useless work. To protect against this type of attacks the receiver needs to verify the sender Identification (e.g. Iid or Rid) each time a message is received. Khalil et al. expires October 2001 [Page 10] INTERNET DRAFT April 2001 If the sender identification is not valid, the message is ignored silently. If the sender identification is valid then the receiver performs the following steps: a - the receiver does not perform the modular exponentiation for the same PBK_x twice and the message will be ignored silently. b - If PBk_x is different but the the sender is sending too many messages within a short period of time (may be a configurable parameter), those extra messages are ignored silently. 4.2 Replay Protection This type of attacks involves capturing of data unit and retransmitting of the same data in the future to cause unauthorized effect. The proposed protocol provides Nonce Sup-option which contains data such as timestamp to help the nodes detect old messages that have been retransmitted before. Upon detection of such messages the nodes ignore them silently. 4.3 Non-repudiation The proposed protocol prevents either sender or receiver from denying a transmitted message. As described earlier, the proposed protocol requires each node to provide a digital signature that contains the sender's identity signed by its private key. 4.4 Message Integrity The proposed protocol provides an Hash Sub-option that includes data based on hashing message fields with secret material known only by the sender and the receiver. Any modification of any message field are detected by the receiver. 5.0 Message Extensions This section describes the message extensions to be used for the protocol. 5.1 The Security Association (SA) Sub-option The Security Association sub-option is used to define the hash function type and the SPI involved in the Security Association. Khalil et al. expires October 2001 [Page 11] INTERNET DRAFT April 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 | 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. 5.2 The Key Payload Sub-option Key Payload Sub-option contains data Data required to generate a secret key or it might contain a public key. Khalil et al. expires October 2001 [Page 12] INTERNET DRAFT April 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 | 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 5.3 The Hash Sub-option The Hash 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 October 2001 [Page 13] INTERNET DRAFT April 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. 5.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 October 2001 [Page 14] INTERNET DRAFT April 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. 5.5 The Digital Signature (DIGSIG) Sub-option The digital signature sub-option carries the digital signature created as a result of encrypting a specific data with a node's private 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 | DIG_SIG data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option not including the type and length fields in units of 8 octets. DIG_SIG is the digital signature data. 5.6 The Nonce (NONCE) Sub-option Khalil et al. expires October 2001 [Page 15] INTERNET DRAFT April 2001 The Nonce Payload contains random data used to guarantee liveness during an exchange and protect against replay attacks. 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 | Nonce Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option not including the type and length fields in units of 8 octets. Nonce Data Contains the random data generated by the transmitting entity. 5.6 The FQDN Sub-option The FQDN Payload contains the Fully Qualified Domain Name for the node. This information is useful in such cases where the node has a secure communication with DNS and may retreive public information about its peer using this secure access to such global data base (e,g, DNS). Khalil et al. expires October 2001 [Page 16] INTERNET DRAFT April 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 | FQDN Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA Length The length of the option not including the type and length fields in units of 8 octets. FQDN Data FQDN data in the form of x.y.z.w 6.0 References [1] Charlie Perkins, Binding Key Establishment for Mobile IPv6 [2] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress), draft-ietf-mobileip-ipv6-13.txt, October 2000 7.0 Acknowledgements 8.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 Khalil et al. expires October 2001 [Page 17] INTERNET DRAFT April 2001 Emad Qaddoura Nortel Networks Inc. 2201 Lakeside Blvd Richardson, TX 75082-4399 Phone: +1 972 684-2705 E-mail: emadq@nortelnetworks.com 9.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, 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 October 2001 [Page 18]