Mobile IP Working Group Charles E. Perkins INTERNET DRAFT Nokia Research Center 25 October 1999 Pat R. Calhoun Sun Microsystems Laboratories Mobile IP Challenge/Response Extensions draft-ietf-mobileip-challenge-06.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, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not conform to existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. Perkins, Calhoun Expires 25 April 2000 [Page i] Internet Draft Mobile IP Challenge/Response 25 October 1999 1. Introduction Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection, and does not conform to existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to a use challenge/response mechanism to authenticate the mobile node. 2. Mobile IP Agent Advertisement Challenge Extension This section defines a new extension to the Router Discovery Protocol [4] for use by foreign agents that need to issue a challenge for authenticating mobile nodes. 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The Challenge Extension Type 24 Length MUST be at least 16 Challenge A random value of at least 128 bits. The Challenge extension, illustrated in figure 1, 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 an authentication for its registration request message. The challenge is selected by the foreign agent to provide local assurance that the mobile node is not replaying any earlier registration request. Eastlake, et al. [5] provides more information on generating pseudo-random numbers suitable for use as values for the challenge. Perkins, Calhoun Expires 25 April 2000 [Page 1] Internet Draft Mobile IP Challenge/Response 25 October 1999 3. Operation This section describes modifications to the Mobile IP registration process which may occur after the Foreign Agent issues a Mobile IP Agent Advertisement containing the Challenge on its local link. 3.1. Mobile Node Processing for Registration Requests Whenever the Agent Advertisement contains the Challenge extension, if the mobile node does not have a security association with the Foreign Agent, then it MUST include the Challenge value in a MN-FA Challenge extension to the Registration Request message. If, on the other hand, the mobile node does have a security association with the foreign agent, it MAY include the Challenge value in its Registration Request message. If the Mobile Node has a security association with the Foreign Agent, it MUST include a Mobile-Foreign Authentication extension in its Registration Request message, according to RFC 2002 [11]. When the Registration Request contains the MN-FA Challenge extension specified in section 4, the Mobile-Foreign Authentication MUST follow the Challenge extension in the Registration Request. If the Mobile Node does not have a security association with the Foreign Agent, the Mobile Node MUST include the MN-AAA Authentication extension as defined in section 4.2, or the MN-RADIUS extension as defined in section 4.3. In addition, the Mobile Node SHOULD include the NAI extension [3], to enable the foreign agent to make use of any available verification infrastructure. The SPI field of the MN-AAA Authentication extension specifies the particular secret and algorithm (shared between the Mobile Node and the verification infrastructure) that must be used to perform the authentication. The MN-RADIUS extension only supports CHAP-style authentication [13] using MD5 [12], and the SPI field MAY be set to any value. In either case, the MN-FA Challenge extension and one of the above specified authentication extensions MUST follow the Mobile-Home Authentication extension, if present. 3.2. Foreign Agent Processing for Registration Requests Upon receipt of the Registration Request, if the Foreign Agent has issued a Challenge as part of its Agent Advertisements, and it does not have a security association with the mobile node, then the Foreign Agent MUST check that the MN-FA Challenge extension exists, and that it contains a challenge value previously unused by the Mobile Node. This ensures that the mobile node is not attempting Perkins, Calhoun Expires 25 April 2000 [Page 2] Internet Draft Mobile IP Challenge/Response 25 October 1999 to replay a previous advertisement and authentication. If the challenge extension is needed and does not exist, the Foreign Agent MUST send a Regstration Reply to the mobile node with the error code MISSING_CHALLENGE. If a mobile node retransmits a Registration Request with the same Identification field and the same Challenge extension, and the Foreign Agent still has a pending Registration Request record in effect for the mobile node, then the Foreign Agent forwards the Registration Request to the Home Agent again. In all other circumstances, if the Foreign Agent receives a Registration Request with a Challenge extension containing a Challenge value previously used by that mobile node, the Foreign Agent SHOULD send a Registration Reply to the mobile node containing the Code value STALE_CHALLENGE. The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was advertised as one of the last CHALLENGE_WINDOW (see section 5) Challenge values inserted into the immediately preceding Agent advertisements. If the Challenge is not one of the recently advertised values, the foreign Agent SHOULD send a Registration Reply with Code UNKNOWN_CHALLENGE (see section 6). Furthermore, the Foreign Agent MUST check that there is either a Mobile-Foreign, a MN-AAA Authentication, or a MN-RADIUS extension after the Challenge value. Any registration message containing the Challenge value without either of these authentication extensions MUST be silently discarded. If the registration message contains a Mobile-Foreign Authentication extension with an incorrect authenticator that fails verification, the Foreign Agent MAY send a Registration Reply to the mobile node with Code value BAD_AUTHENTICATION (see Section 6). If MN-AAA Authentication extension (see Section 4.2) or MN-RADIUS Authentication extension (see Setion 4.3) is present in the message, or if an NAI extension is included indicating that the mobile node belongs to a different administrative domain, the foreign agent may take actions outside the scope of this protocol specification to carry out the authentication of the mobile node. The appendix provides an example of an action that could be taken by a foreign agent. Since the Challenge extension, and the authentication extension that is used by the Mobile Node to satisfy the challenge, both follow the Mobile-Home Authentication extension whenever the latter is present, the Foreign Agent MAY remove the Challenge Extension and the applicable authentication from the Registration Request without disturbing the authentication value computed by the Mobile Node for use by the Home Agent. Perkins, Calhoun Expires 25 April 2000 [Page 3] Internet Draft Mobile IP Challenge/Response 25 October 1999 If the Foreign Agent does not remove those extensions, then the Foreign Agent SHOULD store the Challenge value as part of the pending registration request list [11]. Also in this case, the Foreign Agent MUST reject any Registration Reply message coming from the Home Agent that does not also include the Challenge Extension with the same Challenge Value that was included in the Registration Request. The Foreign Agent MUST send the rejected Registration message to the mobile node, and change the status in the Registration Reply to the value MISSING_CHALLENGE (see section 6). If the Foreign Agent does remove the Challenge extension and applicable authentication from the Registration Request message, then it SHOULD insert the Identification field from the Registration Request message along with its record-keeping information about the particular Mobile Node in order to protect against replays. 3.3. Home Agent Processing for the Challenge Extensions If the Home Agent receives a Registration Request with the MN-FA Challenge extension, and recognizes the extension, the Home Agent MUST include the Challenge extension in the Registration Reply. The Challenge Extension SHOULD be included before the Mobile-Home Authentication extension. Since the extension type for the Challenge extension is within the range 128-255, the Home Agent MUST process such a Registration Request even if it does not recognize the Challenge extension [11]. In this case, the Home Agent will send a Registration Reply to the Foreign Agent that does not include the Challenge extension. 4. Mobile IP Registration Extensions This section specifies new Mobile IP Registration Extensions that are used to satisfy a Challenge in an Agent Advertisement. 4.1. MN-FA Challenge Extension The Challenge extension to the Registration Request message is used to indicate the challenge that the mobile node is attempting to satisfy. Perkins, Calhoun Expires 25 April 2000 [Page 4] Internet Draft Mobile IP Challenge/Response 25 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 | Challenge... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The MN-FA Challenge Extension Type 132 (skippable) (see [11]) Length MUST be at least 16 Challenge The Challenge field is copied from the Challenge field found in the Agent Advertisement Challenge extension (see section 2). 4.2. MN-AAA Authentication Extension The mobile node MAY include this extension in the Registration Request. If the mobile node does not include a Mobile-Foreign Authentication extension, then it MUST include the MN-AAA Authentication extension [11] or the MN-RADIUS extension (section 4.3) whenever the Challenge extension is present. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The MN-AAA Authentication Extension Perkins, Calhoun Expires 25 April 2000 [Page 5] Internet Draft Mobile IP Challenge/Response 25 October 1999 Type 36 (not skippable) (see [11]) Length 4 plus the number of bytes in the Authenticator; MUST be at least 20. SPI Security Parameters Index Authenticator The variable length Authenticator field consists random value of at least 128 bits. The default algorithm for computation of the authenticator is MD5 [12] computed on the following data, in the order shown: Key || Preceding Mobile IP data || Type, Length, SPI || Key where the Type, Length, and SPI are as shown above. Each mobile node MUST support the ability to produce the authenticator by using MD5 as shown (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.3. MN-RADIUS Extension The mobile node MAY include this extension in the Registration Request if it has a security association with a RADIUS server. If the mobile node does not include a Mobile-Foreign Authentication extension, then it MUST include either the MN-AAA or the MN-RADIUS authentication 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: The MN-RADIUS Extension Perkins, Calhoun Expires 25 April 2000 [Page 6] Internet Draft Mobile IP Challenge/Response 25 October 1999 Type 37 (not skippable) (see [11]) Length 4 plus the number of bytes in the Authenticator; MUST be at least 20. SPI Security Parameters Index Authenticator The variable length Authenticator field consists random value of at least 128 bits. The default algorithm for computation of the authenticator is MD5 [12] computed on the following data, in the order shown: High-order byte from Challenge || Key || MD5(Preceding Mobile IP data || Type, Length, SPI) || Least-order 237 bytes from challenge where the Type, Length, and SPI are as shown above. Since the RADIUS protocol cannot carry attributes greater than 253 in size, the Preceding Mobile IP data, type, length and SPI are hashed using MD5. Finally, the least significant 237 octets of the challenge are concatenated. 5. Configurable Parameters Every Mobile IP agent supporting the extensions defined in this document SHOULD be able to configure each parameter in the following table. Each table entry contains the name of the parameter, the default value, and the section of the document in which the parameter first appears. Parameter Name Default Value Section of Document -------------- ------------- ------------------- CHALLENGE_WINDOW 2 3.2 6. Error Values Each entry in the following table contains the name of Code [11] to be returned in a Registration Reply, the value for the Code, and the section in which the error is first mentioned in this specification. Error Name Value Section of Document ---------------------- ----- ------------------- UNKNOWN_CHALLENGE 104 3.2 BAD_AUTHENTICATION 67 3.2; also see [11] MISSING_CHALLENGE 105 3.2 STALE_CHALLENGE 106 3.2 Perkins, Calhoun Expires 25 April 2000 [Page 7] Internet Draft Mobile IP Challenge/Response 25 October 1999 7. IANA Considerations The number for the Mobile IP Agent Advertisement Challenge extension (section 2) is taken from the numbering space defined for Mobile IP extensions to the ICMP Router Advertisements [4] defined in RFC 2002 [11]. The number for the MN-FA Challenge extension (section 4.1) and the MN-AAA Authentication extension (section 4.2) is taken from the numbering space defined for Mobile IP registration extensions defined in RFC 2002 [11] as extended in RFC 2356 [8]. The numbering for the extensions SHOULD NOT conflict with values specified in the Internet Draft for Route Optimization [10] or the Internet Draft for the Mobile IP Network Address Identifier Extension. The Code values specified for errors, listed in section 6, MUST NOT conflict with any other code values listed in RFC 2002, RFC 2344 [7], or RFC 2356 [8], or the abovementioned Internet Drafts. They are to be taken from the space of error values conventionally associated with rejection by the foreign agent (i.e., 64-127). 8. Security Considerations In the event that a malicious mobile node attempts to replay the authenticator for an old MN-FA Challenge, the Foreign Agent would detect it since the agent always checks whether it has recently advertised the Challenge (see section 3.2). Allowing mobile nodes with different IP addresses or NAIs to use the same Challenge value does not represent a security vulnerability, because the authentication data provided by the mobile node will be computed over data that is different (at least by the bytes of the mobile nodes' IP addresses). 9. IPv6 Considerations For use with IPv6 mobility [6], the challenge extension should be applied to Router Advertisements [9]. In order to check the response from the mobile node, the router would need to have a security relationship with either the mobile node, its home agent, or another entity within the IPv6 security infrastructure. 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 each case. Perkins, Calhoun Expires 25 April 2000 [Page 8] Internet Draft Mobile IP Challenge/Response 25 October 1999 10. Acknowledgements The authors would like to thank Tom Hiller, Mark Munson, the TIA TR45-6 WG, Gabriel Montenegro, Vipul Gupta, and Pete McCann 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-07.txt, November 1998. (work in progress). [3] Pat R. Calhoun and Charles E. Perkins. Mobile IP Network Address Identifier Extension. draft-ietf-mobileip-mn-nai-04.txt, September 1999. (work in progress). [4] Stephen E. Deering, Editor. ICMP Router Discovery Messages. RFC 1256, September 1991. [5] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller. Randomness Recommendations for Security. RFC 1750, December 1994. [6] D. Johnson and C. Perkins. Mobility Support in IPv6. draft-ietf-mobileip-ipv6-07.txt, November 1998. (work in progress). [7] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, May 1998. [8] G. Montenegro and V. Gupta. Sun's SKIP Firewall Traversal for Mobile IP. RFC 2356, June 1998. [9] T. Narten, E. Nordmark, and W. Simpson. RFC 2461: Neighbor discovery for IP Version 6 (IPv6), December 1998. Status: DRAFT STANDARD. [10] Charles E. Perkins and David B. Johnson. Route Optimization in Mobile-IP. draft-ietf-mobileip-optim-08.txt, February 1999. (work in progress). [11] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. Perkins, Calhoun Expires 25 April 2000 [Page 9] Internet Draft Mobile IP Challenge/Response 25 October 1999 [12] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, April 1992. [13] W. Simpson. RFC 1994: PPP challenge handshake authentication protocol (CHAP), August 1996. Obsoletes RFC1334. Status: DRAFT STANDARD. A. Verification Infrastructure The Challenge extensions in this protocol specification are expected to be useful to help the Foreign Agent manage connectivity for visiting mobile nodes, even in situations where the foreign agent does not have any security association with the mobile node or the mobile node's home agent. In order to carry out the necessary authentication, it is expected that the foreign agent will need the assistance of external administrative systems, which recently have come to be called AAA systems. For the purposes of this document, we call the external administrative support the "verification infrastructure". The verification infrastructure is described to motivate the design of the protocol elements defined in this document, and is not strictly needed for the protocol to work. The foreign agent is free to use any means at its disposal to verify the credentials of the mobile node. This could, for instance, rely on a separate protocol between the foreign agent and the Mobile IP home agent, and still be completely invisible to the mobile node. In order to verify the credentials of the mobile node, we imagine 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 5. For an example of another protocol that has been specified to actually carry out the challenge verification operations, see [2, 1]. After the foreign agent gets the Challenge authentication, it MAY pass the authentication to the (here unspecified) infrastructure, and await 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 contains Code value BAD_AUTHENTICATION (see Section 6), the foreign agent takes actions indicated for rejected registrations. Implicit in this picture, 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. Perkins, Calhoun Expires 25 April 2000 [Page 10] Internet Draft Mobile IP Challenge/Response 25 October 1999 +----------------------------------------------------+ | | | Verification and Key Management Infrastructure | | | +----------------------------------------------------+ ^ | ^ | | | | | | v | v +---------------+ +---------------+ | | | | | Foreign Agent | | Home Agent | | | | | +---------------+ +---------------+ Figure 5: The Verification Infrastructure 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. Perkins, Calhoun Expires 25 April 2000 [Page 11] Internet Draft Mobile IP Challenge/Response 25 October 1999 Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nortel Networks Inc. Motorola 2201 Lakeside Blvd. 1501 West Shure Drive Richardson, TX. 75082-4399 Arlington Heights, IL 60004 USA USA Phone: +1 972-684-1489 Phone: +1 847-632-3148 EMail: bpatil@nortelnetworks.com EMail: QA3445@email.mot.com Questions about this memo can be directed to: Charles E. Perkins Pat R. Calhoun Nokia Research Center Sun Microsystems Laboratories 313 Fairchild Drive 15 Network Circle Mountain View, California 94043 Menlo Park, California 94025 USA USA Phone: +1-650 625-2986 Phone: +1 650-786-7733 EMail: charliep@iprg.nokia.com EMail: pcalhoun@eng.sun.com Fax: +1 650 691-2170 Fax: +1 650-786-6445 Perkins, Calhoun Expires 25 April 2000 [Page 12]