James Kempf
  Internet Draft                                         DoCoMo Labs USA
  Document: draft-ietf-mipshop-handover-key-00.txt       Rajeev Koodli
                                                         Nokia Research
  Expires: August, 2007                                  February, 2007
             Distributing a Symmetric FMIPv6 Handover Key using SEND
  Status of this Memo
     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
     The list of current Internet-Drafts can be accessed at
     The list of Internet-Draft Shadow Directories can be accessed at
     Fast Mobile IPv6 requires that a Fast Binding Update is secured
     using a security association shared between an Access Router and a
     Mobile Node in order to avoid certain attacks. In this document, a
     method for distributing a shared key to secure this signaling is
     defined. The method utilizes the RSA public key that the Mobile
     Node used to generate its Cryptographically Generated Address in
     SEND. The RSA public key is used to encrypt a shared key sent from
     the Access Router to the Mobile Node prior to handover. The
     ability of the Mobile Node to decrypt the shared key verifies its
     possession of the private key corresponding to the CGA public key
     used to generate the address. This allows the Mobile Node to use
     the shared key to sign and authorize the routing changes triggered
     by the Fast Binding Update.
  Table of Contents
     Kempf & Koodli          Expires August, 2007         [Page 1]

     Internet Draft              FMIP Security           February, 2007
     1.0 Introduction......................................................2
     2.0 Overview of the Protocol..........................................3
     3.0 Handover Key Provisioning and Use.................................3
     4.0 Message Formats...................................................6
     5.0 Security Considerations...........................................8
     6.0 IANA Considerations...............................................8
     7.0 Normative References..............................................8
     8.0 Informative References............................................9
     9.0 Author Information................................................9
     10.0 IPR Statements....................................................9
     11.0 Disclaimer of Validity...........................................10
     12.0 Copyright Statement..............................................10
     13.0 Acknowledgment...................................................10
  1.0 Introduction
     In Fast Mobile IPv6 (FMIPv6) [FMIP], a Fast Binding Update (FBU)
     is sent from a Mobile Node (MN), undergoing IP handover, to the
     previous Access Router (AR). The FBU causes a routing change so
     traffic sent to the MN's previous care-of address on the previous
     AR is tunneled to the new care-of address on the new AR. The
     previous AR requires that only an authorized MN be able to change
     the routing for the old care-of address. If such authorization is
     not established, an attacker can redirect a victim MN's traffic at
     In this document, a lightweight mechanism is defined by which a
     key for securing FMIP can be provisioned on the MN. The mechanism
     utilizes the RSA public key with which the MN generates a care-of
     Cryptographically Generated Address (CGA) in the SEND protocol
     [SEND] to encrypt a shared handover key between the MN and the AR.
     The shared handover key itself is established between the AR and
     the MN at some arbitrary time prior to handover. In SEND, the CGA
     public key is used to authorize possession of an address, and,
     thereby, to perform operations associated with the address. The
     connection between the address and the CGA public/private key pair
     is called the key pair's CGA property. The shared handover key
     derives its authorization potential from the ability of the MN to
     decrypt the handover key using the CGA private key [CGA]. The
     timing of the handover key provisioning is independent of the
     handover timing, thus eliminating any potential additional latency
     in handover.
     Handover keys are an instantiation of the purpose built key
     architectural principle [PBK].
  1.1 Terminology
     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
     NOT",  "SHOULD",  "SHOULD  NOT",  "RECOMMENDED",    "MAY",  and
     Kempf & Koodli           Expires August, 2007        [Page 2]

     Internet Draft              FMIP Security           February, 2007
     "OPTIONAL" in this document are to be interpreted as described in
     RFC 2119 [RFC2119].
     In addition, the following terminology is used:
     CGA public key
            Public key used to generate the CGA according to RFC 3972
     CGA private key
            Private key corresponding to the CGA public key.
  2.0 Overview of the Protocol
  2.1 Brief Review of SEND
     SEND protects against a variety of threats to local link address
     resolution (also known as Neighbor Discovery) and last hop router
     (AR) discovery in IPv6 [RFC3756]. These threats are not exclusive
     to wireless networks, but they generally are easier to mount on
     certain wireless networks because the link between the access
     point and MN can't be physically secured.
     SEND utilizes CGAs in order to secure Neighbor Discovery signaling
     [CGA]. Briefly, a CGA is formed by hashing together the IPv6
     subnet prefix for a node's subnet, a random nonce, and an RSA
     public key, called the CGA public key. The CGA private key is used
     to sign a Neighbor Advertisement (NA) message sent to resolve the
     link layer address to the IPv6 address. The combination of the CGA
     and the signature on the NA proves to a receiving node the
     sender's  authorization  to  claim  the  address.  The  node  may
     opportunistically generate one or several keys specifically for
     SEND, or it may use a certified key that it distributes more
  2.2 Protocol Overview
     The protocol utilizes the SEND secured RS/RA exchange to transport
     an encrypted, shared handover key from the AR to the MN. When the
     AR receives an RS from an MN having a CGA source address and
     including a CGA Option and SEND Signature Option, it includes a
     Handover Key Option in the unicast RA sent as a reply. The MN
     ignores the option if it does not support SEND handover keys;
     otherwise, the option is processed and utilized by the MN to
     provide address authorization on an FBU when the MN moves to
     another AR.
  3.0 Handover Key Provisioning and Use
  3.1 Sending Router Solicitations
     Kempf & Koodli           Expires August, 2007        [Page 3]

     Internet Draft              FMIP Security           February, 2007
     At some time prior to handover, the MN MUST send an IPv6 Router
     Solicitation (RS) [RFC2461] exactly as specified for IPv6 Router
     Discovery. A CGA for the MN MUST be the source address on the
     packet, and the MN MUST include the SEND CGA Option and SEND
     Signature Option with the packet, as specified in [SEND]. The MN
     indicates that it wants to receive a shared handover key by
     setting the handover authentication Algorithm Type (AT) extension
     field in the CGA Option (described in Section 4.2) to the MN's
     preferred authentication algorithm.
  3.2 Receiving Router Solicitations and Sending Router Advertisements
     When an FMIPv6 capable AR with SEND receives an RS from a MN
     including a SEND Signature Option and a CGA Option with the AT
     field set, and the source address is a CGA, the AR MUST first
     validate the RS using SEND as described in RFC 3971. If the RS can
     not be validated, the AR MUST NOT include a Handover Key Option in
     the reply. The AR also MUST NOT change any existing key record for
     the address, since the message may be an attempt by an attacker to
     disrupt communications for a legitimate MN. The AR SHOULD proceed
     to process such an RS as described in [SEND].
     If RS can be validated, the AR MUST then determine whether the CGA
     already has an associated shared handover key. If the CGA has an
     existing handover key, the AR MUST return the existing handover
     key to the MN. If the CGA does not have a shared handover key, the
     AR MUST construct a shared handover key as described in Section
     3.6. The AR MUST encrypt the handover key with the MN's CGA public
     key. The AR MUST insert the encrypted handover key into a Handover
     Key Option (described in Section 4.1) and MUST attach the Handover
     Key Option to the RA. The AR SHOULD set the AT field of the
     Handover Key Option to the MN's preferred algorithm type indicated
     in the AT field of the CGA Option, if it is supported; otherwise,
     the  AR  MUST  select  an  authentication  algorithm  which  is  of
     equivalent strength and set the field to that. The RA is then
     unicast back to the MN at the CGA destination address. The
     handover key MUST be stored by the AR for future use, indexed by
     the CGA, and the authentication algorithm type MUST be recorded
     with the key.
  3.3 Receiving Router Advertisements
     Upon receipt of one or more RAs secured with SEND and having the
     Handover Key Option, the MN MUST first validate the RAs as
     described in RFC 3971. From the RAs that validate, the MN SHOULD
     choose an RA with an AT flag in the Handover Key Option indicating
     an authentication algorithm that the MN supports, decrypt the
     handover key using its CGA private key, and store the handover key
     for later use along with the algorithm type. If more than one
     router responds to the RS, the MN MAY keep track of all such keys.
     The MN MUST use the returned algorithm type indicated in the RA.
     The MN MUST index the handover keys with the AR's IPv6 address, to
     which the MN later sends the FBU, and the CGA. This allows the MN
     to select the proper key when communicating with a previous AR. If
     Kempf & Koodli           Expires August, 2007        [Page 4]

     Internet Draft              FMIP Security           February, 2007
     none of the RAs contains an algorithm type indicator corresponding
     to an algorithm the MN supports, the MN MAY resend the RS
     requesting a different algorithm, but to prevent bidding down
     attacks from compromised routers, the MN SHOULD NOT request an
     algorithm that is weaker than its original request.
  3.4 Sending FBUs
     When the MN needs to signal the previous AR using an FMIPv6 FBU,
     the  MN  MUST  utilize  the  handover  key  and  the  corresponding
     authentication algorithm to generate an authenticator for the
     message. The MN MUST select the appropriate key for the AR using
     the AR's address and the care-of CGA. The MN MUST generate the MAC
     using the handover key and the appropriate algorithm, then include
     the MAC in the FBU message as defined by the FMIPv6 document. As
     specified by FMIPv6 [FMIP], the MN MUST include the care-of CGA in
     a Home Address Option. The FMIPv6 document provides more detail
     about authenticator algorithm selection and the construction of
     the authenticator.
  3.5 Receiving FBUs
     When the AR receives an FBU message containing an authenticator,
     the AR MUST find the corresponding handover key using the care-of
     CGA in the Home Address Option as the index. If a handover key is
     found, the AR MUST utilize the handover key and the appropriate
     algorithm to verify the authenticator. The FMIPv6 document [FMIP]
     provides more detail on how the AR processes an FBU containing an
  3.6 Key Generation and Lifetime
     The AR MUST randomly generate a key having sufficient strength to
     match the authentication algorithm. Some authentication algorithms
     specify a required key size. The AR MUST generate a unique key for
     each CGA public key, and SHOULD take care that the key generation
     is uncorrelated between handover keys, and between handover keys
     and CGA keys. The actual algorithm used to generate the key is not
     important for interoperability since only the AR generates the
     key; the MN simply uses it.
     The AR SHOULD NOT discard the handover key immediately after use
     if it is still valid. It is possible that the MN may undergo rapid
     movement to another AR prior to the completion of Mobile IPv6
     binding update on the new AR, and the MN MAY as a consequence
     initialize  another,  subsequent  handover  optimization  to  move
     traffic from the previous AR to another new AR. The default time
     for keeping the key valid corresponds to the default time during
     which forwarding from the previous AR to the new AR is performed
     for FMIP. The FMIPv6 document [FMIP] provides more detail about
     the default FMIP forwarding time default.
     If the MN returns to a previous AR prior to the expiration of the
     handover key, the AR MAY send and the MN MAY receive the same
     Kempf & Koodli           Expires August, 2007        [Page 5]

     Internet Draft              FMIP Security           February, 2007
     handover key as was previously returned, if the MN generates the
     same CGA for its care-of address. However, the MN MUST NOT assume
     that it can continue to use the old key without actually receiving
     the handover key again from the router in an RA. The MN SHOULD
     discard the handover key after MIPv6 binding update is complete on
     the new AR. The previous AR MUST discard the key after FMIPv6
     forwarding for the previous care-of address times out.
  4.0 Message Formats
  4.1 Handover Key Option
     The Handover Key Option is a standard IPv6 Neighbor Discovery
     option in TLV format.
      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     |        Key Length             |
     |              Encrypted Handover Key . . .
       Type:          To be assigned by IANA.
       Length:     The length of the option in units of 8 octets,
                      including the Type and Length fields. The value 0
                      is invalid. The receiver MUST discard a message
                      that contains this value.
       Key Length:   Length of the encrypted handover key, in units of
       Encrypted Handover Key:
                     The encrypted handover key.
     The option is padded to an 8 octet boundary, as required for IPv6
     Neighbor Discovery Protocol options.
     As an example, suppose the authenticator consists of an AES
     encrypted SHA-1 message digest. Since AES has 128 bit keys, the
     value of the length field is 24 and the value of the Key Length
     field is 16. The 16 octets of the key are followed by 4 octets of
     zeros as padding, to round out the length to a multiple of 8.
  4.2 Handover Authentication Algorithm Type Field
     Handover keys extend the SEND CGA Option to include an Algorithm
     Type (AT) field. This allows the MN to ask for and the AR to
     acknowledge a particular algorithm for FBU authentication.
     Kempf & Koodli           Expires August, 2007        [Page 6]

     Internet Draft              FMIP Security           February, 2007
      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     |   Pad Length  | AT    | Resrvd|
     |                                                               |
     .                                                               .
     .                        CGA Parameters                         .
     .                                                               .
     |                                                               |
     |                                                               |
     .                                                               .
     .                           Padding                             .
     .                                                               .
     |                                                               |
       Type:         11
       Length:     The length of the option, including the Type and
                     Length fields, in units of 8 octets. The value 0
                     is invalid. The receiver MUST discard a message
                     that contains this value.
       Pad Length:   The number of padding octets beyond the end of the
                     CGA  Parameters  field  but  within  the  length
                     specified by the Length field. Padding octets MUST
                     be  set  to  zero  by  senders  and  ignored  by
       AT:           A 4-bit algorithm type field describing the
                     algorithm used by FMIPv6 to calculate the
                     authenticator. See [FMIP] for details.
       Reserved:    A 4-bit field reserved for future use.  The value
                     MUST be initialized to zero by the sender and MUST
                     be ignored by the receiver.
       CGA Parameters:
                     A  variable-length  field  containing  the  CGA
                     Parameters data structure described in Section 4
                     of [CGA]. This specification requires that if both
                     the CGA option and the RSA Signature option are
                     present, then the public key found from the CGA
                     Parameters field in the CGA option MUST be that
                     referred  by  the  Key  Hash  field  in  the  RSA
                     Signature  option.    Packets  received  with  two
                     different keys MUST be silently discarded.  Note
                     that a future extension may provide a mechanism
     Kempf & Koodli           Expires August, 2007        [Page 7]

     Internet Draft              FMIP Security           February, 2007
                     allowing the owner of an address and the signer to
                     be different parties.
      Padding:      A variable-length field making the option length a
                     multiple  of  8,  containing  as  many  octets  as
                     specified in the Pad Length field.
     As an example of the calculation for the CGA Parameters field,
     suppose a 128 byte RSA key is used for the CGA public key. Then
     the Length field is 160 and the Pad Length field is 3. The length
     of the CGA Parameters field is then 160 - 3 - 4 = 153.
  5.0 Security Considerations
     This document describes a key distribution protocol for the FMIPv6
     handover  optimization  protocol.  The  key  distribution  protocol
     utilizes the CGA public key of SEND to bootstrap a shared key for
     authorizing changes due to handover associated with the MN's
     former address on the wireless interface of the AR. General
     security  considerations  involving  CGAs  apply  to  the  protocol
     described in this document, see [CGA] for a discussion of security
     considerations around CGAs.
     This protocol is subject to the same risks from replay attacks and
     DoS attacks using the RS as the SEND protocol [SEND]. The measures
     recommended in RFC 3971 for mitigating replay attacks and DoS
     attacks apply here as well. An additional consideration involves
     when to generate the handover key. To avoid state depletion
     attacks, the handover key MUST NOT be generated prior to SEND
     processing verifying the RS. This includes processing of the time
     stamp option to ensure that the RS has not been replayed. State
     depletion attacks are possible if this ordering is not respected.
     For other FMIPv6 security considerations, please see the FMIPv6
     document [FMIP].
  6.0 IANA Considerations
     A new IPv6 Neighbor Discovery option, the Handover Key Option, is
     defined, and requires a IPv6 Neighbor Discovery option type code
     from IANA.
  7.0 Normative References
     [FMIP] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC
            4068, July 2005.
     [SEND] Arkko, J., editor, Kempf, J., Zill, B., and Nikander, P.,
            "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
     [CGA] Aura, T., "Cryptographically Generated Addresses", RFC 3972,
           March 2005.
     Kempf & Koodli           Expires August, 2007        [Page 8]

     Internet Draft              FMIP Security           February, 2007
     [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, March 1997.
     [RFC3756] Nikander, P., editor, Kempf, J., and Nordmark, E., "
               IPv6 Neighbor Discovery (ND) Trust Models and Threats",
               RFC 3756, May 2004.
     [RFC2461] Narten, T., and Nordmark, E., "Neighbor Discovery for IP
               version 6 (IPv6)", RFC 2461, December 1998.
     [RFC3775] Johnson, D., Perkins, C., and Arkko, J., "Mobility
               Support in IPv6", RFC 3775, June, 2004.
  8.0      Informative References
      [PBK] Bradner, S., Mankin, A., and Schiller, J., "A Framework for
            Purpose-Built  Keys  (PBK)",  Internet  Draft,  work  in
  9.0 Author Information
     James Kempf                     Phone: +1 408 451 4711
     DoCoMo Labs USA                 Email: kempf@docomolabs-usa.com
     181 Metro Drive
     Suite 300
     San Jose, CA
     Rajeev Koodli                   Phone: +1 650 625 2359
     Nokia Research Center           Fax: +1 650 625 2502
     313 Fairchild Drive             Email: Rajeev.Koodli@nokia.com
     Mountain View, CA
  10.0  IPR Statements
     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.
     Kempf & Koodli           Expires August, 2007        [Page 9]

     Internet Draft              FMIP Security           February, 2007
     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
  11.0  Disclaimer of Validity
     This document and the information contained herein are provided on
  12.0  Copyright Statement
     Copyright (C) The IETF Trust (2007).
     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.
  13.0  Acknowledgment
     Funding for the RFC Editor function is currently provided by the
     Internet Society.
     Kempf & Koodli           Expires August, 2007        [Page 10]