INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-mobileip-fa-tokens-00.txt Haseeb Akhtar Date: March 2000 Emad Qaddoura Expires: September 2000 Nortel Networks N. Asokan Nokia Research Center Foreign Agent Keys Encoded as Opaque Tokens for use in Hand-off Process 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. Calhoun, Akhtar, Qaddoura, Asokan [Page 1] INTERNET DRAFT March 2000 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 (within the same administrative domain) while registering. This proposal is intended to decrease the latency involved in the hand-off process, thereby enabling seamless 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. At present, authentication in Mobile IP uses shared key cryptography. However, this proposal is general enough to be able to accommodate authentication based on public key digital signatures if and when it becomes feasible. Calhoun, Akhtar, Qaddoura, Asokan [Page 2] INTERNET DRAFT March 2000 Table of Contents 1.0 Introduction 1.1 Copyright Statement 1.2 Requirements language 2.0 MN-Key-Token Extension 3.0 HA-Key-Token Extension 4.0 Token Issuer's NAI Extension 5.0 Mobile Node Considerations 6.0 Foreign Agent Considerations 7.0 References 8.0 Authors' Addresses Calhoun, Akhtar, Qaddoura, Asokan [Page 3] INTERNET DRAFT March 2000 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 (within the same administrative domain) while registering. This proposal is intended to decrease the latency involved in the hand-off process, thereby enabling seamless 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 authentication tokens from which the foreign agent can extract keys necessary to verify the MN-FA and FA-HA authentication extensions. In the case of shared key based authentication, the extensions consist of session keys which 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. In the case of digital signature based authentication, the extensions consist of public signature verification keys along with certificates vouching for their authenticity and validity. The entity which constructs these authentication tokens is called a "token issuer". The token issuer is trusted by all foreign agents in the visited administrative domain: for example, it could be the AAA server in the domain, or the root foreign agent in a foreign agent hierachy, or the previous foreign agent. The foreign agent MAY also add a token-issuer NAI extension (Section 5.0) to the Registration Reply. When the mobile node moves to a new subnet, or cell, within the same administrative domain, it includes the token extensions in the Registration Request as well as the token issuer's NAI. The foreign agent can determine if it can extract the keys by using the token issuer's NAI. The NAI and the SPI field SHOULD provide sufficient information for the new foreign agent to extract the keys. If the foreign agent is able to extract the keys, it uses the keys to Calhoun, Akhtar, Qaddoura, Asokan [Page 4] INTERNET DRAFT March 2000 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 authentication token extensions also include an expiration time, which is used to ensure that old keys are not provided to the new foreign agent. In the case of authentication based on shared keys, all foreign agents within a single administrative domain must be able to extract each other's keys, and therefore 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 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. In the case of authentication based on digital signatures, the logistical difficulties are less severe. All FAs need to be configured with an authentic copy of the token issuer's public signature verification key. This proposal does not impose any additional requirements on the size and update frequency on this key than is usual due to other considerations. 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 MN-Key-Token Extension In order to allow for the hand-off process to be done with minimal additional latency, the MN-Key-Token Extension allows the mobile node to securely carry the key necessary for the foreign agent to verify the MN-FA authentication extension. 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 belonging to the same administrative domain as the old FA, and this extension was received in a previous Registration Reply, the mobile node SHOULD include this Calhoun, Akhtar, Qaddoura, Asokan [Page 5] INTERNET DRAFT March 2000 extension in the Registration Request. The Mobile Node can verify whether foreign agents belong to the same administrative domain using the advertisement Foreign Agent NAI extension, defined in [15]. The MN-Key-Token Extension is subtype 8 of the Generalized MN-FA Key Reply Extension [14] and 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FA SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticated MN-FA key token... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The MN-Key-Token Subtype-Specific Data FA SPI A 32-bit opaque value, indicating the SPI that the foreign agent must use to determine the algorithm to use for recovering the MN security information. MN SPI A 32-bit opaque value, which the foreign agent MUST use to index all the necessary information recovered from the MN security information after it is decoded. MN Identifier The 32-bit address using which foreign agents within the visited domain can uniquely identify the Mobile Node. This SHOULD be the Mobile Node's 32-bit Home Address. Authenticated MN-FA key token The Authenticated MN-FA key token field is opaque to the mobile node, but is used by a foreign agent in the same administrative domain as the token-issuer to extract an authenticated key that can be used to verify MA-FA authentication extensions in the Registration Request. For this purpose, the MN-FA authenticated key token contains the following fields, bound together using a suitable cryptographic transform: Calhoun, Akhtar, Qaddoura, Asokan [Page 6] INTERNET DRAFT March 2000 - 32 bit timestamp field containing the time at which the token was created by the token issuer, whose format is consistent with the NTP specification [9] - 32 bit expiration field containing the time at which the session keys will expired - 32 bit SPI field that corresponds to the key described in the next field - variable length key from AAA infrastructure, used by foreign agents to verify the MN-FA authentication extension in Registration Requests. The FA SPI field of the extension is used to identify the keys necessary to authenticate this field and extract the key embedded in this field. If MN-FA authentication is based on shared keys, the key embedded in the Authenticated MN-FA key token is the MN-FA session key. In this case, the authenticated key token must provide both confidentiality and authentication. Therefore, it MUST be constructed by encrypting the four fields using a key shared among all foreign agents within the administrative domain. The preferred transform is Triple-DES Cipher Block Chaining mode (3DES-CBC), but other algorithms could also be used. If MN-FA authentication is based on digital signatures, the key embedded in the Authenticated MN-FA key token is the public signature verification key of the mobile node. In this case, the authenticated key token does not need to be encrypted. It MAY be constructed as above, or MAY be constructed using a digital signature of the token-issuer covering the four fields. All foreign agents within the administrative domain MUST have the key(s) necessary to be able to verify this digital signature. 3.0 HA-Key-Token Extension In order to allow for the hand-off process to be done in an efficient manner, the HA-Key-Token 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 belonging to the same administrative domain as the old FA, and this extension was received in a previous Registration Reply, the mobile node SHOULD include this extension in the Registration Request. The Mobile Node Calhoun, Akhtar, Qaddoura, Asokan [Page 7] INTERNET DRAFT March 2000 can verify whether foreign agents belong to the same administrative domain using the advertisement Foreign Agent NAI extension, defined in [15]. The HA-Key-Token Extension is subtype 1 of the Generalized FA-HA Key Reply Extension [14] and 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FA SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticated FA-HA key token... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The HA-Key-Token Subtype-Specific Data FA SPI A 32-bit opaque value, indicating the SPI that the foreign agent must use to determine the algorithm to use for recovering the HA security information. HA SPI A 32-bit opaque value, which the foreign agent MUST use to index all the necessary information recovered from the HA security information after it is decoded. Authenticated FA-HA key token The Authenticated FA-HA key token field is opaque to the mobile node, but is used by a foreign agent in the same administrative domain as the token-issuer to extract an authenticated key that can be used to verify FA-HA authentication extensions in a Registration Reply sent by the home agent. For this purpose, the HA-FA authenticated key token contains the following fields, bound together using a suitable cryptographic transform: - 32 bit timestamp field containing the time at which the token was created by the token issuer, whose format is consistent with the NTP specification [9] - 32 bit expiration field containing the time at which the session keys will expire Calhoun, Akhtar, Qaddoura, Asokan [Page 8] INTERNET DRAFT March 2000 - 32 bit SPI field that corresponds to the key described in the next field - variable length key from AAA infrastructure, used by foreign agents to verify the FA-HA authentication extension in Registration Replies. The FA SPI field of the extension is used to identify the keys necessary to authenticate this field and extract the key embedded in this field. If HA-FA authentication is based on shared keys, the key embedded in the Authenticated FA-HA key token is the FA-HA session key. In this case, the authenticated key token must provide both confidentiality and authentication. Therefore, it MUST be constructed by encrypting the four fields using a key shared among all foreign agents within the administrative domain. The preferred transform is Triple-DES Cipher Block Chaining mode (3DES-CBC), but other algorithms could also be used. If HA-FA authentication is based on digital signatures, the key embedded in the Authenticated FA-HA key token is the public signature verification key of the home agent. In this case, the authenticated key token does not need to be encrypted. It MAY be constructed as above, or MAY be constructed using a digital signature of the token-issuer covering the four fields. All foreign agents within the administrative domain MUST have the key(s) necessary to be able to verify this digital signature. 4.0 Token Issuer's NAI Extension The Token Issuer's NAI Extension is subtype 5 of the Generalized NAI extension [4] and contains the NAI of the token issuer that created the MN-Key-Token and/or HA-Key-Token. The mobile node MUST include this extension if either the MN-Key-Token or the HA-Key-Token are present in the Registration Request. The foreign agent uses this information to identify whether it shares a common security association with the token issuer that would be used to extract the various session keys. The Token Issuer's NAI Extension is defined as follows: Calhoun, Akhtar, Qaddoura, Asokan [Page 9] INTERNET DRAFT March 2000 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 | SubType | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token Issuer's NAI... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The Token Issuer's NAI Extension Type TBD (non-skippable) Sub-Type 5 Length The length field MUST contain at least 1 Token Issuer's NAI The Token Issuer's NAI field contains the NAI of the token issuer that created the extensions defined in section 3.0 and 4.0. 5.0 Mobile Node Considerations The mobile node MAY receive the MN-Key-Token and/or the HA-Key-Token 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 foreign agent that belongs to the same adminstrative domain as the old Foreign Agent (identified via the NAI), it SHOULD include both Key Token extensions and the Token Issuer's 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, using the Advertisement foreign agent NAI extension [15]. In the event that the Mobile Node is requesting keying material by including the MN-AAA [10] authentication extension, if the Foreign Agent returns an authentication failure code of 67 [11], the Mobile Node SHOULD resend a registration that includes the MN-AAA authentication extension. This will allow the Foreign Agent to issue the request to the AAA infrastructure, and receive new keying information. 6.0 Foreign Agent Considerations Calhoun, Akhtar, Qaddoura, Asokan [Page 10] INTERNET DRAFT March 2000 The foreign agent MAY receive the MN-Key-Token and/or the HA-Key- Token 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 extract keys (to be used in verifiying authentication extensions) that were initially derived from the Home AAA (AAAH). In order for a foreign agent to be able to extract 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 case of authentication based on shared keys, if the foreign agent is not able to extract 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. 7.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, 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] M. Khalil, E. Qaddoura, H. Akhtar, P. Calhoun. "Generalized NAI Extension", draft-mkhalil-mobileip-gnaie-00.txt, IETF Work in Progress. February 2000. [5] US National Bureau of Standards. "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information 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] B. Schneier. "Applied Cryptography Second Edition". John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. [8] M. Khalil, R. Narayanan, H. Akhtar, E. Qaddoura. "Mobile IP Extensions Rationalization (MIER)", draft-ietf-mobileip-mier- 03.txt, IETF Work in Progress. December 1999. [9] Mills. "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030. October 1996. [10] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Calhoun, Akhtar, Qaddoura, Asokan [Page 11] INTERNET DRAFT March 2000 Extensions", draft-ietf-mobileip-challenge-09.txt, IETF Work in Progress. February 2000. [11] C. Perkins, Editor. "IP Mobility Support", RFC 2002. October 1996. [12] C. Perkins, P. Calhoun. "AAA Registration Keys for Mobile IP", draft-ietf-mobileip-aaa-keys-01.txt, IETF Work in Progress. January 2000. [13] B. Aboba, M. Beadles. "The Network Access Identifier" RFC 2486. January 1999. [14] C. Perkins, P. Calhoun. "Generalized Key Distribution Extensions for Mobile IP", draft-perkins-mobileip-gen-key-00.txt, IETF Work in Progress. March 2000. [15] E. Gustafsson, A. Johnsson, C. Perkins. "Mobile IP Regional Tunnel Management", draft-ietf-mobileip-reg-tunnel-01.txt, IETF Work in Progress. August 1999. Calhoun, Akhtar, Qaddoura, Asokan [Page 12] INTERNET DRAFT March 2000 8.0 Authors' Addresses 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 N. Asokan Communication Systems Lab Nokia Research Center P.O. Box 407, FIN-00034, Nokia Group Helsinki, Finland Phone: +358 40 743 1961 E-Mail: n.asokan@nokia.com Calhoun, Akhtar, Qaddoura, Asokan [Page 13]