IETF Mobile IP Working Group Charles E. Perkins INTERNET-DRAFT Nokia Research Center 21 October 2004 Precomputable Binding Management Key Kbm for Mobile IPv6 Status of This Memo This document is a submission by the IETF MIPv6 Working Group Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mip6@ietf.org mailing list. This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. Perkins Expires 21 April 2005 [Page i] INTERNET-DRAFT Precomputable Kbm 21 October 2004 1. Precomputing a Binding Management Key (Kbm) A mobile node and a correspondent node may preconfigure data useful for creating a Binding Management Key (Kbm), which can then be used for authorizing binding management messages, especially Binding Update and Binding Acknowledgement messages. This data is as follows: - A shared key (Kcn) used to generate keygen tokens, at least 20 octets long - A nonce for use when generating the care-of keygen token - A nonce for use when generating the home keygen token The keygen tokens MUST be generated from Kcn and the nonces as specified in Mobile IPv6 [1] return routability. Likewise, the binding management key Kbm must subsequently be generated from the keygen tokens in the same way as specified in Mobile IPv6 [1]. The preconfigured data is associated to the mobile node's home address. Replay protection for Binding Update messages using Kbm computed from the preconfigured data depends upon the value of the sequence number field in the Binding Update. If the correspondent node does not maintain information about the recently used values of that field, then there may be an opportunity for a malicious node to replay old Binding Update messages and fool the correspondent node into routing towards an old care-of address. For this reason, a correspondent node that uses a precomputable Kbm also MUST keep track of the most recent value of the Sequence Number field of Binding Update messages using the precomputable Kbm value. When a Binding Update is to be authenticated using such a precomputable binding key (Kbm), the Binding Authorization Data suboption MUST be present. The Nonce Indices option SHOULD NOT be present. If it is present, the nonce indices supplied MAY be ignored and are not included as part of the calculation for the authentication data, which is to be carried exactly as specified in [1]. 2. Applicability Statement Preconfigured shared keys (such as Kcn) between a mobile node and a correspondent node are useful in several specific scenarios: - mobile node and correspondent node are administered within the same domain, and the correspondent node has good reason to trust the actions of the mobile node Perkins Expires 21 April 2005 [Page 1] INTERNET-DRAFT Precomputable Kbm 21 October 2004 - the correspondent node has some guarantee that the mobile node will behave properly (perhaps by contractual agreement) - the method of assignment for keys between the correspondent node and mobile node results in a stronger security association than what can be provided by the Return Routability procedure. - diagnostic procedures - software development and testing Generally speaking, the required level of trust that the correspondent node needs for enabling a precomputable Kbm with a mobile node is more often found within relatively small, closed groups of users who are personally familiar with each other, or who have some external basis for establishing trustworthy interactions. 3. Security Considerations A correspondent node and a mobile node MAY use a precomputable binding management key (Kbm) to manage the authentication requirements for binding cache management messages. Such keys must be handled carefully to avoid inadvertent exposure to the threats outlined in [2]. A mobile node MUST use a different value for Kcn for each node in its Binding Update List, and a correspondent node MUST ensure that every mobile node uses a different value of Kcn. This ensures that the sender of a Binding Update can always be uniquely determined. This is necessary, as this authorization method does not provide any guarantee that the given care-of address is legitimate. For the same reason, this method SHOULD only be applied between nodes that are under the same administration. The return routability procedure is RECOMMENDED for all general use and MUST be the default, unless the user explicitly overrides this by entering the abovementioned preconfigured data for a particular peer. Replay protection for the Binding Authorization Data option authentication mechanism is provided by the Sequence Number field of the Binding Update. This method of providing replay protection fails when the Binding Update sequence numbers cycle through the 16 bit counter (i.e., not more than 65,536 distinct uses of Kbm for any particular care-of address), or if the sequence numbers are not protected against reboots. If the mobile node were to send a fresh Binding Update to its correspondent node every hour, 24 hours a day, every day of the year, and utilize the same care-of address every time, this would require changing keys every 7 years. Even if the mobile node were to do so every minute, this would provide protection for over a month. Given typical mobility patterns, there is little danger of replay problems; nodes for which problems might arise are Perkins Expires 21 April 2005 [Page 2] INTERNET-DRAFT Precomputable Kbm 21 October 2004 expected to use methods other than manual configuration for Kcn and the associated nonces. When the sequence number field rolls over, the parties SHOULD configure a new value for Kcn, so that new Kbm values will be computed. If a correspondent node does NOT keep track of the Sequence Number for Binding Update messages from a particular mobile node, then the correspondent node could be fooled into accepting an old value for the mobile node's care-of address. In the unlikely event that this address was reallocated to another IPv6 node in the meantime, that IPv6 node would then be vulnerable to unwanted traffic emanating from the correspondent node. In order to circumvent this possibility, correspondent nodes are mandated to keep track of the most recent Sequence Number value in a Binding Update message from the mobile node. There is no upper bound on the lifetime defined for the precomputable Kbm. As noted, the key is very, very likely to be quite secure over the lifetime of the security association and usefulness of applications between a mobile node and correspondent node that fit the terms specified in section 2. 4. IANA Considerations No new protocol numbers are required. 5. Acknowledgement Thanks are due to everyone who reviewed the discussion of issue #146. References [1] D. Johnson, C. Perkins, and J. Arkko. Mobility support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, May 2003. [2] P. Nikander, T. Aura, J. Arkko, G. Montenegro, and E. Nordmark. Mobile IP version 6 Route Optimization Security Design Background. Internet Draft, Internet Engineering Task Force, June 2003. The first citation is normative, and the second citation is informative only. Perkins Expires 21 April 2005 [Page 3] INTERNET-DRAFT Precomputable Kbm 21 October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Perkins Expires 21 April 2005 [Page 4] INTERNET-DRAFT Precomputable Kbm 21 October 2004 Author's Address Questions about this document can also be directed to the author: Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Phone: +1 650 625-2986 Fax: +1 650 625-2502 E-mail: charles.perkins@nokia.com Perkins Expires 21 April 2005 [Page 5]