Mobile IP Working Group Pat R. Calhoun INTERNET DRAFT Sun Microsystems, Inc. 25 February 1999 Charles E. Perkins Sun Microsystems, Inc. Mobile IP Challenge/Response Extensions draft-ietf-mobileip-challenge-01.txt 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@smallworks.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 Mobile IP, as originally specified, defined an authentication extension (the Mobile-Foreign Authentication Extension) by which a mobile node could authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection, and worse yet does not conform to existing techniques (such as CHAP) for authenticating transportable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow use of such challenge/response mechanisms for allowing a foreign agent to authenticate the mobile node. Calhoun, Perkins Expires 25 August 1999 [Page i] Internet Draft Mobile IP Challenge/Response 25 February 1999 1. Introduction In this document, we postulate that the foreign agent has access to a verification infrastructure that can return a secure notification to the foreign agent that the authentication has been performed, along with the results of that authentication. This infrastructure may be visualized as shown in figure 1. For an example of another protocol that has been specified to actually carry out the key creation and challenge verification operations, see [2, 1]. After +----------------------------------------------------+ | | | Verification and Key Management Infrastructure | | | +----------------------------------------------------+ ^ | ^ | | | | | | v | v +---------------+ +---------------+ | | | | | Foreign Agent | | Home Agent | | | | | +---------------+ +---------------+ Figure 1: The Verification Infrastructure the foreign agent gets the Challenge Response, it passes the Response along to the (here unspecified) infrastructure, and awaits a a Registration Reply. If the reply has a positive status (indicating that the registration was accepted), the foreign agent accepts the registration. If the reply does not have a positive status code, then the foreign agent assumes that the challenge did not pass verification, for reasons that may or may not be specified by the infrastructure agents. Implicit in this picture, however, is the important observation that the Foreign Agent and the Home Agent have to be equipped to make use of whatever protocol is made available to them by the challenge verification and key management infrastructure shown in the figure. The protocol messages for handling the authentication within the verification infrastructure, and identity of the agent performing the verification of the Foreign Agent challenge, are not specified in this document, because those operations do not have to be performed by any Mobile IP entity. On the other hand, and consistent with the Calhoun, Perkins Expires 25 August 1999 [Page 1] Internet Draft Mobile IP Challenge/Response 25 February 1999 figure, either the foreign agent or the home agent could perform the verification if configured to do so. 1.1. Operation This section describes the modifications to the Mobile IP registration process which occur after the Foreign Agent issues a Mobile IP Agent Advertisement containing the Challenge on its local link, which is captured and processed by the mobile node. 1.2. Registration Request Generation The mobile node extracts the Challenge from the advertisement and computes the Mobile-Challenge-Response extension using the challenge and the Registration Request message hashed with a secret which is known within the verification infrastructure. The mobile node's Registration Request is forwarded to the Foreign Agent and includes the following extensions: , if present (see section 3.1) , if present (see section 3.2) , if present Upon receipt of the Registration Request, the Foreign Agent MUST ensure that the Foreign-Agent-Challenge extension contains a previously unused challenge value. This ensures that the mobile node is not attempting to replay a previous Mobile-Challenge-Response. If the Mobile-Challenge-Response extension is present in the message, or if the Mobile-Node-NAI shows that it belongs to a different administrative domain, the foreign agent forwards the Registration Request to the verification infrastructure (see figure 1). 1.3. Registration Reply Processing The following actions occur when the foreign agent receives a Registration Reply containing the information pertinent to the authentication of the Challenge Response computed by the mobile node. It then validates the Foreign-Home Authentication extension as specified in [7]. If the packet is successfully authenticated, the Foreign Agent adds the Mobile-Foreign Authentication extension. The Registration Reply message forwarded to the mobile node has the following format: Calhoun, Perkins Expires 25 August 1999 [Page 2] Internet Draft Mobile IP Challenge/Response 25 February 1999 , if present 2. Mobile IP Agent Discovery Extensions This section will define a new extension to the Router Discovery Protocol [4] for use by mobility agents that need to issue a challenge for authenticating mobile nodes. A mobile node can assume that the Foreign Agent supports this specification if the extensions in this section are part of the Router Advertisements. 2.1. Challenge Extension The Challenge Extension is inserted in the Agent Advertisements by the Foreign Agent, in order to communicate the latest Challenge value that can be used by the mobile node to compute a Challenge Response. The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was advertised as one of the last two Challenge values inserted into the immediately preceding Agent advertisements. The Challenge 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 | Challenge ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length MUST be at least 18 Challenge A random value of at least 128 bits. 3. Mobile IP Registration Extensions This section specifies new Mobile IP Registration Extensions that are used to satisfy a Challenge in an Agent Advertisement. Calhoun, Perkins Expires 25 August 1999 [Page 3] Internet Draft Mobile IP Challenge/Response 25 February 1999 3.1. Foreign-Agent-Challenge Extension The Foreign-Agent-Challenge extension is copied from the Challenge in the Agent Advertisement. 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 | Challenge... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length MUST be at least 16 Challenge The Challenge field is copied from the Agent Advertisement's Challenge. 3.2. Mobile-Challenge-Response Extension The mobile node MUST include this extension in the Registration Request if the foreign agent's advertisement contains the Challenge Extension. 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 | SPI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... SPI (cont.) | Authenticator +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 6 plus the number of bytes in the Authenticator; MUST be at least 22. SPI Security Parameters Index Authenticator The Challenge field consists random value of at least 128 bits. Variable length hash. The authenticator is computed on the following data, in the order shown: Key || Preceding Mobile IP data || Type, Length, SPI || Key Calhoun, Perkins Expires 25 August 1999 [Page 4] Internet Draft Mobile IP Challenge/Response 25 February 1999 where the Type, Length, and SPI are as shown above. Each mobile node MUST support the ability to produce the authenticator by using MD5 [8] on the specified data, which is known as "prefix+suffix" mode. Just as with Mobile IP, MD5 in the prefix+suffix mode MUST be able to be configured for selection at any arbitrary 32-bit SPI. 4. Security Considerations In the event that a malicious mobile node attempts to replay an old Foreign-Agent-Challenge and Mobile-Node-Response pair, the Foreign Agent would detect it since the Foreign Agent would be able to verify that it had not recently advertised the Challenge. 5. IPv6 Considerations For use with IPv6 mobility, the challenge extension would have to be applied to Router Advertisements [6]. In order to check the response from the mobile node, the router would need to have a security relationship with either the mobile node or its home agent. It is not yet known which security model would be more appropriate, or whether it would make the most sense to enable maximum flexibility by specifying the protocol for both cases. 6. Acknowledgements The authors would like to thank Tom Hiller, Mark Munson, the TIA TR45-6 WG, Gabriel Montenegro and Vipul Gupta for their useful discussions. References [1] P. Calhoun and C. E. Perkins. DIAMETER Mobile IP Extensions. draft-calhoun-diameter-mobileip-01.txt, November 1998. (work in progress). [2] P. Calhoun and A. Rubens. DIAMETER Base Protocol. draft-calhoun-diameter-00.txt, February 1998. (work in progress). [3] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network Address Identifier Extension. draft-ietf-mobileip-mn-nai-01.txt, February 1999. (work in progress). [4] Stephen E. Deering, Editor. ICMP Router Discovery Messages. RFC 1256, September 1991. Calhoun, Perkins Expires 25 August 1999 [Page 5] Internet Draft Mobile IP Challenge/Response 25 February 1999 [5] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP version 6 (IPv6). RFC 1970, August 1996. [6] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor discovery for IP Version 6 (IPv6), December 1998. Obsoletes RFC1970 [5]. Status: DRAFT STANDARD. [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. [8] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, April 1992. Calhoun, Perkins Expires 25 August 1999 [Page 6] Internet Draft Mobile IP Challenge/Response 25 February 1999 Chairs' Addresses The working group can be contacted via the current chairs: Jim Solomon Erik Nordmark Redback Networks, Inc. Sun Microsystems, Inc. 1301 E. Algonquin Road 17 Network Circle Schaumburg, IL 60196 Menlo Park, California 94025 USA USA Phone: +1-847-576-2753 Phone: +1 650 786-5166 Fax: Fax: +1 650 786-5896 E-mail: solomon@redbacknetworks.com E-mail: nordmark@sun.com Author's Addresses Questions about this memo can be directed to: Pat R. Calhoun Charles E. Perkins Sun Microsystems Laboratories Sun Microsystems Laboratories 15 Network Circle 15 Network Circle Menlo Park, CA 94025 Menlo Park, CA 94025 USA USA Phone: +1-650-786-7733 Phone: +1 650 786-6464 EMail: pat.calhoun@sun.com EMail: cperkins@eng.sun.com Fax: +1 650 786-6445 Calhoun, Perkins Expires 25 August 1999 [Page 7]