[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
IETF Mobile IP Working Group                              Pekka Nikander
INTERNET-DRAFT                              Ericsson Research NomadicLab
                                                         Charles Perkins
                                                   Nokia Research Center
                                                           12 April 2001


   Binding Authentication Key Establishment Protocol for Mobile IPv6
                      <draft-perkins-bake-00.txt>


Status of This Memo

   This document is a submission by the mobile-ip 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

   A method is proposed for providing key information for use between
   a mobile node and correspondent node, to be used for the purpose of
   authenticating Mobile IPv6 Binding Updates.  The key distribution
   is secure except against man-in-the-middle attacks, when the
   attacker resides along the routing path between the correspondent
   node and the mobile node's home agent.  The key can be used for
   authenticating subsequent Binding Updates from the same mobile node,
   substantially reducing the number of key establishment cycles needed
   for maintaining efficient communication paths between the mobile node
   and correspondent node.









Nikander and Perkins          Expires 12 October 2001           [Page i]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001




                                Contents


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. Terminology                                                        2
     2.1. Specific Document Terminology . . . . . . . . . . . . . .    2
     2.2. Abbreviations and Symbolic Names  . . . . . . . . . . . .    3

 3. Design goals                                                       4
     3.1. Beliefs held by the CN  . . . . . . . . . . . . . . . . .    5
     3.2. Beliefs held by the MN  . . . . . . . . . . . . . . . . .    5
     3.3. Optional Beliefs  . . . . . . . . . . . . . . . . . . . .    6

 4. Design principles                                                  6
     4.1. Low computational overhead  . . . . . . . . . . . . . . .    6
     4.2. Minimal Messaging . . . . . . . . . . . . . . . . . . . .    7
     4.3. DoS resistance  . . . . . . . . . . . . . . . . . . . . .    7
     4.4. Optional Active Participation of HA . . . . . . . . . . .    8
     4.5. No single message alone gives keying material out . . . .    8
     4.6. Randomness included by both MN and CN . . . . . . . . . .    9
     4.7. Inband creation for BKSA  . . . . . . . . . . . . . . . .    9
     4.8. Protection against "future address stealing"  . . . . . .    9

 5. Protocol overview                                                  9
     5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . .    9
     5.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . .   10

 6. Cryptographic Design Analysis                                     12
     6.1. Message 1:  Binding Warning . . . . . . . . . . . . . . .   13
     6.2. Message 2:  Binding Request . . . . . . . . . . . . . . .   13
           6.2.1. Optional Processing by the Home Agent . . . . . .   14
           6.2.2. Processing by the Mobile Node . . . . . . . . . .   15
     6.3. Message 3:  Binding Key Establishment (with Binding
             Update)  . . . . . . . . . . . . . . . . . . . . . . .   16
     6.4. Discussion  . . . . . . . . . . . . . . . . . . . . . . .   17
     6.5. Correspondent Node Initiated Operation  . . . . . . . . .   18

 7. Protocol Processing                                               20
     7.1. Initiation of the protocol  . . . . . . . . . . . . . . .   20
     7.2. Processing a received Binding Warning . . . . . . . . . .   21
     7.3. Generating data for the Binding Request . . . . . . . . .   22
           7.3.1. Encoding TCP connection . . . . . . . . . . . . .   22
     7.4. Sending the Binding Request . . . . . . . . . . . . . . .   23
     7.5. Forgetting State  . . . . . . . . . . . . . . . . . . . .   24



Nikander and Perkins          Expires 12 October 2001          [Page ii]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


     7.6. Processing Binding Request at the Home Agent  . . . . . .   24
     7.7. Processing Binding Request by the Mobile Node . . . . . .   24
     7.8. Establishing the BKSA . . . . . . . . . . . . . . . . . .   25
     7.9. Sending Binding Key Establishment (and Binding Update)  .   26
    7.10. Receiving Binding Key Establishment   . . . . . . . . . .   27
    7.11. Establishing the CN Security Associations . . . . . . . .   27
    7.12. Processing the rest of the packet . . . . . . . . . . . .   28
    7.13. Reduced operations when the Mobile Node is at home  . . .   28
    7.14. Processing For Correspondent Node Initiation  . . . . . .   28
          7.14.1. Initiating the protocol by sending a Binding
                          Request  . . . . . . . . . . . . . . . . .  29
          7.14.2. Handling a CN initiated Binding Request by a HA .   29
          7.14.3. Handling a CN initiated Binding Request by a MN .   29
          7.14.4. Further operations at the CN end  . . . . . . . .   30
    7.15. Simultanous operation by two Mobile Nodes . . . . . . . .   31

 8. Cryptographic Algorithms                                          31
     8.1. Algorithm for Computing Token T0  . . . . . . . . . . . .   31
     8.2. Algorithm for computing token T1  . . . . . . . . . . . .   32
     8.3. Algorithm for computing nonce N2  . . . . . . . . . . . .   32
     8.4. Algorithm for computing token T2  . . . . . . . . . . . .   32
     8.5. Algorithm for computing key material BK . . . . . . . . .   33

 9. Protocol Data Unit Formats                                        33
     9.1. Binding Warning Message . . . . . . . . . . . . . . . . .   33
     9.2. Binding Request Message . . . . . . . . . . . . . . . . .   34
     9.3. Binding Key Establishment Destination Option  . . . . . .   35

Acknowledgements                                                      36

References                                                            37

Chair's Address                                                       38

Authors' Addresses                                                    39



















Nikander and Perkins         Expires 12 October 2001          [Page iii]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


1. Introduction

   Mobile IPv6 specifies the use of a Binding Update destination option
   for use between a correspondent node and a mobile node.  This Binding
   Update associates a "care-of address" to the mobile node's "home
   address" enabling direct routing of packets to the current point
   of attachment in use by the mobile node.  Unfortunately, there may
   be many instances where no pre-existing security association is
   available for use by the correspondent node to authenticate a Binding
   Update from the mobile node.

   In order to solve this problem, we propose a method by which a
   correspondent node supplies some random data for use by the mobile
   node as input to an algorithm for creating a security association.
   This security association, once established between the mobile node
   and the correspondent node, is then used to create the authentication
   data that is required to be supplied as one of the security fields of
   the Binding Update destination option.

   Without introducing reliance upon use of certifiable public keys, it
   is quite difficult to avoid all attacks against the correspondent
   node that might allow some malicious third part to masquerade as
   the mobile node.  However, we can at least make sure that any such
   malicious node would have to reside along the routing path between
   the correspondent node and the home agent.  This substantially
   reduces to the vulnerability to such attacks, since the specific
   routing path required amounts to an extremely small proportion of the
   Internet.

   Some of the security features of this protocol rely on requiring
   that the correspondent node must send the Binding Requests to the
   home network.  This gives some measure of assurance that subsequent
   protocol actions could avoid interference by nodes not along the
   natural routing path between the correspondent node and the home
   network.

      DISCUSSION. If the security associations created are AH
      security associations, most IPSec implementations would need
      to change their policy engine.  However, we would consider
      AH better than a special purpose protection since using
      AH would allow IKE/AAA/whatever to be used to create the
      SAs between the MN and the HA without too many changes.
      On the other hand, nothing prevents from specifying a new
      DOI/whatever to create BKSAs with IKE/AAA/whatever.  Thus,
      from that point of view, this protocol is just a special
      purpose key management protocol, able to create only BKSAs.

   In this protocol specification, several new messages are introduced:

      Binding Warning
                which is sent by a mobile node to a correspondent node



Nikander and Perkins          Expires 12 October 2001           [Page 1]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


                as an indication that a new care-of address should be
                obtained for the one of the mobile node's addresses.

      Binding Request
                which is sent by a correspondent node to the home
                address of the mobile node in order to elicit a Binding
                Update.

      Binding Key Establishment Extension
                which supplies a key to be used by the correspondent
                node when verifying authentication data supplied by
                the mobile node to ensure the integrity of the Binding
                Update data.

   Subsequent sections provide an overview of the operation of the key
   establishment mechanism, discussion about the cryptological analysis
   motivating the design of the protocol, the format of the protocol
   messages, and detailed specification for the message formats.
   Although a specific authentication key establishment algorithm is
   proposed, it should be noted that other key establishment algorithms
   may be proposed in the future.  Nevertheless, for interoperability,
   all correspondent nodes MUST implement the algorithm specified in
   this document.


2. 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 [1].  Furthermore,
   this document makes use of many general terms defined in the protocol
   specification for Mobile IPv6 [2].


2.1. Specific Document Terminology

   Other specific terms are defined as follows.

      Cookie    a tasty morsel with random bits of goodness

      Hash      a way to scramble tasty morsels of data; often used as a
                message digest or message authentication code (MAC)

      Key       a secret number that enables operation of a
                cryptographic algorithm.

      Binding Key
                a key used for authenticating Binding Update messages.

      Security Association
                a security object shared between two nodes which



Nikander and Perkins          Expires 12 October 2001           [Page 2]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


                includes the data mutually agreed on for operation of
                some cryptographic algorithm (typically including a key,
                as defined above).

      Binding Key Security Association (BKSA)
                a security association established specifically for the
                purpose of producing and verifying authentication data
                passed with a Binding Update destination option.

      Tunnel Protection
                protecting tunneled data against attackers, either by
                encryption, inserting additional integrity checking, or
                by modifying the data in some unforgeable fashion.


2.2. Abbreviations and Symbolic Names

   The protocol messages defined in this specification use some opaque
   data generated according to the needs of various cryptographic
   algorithms.  These data are referred to by symbolic names.  In
   order to reduce confusion, we attempt to use the same symbolic
   names throughout the document.  These names are gathered together
   here for easy reference.  We also include various abbreviations for
   completeness.

      CN        The correspondent node

      HA        The home agent

      MN        The mobile node

      HoA       The home address of the mobile node

      CNA       The IPv6 address of the correspondent node

      KeyMat    Data computed for use in generating the Binding Key
                which defines the BKSA

      BK        The binding key

      BKE       The Binding Key Establishment destination option

      K_CN      A secret value maintained (and reselected periodically)
                by the correspondent node for use in generating nonce N2

      K_(MN,HA) A key shared between mobile node and home agent.

      PCB       Protocol Control Block (used by TCP)






Nikander and Perkins          Expires 12 October 2001           [Page 3]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


      N1        A nonce created by the mobile node for use in the
                Binding Warning, and eventually used to identify the
                Binding Request

      N2        A nonce, reproducible from K_CN and T1, for use by the
                correspondent node when producing token T2.  It is
                used to validate an eventual Binding Key Establishment
                message.

      R         A random number created by the mobile node after
                reception of the Binding Request message, and used when
                creating BK.

      T0        A token computed in order to assure data integrity, and
                to provide a temporarily hidden input for token T1

      T1        A token computed from T0, and made publicly visible in
                protocol messages, in order to assure data integrity.

      T2        The first part of the key generation material,
                calculated by the correspondent node, and delivered to
                the mobile node in the Binding Request message.

      HASH_T0   A cryptographic algorithm used to produce the token T0
                (see section 8.1)

      HASH_T1   A cryptographic algorithm used to produce the token T1
                (see section 8.2)

      HASH_N2   A cryptographic algorithm used to produce the nonce N2
                (see section 8.3)

      HASH_T2   A cryptographic algorithm used to produce the token T2
                (see section 8.4)

      HASH_BK   A cryptographic algorithm used to produce the desired
                Binding Key (see section 8.5)


3. Design goals

   The protocol MUST fulfill the a set of defined goals.  The goals can
   be expressed in terms of beliefs that the parties may hold after a
   successful protocol run.  These beliefs are outlined in Sections 3.1
   through 3.3, below.

   The primary goal of the protocol is to create unauthenticated but
   appropriately authorized keying material that may be reasonably
   used to secure future Binding Updates between a MN and a CN. By
   "unauthenticated" we mean that the protocol does not give any
   assurance about any identity of the MN to the CN or vice versa.  By



Nikander and Perkins          Expires 12 October 2001           [Page 4]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   "appropriately authorized" we mean that the CN has reasonable bases
   to believe that it is sharing the keying material with the MN, i.e.,
   with a party that is reachable through the home address that it
   claims to "own", and that the MN has reasonable bases to believe that
   it is sharing the keying material with the CN, i.e., with the party
   who is reachable through the address that the MN expects the CN to
   have.

   By "reasonable bases" we mean that the protocol does not aim to be
   fully secure in any stronger means of the term "secure" but that it
   does protect against attacks that some unrelated third party might
   be able to launch from an arbitrary location in the Internet.  In
   particular, the protocol does not aim to protect the parties against
   attackers that are able to eavesdrop all traffic flowing between the
   MN, CN and HA.


3.1. Beliefs held by the CN

   In this section, we list the beliefs that the correspondent node is
   expected to act upon during its part of the protocol operation.

    -  The CN is able to believe that the MN has the given home address,
       since it has checked that MN eventually receives packets sent to
       the Home Address, and that the MN is (was) able to reply to them.

    -  The CN is able to believe that the MN wants to provide the given
       CoA for use in routing headers for data to be sent to mobile
       node.

    -  The CN believes that the key it holds with an MN is only known to
       the MN unless there is some third party who is able to either

        *  eavesdrop all traffic send and received by the CN, or

        *  eavesdrop all traffic sent by both the CN and MN, or

        *  eavesdrop all traffic send and received by the MN, and the
           traffic between the MN and the HA is in clear.

   No other passive or active attack scenarios are believed to be
   tolerated by this protocol.


3.2. Beliefs held by the MN

   In this section, we list the beliefs that the mobile node is expected
   to act upon during its part of the protocol operation.






Nikander and Perkins          Expires 12 October 2001           [Page 5]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


    -  The MN believes that packets sent to the CN address are
       (eventually) received by the CN, and that the CN is able to reply
       to them.

    -  The MN believes that the key it holds with the CN is only
       known to the CN unless there is some third party who is able to
       eavesdrop traffic as specified in section 3.1.


3.3. Optional Beliefs

   [XXX: Should we allow the HA have optional beliefs?]

   [XXX: Should we allow the MN have optional beliefs about endorsement
   by the HA?]


4. Design principles

   In the following sections, we discuss the following design principles
   which have been used in the construction of this protocol.

    -  Low computational overhead

    -  Minimal messaging:  MN->CN, CN->HA->MN, MN->CN

    -  Resistant to DoS attacks

          CN does not need to create state before the third message

    -  Allows active participation of HA but does not require it

    -  No single message alone gives keying material out

    -  Randomness included by both MN and correspondent node

    -  Allows inband establishment for the Binding Key Security
       Association (BKSA)

    -  Protection against "future address stealing"

    -  Allows initation by the correspondent node.


4.1. Low computational overhead

   The protocol should have low computational overhead.  In particular,
   it must not require any heavy computation by the CN before it has
   some assurance that the MN is actually there and that the MN is able
   to receive messages sent to the Home Address.  Furthermore, it should




Nikander and Perkins          Expires 12 October 2001           [Page 6]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   not require any heavy computation by the MN as the MN may have severe
   computational limitations.

   On the other hand, optional extensions to the protocol may enable the
   HA to assist the MN in computations.  That is, if the MN and the HA
   trust each other, and the HA has much more computational power than
   the MN, then the MN may rely on the HA to perform heavy computations
   on its behalf.


4.2. Minimal Messaging

   The protocol is conveyed by three messages, namely:

    1. Binding Warning:  sent by a MN to a CN (MN->CN)

    2. Binding Request:  sent by a CN to the MN through the HA
       (CN->HA->MN)

    3. Binding Key Establishment:  sent by a MN to the CN (MN->CN)

   A two message variant of this, initiated by the CN, is also needed;
   this is defined in Section 7.14.


4.3. DoS resistance

   The protocol can be made resistant to "denial of service" (DoS)
   attacks by using the following principles.

    1. The involved parties must minimize state creation before they
       obtain assurance that the alleged peer is on-line.  That is,
       state is created only when a such a message is received that the
       party creating the state can verify that it has itself recently
       been involved in sending a message to which the received message
       is a reply.

    2. The amount of computation performed by a responding party should
       be limited until it is able to check that the initiating party
       has been performed an equal or larger amount of computation.

   As a particular design principle, we want to make it possible for a
   MN to send the first message to the CN before any prior communication
   between the MN and the CN (see section 4.7.  For example, this first
   message could be included in a TCP SYN sent by the MN to the CN.

   In order not to create a possibility for a new TCP SYN flooding type
   of attack, the protocol MUST NOT require the CN to create any state
   before it receives its final protocol message.  This is a particular
   instance of the first DoS design principle, in the context of the
   three-message protocol we specify in this document.  Additionally,



Nikander and Perkins          Expires 12 October 2001           [Page 7]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   we would like to design the protocol in such a way that the CN could
   optionally defer even TCP state creation until it receives the third
   protocol message.  Specifying such mechanism is beyond the scope of
   this document; for here, it suffices to merely create a transparent
   mechanism that could be used for that and other similar purposes.


4.4. Optional Active Participation of HA

   We envision a future with various relationships between the MN and
   the HA, and therefore very different kinds of HAs.  Some of the HAs
   may be mere packet reflectors, tunneling all packets sent to them
   to the MN. For example, HAs used for temporary packet forwarding
   are likely to be like this.  However, some HAs may be much more
   intelligent, and even provide computation services to the MNs.

   In order not to rely on any specific properties of the HAs, but allow
   space for utilizing them, we want to design the protocol in such a
   way that it allows participation of HAs but does not require it.  We
   also expect that some HAs will encrypt encapsulated packets when
   tunneling them to the mobile nodes, providing additional security.


4.5. No single message alone gives keying material out

   Since we do not want to assume any existing security associations
   between the MN and the CN or between the HA and the CN, the protocol
   cannot create properly authenticated keying material out of nothing.
   That is, in the light of currently established wisdom, the protocol
   cannot create keying material in such a way that the participating
   parties would have enough grounds to believe that only they and no
   one else possess the keying material.

      DISCUSSION: For the purposes of appropriate authorization
      (but not authentication), something like the protocol
      presented in draft-nikander-ipng-pbk-addresses-00.txt could
      be used to create keying material in such a way that it
      would be protected against passive attackers and even (at
      least most if not all) active attackers.  However, the
      protocol requires public key computations.

   Thus, the protocol has to be designed in such a way that an attacker
   that is only able to eavesdrop any single message is unable to create
   the keying material.  This gives reasonable protection against
   passive attackers.  In practice, an attacker would have to be on the
   same link with the CN, on the same link with the MN and the traffic
   between the HA and the MN be unprotected, or be able to eavesdrop
   traffic between both the MN and CN and CN and HA. This drastically
   reduces the number of locations from which a malicious node can mount
   an attack.




Nikander and Perkins          Expires 12 October 2001           [Page 8]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


4.6. Randomness included by both MN and CN

   To protect against possible bad random number generators, the keying
   material includes randomness generated both by the MN and the CN.


4.7. Inband creation for BKSA

   We wish to avoid requiring extensive changes to the current Mobile
   IPv6 specification.  Therefore, the protocol is designed in such a
   way that the MN creates a Binding Key Security Association (BKSA)
   after receiving the message from the correspondent node, and that the
   CN is able to create the same BKSA after receiving its final message.
   This makes it possible to send an authenticated BU along with the
   third message.  Furthermore, in this way the normal data flow between
   the two endpoints (mobile node and correspondent node) experiences
   minimal disruption.


4.8. Protection against "future address stealing"

   To protect against "future address stealing" [7], the mobile nodes
   should use random CoAs [6].


5. Protocol overview

   This section gives an overview of the protocol from an implementation
   (engineering) point of view.  A corresponding cryptographic (security
   point of view) description is given in Section 6.  We first outline
   the message exchanges, and then discuss the protocol steps one by
   one.  Section 7 specifies the processing rules, and Section 9 the
   exact message formats.


5.1. Protocol Messages

   The protocol uses the Binding Warning, Binding Request, and the
   Binding Key Establishment (BKE) destination options, as follows.

    1. If no security association between a mobile node and a
       correspondent node exists for the purpose of authenticating a
       Binding Update to that correspondent, the mobile node SHOULD
       send a Binding Warning to the correspondent node, asking it to
       start the process of establishing the needed security association
       with the indicated address of the mobile node.  This packet MUST
       contain the Home Address Destination Option, informing the CN
       about the alleged Home Address (HoA) of the MN.

    2. If the Correspondent Node wants to continue the exchange, it
       sends a Binding Request to the Home Address of the MN. The packet



Nikander and Perkins          Expires 12 October 2001           [Page 9]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


       MUST be sent to the Home Address independent on any possibly
       existing Bindings.  As the default action, the Home Agent SHOULD
       tunnel the packet to the Mobile Node.  The tunnel SHOULD be
       protected using ESP [3], or some other means.

    3. When the Mobile Node receives a Binding Request, passed via the
       tunnel and originated by the Correspondent Node, it creates
       a BKSA that will be used to secure Binding Updates.  It then
       generates a packet that contains at least the following headers
       in the following order:

               IP header
               Routing Header, if present
               Destination Options header, containing
                       Home Address option
                       Binding Key Establishment option
               Fragmentation Header, if present
               IPSec headers, if present
               Destination Options header, including
                       Binding Update
               Upper layer data, if present


       The Binding Key Establishment Destination Option allows the
       Correspondent Node to perform checks to reduce the risk that the
       peer is not the right Mobile Node "owning" the Home Address to
       a reasonable level, and to create the same BKSA that the Mobile
       Node created after the second message.

   At the conclusion of the protocol, a BKSA will have been established,
   for use to create and verify the data containing in Binding Update
   destination options.


5.2. Prerequisites

   We assume that certain conditions are in place before the actual
   protocol is run.  This is a standard practice in security protocols,
   which usually build upon existing security relationships.  However,
   in the case of this protocol those relationships are relatively weak,
   at least if compared to typical security protocols.

   Briefly, there are two requirements:

    -  There is a relationship between the Mobile Node and the Home
       Agent.

    -  The Correspondent Node has to generate random keys, K_CN, known
       only to itself.





Nikander and Perkins          Expires 12 October 2001          [Page 10]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   In the simplest form, the relationship between the Mobile Node and
   the Home Agent may be the implicit agreement that the Home Agent
   will tunnel received packets to the Mobile Node.  Such an agreement
   could be arranged without having any explicit security association
   between the MN and the HA; for example, a temporary HA might just
   forward packets to a fixed address for a period of time.  Using
   Mobile IPv6 [2], a mobile node can update the tunnel point (in
   the Binding Cache) which the home agent maintains for it, using a
   pre-established BKSA. Often, the Mobile Node and Home Agent have
   an IPSec ESP security association, and the Home Agent is able to
   encrypt and integrity protect the tunneled packets.  The protocol
   in this document also allows more advanced security relationships
   between the Home Agent and the Mobile Node, enabling some of the
   crypto processing to be performed by the Home Agent instead of the
   Mobile Node.  The specification of such processing is outside this
   specification.

   The present protocol enables the use of a key, K_(MN,HA), shared
   between the MN and the HA, whose sole purpose SHOULD be to be used
   within this protocol.  Before using the key for any other purposes,
   the possibility of unwanted interactions must be eliminated.

   With some loss of security, it is also possible to run a variation
   of the protocol where the key K_(MN,HA) belongs solely to the Mobile
   Node, and is not known by the HA or any other party.

   The random keys, K_CN, generated by the Correspondent Node are
   assumed to be short lived; a typical lifetime of such a key might be
   e.g. 10 seconds or one minute.  As the key is local to the CN, the
   exact policy and mechanism for generating such keys is not specified.
   For example, one possibility is to generate a completely new key only
   every few minutes or hours, and just keep incrementing the key until
   it is the time to create a completely new key.  To add robustness,
   the Correspondent Node MUST remember a number of previous K_CN
   values.  The exact number of remembered values is a matter of local
   policy.


















Nikander and Perkins          Expires 12 October 2001          [Page 11]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


6. Cryptographic Design Analysis

   From the cryptographic point of view, we have a three-party
   protocol where one of the parties may be a passive forwarder,
   only optionally taking part of the protocol run in any other way
   than reflecting messages.  To emphasize the difference between the
   parties and their addresses, we denote the Mobile Node's current
   address (care-of-address) as CoA, its Home Address as HoA, and the
   Correspondent Node's address as CNA. The parties are the Mobile Node
   (MN), the Corresponding Node (CN) and the Home Agent (HA), assumed
   connected in a triangular manner:

                                  HA
                                 /  ^
                                /    \
                               /      \
                              V        \
                            MN <-----> CN

   The MN and CN are able to directly exchange messages.  However, for
   the purposes of this protocol we assume that the links between the
   CN and the HA, and between the HA and MN are unidirectional.  By
   default, we assume only that the HA can act as a passive reflector,
   tunneling any packets sent to themobile node's home address (HoA) to
   the MN's care-of address (CoA).

   The messages tunneled by the HA to the MN may or may not be
   encrypted.  If they are encrypted, the encryption is assumed to
   effectively defeat eavesdropping on the links along the tunnel's
   path.  The links between the MN and the CN and leading from CN to HA
   are assumed to be clear and vulnerable to eavesdropping.

   From the security point of view, the purpose of the protocol can be
   described as follows.  The protocol starts from an initial situation
   where the MN and HA have a security association with each other.
   More formally, the MN knows that it is currently using the address
   CoA and that its home address is HoA, and that there is the Home
   Agent HA at the home address HoA. Likewise, the HA knows that it is
   currently reflecting packets sent to HoA to the care-of-address CoA,
   and that the MN is assumed to be currently reachable through CoA.
   Furthermore, they may share a secret key K_(MN,HA). Furthermore, the
   MN has (recently) learned an address CNA that it assumes to belong
   to some corresponding node CN. The HA does not have any information
   about the CN. The CN does not have any information about the MN or
   HA.This initial state can be described as the following knowledge sets.


      MN: { CoA, HoA, K_(MN,HA), CNA }
      HA: { CoA, HoA, K_(MN,HA) }
      CN: { K_CN, CNA }




Nikander and Perkins          Expires 12 October 2001          [Page 12]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


6.1. Message 1:  Binding Warning

   The protocol is triggered by the MN deciding that it wants to
   exchange a binding key with whatever CN happens to currently be at
   CNA. To ensure message freshness the MN creates a nonce, N1, and adds
   it to its knowledge set.

      MN: { CoA, HoA, K_(MN,HA), N1 }
      HA: { CoA, HoA, K_(MN,HA) }
      CN: { CNA, K_CN }


   After that, it uses the algorithms in section 8.1 and 8.2 to create
   cryptographic tokens T0 and T1.  T1 may be optionally authenticated
   by the HA if the HA knows the key K_(MN,HA). The reason for this two
   step process of creating the token T1 is that later, in the third
   message, T0 is used to authenticate the MN.

   The first message contains the addresses, the nonce N1 and the
   token T1.  (Note that the addresses are already available in the IP
   headers, and they MUST NOT be repeated in the payload.)

      MN->CN: < CoA, CNA, HoA, N1, T1 >

   When the CN receives the message, it learns the addresses CoA, HoA,
   the nonce N1 and the token T1.  These are tabulated as a separate
   knowledge set since the CN should forget them after it has sent
   the reply.  The reason why we want the CN to forget these data is
   denial-of-service resistance.  Basically, we want the CN to handle
   the packet effectively and fast, and then forget about it.

      MN: { CoA, HoA, K_(MN,HA), N1 }
      HA: { CoA, HoA, K_(MN,HA) }
      CN: { CNA, K_CN } + { CoA, HoA, N1, T1 }


6.2. Message 2:  Binding Request

   For the next message, the CN prepares a structured nonce N2 and an
   authentication token T2.  The first of these, N2, is sent to the MN
   through the HA, and used by the MN as a part of creating the new
   keying material.  The second token, N2, is passed by the HA and MN
   back to the CN, allowing it to authenticate the third message as it
   arrives.  Furthermore, the CN must be able to reconstruct the nonce
   N2, based on the authenticated third message, so that it can create
   the same keying material as the MN does.

      N2 := HASH_N2 ( K_CN ; 0 || T1 ) (see section 8.3)
      T2 := HASH_T2 ( K_CN ; T1 || CoA || CNA || HoA)
      (section 8.4)




Nikander and Perkins          Expires 12 October 2001          [Page 13]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   In creating the tokens, CN uses only information that will
   be available to it when it receives the third message.  The
   authentication token T2 must include all information whose integrity
   must be protected, as well as T1 since its inclusion helps to block
   active attacks later in the protocol.  On the other hand, the content
   of the nonce N2 is not that critical; the only requirements are that
   it is hard to predict (hence K_CN) and it can be easily recomputed
   upon arrival of the third message.  The (relative) freshness of the
   key K_CN supplies freshness to the nonce N2 and the token T2.

   In the second message, CN sends its address, the nonces N1 and N2 and
   the tokens T1 and T2 to the home network, by way of the Home Address
   HoA.

      CN->HA: < CNA, HoA, N1, T1, N2, T2 >


6.2.1. Optional Processing by the Home Agent

   A simple HA will simply forward the second message to the CN through
   tunneling (ESP or non-ESP).

   A more intelligent HA may want to authenticate the packet, and
   perhaps also perform other functions.  After the HA receives the
   message its knowledge set is as follows:

      HA: { CoA, HoA, K_(MN,HA), CNA, N1, T1, N2, T2 }

   By receiving the message, the HA has already implicitly checked that
   the HoA in the message matches a home address for a known mobile
   node.  It MAY now proceed to check validity of T1.

      T1 =?  HASH_T1( K_(MN,HA) ; N1 || CoA || CNA || HoA )

   This check allows the HA to verify that the token T1 was generated by
   the MN, and that MN meant it to be used for a protocol run between
   CoA, CNA and HoA.

   The HA may also perform other activities, like logging some of the
   information to an audit trail.  Additionally, based on a mutual
   agreement between the MN and HA, it may also change the contents of
   N1 and T1 to something that allows MN to determine that the message
   has been processed by the HA. For example, the HA might want to
   replace N1 and T1 with NewN1 and NewT1, where

      NewN1 := N1 + 1
      NewT1 := HASH_T1( K_(MN,HA) ; NewN1 || CoA || CNA || HoA )

   However, such practices are beyond the scope of this protocol.





Nikander and Perkins          Expires 12 October 2001          [Page 14]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   In any case, the HA forwards a message (through a tunnel) a message
   that has the same format as the message it received.

      HA->MN: TUNNEL < CNA, HoA, N1, T1, N2, T2 >

   After processing the message, the home agent SHOULD reduce its
   knowledge set by discarding information that it no longer needs.

      HA: { CoA, HoA, K_(MN,HA) }


6.2.2. Processing by the Mobile Node

   Before the mobile node receives the Binding Request, it has the
   following knowledge set:

      MN: { CoA, HoA, CNA, K_(MN,HA), N1 }

   The mobile node must first check that the addresses match.  The
   CoA is implicitly checked by receiving the message.  The MN
   must explicitly check that the message was properly received
   through a tunnel from the HA, and that the inner header in the
   tunneled packet contains CNA as the source address and HoA as the
   destination address.  After that, it SHOULD check that the nonce N1'
   received with the Binding Request equals the nonce N1 generated in
   section 6.1.  This protects the MN against replay attacks.  Finally,
   it SHOULD check that the received token T1' authenticates correctly.

      T1' =?  HASH_T1 ( K_(MN,HA) ; N1' || CoA || CNA || HoA ) )

   These checks allow the the MN to verify the following.

    -  The initial message was received by some party that is able to
       receive messages sent by the MN to CNA.

    -  If the tunneling check was strong (the MN-HA tunnel is ESP) or
       if the <N1,T1> pair was modified according to a mutual agreement
       between the MN and the HA, the party that received the initial
       message sent a reply to the correct HA, who forwarded the message
       back to the MN.

   Any of the messages may have been intercepted and modified by an
   active attacker.  If the active attacker was able to intercept the
   first message, the above statements still hold since it then acts as
   "some party that is able to receive messages sent by the MN to CNA."
   On the other hand, if the active attacker is only able to intercept
   messages at the CN->HA or HA->MN link, it still cannot modify the
   <N1,T1> pair without knowing the key K_(MN,HA), and therefore T1
   authenticates the address triple.  Consequently, a securely tunneled
   packet or a correctly transformed <N1,T1> pair indicates that the
   message was indeed processed by the HA, and therefore that the



Nikander and Perkins          Expires 12 October 2001          [Page 15]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   message was received and forwarded by the HA. On the other hand, an
   active attacker may have changed the nonce N2 and token T2.

   Note that, within the design principles, no simple means that we are
   aware of allows the MN or the CN to be protected against an active
   attacker present in the same network with the MN. That is, an active
   attacker can play the role of CN towards the MN, and therefore also
   the role of MN towards the CN, and even send packets directly to
   the HA using the CN address as the source address without having
   the CN involved at all.  On the other hand, having the HA involved
   (either through secure tunneling or explicitly) does provide a level
   of protection for the CN against passive attackers close to the MN.
   [XXX: More work is needed to determine the real limitations of the
   approach.]

   After the checks, the MN proceeds to create the keying material
   BK. To do that, it first creates a fresh random number R, and then
   combines the nonce N2 with it, according to the algorithm HASH_BK:

      BK := HASH_BK( R || N2 )      (see section 8.5)

   Even though both N2 and R are not private information, since that
   they have to be sent in clear over some unsecure link, they are
   never sent together or over the same link.  N2 is only sent through
   CN->HA->MN, where even the HA->MN link may be encrypted, and R is
   sent through MN->CN. As a result, the only viable points where
   eavesdropping is easy are the local link where the CN is located
   and (if the tunnel is unprotected) the local link where the MN is
   located.

   If the CN is a stationary server, getting access to its local link is
   probably hard.  On the other hand, if the CN is a mobile node itself,
   the MN is most probably sending the first and third messages to the
   CN through the CN's Home Agent, and therefore the first and third
   messages may well be encrypted as they arrive at the CN.

   Perhaps the weakest point lies near to the MN, since the local link
   of the MN is likely to be wireless.  If the HA uses the protected
   tunnel between HA and MN, this link is effectively secured.  [XXX:
   but we need more security analysis on this point.]


6.3. Message 3:  Binding Key Establishment (with Binding Update)

   In the third message, the MN sends the pre-image of the token T1, the
   authentication token T2 and the new random number R to the CN.

      MN->CN: < CoA, CNA, HoA, T0, T2, R >

   As the correspondent node receives the message, it first generates
   T1 according to the algorithm in section 8.2.  Then CN verifies the



Nikander and Perkins          Expires 12 October 2001          [Page 16]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   message's authenticity and freshness by verifying the token T2, using
   the algorithm in section 8.4.  This verification allows the CN to
   establish the following beliefs:

    -  Some party received the second message that it sent to HoA, and
       is now replying to that message.  That party also allegedly
       received N2 and generated R, and therefore may be expected to
       have calculated and stored the keying material BK.

    -  Second, that same party also knew T0, which the MN is not
       supposed to reveal before it sends the third message.

   Thus, to fool the check the attacker must have intercepted the BKE
   option sent by the MN and replaced it with its own.  Furthermore,
   in order to possess the BK it must have been able to eavesdrop the
   Binding Request in order to learn N2.


6.4. Discussion

   Unless there are holes (but taking into account how new this protocol
   is, we aren't so confident yet), the protocol seems fairly secure
   from the CN's point of view.  Basically, there are two ways an
   attacker can break the protocol.

    1. If the attacker, acting alone, is able to break the home agent
       check in the sense that no packets flow through the home agent,
       then the attacker is apparently able to create bindings for
       whatever address.

    2. If the attacker, attacking while there is an MN running the
       protocol, is able either to learn the newly created keying
       material (BK) or to replace the correct keying material with
       something else, the the attacker will be able to later replace
       the Binding for that particular MN with something else.

   In order to break the home agent check, the attacker must be able to
   eavesdrop packets flowing from the CN to the HA. If it can do that,
   then it can play the part of the MN even when it does not receive
   the packets forwarded by the HA. The only remedy against this would
   be to enhance the protocol in such a way that the CN can actually
   check that the real HA was involved.  Unfortunately, this seems to
   be impossible since there does not exist any security associations
   between the MN and CN.

   [XXX: It might be possible, though, to use the Home Address as a
   pre-established security context, as indirectly suggested in  [7].
   There are two problems with such practice.  First, there may be IPR
   problems.  Second, the practice goes beyond the currently established
   security mechanisms, and requires rigorous peer review before its
   security can be considered known.  However, maybe a mechanism based



Nikander and Perkins          Expires 12 October 2001          [Page 17]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   on that idea should be an optional extension?  Such an extension
   would not do any harm (other than slightly add complexity), but it
   might provide better protection for those hosts that do implement
   it.]

   To passively learn the BK, an attacker must be able to eavesdrop both
   the second packet containing N2 and the third packet containing R. If
   the attacker is able to do this, it could most probably play the part
   of CN as well.

   To replace the real BK with falsified one that it knows, an active
   attacker must be able to eavesdrop the second packet containing N2,
   and then produce a new third packet containing falsified R. However,
   producing falsified third packet is hard unless the attacker is able
   to intercept the real third packet.  That is, in order to pass the
   authentication check, the attacker would have to be able to reverse a
   one-way function and produce T0 from T1.


6.5. Correspondent Node Initiated Operation

   From the security analysis point of view, the CN initiated variant of
   the protocol is a separate protocol from the MN initiated one.  Thus,
   it must be analyzed separately.  Furthermore, since we are sharing
   much of the implementation between these two protocols, it is also
   necessary to analyze the protocols together in order to discover
   potential pitfalls.  In this section, we analyze the CN initiated
   protocol variant in isolation.

   In the CN initiated case, we have two possibilities.  The first
   possibility is that the MN already knows the CN, and therefore the
   initial knowledge sets can be expressed as follows.

      MN: { CoA, HoA, K_(MN,HA), CNA }
      HA: { CoA, HoA, K_(MN,HA) }
      CN: { CNA, HoA }


   In this case the main threat seems to be replay attacks.  That is,
   resource exhausting DoS is fairly hard since both the MN and the CN
   already have their peer's address, and no actual new state must be
   preserved.  On the other hand, unless proper freshness of the BKSA
   keying material can be assured, various replay attacks seem to be
   fairly easy.

   The shortened protocol can be described as follows.  (Zero elements
   have been removed.)

      CN->HA: < CNA, HoA, N2, T2 >
      HA->MN: TUNNEL < CNA, HoA, N2, T2 >




Nikander and Perkins          Expires 12 October 2001          [Page 18]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


      MN->CN: < CoA, CNA, HoA, T2, R >


   Here the token T2 assures freshness of the BKE message.  On the other
   hand, the MN has no way of determining if the first BR is fresh or
   not.  XXX: More analysis needed.

   The case when the MN does not know the CN is more difficult.  The
   initial knowledge sets can be described as follows.

      MN: { CoA, HoA, K_(MN,HA) }
      HA: { CoA, HoA, K_(MN,HA) }
      CN: { CNA, HoA }


   Thus, the MN learns the CN address CNA only by receiving the
   Binding Request.  If it were to simply accept it and proceed with
   establishing state, this would open up a trivial denial-of-service
   attack.  Furthermore, as the MN may be a small device with limited
   storage capacity, such an attack would be even more serious.

   The first and safest option for the MN is simply ignore such a
   Binding Request.  A second option is to proceed much in the same way
   as the CN works when it receives an unsolicited Binding Warning,
   i.e., in a way that does not necessitate creating state.  The basic
   protocol can be expressed as follows.

        First Binding Update:
                CN->HA: < CNA, HoA, N2, T2 >
                HA->MN: TUNNEL < CNA, HoA, N2, T2 >
        Binding Warning:
                MN->CN: < CoA, CNA, HoA, N1, T1 >
        Binding Request:
                CN->HA: < CNA, HoA, N1, T1, N2', T2' >
                HA->MN: TUNNEL < CNA, HoA, N1, T1, N2', T2' >
        Binding Key Exchange:
                MN->CN: < CoA, CNA, HoA, T0, T2', R >


   As said, the crucial issue here is to ensure that the MN does not
   need to create state when it receives the first Binding Request.
   Following the principles that we used in the MN initiated variant of
   the protocol, it would be best to compute the the hash value T1 so
   that it covers N2 and/or T2 in addition to the addresses and N1 that
   it usually covers, to require that the CN uses the same N2 and T2
   when sending the second Binding Request, and let the MN to check this
   coverage upon receiving the second Binding Request.

      DISCUSSION. Including T2 to T1 and requiring that T2' == T2
      is not included in the spec below, but perhaps it should be.
      Further protocol analysis is required in any case.  In order



Nikander and Perkins          Expires 12 October 2001          [Page 19]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


      to ease initial implementations, we have simply specified
      that the protocol flows as usual.  We need more experience
      about the actual implementation.

   [XXX: Add full protocol analysis here.]


7. Protocol Processing

   In this section, processing details for protocol messages are
   specified.


7.1. Initiation of the protocol

   A Mobile Node may initiate the protocol at any convenient moment.
   To do so, it includes a Binding Warning Destination Option into any
   packet containing the Home Address Destination Option.

   The Binding Warning contains two 128-bit pieces of data:  a nonce
   N1, i.e., a newly generated random number, and a cryptographic token
   T1, calculated over the nonce and the addresses involved.  The key
   K_(MN,HA), shared between the MN and the HA, is also used in the
   token generation, allowing the HA to check T1 if it wishes (see
   section 6.2.1).  The token is generated in such a way that it also
   allows the Correspondent Node to check whether the Binding Warning
   and the Binding Key Establishment messages have been sent by the
   same party.  This is done by sending a value (here called T0) in the
   latter message that is could only have been produced with knowledge
   possessed by the party that created T1.  If the latter was MN, and
   if MN does not share this information, then the correspondent node
   can be assured that both the Binding Warning and the Binding Key
   Establishment messages were both sent by the same mobile node.

   Instead of being a random number, it is also possible to use
   a counter as the nonce N1.  In that case, the Mobile Node MUST
   increment the counter every time it sends a Binding Warning to any
   node.  Using a counter instead of a nonce allows the Home Agent to
   check T1 against replay attacks.  By special agreement between the MN
   and the HA, more complex arrangements are possible; for instance, the
   uppermost 64 bits of N1 could be randomly generated and the lower 64
   bits a counter.

   [XXX: Should we be more specific about N1, and define that it
   consists of a 32-bit counter and 96-bit random number?]

   The mobile node computes T0, the pre-image of the token T1, using the
   algorithm specified in section 8.1.  This pre-image will be sent to
   the Corresponding Node as a part of the Binding Key Establishment,
   and therefore the Mobile Node may want to save it.  An alternative to




Nikander and Perkins          Expires 12 October 2001          [Page 20]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   saving is to recompute it when needed.  After creating T0, the mobile
   node creates token T1 using the algorithm specified in section 8.2.

   Once the MN has generated N1 and computed T1, it is ready create the
   Binding Warning.  Along with the Binding Warning option, the packet
   MUST also contain the Home Address option.  Thus, the packet will
   have the following headers, in the following order.

        IP header
                destination address := Correspondent Node address (CNA)
                source address := Care-of-Address (CoA)
        Routing Header, if present
        Destination Options header, containing
                Home Address option
                Binding Warning option
        Fragmentation Header, if present
        IPSec headers, if present
        Upper layer data, if present


   As shown, the packet MAY also contain higher-level protocol payload.
   For example, the upper layer data could be a TCP SYN packet,
   Furthermore, the Mobile Node SHOULD save a <N1,CoA> pair so that
   it can more effectively match the Binding Request to be received.
   It MAY also want to save T0 and/or T1.  In any case, it MUST store
   enough data so that T0 can be later retrieved, either by recomputing
   it or by remembering it.

   If, after transmitting the Binding Warning, the mobile node does not
   receive a Binding Request, it MAY retransmit the Binding Warning up
   to BW_RETRIES times.  The first retransmission MUST be delayed for
   BW_REXMIT_DELAY seconds, and every subsequent retransmission must
   be delayed for twice the amount of additional time as the previous
   retransmission was delayed.


7.2. Processing a received Binding Warning

   When a Correspondent Node receives a packet containing a Binding
   Warning, it SHOULD process the Binding Warning and send a Binding
   Request based on that.  However, it SHOULD limit creation of state
   until it receives the Binding Key Establishment packet back from the
   Mobile Node.

   The reason for not creating a state is to protect the CN from
   memory exhausting Denial-of-Service attacks.  Furthermore, the
   present protocol MAY be used to defer state creation for upper layer
   protocols as well.

   The incoming Binding Warning requires very little processing.
   The nonce N1 is basically just a random number, and since the



Nikander and Perkins          Expires 12 October 2001          [Page 21]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   correspondent node does not have the key K_(MN,HA), the token T1
   looks like a random number as well.  However, the Correspondent Node
   MAY record the fact that is has recently received T1 so that it can
   later check that a Binding Key Establishment really matches with some
   recent Binding Warning.


7.3. Generating data for the Binding Request

   To avoid creating state, the Correspondent Node encodes the relevant
   information into a cryptographic token T2.  The same token will be
   included in the Binding Key Establishment, allowing the Correspondent
   Node to check that the Binding Key Establishment actually contains
   the same pieces of information that the Binding Warning did.

   In addition to creating the the token T2, the CN also creates a
   structured nonce N2.  From the protocol point of view, the nonce N2
   is a random number, eventually used to create the keying material
   needed for the BKSA. However, due to the requirement of not creating
   state at this point, the CN cannot simply generate a new random
   number and use it, since that would require that the CN remembered
   the generated number.  Thus, instead, the CN cryptographically
   combines its key K_CN and the received token T1 to create N2.  This
   allows the CN to later reconstruct N2.  N2 inherits randomness from
   both K_CN and T1.

   The CN first generates N2, using the received 128-bit token T1,
   according to the algorithm in section 8.3.  Then T2 is generated
   using the nonce N2, according to the algorithm in section 8.4.

   The implementation MAY also use some other method for generating the
   token T2, or include more information in the generation (like TCP
   port numbers), depending on the state that it wants to protect and
   forget.


7.3.1. Encoding TCP connection

   As an OPTIONAL implementation issue, we describe how the
   Corresponding Node MAY encode initial TCP state into the token T2,
   allowing it to forget TCP state after sending a TCP SYN-ACK along the
   Binding Request.

   Basically, the TCP protocol control block (PCB) created as a result
   of receiving a TCP SYN would contain the following information

    -  16-bit local port number

    -  16-bit remote port number

    -  32-bit local sequence number



Nikander and Perkins          Expires 12 October 2001          [Page 22]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


    -  32-bit remote sequence number

   Since these will be received in a reconstructible way in the
   forthcoming first ACK packet, the implementation MAY opt to encode
   this information into the token T2, and cease creating an explicit
   protocol control block.  The eventual ACK packet will allow this
   information to be reconstructed, and reception of T2 allows the host
   to check that the reconstructed state matches with what is expected.

   To encode the state into T2, [XXX: the details need to be written.]


7.4. Sending the Binding Request

   Once the CN has the nonces N1 and N2 and the tokens T1 and T2
   available, N1 and T1 from the received Binding Warning and N2 and
   T2 as generated above, it is ready send the Binding Request.  The
   Binding Request MUST be sent to the Home Address of the Mobile
   Node, i.e., the address indicated in the Home Address destination
   option of the received packet.  The transmission MUST bypass any
   possibly existing Binding Cache entry for that specific Home Address,
   and there MUST NOT be any mobility related routing headers in the
   resulting packet.

      Allowing non-mobility related routing headers, such as ones
      configured through manual means, should be considered very
      carefully.  There might be legitimate reasons for doing so.
      Likewise, explicit tunneling requires careful study, and
      there are a number of good reasons to permit it.

   That packet has the following headers, in the following order, and
   NOT including any routing header entry formulated from any binding
   cache entry for the mobile node:

        IP header
                destination address := mobile node's Home Address (HoA)
                source address := Correspondent Node address (CNA)
        Routing Header, if present
        Destination Options header, containing
                Home Address option
                Binding Request option
        Fragmentation Header, if present
        IPSec headers, if present
        Upper layer data, if present


   As an example, the upper layer data could be a TCP SYN-ACK packet,
   i.e.  the second packet in TCP three-way handshake.






Nikander and Perkins          Expires 12 October 2001          [Page 23]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


7.5. Forgetting State

   Once the CN has sent the Binding Request to the Home Address, it
   SHOULD forget all state created.  It can simply discard all Binding
   related data since T0 and T2 are given as part of the Binding Key
   Establishment option; together with the key K_CN, this will allow it
   to reconstruct all necessary state variables.  Furthermore, if the CN
   has coded the upper layer state in the T2, it MAY also opt to discard
   upper layer state such as a TCP protocol control block.


7.6. Processing Binding Request at the Home Agent

   As a minimal requirement, Home Agent MUST forward the Binding Request
   to the Mobile Node through the established tunnel, unless it follows
   any of the more specific strategies outlined below.

   The construction of the token T1 makes it possible to the Home
   Agent to verify that the Mobile Node has once generated T1 for the
   very purpose of communicating from the named CoA with the named
   Corresponding Node.  Furthermore, if there is a counter component in
   N1, the Home Agent may also check against replay attacks.  The exact
   details of such a verification are beyond the scope of this document.

   [XXX: Should we give some outline?  I think we should if we decide
   to give a recommendation for the N1 structure.  If we don't, then I
   think that there is no reason to specify the checking here either.]

   In addition to OPTIONALLY checking T1, the Home Agent MAY also modify
   N1, and correspondingly T1, as per mutual agreement between the Home
   Agent and the Mobile Node.  However, such practices go beyond the
   current scope of this specification.


7.7. Processing Binding Request by the Mobile Node

   The Mobile Node will receive the Binding Request as tunneled by the
   Home Agent.  Whenever the Mobile Node is away from home, it MUST
   NOT accept Binding Requests that are sent directly to it instead of
   being tunneled by the Home Agent.  Additionally, if the MN has an
   ESP protected tunnel with the HA, it MUST silently discard Binding
   Requests unless they have been protected with _that_particular ESP
   security association.

   As a part of accepting the Binding Request, the Mobile Node MUST
   check that the outer header has the CoA as the destination address
   and the Home Address as the source address.  If ESP is used, this
   check is typically performed as a part of the ESP policy processing.
   Additionally, it MUST check that the inner header has the Home
   Address as the destination address and the Correspondent Node address
   as the source address.  The check over the inner header destination



Nikander and Perkins          Expires 12 October 2001          [Page 24]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   address MAY also be performed as a part of the ESP policy processing.
   However, checking of the source address of the inner header typically
   has to be performed separately.  The Mobile Node MUST silently drop
   the packet if it fails the tunneling checks.

   Once the Binding Request has passed the tunneling checks, additional
   checks are made.  First, if the MN saved an <N1,CoA> when making
   calculations for sending the Binding Warning (see section 7.1), it
   SHOULD check that the received nonce N1' matches the saved nonce N1,
   taking into account the OPTIONAL modification(s) by the HA, if used.
   Next, the Mobile Node SHOULD check that the received token T1 matches
   with the saved token T1.  In the basic case (no special arrangements
   between the MN and the HA), to perform the check the MN simply either
   uses its saved T1 value or recomputes it, and compares that "right"
   T1 value with the received T1'.  If the MN knows that the HA may have
   changed the T1, the method for verifying T1 depends on the mutual
   agreement between the MN and the HA, and goes beyond the scope of
   this document.

   Once the MN has accepted the Binding Request, it proceeds to
   establish the MN's end of a security association and prepare data for
   the Binding Key Establishment


7.8. Establishing the BKSA

   To establish the Mobile Node's end of the BKSA that is used to
   authenticate the future Binding Updates, the MN generates a new
   random number R. Then it proceeds to create BK from this new
   random number and the nonce N2 received in the Binding Request (see
   section 8.5).

      BK := HASH_BK( R || N2 )

   The MN sets up an outgoing BKSA using the BK as the keying material.
   The policy of the AH security association MUST be set as follows.

    1. The BKSA MUST be only applied if the outgoing packet contains a
       Binding Update.  It MUST NOT be applied if there are no BUs.

    2. The destination address of the packet MUST be the address of the
       Correspondent Node.

   Correspondingly, the MN sets up an incoming BKSA using the BK as the
   keying material.  The policy of this security association MUST be set
   as follows.

    1. The BKSA only protects Binding Acknowledgements.  Unless there
       are additional IPSec protection, the packet is NOT considered
       integrity protected for any other purpose but informing the MN
       that the CN has received and processed the BU. The BKSA MUST NOT



Nikander and Perkins          Expires 12 October 2001          [Page 25]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


       be used for authenticating other packet data, or any fields in
       packets not containing a Binding Acknowledgement.

      DISCUSSION: Should we require that the IPv6 header has some
      particular source or destination IP addresses?  The BKSA
      should already be considered to identify the sender of the
      Binding Update.


7.9. Sending Binding Key Establishment (and Binding Update)

   In addition to R, the Binding Key Establishment option also needs
   T0, the pre-image of the token T1.  Thus, the MN must provide this,
   either by recomputing it from N1 and the addresses, or by saving
   it after making the calculation during processing of the Binding
   Warning, as described in section 6.1.

   To finish its part of the protocol run, the MN sends a packet that
   MUST contain at least the Binding Key Establishment (BKE) option and
   the Home Address option, located in the Destination Options header.
   The BKE option MUST immediately follow the Home Address option.

   Typically the same packet would contain also the Binding Update that
   the MN initially wanted to send.  If so, that Binding Update MUST
   be protected with the newly protected BKSA. The packet would also
   typically contain upper layer data such as a the first real data
   packet within a TCP connection.

   Thus, the packet containing the BKE would appear as follows:

        IP header
                source address := mobile node's care-of Address (CoA)
                destination address := Correspondent Node address (CNA)
        Routing Header, if present
        Destination Options header, containing
                Home Address option
                Binding Key Establishment option
        Fragmentation Header, if present
        IPSec headers, if present
        Destination Options Header, containing
                Binding Update
        Upper layer data, if present


   This packet structure leads to natural processing of the packet
   at the receiver end, allowing it to first verify the Binding
   Key Establishment and create the BKSA before processing the
   Authentication Header.






Nikander and Perkins          Expires 12 October 2001          [Page 26]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


7.10. Receiving Binding Key Establishment

   The CN may, effectively, receive a Binding Key Establishment (BKE)
   option at any time, since it forget about previous Binding Warning
   messages.

   When the CN starts to process the BKE option, it MUST check that
   there has been a Home Address Destination Option earlier in the
   packet.

   To authenticate the BKE option, the CN collects the MN's current
   Care-of-Address from the IP header, the MN's home address from the
   Home Address destination option, and its own IP address from the
   IP header.  It first calculates the token T1, according to the
   algorithm in section 8.2, using the received token T0 from the BKE
   option.  It then recomputes the token T2 according to the algorithm
   in section 8.4, and compares the recomputed T2 with the received T2',
   as found in the received BKE option.  If they are equal, the check
   succeeds.

   Otherwise, if the comparison fails, take the previous K_CN value,
   and recompute the token T2.  The exact number of previous saved
   previous keys and repeated checking attempts is a local policy
   issue.  However, it is RECOMMENDED that at most two previous K_CN
   values are tried.  This limits the amount of resources that a
   resource-exhausting denial-of-service attack may consume.

   As an additional measure against resource-exhausting
   denial-of-service attacks, the host MAY limit the rate in
   which it checks Binding Key Establishment messages.  It MAY also
   dynamically modify the number of additional checking steps that it is
   ready to perform in the case the the first check fails.

   [XXX: Should we just include a random nonce, N3, in the Binding
   Request and BKE? The CN could generate them on short intervals
   similar to the key K_CN. It would be simply sent in clear, and when
   the CN receives it, it would just check that it is recent.  That
   would limit the resource-exhausting DoS attacks.]


7.11. Establishing the CN Security Associations

   Once the Binding Key Exchange has been verified, the CN proceeds to
   establish its BKSA. To do so, it first recomputes the nonce N2, using
   the algorithm in section 8.3, and then combines the nonce N2 with
   the random number R received in the BKE option to generate the same
   keying material (BK) that the MN generated.

   The CN sets up an incoming BKSA using BK as the keying material.  The
   policy of this security association MUST be set as follows.




Nikander and Perkins          Expires 12 October 2001          [Page 27]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


    1. The BKSA only protects the Binding Update.  Unless there is
       additional IPSec protection, the data within the packet is NOT
       integrity protected for any other purpose except entering a new
       care-of address into the CN's binding cache.

    2. The destination address of the packet SHOULD be the CN's address.

   The CN sets up an outgoing BKSA using the BK as the keying material.
   The policy of the security association MUST be set as follows.

    1. The BKSA MUST be only applied if the outgoing packet contains a
       Binding Acknowledgement.  It MUST NOT be applied otherwise.

    2. The destination address of the packet MUST be a home address of
       the Mobile Node.


7.12. Processing the rest of the packet

   The rest of the packet MAY contain an AH header to protect the other
   headers and the payload.  Thus, the rest of the packet is processed
   normally according to the rules in RFC 2406 [3].  The Binding
   Update, including the authentication data, MUST be included in the AH
   computation if the AH is present.


7.13. Reduced operations when the Mobile Node is at home

   If the Mobile Node wants to run the described protocol while it is
   still at home, it MAY do so.  In that case, the Care-of-Address and
   the Home Address will be the same.  However, the packets containing
   the Binding Warning and Binding Key Establishment MUST still contain
   the Home Address destination option.  Thus, the CN implementation
   does not need to care about whether the MN is at home or away from
   home while running the protocol -- from its point of view, the
   protocol will still run the same.

   [XXX: Check SHA-1 and HMAC-SHA-1 input and output sizes.]  [XXX:
   Check source and dest address order in IPv6 header, and update their
   inclusion order in hashes so that you can copy both with a single
   copy instead of requiring two.]

   [XXX: Decide whether to use an additional nonce N3 or not; see the
   discussion in Section 7.10]


7.14. Processing For Correspondent Node Initiation

   In addition to the Mobile Node, the Correspondent Node MAY also want
   to initiate the protocol.  However, in that case some of the threats
   are different.  Especially, since the CN is the initiator and the MN



Nikander and Perkins          Expires 12 October 2001          [Page 28]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   is the responder, it is important to protect the MN from resource
   exhausting denial-of-service attacks.  Thus, from the security point
   of view, the MN initiated and the CN initiated versions of the
   protocol are different cryptographic protocols.  However, the CN
   initiated version has been designed in such a way that almost all of
   the implementation is shared between these two protocol variants.


7.14.1. Initiating the protocol by sending a Binding Request

   When the CN wants to initiate the protocol, it assigns zero for the
   Nonce N1, assigns zero for the Token T1, and generates the Nonce N2
   and Token T2 as defined in Section 7.3.  The values for Nonce N1
   and Token T1 MUST be zero as they signal the MN that this is a CN
   initiated version of the protocol.

   Note that since the key K_CN and the Home Address are used in the
   computation, the generated N2 is hard to predict even when T1 is
   fixed to zero.  On the other hand, since the CN will be creating
   state and therefore will remember N2, it MAY just simply use a random
   number generator to create N2.  The same applies for T2.

   Once the CN has prepared values for nonces N1 and N2 and tokens T1
   and T2, it proceeds to send a Binding Request as usual.  The Binding
   Request MUST be sent to the Home Address of the Mobile Node.

   Since the CN is initiating the protocol, it MUST NOT clear its
   internal state.  Instead it MUST remember that it has initiated the
   protocol with the MN.


7.14.2. Handling a CN initiated Binding Request by a HA

   A Home Agent cannot do much for a CN initiated Binding Request.  The
   optional check of token T1 would fail, but the fact that N1 and T1
   are zero indicate that the protocol was initiated by the CN. In
   particular, the Home Agent SHOULD NOT replace the value T1 with
   another value that would pass the integrity test at the MN.

   [XXX: There may be problems with this approach and the various ways
   we have thought the Home Agent could possibly participate to the
   protocol.  More work is needed here.]


7.14.3. Handling a CN initiated Binding Request by a MN

   When a MN receives a CN initiated Binding Request, zero N1 indicates
   it that it has not itself initiated the protocol this time.

   Now, the MN has basically two different paths to follow.  If it
   determines that it already has traffic going on with the CN, it MAY



Nikander and Perkins          Expires 12 October 2001          [Page 29]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   proceed the fast way and send a Binding Key Establishment packet
   immediately (see below).  For example, the implementation MAY scan
   the active protocol control blocks, and finding a PCB with the CN
   as the remote address can be considered as positive indication that
   there is already traffic going on with the CN.

   On the other hand, if the MN determines that it does not recognize
   the CN, it SHOULD defer creating state and continue in a stateless
   fashion.  Again, there are two options here.  First, the Mobile Node
   MAY decide to ignore the Binding Request completely.  Second, it MAY
   send a Binding Warning in a stateless fashion.

   If the MN decides to create state and send a Binding Key
   Establishment message, it cannot compute T0.  On the other hand, it
   knows that the CN has state.  Thus, to allow the CN to recognize the
   case, it simply sets T0 to zero.  T2 is copied over from the Binding
   Request as usual, and R is a random number as usual.

   If the MN decides to send a Binding Warning in a stateless fashion,
   it proceeds as defined in Section 7.1.  However, in this case the
   Mobile Node SHOULD NOT save the N1 or any other information about
   the fact that it has sent the Binding Warning.  That is, when the MN
   receives a Binding Request from the MN the second time, it notices
   that the Token T1 is a valid one but that there does not exist any
   state, and continues to establish the state (i.e.  BKSA) and send the
   BKE.

   In either case, the resulting BKSA should have fairly short
   timeout.  The timeout can be extended once the MN receives a properly
   authenticated Binding Acknowledgement from the CN.


7.14.4. Further operations at the CN end

   As the CN has state, it will be expecting a Binding Warning or
   Binding Key Establishment.  It will recognize the received Binding
   Warning simply by the addresses.  In that case proceeds normally
   other than that it SHOULD NOT forget its state after sending the
   (second) Binding Request, simplifying checks later on when the BKE is
   received.

   On the other hand, if the CN receives a Binding Key Establishment,
   it will recognize the BKE as a reply to its Binding Request since T0
   is zero, and again use the addresses to find its saved state.  After
   that, it simply checks the received T2' against the remembered T2,
   and proceeds normally.








Nikander and Perkins          Expires 12 October 2001          [Page 30]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


7.15. Simultanous operation by two Mobile Nodes

   In this section, we present a nonexistent discussion about various
   issues when two Mobile Nodes, both acting as a Correspondent Node to
   each other, want to run this protocol at the same time.


8. Cryptographic Algorithms

   The various algorithms for creating tokens and keys are collected in
   this section.  This is done for three reasons:

    -  To make sure the same algorithm is used even when specified at
       different places in the document

    -  To allow for easy modifications if consensus develops within the
       working group

    -  For easy cross-reference throughout the document


8.1. Algorithm for Computing Token T0

   The input for the algorithm HASH_T0 is created by concatenating the
   following data:

    1. N1, the nonce generated by the mobile node for this purpose.

    2. CoA, the mobile node's 128-bit care-of-address

    3. CNA, the 128-bit Correspondent Node address

    4. HoA, the mobile node's 128-bit home-address

   This concatenation (N1 || CNA || CoA || HoA) results in a 512-bit
   bitstring.

   Calculate a hashed MAC, as defined in [4], over the 512-bit
   bitstring, using the key K_(MN,HA). The RECOMMENDED algorithm is
   HMAC-SHA-1 [5], but since the exact algorithm is an issue private
   to the MN and HA, other algorithms can be used according to mutual
   agreement.

   Obtain the result by taking the rightmost 128 bits of the resulting
   HMAC code.  This is called the pre-image of the token T1, called T0.
   This pre-image will be sent to the Corresponding Node as a part of
   the Binding Key Establishment, and therefore the Mobile Node may want
   to save it.  An alternative to saving is to recompute it when needed.






Nikander and Perkins          Expires 12 October 2001          [Page 31]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


8.2. Algorithm for computing token T1

   The input for the algorithm HASH_T1 is created by padding the 128-bit
   T0 to the left with 32 zero bits to form a bitstring with 160 bits.

   Apply basic SHA-1 [5] over the bitstring.

   Obtain T1 (the result) by taking the rightmost 128 bits of the the
   SHA-1 result.


8.3. Algorithm for computing nonce N2

   The data for algorithm HASH_N2 is obtained by concatenating a 128-bit
   (16 byte) zero value and the received 128-bit token T1, resulting in
   a bitstring with 256 bits.

   Calculate a hashed MAC, as defined in [4], over the bitstring, using
   tke key K_CN. The RECOMMENDED algorithm is HMAC-SHA-1 [5], but since
   the exact algorithm is an issue private to the correspondent node,
   the implementation MAY elect to use some other algorithm.

   Obtain the result by taking the rightmost 128 bits of the resulting
   HMAC code.  This is the nonce N2.


8.4. Algorithm for computing token T2

   The input data for algorithm HASH_T2 is obtained by concatenation of
   the following values:

    1. T1, the received 128-bit token generated by the mobile node in
       the Binding Warning destination option

    2. CoA, the mobile node's 128-bit care-of-address, and

    3. CNA, the 128-bit Correspondent Node address from the IP header
       destination address field

    4. HoA, the 128-bit home-address from the Home Address destination
       option

   This concatenation (T1 || CoA || CNA || HoA) results in a 512-bit
   bitstring.

   Calculate a hashed MAC, as defined in [4], over the 512-bit
   bitstring, using the key K_CN. The RECOMMENDED algorithm is
   HMAC-SHA-1 [5], but since the exact algorithm is an issue private to
   the CN, the implementation MAY select to use some other algorithm.





Nikander and Perkins          Expires 12 October 2001          [Page 32]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


   Obtain the result by taking the rightmost 128 bits of the resulting
   HMAC code.  This is the token T2.


8.5. Algorithm for computing key material BK

   The data for algorithm HASH_T2 is obtained by concatenation of the
   following values:

    1. R, the random number generated for this purpose by the mobile
       node and included in the Binding Key Establishment message

    2. N2, the 128-bit nonce calculated by the correspondent node and
       delivered to the mobile node in the Binding Request message.

   This concatenation (R || N2) results in a 256-bit input bitstring.

   KeyMat := MD5( R || N2 )

   Obtain the result by hashing (using MD5 [8]) the 256-bit input.  This
   is the desired key material BK.


9. Protocol Data Unit Formats

9.1. Binding Warning Message

   A mobile node may use the Binding Warning destination option to
   enable a correspondent node to initiate the process of establishing a
   Binding Key for use when authenticating its Binding Update messages.


       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
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  | Option Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Nonce N1 (128 bits)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Cryptographic Token T1 (128 bits)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Figure 1: The Binding Warning Destination Option format










Nikander and Perkins          Expires 12 October 2001          [Page 33]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


      Nonce N1   A 128-bit opaque value.

      Token T1   A 128-bit hashed value, computed over the addresses
                 involved.

   See section 7.1 for processing details on the selection of the Nonce
   N1, and the calculation of the Cryptographic Token T1.


9.2. Binding Request Message

   A correspondent node may use the Binding Request destination option
   to transmit key material to a mobile node.


       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
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  | Option Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Nonce N1 (128 bits)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Cryptographic Token T1 (128 bits)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Structured Nonce N2 (128 bits)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Cryptographic Token T2 (128 bits)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Figure 2: The Binding Request Destination Option format


      Nonce N1   A 128-bit opaque value, copied over from corresponding
                 value in the Binding Warning sent from the mobile node.

      Token T1   A 128-bit hashed value, copied over from corresponding
                 value in the Binding Warning sent from the mobile node.

      Nonce T2   A 128-bit hashed value created using a new nonce and
                 the information from the mobile node.

      Token T2   A 128-bit authentication token which includes all
                 information whose integrity must be protected, as well
                 as T1

   See sections 7.3 and 6.2 for details on the the calculation of the
   Structured Nonce N2, and the Cryptographic Token T2.  Including T1
   into the authentication token T2 helps to block active attacks later
   in the protocol.




Nikander and Perkins          Expires 12 October 2001          [Page 34]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001



9.3. Binding Key Establishment Destination Option

   A mobile node may use the Binding Key Establishment destination
   option to transmit key material to a correspondent node.

      Lifetime   A 32-bit value specifying the lifetime of the BKSA in
                 seconds.

      Nonce N1   A 128-bit opaque value, copied over over from the
                 information in the Binding Request.

      Token T0   A 128-bit hashed value, previously computed and
                 possibly saved when sending the Binding Warning.

      Token T2   A 128-bit authentication token which is copied over
                 from the information in the Binding Request.

      Random R   A 128-bit random number, used as the second half of the
                 keying material to be created.

   See sections 6.2 and 8 for details on the the calculation of the
   Cryptographic Tokens T0 and T2.  The mobile node SHOULD check that
   the nonce N1 corresponds to the nonce which it sent in the Binding
   Warning message to the correspondent node.



       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
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |  Option Type  | Option Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Lifetime (32 bits)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Nonce N1 (128 bits)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Cryptographic Token T0 (128 bits)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Cryptographic Token T2 (128 bits)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Random Number (128 bits)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Figure 3: The Binding Key Establishment
                       Destination Option format








Nikander and Perkins          Expires 12 October 2001          [Page 35]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


Acknowledgements

   We would like to thank the members of the Mobile IP and IPng Working
   Groups for their comments and suggestions on this work.  We would
   particularly like to thank (in alphabetical order) Francis Dupont
   (ENST Bretagne)
















































Nikander and Perkins          Expires 12 October 2001          [Page 36]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


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).
       draft-ietf-mobileip-ipv6-13.txt, October 2000.

   [3] S. Kent and R. Atkinson.  IP Encapsulating Security Payload
       (ESP).  Request for Comments (Proposed Standard) 2406, Internet
       Engineering Task Force, November 1998.

   [4] H. Krawczyk, M. Bellare, and R. Canetti.  HMAC: Keyed-Hashing for
       Message Authentication.  Request for Comments (Informational)
       2104, Internet Engineering Task Force, February 1997.

   [5] C. Madson and R. Glenn.  The Use of HMAC-SHA-1-96 within ESP and
       AH.  Request for Comments (Proposed Standard) 2404, Internet
       Engineering Task Force, November 1998.

   [6] T. Narten and C. E. Perkins.  Privacy Extensions for Stateless
       Address Autoconfiguration in IPv6, January 2001.

   [7] P. Nikander.  An Address Ownership Problem in IPv6 (work in
       progress).  draft-nikander-ipng-address-ownership-00.txt,
       February 2001.

   [8] R. Rivest.  The MD5 Message-Digest Algorithm.  Request for
       Comments (Informational) 1321, Internet Engineering Task Force,
       April 1992.






















Nikander and Perkins          Expires 12 October 2001          [Page 37]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


Chair's Address

   The Working Group can be contacted via its current chairs:

        Phil Roberts
        Motorola
        1501 West Shure Drive
        Arlington Heights, IL 60004

        Phone:  +1 847 632-3148
        E-mail: qa3445@email.mot.com


        Basavaraj Patil
        Nokia
        6000 Connection Drive
        M/S M8-540
        Irving, TX 75039
        USA

        Phone:  +1 972 894-6709
        Fax:    +1 972 894-5349
        E-mail: raj.patil@nokia.com































Nikander and Perkins          Expires 12 October 2001          [Page 38]


INTERNET-DRAFT  Binding Authentication Key Establishment   12 April 2001


Authors' Addresses

   Questions about this document can also be directed to the authors:

        Pekka Nikander
        Ericsson Research NomadicLab
        Espoo, Finland
        phone: +358-40-721 4424
        email: Pekka.Nikander@nomadiclab.com


        Charles Perkins
        Nokia
        313 Fairchild Drive
        Mountain View, CA 94043
        USA

        Phone:  +1 650 625-2986
        Fax:    +1 650 625-2502
        E-mail: charliep@iprg.nokia.com


































Nikander and Perkins          Expires 12 October 2001          [Page 39]