Network Working Group                                          Feng BAO
INTERNET-DRAFT                                              Robert DENG
Expires: February 9, 2005                                      Ying QIU
Network Working Group                                     Jianying ZHOU
                                   Institute for Infocomm Research(I2R)
                                                        August 10, 2004



             Certificate-based Binding Update Protocol (CBU)
           <draft-qiu-mip6-certificated-binding-update-02.txt>


Status of this Memo

   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.

   This Internet-Draft will expire on February 9, 2005.


Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


Abstract

   This document proposes a comprehensive security solution for mobile
   IPv6 networks including secure binding update, secure fast handover,
   user authentication and session key management for data security. In
   our proposal, one of the home agent's functions is to act as
   security proxy for its mobile nodes. The authentication is based on
   the home agent's certificate and the secret session keys are
   generated by strong cryptosystems. Our proposal avoids many security
   obstacles in the Return Routability protocol and provides a simple,
   integrated and efficient security solution for mobile communication.


Expires: February 9, 2005                                      [Page 1]


Internet Draft                  CBU                     August 10, 2004


Table of Contents

   1.  Introduction ................................................. 2
   2.  Notations .................................................... 4
   3.  Certificate-based Binding Update Protocol(CBU) ............... 4
   4.  Use of CBU: Secure Binding Update between Two Mobile Nodes .. 10
   5.  Use of CBU: Implementation of CBU in HMIPv6 ................. 11
   6.  Security Considerations ......................................13
   7.  Conclusion ...................................................13
   8.  Acknowledgements .............................................14
   9.  References ...................................................15
   10. Authors' Addresses ...........................................15
   A.  Change Log ...................................................16
   Intellectual Property and Copyright Statements ...................16



1. INTRODUCTION

   The demand for mobile communication requires a solution for
   efficient authentication of mobile nodes and protection of
   communications between mobile nodes. Presently, the IETF mobile
   working group has submitted two major drafts on mobile connection:

   i)  "Mobility Support in IPv6 (MIPv6)"[1], which specifies a
       protocol that allows mobile nodes to remain reachable while
       moving around in the IPv6 Internet, and
   ii) "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)"[2],
       which introduces extensions to Mobile IPv6 and IPv6 Neighbour
       Discovery to allow for local mobility handling.

   Figure 1 illustrates the topology of communications among Mobile
   Node (MN), Correspondent Node(CN), Home Agent(HA) and Mobility
   Anchor Point (MAP). Under this architecture, the major security
   issue is how to authenticate MN by CN and MAP and how to protect
   communications in channels of MN-HA, MN-CN, HA-CN, MAP-MN and
   MAP-HA.


                            CN ------ HA
                             |       /|
                             |     /  |
                             |   /    |
                             | /      |
                            MN ----- MAP

           Figure 1: Topology and protected channels in MIPv6.





Expires: February 9, 2005                                      [Page 2]


Internet Draft                  CBU                     August 10, 2004


   In the Mobile IPv6 [1], a method of Return Routability(RR) is used
   to process Binding Updates(BU). However, RR cannot provide satisfied
   level of security. Therefore, the working group suggests to bundle
   IKE[3] for improving the authentication ability and protecting the
   communication channel MN-HA.

   The original goal of RR was to provide a simple way to protect the
   signals of binding update. But it is now used with IKE and IPsec for
   higher security requirement. Consequently, many patches for RR are
   introduced to solve the above issues, and the RR solution becomes
   more and more complicated. For example, in order to handle the
   scenario of two mobile nodes in simultaneous movement, a new RR
   model is introduced: one deals with fixed CN while another deals
   with mobile CN.

   Even worse, due to the heavy computing overheads, IKE is not
   suitable for mobile devices (e.g., mobile phone, etc.) with very
   limited computing power and battery lifetime.

   In this document, we propose a comprehensive security solution for
   mobile IPv6 networks and try to provide a simple, integrated and
   efficient security solution for mobile communication.

   In our solution, all the security features, such as secure binding
   update, seamless secure fast handover, user authentication, session
   key management for data security, etc., are provided within one
   framework.

   In this solution, the home agent handles strong authentication for
   its mobile nodes and the authentication process is mainly run
   between wired devices (i.e., a home agent and a wired correspondent
   node or the home agent of a mobile correspondent node). Moreover,
   the complicated session key management and security association
   management are also deployed on the home agent. The motivation
   behind this is that home agents are fixed machines with rich
   computing capability and are connected to wired networks with a much
   broader bandwidth and more stable connection than mobile networks.
   Therefore, our solution could keep the balance well between the
   strong security requirements for e-commerce and the weak capability
   of mobile devices in terms of computing power and communicating
   speed.











Expires: February 9, 2005                                      [Page 3]


Internet Draft                  CBU                     August 10, 2004


2. NOTATIONS

   The notations used throughout this paper are listed below for easy
   reference:

   h():  a one-way hash function, such as MD5 or SHA.
   prf(k, m):  a keyed pseudo random function -- often a keyed hash
      function. It accepts a secret key k and a message m, and
      generates a pseudo random output. This function is used for both
      message authentication and cryptographic key derivations.
   e(k ,m):  encryption of message m with a secret key k.
   Px/Sx:  a public and private key pair of node X in a digital
      signature scheme such as RSA or DSS.

   Sig(Sx, m):  node X's digital signature on a message m using a
      private key Sx.
   m|n: concatenation of two messages m and n.


3. CERTIFICATE-BASED BINDING UPDATE PROTOCOL(CBU)

   In CBU protocol, the digital signature cryptosystem is used. The
   public/private key pair of HA is denoted by PK_HA and SK_HA. The
   private key SK_HA is kept by HA in the home link, probably inside
   a tamper-resistant hardware of cryptogram processing device. The
   home link obtains a public key certificate,

        Cert_HA = {HLSP, PK_HA, Valid_Interval, SIG_CA}

   from a Certification Authority(CA), where HLSP is the home link
   subnet prefix, Valid_Interval is the valid duration of the
   certificate, and SIG_CA is CA's signature on HLSP, PK_HA and
   Valid_Interval.

   Figure 2 shows message exchange between a mobile node MN, its home
   agent HA and its correspondent node CN in CBU protocol. The
   existence of and operations performed by HA are made transparent to
   CN.

   The use of cookies during the key exchange is a weak form of
   protection against an attacker who generates a series of request
   packets, each with a different spoofed source IP address, and sends
   them to a protocol party. For each request, the protocol party will
   first validate cookies before performing computational expensive
   public key cryptographic operations. Below is a detailed description
   of the CBU protocol.

   When a mobile node MN wants to start route optimization operation
   with a correspondent node CN, it sends a route optimization request



Expires: February 9, 2005                                     [Page 4]


Internet Draft                 CBU                      August 10, 2004



                MN             HA             CN
                |              |              |
                |=====REQ=====>|===COOKIE0===>|
                |              |              |
                |              |<===COOKIE1===|    long term
                |              |              |    messages
                |              |====EXCH0====>|
                |              |              |
                |<=====REP=====|<====EXCH1====|
                |              |              |
         ------------------------------------------------------
                |              |              |
                |======BU====================>|
                |              |              |    short term
                |<====================BA======|  message for BU
                |              |              |
                |------BC-------------------->|
                |              |              |
         ------------------------------------------------------
                |              |              |
                |===REQ_KEY===>|===EXCH0'====>|    short term
                |              |              |  message for k_EN
                |<====NEWKEY===|<===EXCH1'====|
                |              |              |

            Figure 2. Message exchange in CBU protocol.



        REQ = {Src=HoA, Des=HA, e(k_HA, HoA, CoA, CN, N0 )}

   to HA via IPsec-protected secure tunneling. Here, HA represents both
   the home agent and its IP address while CN represents both the
   correspondent node and its IP address. N0 is a nonce used to match
   the reply message REP. k_HA is a session key for the IPsec secure
   tunnel, its initial value is a pre-shared secret value z which is
   generated by HA before MN leaves its home link. How to update the
   session key will be described later. IPsec provides replay
   protection only when dynamic security association establishment is
   used. This may not always be possible and manual keying might be
   preferred in certain circumstances. For this reason, a random number
   N0 is included in order to counter message replay.

   After decrypting the REQ message and verifying HoA, HA creates a
   cookie C0 and sends

        COOKIE0 = {Src=HoA, Des= CN, C0}

   to CN. In reply, CN generates a nonce N1 and a cookie C1, and sends


Expires: February 9, 2005                                     [Page 5]


Internet Draft                  CBU                     August 10, 2004


        COOKIE1 = {Src=CN, Des=HoA, C0, C1, N1}

   to MN. Note that the destination address in COOKIE1 is MN's home
   address HoA. As a result, this message is delivered to MN's home
   link and intercepted by HA using IPv6 Neighbor Discovery.

   Upon receiving COOKIE1, HA checks on the validity of C0, generates a
   nonce N2 and a Diffie-Hellman secret value x < p, computes its
   Diffie-Hellman public value g^x and its signature

        SIG_HA = Sig(SK_HA,  HoA | CN | g^x | N1 | N2 | TS)

   using home link's private key SK_HA, where TS is a time stamp. This
   time stamp does not have to be checked by the recipient during the
   message exchange. It will be used to trace back the culprit should a
   malicious mobile node flooding attack have occurred. Finally, HA
   replies CN with

        EXCH0 = {Src=HoA, Des= CN, C0, C1, N1, N2, g^x,
                TS, SIG_HA, Cert_HA},

   where Cert_HA is the public key certificate of the home link as
   defined before. Note that the values of N1 and N2 are included in
   the signature SIG_HA in order to counter replay of old signatures
   and to resist chosen message attacks to the signature scheme,
   respectively.

   When CN receives EXCH0, it validates the cookies, the home link's
   public key certificate Cert_HA, the signature and more importantly,
   checks for equality of the home link subnet prefix strings embedded
   in both Cert_HA and HoA. If all the validations and checking are
   positive, CN can be confident that the home address HoA of MN is
   authorized by its home link and the Diffie-Hellman public vaule g^x
   is freshly generated by MN's home link. CN next generates its
   Diffie-Hellman secret value y < p. It then computes its Diffie-
   Hellman public value g^y, the Diffie-Hellman key

        k_DH = (g^x)^y,

   a master secret

        k_master = prf(k_DH, N1 | N2 ),

   and three secret session keys

        k_BU = prf(k_master, N1 | N2 | 0),
        k_BA = prf(k_master, N1 | N2 | 1),
        k_EN = prf(k_master, N1 | N2 | 2),




Expires: February 9, 2005                                     [Page 6]


Internet Draft                  CBU                     August 10, 2004


   where k_BU is the binding key used for authenticating binding update
   messages from MN to CN, k_BA is the acknowledgement key used for
   authenticating binding acknowledge messages from CN to MN, and k_EN
   is the encryption key used for encrypting/decrypting packets between
   MN and CN. Then CN sends MN

        EXCH1 = {Src=CN, Des= HoA, C0, C1, g^y, SIG_CN, Cert_CN},

   where

        SIG_CN = Sig(SK_CN, CN | HoA | g^y | EXCH0).
   and
        Cert_CN = {CN, PK_CN, Valid_Interval, SIG_CA}

   is CN's certificate from CA, and CN could be CN's IP address (if CN
   is a wired terminal node) or CN's home link subnet prefix (if CN is
   a server-supported mobile node). Therefore, both parties MN and CN
   could identify each other, which will be useful for setting up
   access control on MN (or HA) and CN.

   Again, this message is intercepted by HA, which first validates the
   cookies, calculates the Diffie-Hellman key k_DH = (g^y)^x and the
   master secret k_master = prf(k_DH, N1|N2). HA also generates the
   secret session keys

        k_BU = prf(k_master, N1|N2|0),
        k_BA = prf(k_master, N1|N2|1),
        k_EN = prf(k_master, N1|N2|2)
   and
        k_HA-next = prf(z, N0 | N1 ),

   where k_HA-next is the IPsec session key used for the IPsec-
   protected tunnel between MN and HA. Then HA sends

        REP = {Src= CN, Des=CoA, payload}

   to MN through IPsec-protected secure tunneling, where

        payload = e(k_HA, N0, k_BU, k_BA, k_EN, k_HA-next).

   Please note, we use the current k_HA to encrypt the next k_HA-next,
   which will be kept by both MN and HA for next use when MN sends a
   new REQ to HA.









Expires: February 9, 2005                                     [Page 7]


Internet Draft                  CBU                     August 10, 2004


   Considering the REP message might be lost during the transfer, HA
   should keep the previous k_HA until it confirms MN had used the new
   k_HA. If MN did not receive the REP message after a reasonable
   interval, it will resend the REQ message. First, HA use its current
   k_HA(i.e. k_HA-next here) to decrypt the REQ message. If HA cannot
   get a HoA that is belonged to its home link subnet, it will use the
   previous k_HA(i.e. k_HA here) to decrypt the REQ message again.
   After verifying HoA, HA can simply resend the REP message to MN.

   After receiving REP, MN decrypts the payload with the current k_HA
   and checks whether N0 is the same as the one it sent out in REQ. If
   so, MN proceeds to send a binding update message

        BU = {Src=CoA, Des=CN, HoA, Seq#, LT_BU, MAC_BU}

   to CN, where

        MAC_BU = prf(k_BU, HoA | CoA | Seq# | LT_BU)

   is a MAC generated with k_BU to authenticate the BU message, Seq# is
   a sequence number used to detect replay attack, and LT_BU is the
   lifetime of the binding. If BU is verified positive, CN may reply
   with a binding acknowledgement message

        BA = {Src=CN, Des=CoA, HoA, Seq#, LT_BA, LT_EN, MAC_BA},

   where Seq# is copied from the BU message, LT_BA is the granted
   lifetime of the binding, LT_EN is the lifetime of k_EN, and

         MAC_BA = prf(k_BA, CoA | CN | Seq# | LT_BA  | LT_EN)

   is a MAC generated with k_BA to authenticate the BA message. Then,
   CN will create a binding cache entry for HoA which includes the
   care-of-address, session keys, lifetimes, etc. Now CN can start
   sending packets encrypted with k_EN to MN at CoA address.

   In order to protect against the third party bombing attacks, after
   receiving BA, MN should reply a binding confirmation message

        BC = {Src=CoA, Des=CN, HoA, Seq#, Flag, MAC_BC}

   to CN, where

        MAC_BC = prf(k_BA, HoA | CoA | Seq# | Flag).

   is a MAC generated with k_BA to authenticate the BC message and Flag
   is the indicator of binding confirmation. For the consideration of
   performance, the CN does not need to wait the BC before shifting to
   the new care-of-address. If the CN can not receive the proper BC
   after a certain amount of traffics, e.g 10 packets or 10 seconds,
   the traffic between CN and the new CoA will be stopped.

Expires: February 9, 2005                                     [Page 8]


Internet Draft                  CBU                     August 10, 2004


   When the binding expires, which is defined by LT_BA or MN changes
   its domain, MN and CN can use messages BU and BA to update the
   binding.

   Meanwhile, when k_EN expires, which is defined by LT_EN, MN sends HA
   a message

       REQ_KEY = {Src=HoA, Des=HA, e(k_HA, HoA, CoA, CN, N0', REQKEN)}

   where REQKEN indicates to update k_EN. After decrypting the REQ_KEY
   message and verifying HoA, HA generates a new nonce N1' and sends

        EXCH0' = {Src=HoA, Des=CN, N1', MAC_EXCH0'}

   to CN, where

        MAC_EXCH0' = prf(k_EN, HoA | N1' ).

   If EXCH0' is verified positive, CN also generates a new nonce N2'
   and replies

        EXCH1' = {Src=CN, Des=HoA, N1', N2', LT_EN, MAC_EXCH1'}

   to HA, where

        MAC_EXCH1' = prf(k_EN, CN | N1' | N2' | LT_EN );

   After verifying and getting the new nonces N0' and N1', both HA and
   CN compute the new encryption key respectively

        k_EN-new = prf(k_master, N1' | N2' | 2 ),

   then HA forwards the new encryption key

        NEWKEY = {Src=CN, Des=CoA, e(k_HA, N0', k_EN-new, LT_EN )}.

   to MN for following packets between MN and CN .

   As the messages of REQ_KEY and NEWKEY might get lost during the
   transfer, MN could resend the requst message REQ_KEY if it does not
   receive the NEWKEY message after a resonable interval.

   In this proposal, messages for a new binding update request
   (referring to Figure 2.) are long-term, i.e., throughout a
   communication session or even across multiple sessions, while
   messages for the follow-up binding updates and the IPsec session
   keys are short-term, which are decided by their lifetimes LT_BA and
   LT_EN, respectively. In most of time, when MN changes its CoA, it
   only needs to send the BU message to CN. Therefore, our protocol
   could get high performance in the handover process.


Expires: February 9, 2005                                     [Page 9]


Internet Draft                  CBU                     August 10, 2004


   In the CBU protocol, as described above, the security association
   (binding cache entry) is based on the addresses of CN and CoA.
   Therefore, the IPsec could be used as usual. On the contrast, in RR
   bundled IKE method, the security association is based on addresses
   of CN and HoA, the IPsec cannot be used without modification because
   HoA is not deployed as source/destination address in the header of
   IP packets.

   A major feature of our CBU protocol is provision of key management
   in the IKE style for protecting the channels of MN-HA, MN-CN and
   HA-CN.



4. SECURE BINDING UPDATE BETWEEN TWO MOVING MOBILE NODES

   In this section, we discuss how to use CBU protocol in the scenarios
   of two mobile nodes in simultaneous movement.

   In Figure 3, CN_MN is a mobile correspondent node with home address
   CN_HoA and care-of-address CN_CoA while CN_HA is its home agent. The
   messages between NM, HA and CN_HA are the same as those shown in
   Figure 2 but the CN's address is replaced by CN_HoA.


            MN             HA           CN_HA         CN_MN
            |              |              |             |
            |=====REQ=====>|===COOKIE0===>|----TEST---->|
            |              |              |             |
            |              |<===COOKIE1===|<---ALIVE----|
            |              |              |             |
            |              |====EXCH0====>|             |
            |              |              |             |
            |<=====REP=====|<====EXCH1====|====KEYS====>|
            |              |              |             |
            |======BU====================>|====FWD=====>|
            |              |              |             |
            |<====================BA====================|
            |              |              |             |

        Figure 3. Message exchange between two mobile nodes.


   Messages TEST and ALIVE are optional for testing whether CN_MN is
   alive.

        TEST = {Src=CN_HA, Des=CN_CoA, test_flag}
        ALIVE = {Src= CN_CoA, Des=CN_HA, N3}

   where N3 is a nonce generated by CN_MN.


Expires: February 9, 2005                                    [Page 10]


Internet Draft                  CBU                     August 10, 2004


   After computing secret session keys k_BU, k_BA and k_EN, CN_HA also
   sends these keys

        KEYS = {Src=CN_HA, Des=CN_CoA, e(k_CN, N3, k_BU, k_BA, k_EN)}

   to CN_MN through their own IPsec-protected tunnel, encrypted with
   their preset IPsec session key k_CN.

   When CN_HA intercepts the binding message BU from MN, CN_HA simply
   forwards the message to CN_MN through the reserved tunnel

        FWD = {Src=CoA, Des= CN_CoA, HoA, Seq#, LT_BU, MAC_BU}.

   Upon receiving FWD and checking the validity of MAC_BU, CN_MN
   Returns

        BA = {Src=CN_CoA, Des=CoA, CN_HoA, Seq#, LT_BA, LT_EN, MAC_BA}

   to MN in order to inform MN of its current care-of-address CN_CoA.
   MAC_BA is calculated as

        MAC_BA = prf(k_BA, CoA | CN_CoA | Seq# | LT_BA | LT_EN).

   After receiving the messages of BU and BA, MN and CN_MN will create
   a binding cache entry for each other, respectively, which includes
   care-of-addresses of the both peers, session keys, lifetimes, etc.
   Then the two mobile nodes can start sending packets encrypted with
   k_EN to each other at their CoA addresses.

   As described above, the home agent always negotiates with a fixed
   peer, either a fixed CN or the home agent (CN_HA) of a mobile CN.
   When the initial mobile node (MN) sends its current CoA in the BU
   message to the correspondent home agent (CN_HA), CN_HA will forward
   MN's CoA to its mobile node (CN_MN), and CN_MN will send its current
   CoA to MN directly. Therefore, from MN's point of view, it never
   takes care whether the correspondent node is a moving node or not.
   On the contrary, in the RR protocol, a special message type is used
   to process the scenario of two mobile nodes in simultaneous
   movement.


5. IMPLEMENTATION of CBU in HMIPv6

   In the protocol of HMIPv6 [2], the concept of Mobility Anchor Point
   (MAP) is introduced. MAP is a router located in a domain visited by
   the mobile nodes. MAP provides the localized mobility management for
   the visiting mobile nodes.





Expires: February 9, 2005                                    [Page 11]


Internet Draft                  CBU                     August 10, 2004


   Every mobile node bundles three addresses: Home Address (HoA),
   Regional Care-of-Address (RCoA), and On-Link Care-of-Address (LCoA).
   RCoA is an address on the MAP subnet, and obtained by the mobile
   Node (MN) from the visited domain. LCoA is configured on a MN's
   interface based on the prefix advertised by its default router. In
   fact, it is a care-of-address in normal MIPv6. Figure 4 shows the
   architecture of HMIPv6.


                    +----+      +----+
                    | HA |      | CN |
                    +----+      +----+
                       |          |
                       +---+  +---+
                           |  |
                         +-------+
                         |  MAP  |
                         +-------+
                           |  |
                       +---+  +---+
                       |          |
                    +-----+    +-----+
              LCoA1 | AR1 |    | AR2 | LCoA2
                    +-----+    +-----+
                 +----+
                 | MN |   movement
                 +----+  --------->

         Figure 4. Hierarchical MIPv6 domain.


   In HMIPv6, when CN sends packets to MN's RCoA, MAP intercepts the
   packets and forwards the packets to MN's LCoA. However, as the
   binding update message from MN to MAP is not authenticated when MN
   changes its Access Router (AR), attackers can easily launch
   "Redirect Attacks", i.e., the attacks which redirect the traffic
   from MAP to fake destinations chosen by the attackers. Therefore, in
   this section, we propose an approach to protect the binding update
   message from MN to MAP.

   When MN roams in the MAP domain, as soon as MN attaches to another
   AR and gets a new LCoA, MN will send a BU message to MAP with its
   certificate and signature

        BU = { Src=LCoA, Des=MAP, HoA, RCoA, SIG_MN, Cert_MN }

   where

        SIG_MN = Sig{SK_MN, LCoA | MAP | HoA | RCoA},



Expires: February 9, 2005                                    [Page 12]


Internet Draft                  CBU                     August 10, 2004


   and

        Cert_MN = {HoA, PK_MN, Valid_Iinterval, SIG_HA}.

   SK_MN and PK_MN are a private and public key pair for MN. MN's
   public key certificate is issued by its home agent (HA). Here,
   SIG_HA is HA's signature on HoA, PK_MN and Valid_ Interval.

   After MAP got the message, if MAP does not have HA's public key
   certificate, MAP will send a request for certificate to HA,

        REQ_Cert = {Src=MAP, Des=HA, request_cert}.

   Then, HA will return to MAP its public key certificate issued by a
   CA,

        REP_Cert = {Src=HA, Des=MAP, Cert_HA}.

   Upon getting HA's public key certificate, MAP can verify HA's
   signature SIG_HA and trust the MN's public key certificate Cert_MN.
   With Cert_MN, MAP can further verify MN's signature. After double
   checking the equality of home link's subnet prefix string embedded
   in both Cert_HA and HoA, MAP can finally trust MN's new binding
   update message BU.


6. SECURITY CONSIDERATIONS

   The proposal of Certificate-based Binding Update (CBU) solves many
   security issues in mobile networks, i.e. the secure binding update,
   seamless secure fast handover, user authentication, session key
   management for data security, etc.

   With the use of a digital signature scheme and the Diffie-Hellman
   key exchange algorithm, the CBU protocol can prevent the Session
   Hijacking attacks (an intruder hijacks an existing session between a
   mobile node and a correspondent node and redirects the correspondent
   node's traffic to a malicious location) and the Malicious Mobile
   Node Flooding attacks (a mischievous mobile node sets up
   communication sessions with correspondent nodes, and then redirect
   traffic from the correspondent nodes to flood a victim node or
   network). For the detail analysis, please refer to [4].










Expires: February 9, 2005                                    [Page 13]


Internet Draft                  CBU                     August 10, 2004


7. CONCLUSION

   As described in this document, the CBU protocol provides a key
   management scheme to protect all the channels, e.g., the channels of
   MN-HA, MN-CN, HA-CN as well as MN-MAP, HA-MAP in mobile IPv6
   networks. For the channel MN-HA, because HA acts as a security agent
   for MN and they share a secret value, our scheme provides a dynamic
   encryption key for this IPsec channel. For the channel MN-CN, our
   scheme manages both the long-term security associations for
   authentication and the short-term security associations for packet
   encryption in the channel. For the channel HA-CN, authentication is
   also provided.

   Thanks to a strong cryptosystem used in the proposal, in most of
   time, MN can simply send the authenticated binding update messages
   (BU) to its CN when it enters into other subnets, without
   re-establishing new authentication keys via HA. So it is more
   suitable for fast handover in mobile networks.

   Due to the dynamic security associations (SA) for IPsec channels
   based on CoAs of these two nodes, our scheme can avoid the indexical
   problem that RR protocol must face, in which IP addresses in IP
   packets do not match the IP addresses in the SA database.

   As both CoAs of two nodes are never involved in the process of
   security negotiation in our scheme, either fixed CN or mobile CN can
   be dealt with the same method. Contrastively, RR protocol has to
   provide different methods to process these two scenarios.

   Because the major security negotiation in our scheme is carried out
   on the fixed machines (home agents or fixed CNs) connected with the
   wired networks, our solution can significantly reduce the computing
   and communication requirements on the mobile nodes.


   Therefore, our proposal could keep well a balance between the strong
   security requirements for e-commerce and the weak capability of
   mobile devices, and provides a more tidy, integrated, practical and
   efficient security solution for mobile networks.




8. ACKNOWLEDGEMENTS

   The authors would like to thank James Kempf for his valuable
   comments and suggestions.





Expires: February 9, 2005                                    [Page 14]


Internet Draft                  CBU                     August 10, 2004


9. REFERENCES

   [1]  D. B. Johson and C. Perkins, "Mobility Support in IPv6", IETF
        INTERNET-DRAFT, July 2003.
   [2]  H. Soliman and K. El-Malki, "Hierarchical MIPv6 Mobility
        Management (HMIPv6)", July 2003.
   [3]  D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)",
        RFC 2409, November 1998.
   [4]  R. Deng, J. Zhou and F. Bao, "Defending against Redirect
        Attacks in Mobile IP", Proceedings of 9th ACM Conference on
        Computer and Communications Security, pages 59--67, Washington,
        DC, November 2002, ACM Press.



10. AUTHORS' ADDRESSES

      Feng BAO
      Institute for Infocomm Research
      21 Heng Mui Keng Terrace
      Singapore 119613

      Phone: +65-6874-8456
      EMail: baofeng@i2r.a-star.edu.sg


      Robert DENG
      Institute for Infocomm Research
      21 Heng Mui Keng Terrace
      Singapore 119613

      Phone: +65-6874-7862
      EMail: deng@i2r.a-star.edu.sg


      Ying QIU
      Institute for Infocomm Research
      21 Heng Mui Keng Terrace
      Singapore 119613

      Phone: +65-6874-6742
      EMail: qiuying@i2r.a-star.edu.sg


      Jianying ZHOU
      Institute for Infocomm Research
      21 Heng Mui Keng Terrace
      Singapore 119613

      Phone: +65-6874-8543
      EMail: jyzhou@i2r.a-star.edu.sg

Expires: February 9, 2005                                    [Page 15]


Internet Draft                  CBU                     August 10, 2004


A. CHANGE LOG

   The following changes have taken place since the previous version.

   -  In section 3, add a binding confirmation message (BC) in order to
      protect against the third party bombing attacks.

   -  Revision of IPSec to IPsec.



INTELLECTUAL PROPERTY STATEMENT

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances
   of licenses to be made available, or the result of an attempt made
   to obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification
   can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

Expires: February 9, 2005                                    [Page 16]


Internet Draft                  CBU                     August 10, 2004


   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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





































Expires: February 9, 2005                                    [Page 17]