IETF Mobile IP Working Group                          Charles E. Perkins
INTERNET-DRAFT                                     Nokia Research Center
                                                             21 May 2005

   Securing Mobile IPv6 Route Optimization Using a Static Shared Key

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 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 becomes aware will be disclosed, in accordance with
   Section 6 of BCP 79.

   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 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

   The list of Internet-Draft Shadow Directories can be accessed at


   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 November 2005                 [Page i]

INTERNET-DRAFT       Shared Data for Precomputable Kbm       21 May 2005

1. Introduction

   This specification introduces an alternative, low-latency security
   mechanism for protecting signaling related to the route optimization
   in Mobile IPv6.  The default mechanism specified in [1] uses a
   periodic return routability test to verify both the "right" of
   the mobile node to a use a specific home address, as well as the
   validity of the claimed care-of address.  This mechanism requires no
   configuration and no trusted entities beyond the mobile node's home

   The mechanism specified in this document, however, requires
   the configuration of a shared secret between mobile node and
   its correspondent node.  As a result, messages relating to the
   routability tests can be omitted, leading to significantly smaller
   latency.  In addition, the right to use a specific address is
   assured in a stronger manner than in [1].  On the other hand, the
   applicability of this mechanisms is limited due to the need for
   pre-configuration.  This mechanism is also limited to use only in
   scenarios where mobile nodes can be trusted to not misbehave, as the
   validity of the claimed care-of addresses is not verified.

2. 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

    -  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

Perkins                Expires 21 November 2005                 [Page 1]

INTERNET-DRAFT       Shared Data for Precomputable Kbm       21 May 2005

   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].

3. 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

    -  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.

4. 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

Perkins                Expires 21 November 2005                 [Page 2]

INTERNET-DRAFT       Shared Data for Precomputable Kbm       21 May 2005

   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 aforementioned
   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), 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, 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 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

   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

   There is no upper bound on the lifetime defined for the precomputable
   Kbm.  As noted, the key is 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 3.

5. IANA Considerations

   No new protocol numbers are required.

Perkins                Expires 21 November 2005                 [Page 3]

INTERNET-DRAFT       Shared Data for Precomputable Kbm       21 May 2005

6. Acknowledgement

   Thanks are due to everyone who reviewed the discussion of issue #146.
   Thanks to Jari Arkko for supplying text for the Introduction.


   [1] D. Johnson, C. Perkins, and J. Arkko.  Mobility Support in IPv6.
       Request for Comments (Proposed Standard), Internet Engineering
       Task Force, July 2004.

   [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 November 2005                 [Page 4]

INTERNET-DRAFT       Shared Data for Precomputable Kbm       21 May 2005

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

   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

Disclaimer of Validity

   This document and the information contained herein are provided

Copyright Statement

   Copyright (C) The Internet Society (2005).  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 November 2005                 [Page 5]

INTERNET-DRAFT       Shared Data for Precomputable Kbm       21 May 2005

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

     Phone:  +1 650 625-2986
     Fax:  +1 650 625-2502

Perkins                Expires 21 November 2005                 [Page 6]