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]