idnits 2.17.1 draft-haddad-mipv6-omipv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7376 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-nikander-mobileip-v6-ro-sec-01 == Outdated reference: A later version (-05) exists of draft-dupont-mipv6-3bombing-00 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Wassim Haddad 3 Internet Draft Ericsson Research Canada 4 Expires in July 2004 Helsinki University of Technology 5 Francis Dupont 6 ENST de Bretagne 7 Lila Madour 8 Suresh Krishnan 9 Ericsson Research Canada 10 Soohong Daniel Park 11 Samsung Electronics 12 February 2004 14 Optimizing Mobile IPv6 (OMIPv6) 16 18 Status of this memo 20 This document is an Internet Draft and is in full conformance with 21 all provisions of Section 10 of RFC 2026. 23 This document is an Internet-Draft. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its 25 areas, and its working groups. Note that other groups may also 26 distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as 32 "work in progress." 34 The list of current Internet Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Distribution of this memo is unlimited 42 Abstract 44 Mobile IPv6 protocol introduced the route optimization mode to 45 allow a direct exchange of data packets between the mobile node 46 (MN) and the correspondent node (CN). This memo is a proposal 47 to optimize the Mobile IPv6 solution, by reducing the handoff 48 latency and the number of signaling messages. 50 Table of contents 52 1. Introduction...............................................2 53 2. Conventions used in this document..........................2 54 3. Terminology................................................2 55 4. Motivation.................................................3 56 5. Overview of OMIPv6.........................................4 57 6. OMIPv6 Operation...........................................5 58 7. The Diffie-Hellman Exchange................................6 59 7.1 The DH Messages Structures................................8 60 8. Security considerations...................................10 61 9. Acknowledgements..........................................10 62 10. Normative References.....................................10 63 11. Informative References...................................10 64 12. Authors'addresses........................................11 65 13. Full Copyright Statement.................................12 67 1. Introduction 69 Mobile IPv6 [1] introduced the route optimization (RO) mode to 70 allow a direct exchange of data packets between a mobile node 71 and a correspondent node (CN). Such mode is efficient, but it 72 raises many security concerns and generates an excessive amount 73 of redundant mobility signaling messages. 75 According to [1], these signaling messages are needed to 76 periodically create a shared secret between the MN and the CN. 78 This memo describes an optimization to the RO mode, which aims 79 to enhance its efficiency by making it less vulnerable, while 80 keeping it at least as secure as it is in the RO mode and by 81 reducing the high number of redundant signaling messages as 82 well as the handover latency. 84 2. Conventions used in this document 86 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" 87 in this document are to be interpreted as described in RFC 2219 88 [2]. 90 3. Terminology 92 DH Message 94 Diffie-Hellman message that is made by Diffie-Hellman 95 algorithm. 97 RO 98 Route Optimization mode which allows the correspondent node 99 to route data packets directly to the MN's care-of address. 100 The RO mode requires the MN to register its new IP address 101 with the Correspondent node. 103 Kabm 105 The shared secret resulting from a DH exchange. Kabm refers 106 in this draft to the "Authenticated Binding Management" key 107 that is used to authenticate the mobility signaling 108 messages. 110 MiTM attack 112 Man-in-The-Middle attack, which is able to be launched 113 through the spoofing of DH messages. 115 Note that most related terminologies used in this document are 116 described in more details in [1]. 118 4. Motivation 120 The RO mode allows the MN to talk directly to the CN, i.e, by 121 using the direct path between them. In order to do so, the RO 122 mode requires both entities to compute a shared secret (i.e., 123 Kbm) in order to authenticate the binding updates (BUs) and 124 binding acknowledgments (BA) messages with the same shared 125 secret. 127 For security reasons, it is required that the lifetime of the 128 shared secret be reduced to few minutes, thus obliging both 129 entities to re-create a new Kbm at a high frequency. For more 130 information about the security concerns and necessary defenses 131 related to the RO mode, please refer to [4]. 133 Each time the MN needs to compute a fresh Kbm, it needs to 134 exchange four messages with the CN, i.e., to run the return 135 routability (RR) procedure. The loss of any of the four 136 messages requires the exchange of at least two additional 137 messages with the CN. Note that for security reasons, the MN's 138 home agent (HA) MUST get involved each time the RR test is 139 performed. 141 If the RR test succeeds (i.e., the MN and the CN compute a Kbm 142 shared secret), the MN must send a BU message to its HA and 143 waits for a BA. Upon receiving a BA from its HA, the MN sends a 144 BU to its CN to update its binding cache entry (BCE) with its 145 new location (i.e., care-of address (CoA)) and waits for a BA. 147 The BUs authentication procedure requires approximately 1.5 148 round trips time between the mobile node and each correspondent 149 node (for the entire RR procedure in a best case scenario, i.e, 150 no packet loss) and one round trip time between the MN and the 151 HA. Needless to mention that the delay resulting from such 152 redundancy is NOT acceptable for time sensitive applications. 154 Note that each time the MN performs an RR test, 2 messages 155 are exchanged in clear between the MN and the CN and two others 156 are exchanged in clear between the HA and the CN across the 157 Internet, thus exposing all the vulnerabilities and critical 158 ingredients every few minutes during the ongoing session. 160 It becomes clear from the above that the RO mode introduces an 161 expensive efficiency in terms of excessive mobility signaling 162 messages, high latency and many security concerns. 164 This draft describes one way to make the exchange of BU/BA 165 messages safer and substantially reduce the number of mobility 166 signaling messages as well as the latency of the handover. 168 5. Overview of OMIPv6 170 The OMIPv6 proposal is a practical aspect of the trade-off 171 suggested by S. Bradner, A. Mankin and J. Schiller in the 172 Purpose-Built Keys (PBK) framework [3]: 174 "However, there are many circumstances where we can improve 175 overall security by narrowing the window of vulnerability, so 176 that if we assume that some operation is performed securely, we 177 can secure all future transactions". 179 One of the main advantages for using OMIPv6 is that it gives a 180 malicious node only ONE chance to launch a successful attack 181 against the HoT and/or CoT messages, thus narrowing the window 182 of vulnerability to the minimum. 183 This advantage becomes more critical when the random parameter 184 is added. Actually, switching to OMIPv6 can occur at anytime, 185 any location and at any stage during the ongoing session. 187 At the opposite, if the assumption is wrong, all future 188 transactions are compromised, i.e., attacks are made more 189 difficult and very limited in time but when they succeed their 190 effects last for a longer time. 192 Such assumption is reasonable with regards to security needs 193 since it is based on the MIPv6 security design, and offers 194 better performance for the rest of the ongoing session. 196 The suggested solution should be implemented on top of the 197 current MIPv6 architecture. OMIPv6 utilizes the RR test 198 procedure, which has been designed in [1] and SHOULD NOT be 199 used alone. 201 OMIPv6 allows to compute a shared secret secret, which is 202 longer than the one created in MIPv6, thus making it more 203 difficult to crack. 205 OMIPv6 substantially reduces the amount of mobility signaling 206 messages by eliminating the need for the CoTI/CoT and HoTI/HoT 207 messages in normal situation. Such reduction will result in a 208 reduced handover latency. 210 Another feature is that OMIPv6 does not require the deployment 211 of an infrastructure to distribute keys, thus eliminating any 212 scalability problems. 214 6. OMIPv6 Operation 216 OMIPv6 consists on deriving a long shared secret which will be 217 used by both entities to authenticate the BU/BAs messages. 218 The new shared secret is derived from a DH exchange, which 219 SHOULD be launched by the MN immediately after a successful RR 220 test. Further DH procedures MAY be performed later during the 221 session and MUST NOT rely on an RR test. 223 After a successful RR test, the MN and the CN will share a 224 secret (Kbm). This key MUST be used to authenticate the DH 225 messages exchanged between the CN and the MN. Note that using 226 the shared secret resulting from the RR test enables also both 227 nodes to authenticate each other. 229 The DH messages MUST be exchanged on the same paths used to 230 exchange the RR test messages. For this purpose, the MN MUST 231 sign the first DH message with the Kbm and send it to the CN 232 via the direct path. The MN MUST include its home address by 233 using a home address option (HAO). 235 The CN's reply to the first message MUST also be signed with 236 the Kbm, duplicated and both copies MUST be sent to the MN: 237 One copy MUST be sent via the direct path and another copy via 238 the path going through the MN's HA. 239 If the MN finds the two messages identical, then it pursues the 240 DH exchange and sends the third message via the direct path. 242 The CN ends the procedure by sending the fourth DH message on 243 the same path. 245 Note that the main objective behind duplicating the second DH 246 message is the potential ability to reveal a possible MiTM 247 attack on the first one (i.e., if the malicious node knows the 248 Kbm). By duplicating the second DH message, a successful MiTM 249 attack will consist on attacking two duplicated messages sent 250 on two different paths at the same time, which will probably 251 make such kind of attack more difficult. 253 The DH exchange will allow both entities to compute a long 254 shared secret (Kabm), and to establish a bidirectional security 255 association (SA) between them without the need to rely on any 256 existing public key infrastructure. 258 The Kabm MUST be used to authenticate the Binding Update (BU), 259 Binding Acknowledgement (BA) messages exchanged between the MN 260 and the CN. 262 In order to reduce the handover latency, the MN will send the 263 BU on the direct path immediately after receiving a BA message 264 from its HA. Note that the MN MAY duplicate the BU message and 265 send a copy on the path going via its HA. Only one copy is 266 enough to update the CN's binding cache entry. In this case, 267 the BU sent via the HA MUST have the same sequence number than 268 the one sent via the direct path. 270 When the CN gets a valid BU signed with the Kabm, it will update 271 its BCE, send a BA message to the MN and continue the session. 273 The CN will continue the session immediately after sending the 274 BA. 276 After establishing a bidirectionnal SA between the MN and the 277 CN, the following rules MUST be applied: 279 - The MN MUST NOT use the alternate care-of address option in 280 the BU message sent to the CN in order to counter a third 281 party bombing attack [6]. 283 - The MN MUST NOT use the nonce indices option in new binding 284 updates messages sent after a care-of address change. 286 The MN SHOULD set the Acknowledge (A) bit in the BU message 287 after switching to OMIPv6. 289 To avoid replay attacks, the MN will keep the sequence number 290 sent in the first BU immediately after a DH exchange and 291 increment it in all subsequent BU messages. 293 7. The Diffie-Hellman Exchange 295 The DH exchange can be launched at any time during the ongoing 296 session. In order to reduce the amount of signaling messages to 297 the minimum, it MAY be launched, for example, immediately after 298 running the first RR test. 300 The update of the Kabm MAY be done periodically or each time 301 after the MN switches to a new network. The DH procedure MAY be 302 done in parallel with the ongoing session and the resulting new 303 Kabm SHOULD be used to refresh the CN's BCE with the current 304 MN's CoA. 305 After completing a DH procedure, any new mobility signaling 306 message MUST be signed with the new Kabm computed from the DH 307 exchange. The two endpoints SHOULD silently drop any mobility 308 message related to the MN's IP home/care-of address or the CN's 309 address and not signed with the Kabm. 311 The scheme below shows the different paths taken by the four 312 messages of a DH exchange between a MN and the CN: 314 +------------+ +------+ 315 | | | | 316 | MN |<----------------------| HA | 317 | | DH2 | | 318 +------------+ +------+ 319 | ^ ^ | ^ 320 | | DH2| |DH1 / 321 | | | | / 322 DH3| |DH4 | | / 323 V | | V / 324 +------------+ / 325 | | / 326 | CN |-------------------/ 327 | | DH2 328 +------------+ 330 As it has been mentioned, the DH messages MUST be authenticated 331 from both sides by using the Kbm. The contents and the signature 332 associated with each DH message has been detailed in [5]. 334 In OMIPv6, the DH messages exchanged between the two MNs are 335 described in the following: 337 MN HA CN 338 -- -- -- 340 DH1 =========================================================> 342 DH2 <========================================================= 344 DH2 <############################o<=========================== 346 DH3 =========================================================> 348 DH4 <========================================================= 350 ===> : denotes an authenticated message 352 ###> : denotes an encrypted message 354 7.1 The DH messages structures: 356 The DH message structure is shown in the following: 358 - DH1 message structure: 360 sid , gX, N , info 361 MN MN MN MN CN 362 ---------------------------------------------------------------> 364 - DH2 message structure: 366 sid , sid , gY, N , info 367 MN MN CN CN CN CN 368 <--------------------------------------------------------------- 369 - DH3 message structure: 371 sid , sid ,MN, SIG (N , sid ,gX, info , info ), MAC(MN) 372 MN CN Kbm CN MN MN CN Km CN 373 ---------------------------------------------------------------> 375 - DH4 message structure: 377 sid , sid , info ,CN, SIG (N , sid ,gY,info, info), MAC(CN) 378 MN CN CN Kbm MN CN CN MN Km CN 379 <--------------------------------------------------------------- 381 In the above scheme, the following abbreviations have been 382 adopted: 384 - gX = shared part of MN's secret 386 - gY = shared part of CN's secret 388 - sid = session identifier used to specify the ongoing 389 session. 391 - N = nonce 393 - info = additional information carried in the protocol 394 messages 396 - MN = Identity of MN 398 - CN = Identity of CN 400 - Kbm = key generated from the RR test 402 - SIG(msg) = denotes the signature of "msg" using the Kbm. 404 - Km = key generated from DH (known only by the MN and the 405 CN) 407 - MAC(msg) = denotes a message authenticated code computed 408 Km from "msg" and signed by Km. 410 8. Security considerations 412 The design principle of base MIPv6 RO is the establishment of 413 bindings using a security-wise "weak" authentication scheme, but 414 at the same time limiting the set of possible attackers to a 415 certain path and limiting the potential consequences of an 416 attack to bindings of short duration. 418 This draft proposes an alternative mechanisms where different 419 design tradeoffs have been incorporated. In particular, we 420 increase the strength of the authentication mechanism while at 421 the same time allowing a more permanent binding. 423 The DH mechanism is performed without authentication beyond the 424 usage of the original Kbm provided from RR, which is used to 425 authenticate the BU/BA messages in MIPv6. 427 9. Acknowledgements 429 Authors would like to thank Laurent Marchand and Jari Arkko for 430 reviewing the draft. Authors gratefully thank Erik Nordmark for 431 his valuable inputs on the concept. 433 10. Normative References 435 [1] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in 436 IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003. 438 [2] S. Bradner, "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119. 441 11. Informative References 443 [3] S. Bradner, A. Mankin and J. Schiller, " A Framework for 444 Purpose-Built Keys (PBK)". draft-bradner-pbk-frame-06.txt, 445 October 2003. 447 [4] P. Nikander, T. Aura, J. Arkko, G.Montenegro and E. Nordmark 448 "Mobile IP version 6 Route Optimization Security Design 449 Background", draft-nikander-mobileip-v6-ro-sec-01. 451 [5] Krawczyk, H., "SIGMA: the 'SIGn-and-MAC'Approach to 452 Authenticated Diffie-Hellman and its use in the IKE 453 Protocols", in Advanceds in Cryptography - CRYPTO 2003 454 Proceedings, LNCS 2729, Springer, 2003. Available at: 455 http://www.ee.technion.ac.il/~hugo/sigma.html. 457 [6] F. Dupont, "A note about 3rd party bombing in Mobile IPv6", 458 draft-dupont-mipv6-3bombing-00, February 2004. 460 12. Author's Addresses 462 Wassim Haddad 463 Ericsson Research Canada 464 8400, Decarie Blvd 465 Town of Mount Royal 466 Quebec H4P 2N2 467 CANADA 468 Phone: +1 514 345 7900 469 Fax: +1 514 345 6105 470 E-Mail: Wassim.Haddad@lmc.ericsson.se 472 Francis Dupont 473 ENST de Bretagne 474 Campus de Rennes 475 2, rue de la Chataigneraie 476 BP 78 477 35510 Cesson Sevigne Cedex 478 FRANCE 479 Fax: +33 2 99 12 70 30 480 E-Mail: Francis.Dupont@enst-bretagne.fr 482 Lila Madour 483 Ericsson Research Canada 484 8400, Decarie Blvd 485 Town of Mount Royal 486 Quebec H4P 2N2 487 CANADA 488 Phone: +1 514 345 7900 489 Fax: +1 514 345 6195 490 E-Mail: Lila.Madour@ericsson.com 492 Suresh Krishnan 493 Ericsson Research Canada 494 8400, Decarie Blvd 495 Town of Mount Royal 496 Quebec H4P 2N2 497 CANADA 498 Phone: +1 514 345 7900 499 Fax: +1 514 345 6195 500 E-Mail: Suresh.Krishnan@ericsson.com 502 Soohong Daniel Park 503 Samsung Electronics 504 Mobile Platform Laboratory, Samsung Electronics 505 416. Maetan-Dong, Yeongtong-Gu, Suwon 506 Korea 507 Phone: +81 31 200 4508 508 E-Mail: soohong.park@samsung.com 510 13. Full Copyright Statement 512 Copyright (C) The Internet Society (2003). All Rights Reserved. 513 This document and translations of it may be copied and furnished 514 to others, and derivative works that comment on or otherwise 515 explain it or assist in its implementation may be prepared, 516 copied, published and distributed, in whole or in part, without 517 restriction of any kind, provided that the above copyright 518 notice and this paragraph are included on all such copies and 519 derivative works. However, this document itself may not be 520 modified in any way, such as by removing the copyright notice or 521 references to the Internet Society or other Internet 522 organizations, except as needed for the purpose of developing 523 Internet standards in which case the procedures for copyrights 524 defined in the Internet Standards process must be followed, or 525 as required to translate it into languages other than English. 526 The limited permissions granted above are perpetual and will not 527 be revoked by the Internet Society or its successors or 528 assignees. 529 This document and the information contained herein is provided 530 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 531 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 532 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 533 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 534 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 535 PARTICULAR PURPOSE.