INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-mobileip-min-lat-handoff-00.txt Haseeb Akhtar Date: October 1999 Emad Qaddoura Nortel Networks Minimal Latency Secure Hand-off Status of this Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.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 The Mobile IP Working Group has been working on defining its AAA requirements, which currently supports a Key Distribution Center (KDC) model that issues temporary session keys for use between the mobility nodes. In order to support real-time traffic, the Mobile IP architecture also requires that hand-off be done in a quick and efficient manner, and has provisions to allow new foreign agents to retrieve the session keys from the AAA infrastructure. Although the AAA infrastructure can assist in the hand-off process, Calhoun, Akhtar, Qaddoura expires April 2000 [Page 1] INTERNET DRAFT October 1999 this is largely a mobility problem, and should be dealt with in the mobility protocol. This draft describes how the mobile node can assist in the hand-off process by carrying the foreign agent's keying information, providing the keys to new foreign agents while registering. This proposal is intended to decrease the latency involved in the hand-off process, thereby enabling seemless real time traffic over Mobile IP networks. This draft still allows the foreign agents to get keying information from the AAA infrastructure should that be necessary. Calhoun, Akhtar, Qaddoura expires April 2000 [Page 2] INTERNET DRAFT October 1999 Table of Contents 1.0 Introduction 1.1 Copyright Statement 1.2 Requirements language 2.0 New Extensions 2.1 FA-Encrypted-MN-Key Extension 2.2 FA-Encrypted-HA-Key Extension 2.3 Previous Foreign Agent NAI Extension 3.0 Mobile Node Considerations 4.0 Foreign Agent Considerations 5.0 References 6.0 Author's Address Calhoun, Akhtar, Qaddoura expires April 2000 [Page 3] INTERNET DRAFT October 1999 1.0 Introduction The Mobile IP Working Group has been working on defining its AAA requirements, [3] which currently supports a Key Distribution Center (KDC) model that issues temporary session keys for use between the mobility nodes. In order to support real-time traffic, the Mobile IP architecture also requires that hand-off be done in a quick and efficient manner, and has provisions to allow new foreign agents to retrieve the session keys from the AAA infrastructure. Although the AAA infrastructure can assist in the hand-off process, this is largely a mobility problem, and should be dealt with in the mobility protocol. This draft describes how the mobile node can assist in the hand-off process by carrying the foreign agent's keying information, providing the keys to new foreign agents while registering. This proposal is intended to decrease the latency involved in the hand-off process, thereby enabling seemless real time traffic over Mobile IP networks. This draft still allows the foreign agents to get keying information from the AAA infrastructure should that be necessary. This specification defines new extensions that a foreign agent SHOULD add to a Registration Reply when new keying information is received by the AAA infrastructure. The extensions contain the session keys that the foreign agent uses for the MN-FA and FA-HA authentication extensions. The session keys in the extensions are encrypted so that the mobile node cannot decrypt them, and this also enables the new foreign agent some guarantees that the mobile node is not providing invalid keys for the purposes of fraud. When the mobile node moves to a new subnet, or cell, it includes the key extensions in the Registration Request as well as the previous foreign agent's NAI. The foreign agent can determine if it can decrypt the keys by using the previous foreign agent's NAI. The NAI and the SPI field SHOULD provide sufficient information for the new foreign agent to decrypt the keys. If the foreign agent is able to decrypt the keys, it uses the keys to authenticate the MN-FA authentication extension in the Registration Request, which will ensure that the keys are valid, otherwise a request to the AAA infrastructure is required. The encrypted key extensions also include an expiration time, which is used to ensure that old keys are not provided to the new foreign agent. In order for the foreign agents within a single administrative domain to be able to decrypt their keys, a group key is recommended. This is due to the fact that a foreign agent cannot encrypt the keys for a specific new foreign agent since the movement pattern of the mobile node is not known a priori. Due to the fact that the cost of Calhoun, Akhtar, Qaddoura expires April 2000 [Page 4] INTERNET DRAFT October 1999 changing group keys within a network is quite high, it is recommended that the group key size used be sufficiently large (e.g. 128 bits). The network operator SHOULD still change the group keys periodically in order to ensure that if the key become compromised it cannot be used. [editor's note: I am not sure about the previous two statements, but it seemed logical to add such a warning, which has nothing to with the spec]. 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 [1]. 2.0 New Extensions This section details the new extensions that an implementation MUST support in order to conform to this specification. 2.1 FA-Encrypted-MN-Key Extension In order to allow for the hand-off process to be done with minimal additional latency, the FA-Encrypted-MN-Key extension allows the mobile node to carry the foreign agent's MN-FA session key information. The foreign agent adds this extension in a Registration Reply that includes keying information from the AAA infrastructure. If the mobile node detects that it is being serviced by a new foreign agent, and this extension was received in a previous Registration Reply, the mobile node SHOULD include this extension in the Registration Request. The FA-Encrypted-MN-Key Extension is defined as follows: Calhoun, Akhtar, Qaddoura expires April 2000 [Page 5] INTERNET DRAFT October 1999 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-FA Session Key... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Reserved 0 Length The length field MUST contain at least 15 SPI The Security Parameter Index field contains an opaque value that is used to identify the keying material used to encrypt the following field. MN-FA Session Key The MN-FA Session Key field contains an encrypted version of the following fields: - 32 bit timestamp field containing the time at which the extension was created by the foreign agent - 32 bit expiration field containing the time at which the session keys will expire - 32 bit SPI field that corresponds to the session key - variable length MN-FA session key from AAA infrastructure The SPI field is used to identify the keys necessary to decrypt this field. The preferred transform is Triple-DES Cipher Block Chaining mode (3DES-CBC), but other algorithms could also be used. Calhoun, Akhtar, Qaddoura expires April 2000 [Page 6] INTERNET DRAFT October 1999 2.2 FA-Encrypted-HA-Key Extension In order to allow for the hand-off process to be done in an efficient manner, the FA-Encrypted-HA-Key extension allows the mobile node to carry the foreign agent's FA-HA session key information. The foreign agent adds this extension in a Registration Reply that includes keying information from the AAA infrastructure. If the mobile node detects that it is being serviced by a new foreign agent, and this extension was received in a previous Registration Reply, the mobile node SHOULD include this extension in the Registration Request. The FA-Encrypted-HA-Key Extension is defined as follows: 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FA-HA Session Key... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Reserved 0 Length The length field MUST contain at least 15 SPI The Security Parameter Index field contains an opaque value that is used to identify the keying material used to encrypt the following field. FA-HA Session Key The FA-HA Session Key field contains an encrypted version of the following fields: Calhoun, Akhtar, Qaddoura expires April 2000 [Page 7] INTERNET DRAFT October 1999 - 32 bit timestamp field containing the time at which the extension was created by the foreign agent - 32 bit expiration field containing the time at which the session keys will expire - 32 bit SPI field that corresponds to the session key - variable length FA-HA session key from AAA infrastructure The SPI field is used to identify the keys necessary to decrypt this field. The preferred transform is Triple-DES Cipher Block Chaining mode (3DES-CBC), but other algorithms could also be used. 2.3 Previous Foreign Agent NAI Extension The Previous Foreign Agent NAI Extension contains the NAI of the foreign agent that provided service to the mobile node before entering the new service area. The mobile node MUST include this extension if either the FA-Encrypted-MN-Key or the FA-Encrypted-HA- Key are present in the Registration Request. The foreign agent uses this information to identify whether it shares a common security association with the old foreign agent that would be used to decrypt the various session keys. The Previous Foreign Agent NAI Extension is defined as follows: 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 | Previous Foreign Agent NAI... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Length The length field MUST contain at least 1 Previous Foreign Agent NAI The Previous Foreign Agent NAI field contains the NAI of the foreign agent that created the extensions defined in section 2.1 and 2.2. Calhoun, Akhtar, Qaddoura expires April 2000 [Page 8] INTERNET DRAFT October 1999 3.0 Mobile Node Considerations The mobile node MAY receive the FA-Encrypted-MN-Key and/or the FA- Encrypted-HA-Key in a Registration Reply from the foreign agent. The extensions MUST be found prior to the MN-FA authentication extension and after the MN-HA authentication extension. When a mobile node moves to a new subnet, or cell, serviced by a new foreign agent, it SHOULD include the both key and the Previous foreign agents NAI extensions in the Registration Request. The mobile node MAY attempt to determine whether both foreign agents belong to the same administrative domain prior to including the extensions. Since it is possible that the keying information provided cannot be used by the new foreign agent, the mobile node MUST also include the MN-AAA authentication extension in the Registration Request. This will allow the foreign agent to send a request to the AAA infrastructure, should that be necessary. 4.0 Foreign Agent Considerations The foreign agent MAY receive the FA-Encrypted-HA-Key and/or the FA- Encrypted-MN-Key within a Registration Request from a mobile node that does not already belong to its visitors list. The foreign agent MUST use the SPI field in the extensions in order to decrypt the session keys that were initially derived from the AAAH. In order for a foreign agent to be able to decrypt keys from another foreign agent, the foreign agents MUST share a group key. Since group keys are somewhat difficult to manage, it is imperative that they not be compromised. Therefore, the group key used MUST be sufficiently strong and SHOULD be used only for the encryption of the extensions defined in this specification. In the event that the foreign agent is not able to decrypt the session keys, it SHOULD issue a request to the AAA infrastructure. The AAA infrastructure can then either issues new session keys or return the old session keys. 5.0 References [1] Bradner, "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [2] G. Dommety, S. Glass, T. Hiller, S. Jacobs, B. Patil, C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", draft-ietf-aaa-mobile-ip-req-00.txt Calhoun, Akhtar, Qaddoura expires April 2000 [Page 9] INTERNET DRAFT October 1999 IETF Work in Progress, April 1999. [3] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [4] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication [5] US National Bureau of Standards, "Guidelines for Implement- ing and Using the Data Encryption Standard", Federal Infor- mation Processing Standard (FIPS) Publication 74, April 1981. [6] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [7] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. Calhoun, Akhtar, Qaddoura expires April 2000 [Page 10] INTERNET DRAFT October 1999 6.0 Author's Address Questions about this memo can be directed to: Pat R. Calhoun Sun Laboratories, Network and Security Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-650-786-7733 Fax: 1-650-786-6445 E-mail: pcalhoun@eng.sun.com Haseeb Akhtar Wireless Technology Labs Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082-4399 USA Phone: 1-972-684-8850 E-Mail: haseeb@nortelnetworks.com Emad Qaddoura Wireless Technology Labs Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082-4399 USA Phone: 1-972-684-2705 E-Mail: emadq@nortelnetworks.com Calhoun, Akhtar, Qaddoura expires April 2000 [Page 11]