IETF Mobile IP Working Group Charles E. Perkins INTERNET DRAFT Nokia Research Center 15 June 2002 Vijay Devarapalli Nokia Research Center SPI Option for Mobile IPv6 Authentication Data Option draft-perkins-mobileip-spi-00.txt Status of This Memo This document is a submission by the IETF Mobile IP Working Group Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@sunroof.eng.sun.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 This document specifies a new SPI (Security Parameters Index) option for use with the Binding Authorization Data option. The new SPI option allows for selection of a particular mobility security association to handle the case when several such security associations may exist between nodes exchanging messages containing a mobility header requiring authorization. The SPI value may be set during manual configuration of the security association between two nodes, for example a mobile node and its home agent, or between a mobile node and a favored correspondent node. Perkins, Devarapalli Expires 15 December 2002 [Page i]
Internet Draft SPI for Mobile IPv6 15 June 2002 1. Introduction This document specifies a new SPI (Security Parameters Index) option for use with the Binding Authorization Data option which has been defined for use with Mobile IPv6 [2]. The new SPI option allows for selection of a particular mobility security association to handle the case when several such security associations may exist between nodes exchanging messages containing a mobility header requiring authorization. The SPI value may be set during manual configuration of the security association between two nodes, for example a mobile node and its home agent, or between a mobile node and a favored correspondent node. This use of SPI closely models the existing practice for home agents and mobile nodes using Mobile IP for IPv4 [3]. 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. This section defines other terminology used that is not already defined in [2]. SPI An index identifying a security association between a pair of nodes among those available in the Mobility Security Association. 3. SPI Option Format The format of the SPI option conforms to the general format specified for Mobile IPv6 [2]. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type <To Be Assigned by IANA> Length 2 Perkins, Devarapalli Expires 15 December 2002 [Page 1]
Internet Draft SPI for Mobile IPv6 15 June 2002 SPI A 16-bit value specifying which SPI is to be used for verifying the authorization data in the Binding Authorization Data option 4. Operation and Use of the SPI Option A mobile node may have established one or more mobility security associations with the sender or intended receiver of a message containing a Binding Authorization Data option (which is present along with a Mobility Header). In such cases, the SPI option can be used to identify the particular security association which should be used to verify the authorization data in the Binding Authorization Data option. The option is required to occur immediately before the Binding Authorization Data option, to simplify processing of the latter option. Replay protection can be assured by the sending node in several ways, each affording longer effective use of the same security association identified by the SPI. When replay protection can no longer be provided, the security association SHOULD NOT be used for authorizing any future mobility header operations. See section 7 for more information. Replay protection can be assured in either of the following ways: - The node can make use of the sequence # field of the Binding Update or Binding Acknownledgement message. This allow up to 65,535 uses of the same security association. When the sequence number field rolls over, the node SHOULD NOT use the same security association for future Binding Updates or Acknowledgements. - The node can keep a hash table of values corresponding to the leading bits of the authorization data. The hash buckets can contain an arbitrary number of (longer!) values for specific instances of the Authorization data used in previous messages. The latter method works for all messages using Mobility Headers, not just the messages which have a Sequence number field. Furthermore, it works to check arbitrarily many messages against replay attempts, at the cost of using more memory than the simple sequence # counting method. The SPI feature is intended to be used just as the analogous feature for Mobile IPv4 is used today. To that end, the first 255 values Perkins, Devarapalli Expires 15 December 2002 [Page 2]
Internet Draft SPI for Mobile IPv6 15 June 2002 are reserved, and not to be used when carrying out the operations in section 5. 5. Manual Configuration The SPI option can be used to facilitate manual configuration of security associations between a mobile node and its home agent. For each security association, a configuration manager has to establish the information about the secret key and the cryptographic algorithm to be used to create the authorization data in the Binding Authorization Data option. The SPI option is to be used to allow the mobile node and home agent node to specify which of the security associations is to be used for the authorization data send with the binding message in the mobility header. Likewise, specialized correspondent nodes (e.g., servers with a special relationship with the mobile node) could have manual configuration of security associations with the mobile node, each with varying degrees of strength. The SPI option is to be used to allow the mobile node and correspondent node to specify which of the security associations is to be used for the authorization data. While nothing in this specification depends on AAA, a great deal of work has been expended to develop methods by which AAA can help to establish security associations between mobile nodes and mobility agents in Mobile IPv4. It is expected that similar methods will be developed for Mobile IPv6. The SPI option will help the use of such methods by enabling them to make better use of the Binding Authorization Data option. 6. IANA Considerations This specification reserves one number for the SPI option(see section 3) from the space of numbers for options defined in the specification for Mobile IPv6 [2]. 7. Security Considerations The option in this document allows for additional security associations to be used for authorizing Mobile IPv6 binding messages. This will encourage the use of security methods that are stronger than the existing Return Routability methods. If the same security association is used after the replay protection method is no longer guaranteed to work, then an attacker could attempt to replay one of its stored messages and the receiver would Perkins, Devarapalli Expires 15 December 2002 [Page 3]
Internet Draft SPI for Mobile IPv6 15 June 2002 not have a good way to to detect the attack. Thus, it is strongly recommended that the security association be recreated (at least by re-keying) before the replay protection method is no longer guaranteed to offer the desired protection. References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, March 2001. [3] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 3220, Internet Engineering Task Force, December 2001. Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Megisto Corp. 6000 Connection Dr. Suite 120 20251 Century Blvd Irving, TX. 75039 Germantown MD 20874 USA USA Phone: +1 972-894-6709 Phone: +1 847-202-9314 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com Questions about this memo can also be directed to the authors: Charles E. Perkins Vijay Devarapalli Communications Systems Lab Communications Systems Lab Nokia Research Center Nokia Research Center 313 Fairchild Drive 313 Fairchild Drive Mountain View, California 94043 Mountain View, California 94043 USA USA Phone: +1-650 625-2986 Phone: +1-650 625-2320 Fax: +1 650 625-2502 Fax: +1 650 625-2502 EMail: charliep@iprg.nokia.com EMail: vijayd@iprg.nokia.com Perkins, Devarapalli Expires 15 December 2002 [Page 4]