James
Network Working Group                                           J. Kempf
  Internet Draft
Request for Comments: 5108                               DoCoMo Labs USA
  Document: draft-ietf-mipshop-handover-key-03.txt       Rajeev
Category: Standards Track                                      R. Koodli
  Intended Status: Proposed Standard
                                           Nokia-Siemens Research Center
  Expires: May,
                                                           January 2008                                     November, 2007

 Distributing a Symmetric FMIPv6 Fast Mobile IPv6 (FMIPv6) Handover Key using SEND
                     (draft-ietf-mipshop-handover-key-03.txt)
                   SEcure Neighbor Discovery (SEND)

Status of this 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

   This document specifies an Internet standards track protocol for the
   Internet Engineering
     Task Force (IETF), its areas, community, and its working groups.  Note that
     other   groups   may   also   distribute   working   documents   as
     Internet-Drafts.

     Internet-Drafts are draft documents valid requests discussion and suggestions for a maximum
   improvements.  Please refer to the current edition of six
     months the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   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 status of current Internet-Drafts can be accessed at
     http://www.ietf.org/1id-abstracts.html

     The list this protocol.  Distribution of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html. this memo is unlimited.

Abstract

   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 provisioning a shared key from the Access Router to the Mobile
   Node is defined to protect this signaling.  The Mobile Node generates
   a public/private key pair using the same public key algorithm as for
   SEND (RFC 3971).  The Mobile Node sends the public key to the Access
   Router.  The Access Router encrypts a shared handover key using the
   public key and sends it back to the Mobile Node.  The Mobile Node
   decrypts the shared handover key using the matching private key, and
   the handover key is then available for generating an authenticator on
   a Fast Binding Update.  The Mobile Node and Access Router use the
   Router Solicitation for Proxy Advertisement and Proxy Router
   Advertisement from Fast Mobile IPv6 for the key exchange.  The key
   exchange messages are required to have SEND security; that is, the
   source address is a Cryptographically Generated Address (CGA) and the
   messages are signed using the CGA private key of the sending node.
   This allows the Access Router, prior to providing the shared handover
   key, to verify the authorization of the Mobile Node to claim the
   address so that the previous care-of CGA in the Fast Binding Update
   can act as the name of the key.

Table of Contents

     1.0 Introduction.............................................2
     2.0

   1. Introduction ....................................................2
      1.1. Terminology ................................................3
   2. Overview of the Protocol.................................3
     3.0 Protocol ........................................3
      2.1. Brief Review of SEND .......................................3
      2.2. Protocol Overview ..........................................4
   3. Handover Key Provisioning and Use........................4
     4.0 Use ...............................4
      3.1. Sending Router Solicitations for Proxy Advertisement .......4
      3.2. Receiving Router Solicitations for Proxy
           Advertisement and Sending Proxy Router Advertisements ......5
      3.3. Receiving Proxy Router Advertisements ......................6
      3.4. Sending FBUs ...............................................7
      3.5. Receiving FBUs .............................................7
      3.6. Key Generation and Lifetime ................................7
      3.7. Protocol Constants .........................................8
   4. Message Formats..........................................7
     5.0 Formats .................................................8
      4.1. Handover Key Request Option ................................8
      4.2. Handover Key Reply Option .................................10
   5. Security Considerations.................................10
     6.0 Considerations ........................................11
   6. IANA Considerations.....................................10
     7.0 Considerations ............................................11
   7. References .....................................................12
      7.1. Normative References....................................10
     8.0 References ......................................12
      7.2. Informative References..................................11
     9.0 Author Information......................................11
     10.0 IPR Statements.........................................11
     11.0 Disclaimer of Validity.................................12
     12.0 Copyright Statement....................................12
     13.0 Acknowledgment.........................................12

  1.0 References ....................................12

1.  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's link is
   tunneled to the new care-of address on the new AR's link.  Only a an MN
   authorized to claim the address should be able to change the routing
   for the previous care-of address.  If such authorization is not
   established, an attacker can redirect a victim MN's traffic at will.

   In this document, a lightweight mechanism is defined by which a
   shared handover key for securing FMIP can be provisioned on the MN by
   the AR.  The mechanism utilizes SEND [SEND] and an additional
   public/private key pair, generated on the MN using the same public
   key algorithm as SEND, to encrypt/decrypt a shared handover key sent
   from the AR to the MN.  The key provisioning occurs at some arbitrary
   time prior to handover, thereby relieving any performance overhead on
   the handover process.  The message exchange between the MN and AR to
   provision the handover key is required to be protected by SEND; that
   is, the source address for the key provisioning messages must be a
   CGA and the messages must be signed with the CGA private key.  This
   allows the AR to establish the MN's authorization to operate on the
   CGA.  The AR uses the CGA to name the handover key.  The SEND key
   pair is, however, independent from the handover encryption/decryption
   key pair and from the actual handover key.  Once the shared handover
   key has been established, when the MN undergoes IP handover, the MN
   generates an authorization MAC Message Authentication Code (MAC) on the
   FBU.  The previous care-of CGA included in the FBU is used by the AR
   to find the right handover key for checking the authorization.

   Handover keys are an instantiation of the purpose built key
   architectural principle [PBK].

  1.1

1.1.  Terminology

   The key words "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 [RFC2119].

   In addition, the following terminology is used:

   CGA public key

          Public key used to generate the CGA according to RFC 3972
          [CGA].

   CGA private key

          Private key corresponding to the CGA public key.

   Handover key encryption public key

          Public key generated by the MN and sent to the current AR to
          encrypt the shared handover key key.

   Handover key encryption private key

          Private key corresponding to handover key encryption public
          key, held by the MN

  2.0 MN.

2.  Overview of the Protocol

  2.1

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

  2.2

2.2.  Protocol Overview

   The protocol utilizes the SEND secured Router Solicitation for Proxy
   Advertisement (RtSolPr)/Proxy Router Advertisement (PrRtAdv) [FMIP]
   exchange between the MN and the AR to transport an encrypted, shared
   handover key from the AR to the MN.  First, the MN generates the
   necessary key pair and associated CGA addresses so that the MN can
   employ SEND.  Then  Then, the MN generates a public/private key pair for
   encrypting/decrypting the shared handover key, using the same public
   key algorithm as was used for SEND.  The MN then sends a RtSolPr
   message with a Handover Key Request Option containing the handover
   key encryption public key.  The source address of the RtSolPr message
   is the MN's care-of CGA on the AR's link, the RtSolPr message is
   signed with the MN's CGA key, and contains the CGA Parameters option,
   in accordance with RFC 3971 [SEND].  The AR verifies the message
   using SEND, then utilizes the handover key encryption public key to
   encrypt a shared handover key, which is included with the PrRtAdv in
   the Handover Key Reply Option.  The MN decrypts the shared handover
   key and uses it to establish an authorization MAC when it sends an
   FBU to the previous AR.

  3.0

3.  Handover Key Provisioning and Use

  3.1

3.1.  Sending Router Solicitations for Proxy Advertisement

   At some time prior to handover, the MN MUST generate a handover key
   encryption public/private key pair, using exactly the same public key
   algorithm with exactly the same parameters (key size, etc.) as for
   SEND [SEND].  The MN can reuse the key pair on different access
   routers but MUST NOT use the key pair for any other encryption or for
   signature operation.  In order to prevent cryptanalysis, the key pair
   SHOULD be discarded after either a duration of HKEPK-LIFETIME or
   HKEPK-HANDOVERS number of handovers, whichever occurs first.  See
   Section 3.7 for definitions of protocol constants.

   The MN MUST send a Router Solicitation for Proxy Advertisement
   (RtSolPr) containing a Handover Key Request Option with the handover
   encryption public key.  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 SEND
   signature covers all fields in the RtSolPr, including the 128 bit
   source and destination addresses and ICMP checksum as described in
   RFC 3971, except for the Signature Option itself.  The MN also sets
   the handover authentication Algorithm Type (AT) extension field in
   the Handover Key Request Option to the MN's preferred FBU
   authentication algorithm.  The SEND Nonce MUST also be included for
   anti-replay protection.

  3.2

3.2.  Receiving Router Solicitations for Proxy Advertisement and Sending
      Proxy Router Advertisements

   When an FMIPv6 capable AR with SEND receives a RtSolPr from a MN
   protected with SEND and including a Handover Key Request Option, the
   AR MUST first validate the RtSolPr using SEND as described in RFC
   3971.  If the RtSolPr can not be validated, the AR MUST NOT include a
   Handover Key Reply 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 respond to the RtSolPr but MUST NOT perform handover
   key provisioning.

   If the RtSolPr can be validated, the AR MUST then determine whether
   the CGA is already associated with a shared handover key.  If the CGA
   is associated with 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 handover key encryption public key included in the Handover Key
   Request Option.  The AR MUST insert the encrypted handover key into a
   Handover Key Reply Option and MUST attach the Handover Key Reply
   Option to the PrRtAdv.  The lifetime of the key, HK-LIFETIME, MUST
   also be included in the Handover Key Reply Option.  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 Handover Key Request
   Option, if it is supported; otherwise, the AR MUST select an
   authentication algorithm which that is of equivalent strength or stronger stronger,
   and set the field to that.  The AR MUST also include the SEND nonce
   from the RtSolPr for anti-
     replay anti-replay protection.  The AR MUST use the CGA constructed from its
     certified key as the source address have a
   certificate suitable for the PrRtAdv a SEND-capable router, support SEND
   certificate discovery, and include a SEND CGA Option and a SEND
   Signature Option  with in the  SEND
     signature of PrRtAdv messages it sends.  Similarly, the message.
   mobile nodes MUST be configured with one or more SEND trust anchors
   so that they can verify these messages.  The SEND signature covers
   all fields in the PrRtAdv, including the  128  bit 128-bit source and
   destination addresses and ICMP checksum as described in RFC 3971,
   except for the Signature Option itself.  The PrRtAdv is then unicast
   back to the MN at the MN's care-of CGA that was the source address on
   the RtSolPr.  The handover key MUST be stored by the AR for future
   use, indexed by the CGA, and the authentication algorithm type (i.e.,
   the resolution of the AT field processing) and HK-LIFETIME MUST be
   recorded with the key.

  3.3

3.3.  Receiving Proxy Router Advertisements

   Upon receipt of one or more PrRtAdvs secured with SEND and having the
   Handover Key Reply Option, the MN MUST first validate the PrRtAdvs as
   described in RFC 3971. Normally  Normally, the MN will have obtained the
   router's certification path to validate an RA prior to sending the
   PrRtSol and the MN MUST check to ensure that the key used to sign the
   PrRtAdv is the router's certified public key.  If the MN does not
   have the router's certification path cached, it MUST use the SEND
   CPS/CPA messages to obtain the certification path to validate the
   key.  If a certified key from the router was not used to sign the
   message, the message MUST be dropped.

   From the messages that validate, the MN SHOULD choose one with an AT
   flag in the Handover Key Reply Option indicating an authentication
   algorithm that the MN supports.  From that message, the MN MUST
   determine which handover key encryption public key to use in the
   event the MN has more than one.  The MN finds the right public key to
   use by matching the SEND nonce from the RtSolPr.  If no such match
   occurs, the MN MUST drop the PrRtAdv.  The MN MUST use the matching
   private key to decrypt the handover key using its handover key
   encryption private key, and store the handover key for later use,
   named with the AR's CGA, along with the algorithm type and
   HK-LIFETIME.  The MN MUST use the returned algorithm type indicated
   in the PrRtAdv.  The MN MUST index the handover keys with the AR's
   IPv6 address, to which the MN later sends the FBU, and the MN's CGA
   to which the handover key applies.  This allows the MN to select the
   proper key when communicating with a previous AR. Prior to
   HK-LIFETIME expiring, the MN MUST request a new key from the AR if
   FMIPv6 service is still required from the router.

   If more than one router responds to the RtSolPr, the MN MAY keep
   track of all such keys.  If none of the PrRtAdvs contains an
   algorithm type indicator corresponding to an algorithm the MN
   supports, the MN MAY re-send the RtSolPr 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

3.4.  Sending FBUs

   When the MN needs to signal the Previous AR (PAR) 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 PAR using
   the PAR's CGA and the MN's previous care-of CGA on the PAR's link.
   As defined by the FMIPv6 [FMIP], the MN MUST generate the
   authentication MAC using the handover key and the appropriate
   algorithm and MUST include the MAC in the FBU message.  As specified
   by FMIPv6, the MN MUST include the old care-of CGA in a Home Address
   Option.  The FMIPv6 document provides more detail about the
   construction of the authenticator on the FBU.

  3.5

3.5.  Receiving FBUs

   When the PAR receives an FBU message containing an authenticator, the
   PAR MUST find the corresponding handover key using the MN's care-of
   CGA in the Home Address Option as the index.  If a handover key is
   found, the PAR MUST utilize the handover key and the appropriate
   algorithm to verify the authenticator.  If the handover key is not
   found, the PAR MUST NOT change forwarding for the care-
     of care-of CGA.  The
   FMIPv6 document [FMIP] provides more detail on how the AR processes
   an FBU containing an authenticator.

  3.6

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.

   A PAR 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 PAR, and the MN MAY as a consequence initialize
   another, subsequent handover optimization to move traffic from the
   PAR to another new AR.  The default time for keeping the key valid
   corresponds to the default time during which forwarding from the PAR
   to the new AR is performed for FMIP.  The FMIPv6 document [FMIP]
   provides more detail about the FMIP forwarding time default.

   If the MN returns to a PAR prior to the expiration of the handover
   key, the PAR MAY send and the MN MAY receive the same 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 PAR.  The MN SHOULD discard the handover key after
   MIPv6 binding update is complete on the new AR.  The PAR MUST discard
   the key after FMIPv6 forwarding for the previous care-of address
   times out or when HK-LIFETIME expires.

  3.7

3.7.  Protocol Constants

   The following are protocol constants with suggested defaults:

   HKEPK-LIFETIME:   The maximum lifetime for the handover key
                     encryption public key.  Default is 12 hours.

   HKEPK-HANDOVERS:  The maximum number of handovers for which the
                     handover key encryption public key should be
                     reused.  Default is 10.

   HK-LIFETIME:      The maximum lifetime for the handover key.  Default
                     is 12 hours (43200 seconds).

  4.0

4.  Message Formats

  4.1

4.1.  Handover Key Request Option

   The Handover Key Request Option is a standard IPv6 Neighbor Discovery [RFC2461]
   [RFC4861] option in TLV format.  The Handover Key Request Option is
   included in the RtSolPr message along with the SEND CGA Option, RSA
   Signature Option, and Nonce Option.

    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.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .              Handover Key Encryption Public Key               .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                           Padding                             .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Fields:

      Type:         To be assigned by IANA.          27

      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.

      Pad Length:    The number of padding octets beyond the end of the
                     Handover Key Encryption Public Key field but within
                     the length specified by the Length field. Padding
                     octets MUST be set to zero by senders and ignored
                     by receivers.

      AT:            A 4-bit algorithm type field describing the
                     algorithm used by FMIPv6 to calculate the
                     authenticator.  See [FMIP] for details.

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

      Handover Key Encryption Public Key:
                     The handover key encryption public key.  The key
                     MUST be formatted according to the same
                     specification as the CGA key in the CGA Parameters
                     Option [CGA] of the message, and MUST have the same
                     parameters as the CGA key.

      Padding:       A variable-length field making the option length a
                     multiple of 8, containing as many octets as
                     specified in the Pad Length field.

  4.2

4.2.  Handover Key Reply Option

   The Handover Key Reply Option is a standard IPv6 Neighbor Discovery [RFC2461]
   [RFC4861] option in TLV format.  The Handover Key Reply Option is
   included in the PrRtAdv message along with the SEND CGA Option, RSA
   Signature Option, and Nonce Option.

    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.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Key Lifetime        |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   .                                                               .
   .                    Encrypted Handover Key                     .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                           Padding                             .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

      Type:          To be assigned by IANA.          28

      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.

      Pad Length:    The number of padding octets beyond the end of the
                     Encrypted Handover Key field but within the length
                     specified by the Length field.  Padding octets MUST
                     be set to zero by senders and ignored by receivers.

      AT:            A 4-bit algorithm type field describing the
                     algorithm used by FMIPv6 to calculate the
                     authenticator.  See [FMIP] for details.

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

      Key Lifetime:  Lifetime of the handover key, HK-LIFETIME, in
                     seconds.

      Encrypted Handover Key:
                     The shared handover key, encrypted with the MN's
                     handover key encryption public key, using the
                     RSAES-PKCS1-v1_5 format [RFC3447].

      Padding:       A variable-length field making the option length a
                     multiple of 8, containing as many octets as
                     specified in the Pad Length field.

  5.0

5.  Security Considerations

   This document describes a shared key provisioning protocol for the
   FMIPv6 handover optimization protocol.  The key provisioning protocol
   utilizes a public key generated with the same public key algorithm as
   SEND to bootstrap a shared key for authorizing changes due to
   handover associated with the MN's former address on the PAR.  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 RtSolPr as the
   SEND protocol [SEND] for RS.  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
   on the AR.  To avoid state depletion attacks, the handover key SHOULD
   NOT be generated prior to SEND processing that verifies the
   originator of RtSolPr.  State depletion attacks can be addressed by techniques
   techniques, such as rate limiting RtSolPr, restricting the amount of
   state reserved for unresolved solicitations, and clever cache
   management.  These techniques are the same as used in implementing
   Neighbor Discovery.

   For other FMIPv6 security considerations, please see the FMIPv6
   document [FMIP].

  6.0

6.  IANA Considerations

     Two

   IANA has assigned IPv6 Neighbor Discovery option type codes for the
   two new IPv6 Neighbor Discovery options, the Handover Key Request
   Option (27) and Handover Key Reply Option, are defined, and require a
     IPv6 Neighbor Discovery option type code from IANA.

  7.0 Option (28), defined in this
   document.

7.  References

7.1.  Normative References

   [FMIP]    Koodli, R., editor, Ed., "Fast Handovers for Mobile IPv6",
            Internet Draft, Work in Progress. RFC
             4068, July 2005.

   [SEND]    Arkko, J., editor, Ed., Kempf, J., Zill, B., and P. Nikander, P.,
             "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [CGA]     Aura, T., "Cryptographically Generated Addresses", Addresses (CGA)",
             RFC 3972, March 2005.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, March 1997.

     [RFC2461]

   [RFC4861] Narten, T., and Nordmark, E., Simpson, W., and H. Soliman,
             "Neighbor Discovery for IP version 6 (IPv6)", RFC 2461, December 1998. 4861,
             September 2007.

   [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
             Standards (PKCS) #1: RSA Cryptography Specifications
             Version 2.1", RFC 3447, February 2003.

  8.0

7.2.  Informative References

   [RFC3756] Nikander, P., editor, Ed., Kempf, J., and E. Nordmark, E., "
               IPv6 "IPv6
             Neighbor Discovery (ND) Trust Models and Threats", RFC
             3756, May 2004.

   [PBK]     Bradner, S., Mankin, A., and Schiller, J., "A Framework for
             Purpose-Built Keys (PBK)",  Internet  Draft,  work Work in
            progress.

  9.0 Author Information Progress, June 2003.
             Progress.

Authors' Addresses

   James Kempf                     Phone: +1 650 496 4711
   DoCoMo Labs USA                 Email: kempf@docomolabs-usa.com
   3240 Hillview Avenue
   Palo Alto, CA 94303
   USA

     Rajeev Koodli

   Phone: +1 650 625 2359 496 4711
   EMail: kempf@docomolabs-usa.com

   Rajeev Koodli
   Nokia-Siemens Research Center   Fax: +1 650 625 2502
   313 Fairchild Drive             Email: Rajeev.Koodli@nokia.com
   Mountain View, CA 94043
   USA

  10.0  IPR Statements

   Phone: +1 650 625 2359
   Fax: +1 650 625 2502
   EMail: Rajeev.Koodli@nsn.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.

Intellectual Property

   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.

  11.0  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, THE
     IETF TRUST 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.

  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  Acknowledgments

     Funding for the RFC Editor function is currently provided by the
     Internet Society.

     The authors would like to thank John C. Mitchell and Arnab Roy, of
     Stanford University, for their review of the design and suggestions
     for improving it.