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

Versions: 00 01                                                         
Internet Engineering Task Force                           Wassim Haddad
Internet Draft                                 Ericsson Research Canada
Expires in July 2004                  Helsinki University of Technology
                                                         Francis Dupont
                                                       ENST de Bretagne
                                                            Lila Madour
                                                        Suresh Krishnan
                                               Ericsson Research Canada
                                                    Soohong Daniel Park
                                                    Samsung Electronics
                                                          February 2004



                      Optimizing Mobile IPv6 (OMIPv6)

                    <draft-haddad-mipv6-omipv6-01.txt>



Status of this memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   This document is an Internet-Draft.  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.

   Distribution of this memo is unlimited



Abstract

   Mobile IPv6 protocol introduced the route optimization mode to
   allow a direct exchange of data packets between the mobile node
   (MN) and the correspondent node (CN). This memo is a proposal
   to optimize the Mobile IPv6 solution, by reducing the handoff
   latency and the number of signaling messages.



Haddad, et al.                 Expires July 2004                [Page 1]


INTERNET-DRAFT                       OMIPv6                February 2004



Table of contents


   1. Introduction...............................................2
   2. Conventions used in this document..........................2
   3. Terminology................................................2
   4. Motivation.................................................3
   5. Overview of OMIPv6.........................................4
   6. OMIPv6 Operation...........................................5
   7. The Diffie-Hellman Exchange................................6
   7.1 The DH Messages Structures................................8
   8. Security considerations...................................10
   9. Acknowledgements..........................................10
   10. Normative References.....................................10
   11. Informative References...................................10
   12. Authors'addresses........................................11
   13. Full Copyright Statement.................................12


1. Introduction

   Mobile IPv6 [1] introduced the route optimization (RO) mode to
   allow a direct exchange of data packets between a mobile node
   and a correspondent node (CN). Such mode is efficient, but it
   raises many security concerns and generates an excessive amount
   of redundant mobility signaling messages.

   According to [1], these signaling messages are needed to
   periodically create a shared secret between the MN and the CN.

   This memo describes an optimization to the RO mode, which aims
   to enhance its efficiency by making it less vulnerable, while
   keeping it at least as secure as it is in the RO mode and by
   reducing the high number of redundant signaling messages as
   well as the handover latency.


2. Conventions used in this document

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY"
   in this document are to be interpreted as described in RFC 2219
   [2].










Haddad, et al.                 Expires July 2004                [Page 2]


INTERNET-DRAFT                       OMIPv6                February 2004



3. Terminology

   DH Message

       Diffie-Hellman message that is made by Diffie-Hellman
       algorithm.

   RO
       Route Optimization mode which allows the correspondent node
       to route data packets directly to the MN's care-of address.
       The RO mode requires the MN to register its new IP address
       with the Correspondent node.

   Kabm

       The shared secret resulting from a DH exchange. Kabm refers
       in this draft to the "Authenticated Binding Management" key
       that is used to authenticate the mobility signaling
       messages.


   MiTM attack

       Man-in-The-Middle attack, which is able to be launched
       through the spoofing of DH messages.


   Note that most related terminologies used in this document are
   described in more details in [1].


4. Motivation

   The RO mode allows the MN to talk directly to the CN, i.e, by
   using the direct path between them. In order to do so, the RO
   mode requires both entities to compute a shared secret (i.e.,
   Kbm) in order to authenticate the binding updates (BUs) and
   binding acknowledgments (BA) messages with the same shared
   secret.

   For security reasons, it is required that the lifetime of the
   shared secret be reduced to few minutes, thus obliging both
   entities to re-create a new Kbm at a high frequency. For more
   information about the security concerns and necessary defenses
   related to the RO mode, please refer to [4].

   Each time the MN needs to compute a fresh Kbm, it needs to
   exchange four messages with the CN, i.e., to run the return
   routability (RR) procedure.  The loss of any of the four



Haddad, et al.                 Expires July 2004                [Page 3]


INTERNET-DRAFT                       OMIPv6                February 2004



   messages requires the exchange of at least two additional
   messages with the CN. Note that for security reasons, the MN's
   home agent (HA) MUST get involved each time the RR test is
   performed.

   If the RR test succeeds (i.e., the MN and the CN compute a Kbm
   shared secret), the MN must send a BU message to its HA and
   waits for a BA. Upon receiving a BA from its HA, the MN sends a
   BU to its CN to update its binding cache entry (BCE) with its
   new location (i.e., care-of address (CoA)) and waits for a BA.

   The BUs authentication procedure requires approximately 1.5
   round trips time between the mobile node and each correspondent
   node (for the entire RR procedure in a best case scenario, i.e,
   no packet loss) and one round trip time between the MN and the
   HA. Needless to mention that the delay resulting from such
   redundancy is NOT acceptable for time sensitive applications.

   Note that each time the MN performs an RR test, 2 messages
   are exchanged in clear between the MN and the CN and two others
   are exchanged in clear between the HA and the CN across the
   Internet, thus exposing all the vulnerabilities and critical
   ingredients every few minutes during the ongoing session.

   It becomes clear from the above that the RO mode introduces an
   expensive efficiency in terms of excessive mobility signaling
   messages, high latency and many security concerns.

   This draft describes one way to make the exchange of BU/BA
   messages safer and substantially reduce the number of mobility
   signaling messages as well as the latency of the handover.


5. Overview of OMIPv6

   The OMIPv6 proposal is a practical aspect of the trade-off
   suggested by S. Bradner, A. Mankin and J. Schiller in the
   Purpose-Built Keys (PBK) framework [3]:

   "However, there are many circumstances where we can improve
   overall security by narrowing the window of vulnerability, so
   that if we assume that some operation is performed securely, we
   can secure all future transactions".

   One of the main advantages for using OMIPv6 is that it gives a
   malicious node only ONE chance to launch a successful attack
   against the HoT and/or CoT messages, thus narrowing the window
   of vulnerability to the minimum.
   This advantage becomes more critical when the random parameter



Haddad, et al.                 Expires July 2004                [Page 4]


INTERNET-DRAFT                       OMIPv6                February 2004



   is added. Actually, switching to OMIPv6 can occur at anytime,
   any location and at any stage during the ongoing session.

   At the opposite, if the assumption is wrong, all future
   transactions are compromised, i.e., attacks are made more
   difficult and very limited in time but when they succeed their
   effects last for a longer time.

   Such assumption is reasonable with regards to security needs
   since it is based on the MIPv6 security design, and offers
   better performance for the rest of the ongoing session.

   The suggested solution should be implemented on top of the
   current MIPv6 architecture. OMIPv6 utilizes the RR test
   procedure, which has been designed in [1] and SHOULD NOT be
   used alone.

   OMIPv6 allows to compute a shared secret secret, which is
   longer than the one created in MIPv6, thus making it more
   difficult to crack.

   OMIPv6 substantially reduces the amount of mobility signaling
   messages by eliminating the need for the CoTI/CoT and HoTI/HoT
   messages in normal situation. Such reduction will result in a
   reduced handover latency.

   Another feature is that OMIPv6 does not require the deployment
   of an infrastructure to distribute keys, thus eliminating any
   scalability problems.


6. OMIPv6 Operation

   OMIPv6 consists on deriving a long shared secret which will be
   used by both entities to authenticate the BU/BAs messages.
   The new shared secret is derived from a DH exchange, which
   SHOULD be launched by the MN immediately after a successful RR
   test. Further DH procedures MAY be performed later during the
   session and MUST NOT rely on an RR test.

   After a successful RR test, the MN and the CN will share a
   secret (Kbm). This key MUST be used to authenticate the DH
   messages exchanged between the CN and the MN. Note that using
   the shared secret resulting from the RR test enables also both
   nodes to authenticate each other.

   The DH messages MUST be exchanged on the same paths used to
   exchange the RR test messages. For this purpose, the MN MUST
   sign the first DH message with the Kbm and send it to the CN



Haddad, et al.                 Expires July 2004                [Page 5]


INTERNET-DRAFT                       OMIPv6                February 2004



   via the direct path. The MN MUST include its home address by
   using a home address option (HAO).

   The CN's reply to the first message MUST also be signed with
   the Kbm, duplicated and both copies MUST be sent to the MN:
   One copy MUST be sent via the direct path and another copy via
   the path going through the MN's HA.
   If the MN finds the two messages identical, then it pursues the
   DH exchange and sends the third message via the direct path.

   The CN ends the procedure by sending the fourth DH message on
   the same path.

   Note that the main objective behind duplicating the second DH
   message is the potential ability to reveal a possible MiTM
   attack on the first one (i.e., if the malicious node knows the
   Kbm). By duplicating the second DH message, a successful MiTM
   attack will consist on attacking two duplicated messages sent
   on two different paths at the same time, which will probably
   make such kind of attack more difficult.

   The DH exchange will allow both entities to compute a long
   shared secret (Kabm), and to establish a bidirectional security
   association (SA) between them without the need to rely on any
   existing public key infrastructure.

   The Kabm MUST be used to authenticate the Binding Update (BU),
   Binding Acknowledgement (BA) messages exchanged between the MN
   and the CN.

   In order to reduce the handover latency, the MN will send the
   BU on the direct path immediately after receiving a BA message
   from its HA. Note that the MN MAY duplicate the BU message and
   send a copy on the path going via its HA. Only one copy is
   enough to update the CN's binding cache entry. In this case,
   the BU sent via the HA MUST have the same sequence number than
   the one sent via the direct path.

   When the CN gets a valid BU signed with the Kabm, it will update
   its BCE, send a BA message to the MN and continue the session.

   The CN will continue the session immediately after sending the
   BA.

   After establishing a bidirectionnal SA between the MN and the
   CN, the following rules MUST be applied:

   - The MN MUST NOT use the alternate care-of address option in
     the BU message sent to the CN in order to counter a third



Haddad, et al.                 Expires July 2004                [Page 6]


INTERNET-DRAFT                       OMIPv6                February 2004



     party bombing attack [6].

   - The MN MUST NOT use the nonce indices option in new binding
     updates messages sent after a care-of address change.

   The MN SHOULD set the Acknowledge (A) bit in the BU message
   after switching to OMIPv6.

   To avoid replay attacks, the MN will keep the sequence number
   sent in the first BU immediately after a DH exchange and
   increment it in all subsequent BU messages.


7. The Diffie-Hellman Exchange

   The DH exchange can be launched at any time during the ongoing
   session. In order to reduce the amount of signaling messages to
   the minimum, it MAY be launched, for example, immediately after
   running the first RR test.

   The update of the Kabm MAY be done periodically or each time
   after the MN switches to a new network. The DH procedure MAY be
   done in parallel with the ongoing session and the resulting new
   Kabm SHOULD be used to refresh the CN's BCE with the current
   MN's CoA.
   After completing a DH procedure, any new mobility signaling
   message MUST be signed with the new Kabm computed from the DH
   exchange. The two endpoints SHOULD silently drop any mobility
   message related to the MN's IP home/care-of address or the CN's
   address and not signed with the Kabm.

   The scheme below shows the different paths taken by the four
   messages of a DH exchange between a MN and the CN:


           +------------+                       +------+
           |            |                       |      |
           |     MN     |<----------------------|  HA  |
           |            |          DH2          |      |
           +------------+                       +------+
            | ^     ^  |                           ^
            | |  DH2|  |DH1                       /
            | |     |  |                         /
         DH3| |DH4  |  |                        /
            V |     |  V                       /
           +------------+                     /
           |            |                    /
           |     CN     |-------------------/
           |            |       DH2
           +------------+


Haddad, et al.                  Expires July 2004               [Page 7]


INTERNET-DRAFT                       OMIPv6                February 2004



   As it has been mentioned, the DH messages MUST be authenticated
   from both sides by using the Kbm. The contents and the signature
   associated with each DH message has been detailed in [5].

   In OMIPv6, the DH messages exchanged between the two MNs are
   described in the following:



        MN                          HA                          CN
        --                          --                          --

   DH1  =========================================================>


   DH2  <=========================================================


   DH2  <############################o<===========================


   DH3  =========================================================>


   DH4  <=========================================================


    ===> : denotes an authenticated message

    ###> : denotes an encrypted message



7.1 The DH messages structures:

   The DH message structure is shown in the following:


   - DH1 message structure:

                        sid   , gX, N   , info
   MN                      MN        MN       MN                 CN
   --------------------------------------------------------------->

   - DH2 message structure:

                     sid   , sid   , gY, N   , info
   MN                   MN     CN         CN      CN             CN
   <---------------------------------------------------------------



Haddad, et al.                  Expires July 2004               [Page 8]


INTERNET-DRAFT                       OMIPv6                February 2004



   - DH3 message structure:


   sid ,  sid ,MN, SIG (N  , sid  ,gX, info , info ), MAC(MN)
     MN     CN      Kbm  CN    MN         MN     CN      Km      CN
   --------------------------------------------------------------->


   - DH4 message structure:

   sid , sid , info ,CN, SIG (N  , sid ,gY,info, info), MAC(CN)
     MN    CN     CN      Kbm  MN    CN       CN    MN     Km    CN
   <---------------------------------------------------------------


   In the above scheme, the following abbreviations have been
   adopted:


     - gX = shared part of MN's secret

     - gY = shared part of CN's secret

     - sid = session identifier used to specify the ongoing
             session.

     - N = nonce

     - info = additional information carried in the protocol
              messages

     - MN  = Identity of MN

     - CN = Identity of CN

     - Kbm = key generated from the RR test

     - SIG(msg) = denotes the signature of "msg" using the Kbm.

     - Km = key generated from DH (known only by the MN and the
            CN)

     - MAC(msg) = denotes a message authenticated code computed
        Km        from "msg" and signed by Km.








Haddad, et al.                  Expires July 2004               [Page 9]


INTERNET-DRAFT                       OMIPv6                February 2004



8. Security considerations

   The design principle of base MIPv6 RO is the establishment of
   bindings using a security-wise "weak" authentication scheme, but
   at the same time limiting the set of possible attackers to a
   certain path and limiting the potential consequences of an
   attack to bindings of short duration.

   This draft proposes an alternative mechanisms where different
   design tradeoffs have been incorporated. In particular, we
   increase the strength of the authentication mechanism while at
   the same time allowing a more permanent binding.

   The DH mechanism is performed without authentication beyond the
   usage of the original Kbm provided from RR, which is used to
   authenticate the BU/BA messages in MIPv6.


9. Acknowledgements

   Authors would like to thank Laurent Marchand and Jari Arkko for
   reviewing the draft. Authors gratefully thank Erik Nordmark for
   his valuable inputs on the concept.


10. Normative References

   [1] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in
       IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003.

   [2] S. Bradner, "Key words for use in RFCs to Indicate
       Requirement Levels", BCP 14, RFC 2119.


11. Informative References

   [3] S. Bradner, A. Mankin and J. Schiller, " A Framework for
       Purpose-Built Keys (PBK)". draft-bradner-pbk-frame-06.txt,
       October 2003.

   [4] P. Nikander, T. Aura, J. Arkko, G.Montenegro and E. Nordmark
       "Mobile IP version 6 Route Optimization Security Design
       Background", draft-nikander-mobileip-v6-ro-sec-01.

   [5] Krawczyk, H., "SIGMA: the 'SIGn-and-MAC'Approach to
       Authenticated Diffie-Hellman and its use in the IKE
       Protocols", in Advanceds in Cryptography - CRYPTO 2003
       Proceedings, LNCS 2729, Springer, 2003. Available at:
       http://www.ee.technion.ac.il/~hugo/sigma.html.



Haddad, et al.                  Expires July 2004              [Page 10]


INTERNET-DRAFT                       OMIPv6                February 2004



   [6] F. Dupont, "A note about 3rd party bombing in Mobile IPv6",
       draft-dupont-mipv6-3bombing-00, February 2004.


12. Author's Addresses

   Wassim Haddad
   Ericsson Research Canada
   8400, Decarie Blvd
   Town of Mount Royal
   Quebec H4P 2N2
   CANADA
   Phone: +1 514 345 7900
   Fax: +1 514 345 6105
   E-Mail: Wassim.Haddad@lmc.ericsson.se

   Francis Dupont
   ENST de Bretagne
   Campus de Rennes
   2, rue de la Chataigneraie
   BP 78
   35510 Cesson Sevigne Cedex
   FRANCE
   Fax: +33 2 99 12 70 30
   E-Mail: Francis.Dupont@enst-bretagne.fr

   Lila Madour
   Ericsson Research Canada
   8400, Decarie Blvd
   Town of Mount Royal
   Quebec H4P 2N2
   CANADA
   Phone: +1 514 345 7900
   Fax: +1 514 345 6195
   E-Mail: Lila.Madour@ericsson.com

   Suresh Krishnan
   Ericsson Research Canada
   8400, Decarie Blvd
   Town of Mount Royal
   Quebec H4P 2N2
   CANADA
   Phone: +1 514 345 7900
   Fax: +1 514 345 6195
   E-Mail: Suresh.Krishnan@ericsson.com

   Soohong Daniel Park
   Samsung Electronics
   Mobile Platform Laboratory, Samsung Electronics



Haddad, et al.                  Expires July 2004              [Page 11]


INTERNET-DRAFT                       OMIPv6                February 2004



   416. Maetan-Dong, Yeongtong-Gu, Suwon
   Korea
   Phone: +81 31 200 4508
   E-Mail: soohong.park@samsung.com


13. Full Copyright Statement

   Copyright (C) The Internet Society (2003). 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.
   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.




















Haddad, et al.                  Expires July 2004              [Page 12]