[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

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


   Binding Authentication Key Establishment Protocol for Mobile IPv6
                      <draft-perkins-bake-01.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 certain 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 2 January 2002           [Page i]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 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                                                       5
     3.1. Beliefs held by the CN  . . . . . . . . . . . . . . . . .    5
     3.2. Beliefs held by the MN  . . . . . . . . . . . . . . . . .    6
     3.3. Optional Beliefs  . . . . . . . . . . . . . . . . . . . .    6

 4. Design principles                                                  6
     4.1. Low computational overhead  . . . . . . . . . . . . . . .    7
     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 BSA . . . . . . . . . . . . . . . . .    9
     4.8. Protection against Future Address Stealing  . . . . . . .    9

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

 6. Cryptographic Design Analysis                                     12
     6.1. Message 1:  Binding Warning . . . . . . . . . . . . . . .   13
     6.2. Message 2:  Binding Key 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. Tunnel Protection . . . . . . . . . . . . . . . . . . . .   18

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



Nikander and Perkins          Expires 2 January 2002           [Page ii]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


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

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

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

Acknowledgements                                                      34

References                                                            34

 A. Correspondent Node Initiated Operation                            36

 B. An open question about this draft                                 37

Chair's Address                                                       39

Authors' Addresses                                                    39














Nikander and Perkins          Expires 2 January 2002          [Page iii]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 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
   or trusted third party based security infrastructure, 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 Key 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 security associations with
      IKE/AAA/whatever.  Thus, from that point of view, this
      protocol is just a special purpose key management protocol,
      able to create only security associations for securing
      Binding Updates.

   In this protocol specification, several new messages are introduced:




Nikander and Perkins           Expires 2 January 2002           [Page 1]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


      Binding Warning
                which is sent by a mobile node to a correspondent node
                as an indication that a new care-of address should be
                obtained for the one of the mobile node's addresses.

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

      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.






Nikander and Perkins           Expires 2 January 2002           [Page 2]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


      Binding Warning Packet
                any packet containing a Binding Warning destination
                option

      BKE Packet
                any packet containing a Binding Key Establishment
                destination option

      Binding Key Request Packet
                any packet containing a Binding Key Request destination
                option

      Binding Key
                a key used for authenticating Binding Update messages.

      Security Association
                a security object shared between two nodes which
                includes the data mutually agreed on for operation of
                some cryptographic algorithm (typically including a key,
                as defined above).

      Binding Security Association (BSA)
                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.  See
                section 6.5.


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




Nikander and Perkins           Expires 2 January 2002           [Page 3]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


      CNA       The (IPv6) address of the correspondent node

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

      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 a mobile node and its home agent.

      PCB       Protocol Control Block (used by TCP)

      N1        A nonce created by the mobile node for use in the
                Binding Warning, and eventually used to identify the
                Binding Key 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.

      N_BK      A random number created by the mobile node after
                reception of the Binding Key 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 Key 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)




Nikander and Perkins           Expires 2 January 2002           [Page 4]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


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


3. Design goals

   The protocol MUST fulfill 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
   "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 sent and received by the CN, or




Nikander and Perkins           Expires 2 January 2002           [Page 5]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


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

        *  eavesdrop all traffic sent 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.

    -  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 this section, 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




Nikander and Perkins           Expires 2 January 2002           [Page 6]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


    -  Allows inband establishment for the Binding Security Association
       (BSA)

    -  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 that node
   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 not require any heavy computation by the MN as the MN may have
   significant processing limitations.


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

   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.


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.





Nikander and Perkins           Expires 2 January 2002           [Page 7]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


    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.

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





Nikander and Perkins           Expires 2 January 2002           [Page 8]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   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.

      DISCUSSION: Some people have suggested to use
      (unauthenticated) Diffie-Hellman (D-H) instead of
      simply combining two independent random numbers through
      a one-way hash.  From the security point of view, that
      would have the benefit of protecting the generated
      key against those passive attackers that are able to
      eavesdrop both halves of the key.  However, unless properly
      authenticated, it would NOT provide any more security
      against active attackers.  Thus, given the additional
      complexity and computational overhead, i.e.  the requirement
      of implementing a big integer library and calculating
      big integer exponetiations, we do not consider the added
      security worth the added trouble.  (See also section B.)


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 BSA

   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 (BSA)
   after receiving the message from the correspondent node, and that the
   CN is able to create the same BSA 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

   Future address stealing [8] is a vulnerability whereby an adversary
   may be able to usurp ownership of an address which would likely be
   claimed by a mobile node some time in the future.  To protect against
   this threat", the mobile nodes SHOULD use random CoAs [7].




Nikander and Perkins           Expires 2 January 2002           [Page 9]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


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 Key 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 Key Request to the Home Address of the MN. The
       packet 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 Key Request, passed via
       the tunnel and originated by the Correspondent Node, it creates a
       BSA that will be used to secure Binding Updates.

       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 BSA that the Mobile Node
       created after the Binding Key Request message.

   At the conclusion of the protocol, a BSA 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,



Nikander and Perkins          Expires 2 January 2002           [Page 10]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   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.

   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 endpoint (in
   the Binding Cache) which the home agent maintains for it, using a
   pre-established BSA. 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 2 January 2002           [Page 11]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 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 the mobile 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 2 January 2002           [Page 12]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 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 sections 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 as the original source of
   T1.

   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 SHOULD 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 Key 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, T2, 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 2 January 2002           [Page 13]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   When 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.  Including T1 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 2 January 2002           [Page 14]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   In any case, the HA forwards (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 Key Request, it has the
   following knowledge set:

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

   The mobile node must first check that the addresses match.  The CoA
   is implicitly checked by receiving the message.  The mobile node MUST
   explicitly check that the message was 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
   Key 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.

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

   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 message may have been intercepted and modified by an active
   attacker.  If the active attacker was able to intercept the Binding
   Warning 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



Nikander and Perkins          Expires 2 January 2002           [Page 15]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


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

   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 N_BK, and then
   combines the nonce N2 with it, according to the algorithm HASH_BK:

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

   Even though neither N2 nor N_BK are hidden (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 N_BK 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 N_BK to the CN.

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

   When 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 2 January 2002           [Page 16]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 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 N_BK, 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 Key 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 we do not presuppose any security associations
   between the MN and CN.

      DISCUSSION: It might be possible, though, to use the Home
      Address as a pre-established security context, as indirectly
      suggested in  [8] and directly in [6].  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



Nikander and Perkins          Expires 2 January 2002           [Page 17]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


      peer review before its security can be considered known.
      However, maybe a mechanism based 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 N_BK.
   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 N_BK.
   However, producing falsified third packet is hard unless the attacker
   is able to intercept the real third packet.  Otherwise 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. Tunnel Protection

   There are three ways that the tunnel between the home agent and the
   mobile node can be protected against attack.

    -  The home agent can encrypt all packets destined for the mobile
       node, e.g., with ESP. This is the RECOMMENDED method.

    -  The home agent can disturb some of the data fields of the BKE
       message in some way that has been arranged in advance with the
       mobile node, beyond the scope of this specification.

    -  The home agent can insert some additional options, not defined in
       this specification.


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



Nikander and Perkins          Expires 2 January 2002           [Page 18]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


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

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

   [CEP: Yes, we should]

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






Nikander and Perkins          Expires 2 January 2002           [Page 19]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   As shown, the packet MAY also contain higher-level protocol payload.
   For example, the upper layer data could be a TCP SYN packet, The
   Mobile Node MUST save the <N1,CoA,CNA> triplet so that it can more
   effectively match the Binding Key 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 Key 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 state is to protect the CN from memory
   exhausting Denial-of-Service attacks.  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
   correspondent node does not have the key K_(MN,HA), the token T1
   appears random number as well.


7.3. Generating data for the Binding Key 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 BSA. 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




Nikander and Perkins          Expires 2 January 2002           [Page 20]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


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

    -  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 Key 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 Key Request.  The
   Binding Key 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 Binding Warning packet.  The transmission MUST
   bypass any possibly existing Binding Cache entry for that specific




Nikander and Perkins          Expires 2 January 2002           [Page 21]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   Home Address, and there MUST NOT be any routing headers containing
   any of the mobile node's care-of addresses 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.

   The Binding Key Request packet has the following headers, in the
   following order:

        IP header
                destination address := mobile node's Home Address (HoA)
                source address := Correspondent Node address (CNA)
        Routing Header, if present (no mobile node CoA)
        Destination Options header, containing
                Home Address option
                Binding Key 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.


7.5. Forgetting State

   Once the CN has sent the Binding Key Request packet 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 Key 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.



Nikander and Perkins          Expires 2 January 2002           [Page 22]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   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.  See section 6.5.


7.7. Processing Binding Key Request by the Mobile Node

   The Mobile Node will receive the Binding Key Request as tunneled by
   the Home Agent.  Whenever the Mobile Node is away from home, it MUST
   NOT accept Binding Key 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 Key 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 (HoA) as the destination address and the Correspondent Node
   address (CNA) as the source address.  The check over the inner header
   destination 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 Key Request has passed the tunneling checks, further
   checks are made.  First, if the MN saved a <N1,CoA,CNA> 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
   (see 6.5).  Next, the Mobile Node SHOULD check that the received
   token T1' matches with the saved/recomputed 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
   T0 and T1, and compares the recomputed 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 Key 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 BSA

   To establish the Mobile Node's end of the BSA that is used to
   authenticate the future Binding Updates, the MN generates a new



Nikander and Perkins          Expires 2 January 2002           [Page 23]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   random number N_BK. Then it proceeds to create BK from this new
   random number and the nonce N2 received in the Binding Key Request
   (see section 8.5).

      BK := HASH_BK( N_BK || N2 )

   The MN sets up an outgoing BSA using the BK as the keying material.
   The policy of the BSA MUST be set as follows.

    1. The BSA 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 BSA using the BK as the
   keying material.  The policy of this security association MUST be set
   as follows.

    1. The BSA only protects Binding Acknowledgements.  Unless there
       is 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 BSA MUST NOT
       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 BSA
      should already be considered to identify the sender of the
      Binding Update.


7.9. Sending Binding Key Establishment (and Binding Update)

   In addition to N_BK, 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
   <N1,CoA,CNA,T0> 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 new BSA. The packet would also typically contain
   upper layer data such as a the first real data packet within a TCP
   connection.




Nikander and Perkins          Expires 2 January 2002           [Page 24]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   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 BSA before processing the Binding Update
   Header.


7.10. Receiving Binding Key Establishment

   To the CN it may, effectively, appear to receive a Binding Key
   Establishment (BKE) option at any time, since it is likely to 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
   destination options header.

   To authenticate the BKE option, the CN collects the MN's current
   Care-of-Address from the IP header, the MN's home address (HoA) from
   the Home Address destination option, and its own IP address (CNA)
   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, the CN repeats the attempted
   verification using the next previous K_CN value, and recomputes 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 three previous K_CN values are tried.
   This limits the amount of resources that a resource-exhausting
   denial-of-service attack may consume.





Nikander and Perkins          Expires 2 January 2002           [Page 25]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   As an additional measure against resource-exhausting
   denial-of-service attacks, the correspondent node 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.


7.11. Establishing the CN Security Associations

   Once the Binding Key Exchange has been verified, the CN proceeds to
   establish its BSA. 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 N_BK received in the BKE option to generate the same
   keying material (BK) that the MN generated.

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

    1. The BSA 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 BSA using the BK as the keying material.
   The policy of the security association MUST be set as follows.

    1. The BSA 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.  In that case, the rest of the packet is
   processed normally according to the rules in RFC 2406 [3].


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




Nikander and Perkins          Expires 2 January 2002           [Page 26]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


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


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
   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. CN Initiation by sending a Binding Key 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 Key Request as usual.  The
   Binding Request MUST be sent to the Home Address of the Mobile Node.

   When the CN is initiating the protocol (see appendix A, 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 Key Request by a HA

   A Home Agent cannot do much for a CN initiated Binding Key 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




Nikander and Perkins          Expires 2 January 2002           [Page 27]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   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 Key Request by a MN

   When a MN receives a CN initiated Binding Key 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
   proceed the fast way and send a BKE 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 Key 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 N_BK 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 T1 or any other information about
   the fact that it has sent the Binding Warning.  That is, when the
   MN receives a Binding Key Request from the CN 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.  BSA) and
   send the BKE.

   In either case, the resulting BSA 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



Nikander and Perkins          Expires 2 January 2002           [Page 28]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


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


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



Nikander and Perkins          Expires 2 January 2002           [Page 29]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


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


8.2. Algorithm for computing token T1

   The input data 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 input 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




Nikander and Perkins          Expires 2 January 2002           [Page 30]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


    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.

   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. N_BK, 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 Key Request message.

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

   KeyMat := MD5( N_BK || N2 )

   Obtain the result by hashing (using MD5 [9]) 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.

      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.





Nikander and Perkins          Expires 2 January 2002           [Page 31]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


       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



9.2. Binding Key Request Message

   A correspondent node may use the Binding Key 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 Key Request Destination Option format

















Nikander and Perkins          Expires 2 January 2002           [Page 32]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


      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 N2   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 some active attacks.


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.
































Nikander and Perkins          Expires 2 January 2002           [Page 33]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


       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 N_BK (128 bits)                 =
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Figure 3: The Binding Key Establishment
                       Destination Option format


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

      Nonce N1   A 128-bit opaque value, copied over over from the
                 information in the Binding Key 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 Key Request.

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


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) N Asokan (Nokia)
   Francis Dupont (ENST Bretagne) Michael Thomas (Cisco)






Nikander and Perkins          Expires 2 January 2002           [Page 34]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 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] G. Montenegro and C. Castelluccia.  Statistically Unique and
       Cryptographically Verifiable Identifiers (work in progress).
       draft-montenegro-sucv-00.txt, April 2001.

   [7] T. Narten and R. Draves.  Privacy Extensions for Stateless
       Address Autoconfiguration in IPv6, January 2001.

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

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


















Nikander and Perkins          Expires 2 January 2002           [Page 35]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


A. 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 BSA
   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 >
      MN->CN: < CoA, CNA, HoA, T2, N_BK >


   Here the token T2 assures freshness of the BKE message.  On the other
   hand, the MN has no way of determining if the first Binding Key
   Request 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
   Key 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.



Nikander and Perkins          Expires 2 January 2002           [Page 36]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   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 Key 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', N_BK >


   As said, the crucial issue here is to ensure that the MN does not
   need to create state when it receives the first Binding Key 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 Key Request, and let the MN to check
   this coverage upon receiving the second Binding Key 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
      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.]


B. An open question about this draft

   We are currently considering whether we should add authenticated
   Diffie-Hellman (D-H) support as an option.  One suggested way to
   accomplish this is to unify the first message (Binding Warning)
   of this protocol with the first message of some other protocol
   supporting D-H, e.g. [6].  Another way would be to further complicate
   this protocol and explicitly allow D-H based key exchange, combined
   with strong authentication, in messages 2 and 3 (Binding Key Request
   and Binding Key Establishment).

   In any case, we do not currently see much value of adding
   non-authenticated D-H support to this protocol, since such an
   extension would be equally vulnerable to active attacks, and the



Nikander and Perkins          Expires 2 January 2002           [Page 37]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


   added protection against passive attacks does not pay off the added
   complexity.




















































Nikander and Perkins          Expires 2 January 2002           [Page 38]


INTERNET-DRAFT   Binding Authentication Key Establishment    2 July 2001


Chair's Address

   The Working Group can be contacted via its current chairs:

       Basavaraj Patil                       Phil Roberts
       Nortel Networks Inc.                  Megisto Corp.
                                             Suite 120
       2201 Lakeside Blvd.                   20251 Century Blvd
       Richardson, TX. 75082-4399            Germantown MD 20874
       USA                                   USA
       Phone:  +1 972-684-1489               Phone:  +1 847-202-9314
       Email:  bpatil@nortelnetworks.com     Email:  PRoberts@MEGISTO.com

Authors' Addresses

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


     Pekka Nikander                     CharlesCE.oPerkinsmmunications Systems Lab
     Ericsson Research NomadicLab
     P.O.BOX 58                         Nokia3Research1Center3 Fairchild Drive
     FIN-02131 ESPOO
     Finland                            MountainUView,SCaliforniaA94043
     Phone:  +358-40-721-4424
     Pekka.Nikander@nomadiclab.com      Phone:Em+1-650a625-2986il:  charliep@iprg.nokia.com
     Fax:  +358-9-299-5055              Fax:  +1 650 625-2502




























Nikander and Perkins          Expires 2 January 2002           [Page 39]