idnits 2.17.1 draft-haddad-mipv6-bub-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.) ** There are 17 instances of lines with control characters in the document. 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 7375 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: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Wassim Haddad 2 Internet Draft Ericsson Research Canada 3 Expires in July 2004 Helsinki University of Technology 4 Francis Dupont 5 ENST Bretagne 6 Lila Madour 7 Alan Kavanagh 8 Suresh Krishnan 9 Ericsson Research Canada 10 Soohong Daniel Park 11 Samsung Electronics 12 Hannu Kari 13 Helsinki University of Technology 14 February 2004 16 BUB: Binding Update Backhauling 18 20 Status of this Memo 22 This document is an Internet Draft and is in full conformance with 23 all provisions of Section 10 of RFC 2026. 25 This document is an Internet-Draft. Internet-Drafts are working 26 documents of the Internet Engineering Task Force (IETF), its 27 areas, and its working groups. Note that other groups may also 28 distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet- 32 Drafts as reference material or to cite them other than as 33 "work in progress." 35 The list of current Internet Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Distribution of this memo is unlimited 43 Abstract 45 Mobile IPv6 protocol defines two different modes to address the 46 mobility problem. This document describes a new mode, called 47 Binding Update Backhauling (BUB), which has been especially 48 designed for highly mobile environment, i.e, the two mobile 49 nodes are mobile. The BUB mode offers a more secure and 50 optimized exchange of binding updates (BUs) between the two 51 mobile endoints. 53 Table of Contents 55 1. Introduction...............................................2 56 2. Terminology................................................3 57 3. Motivation.................................................3 58 4. Proposed solution..........................................4 59 5. Defining BUB...............................................5 60 5.1 The BUB test...........................................5 61 5.2 The BUB Option format..................................7 62 5.3 The BUB Complete Message Structure.....................8 63 6. The Diffie Hellman Exchange...............................10 64 7. Impact on BU/BA Messages..................................10 65 8. Security Considerations...................................12 66 9. Acknowledgments...........................................12 67 10. Normative References.....................................12 68 11. Informative References...................................13 69 12. Author's Addresses.......................................13 70 13. Full Copyright Statement.................................14 71 Appendix A...................................................16 73 1. Introduction 75 The mobility problem has been described in most cases, as a 76 scenario involving one mobile endpoint referred to as MN and 77 another static endpoint referred to as CN. 79 Mobile IPv6 defines two different modes to handle the mobility 80 problem. These modes are the bidirectional tunneling (BT) and 81 route optimization (RO). The two modes represent a trade-off 82 between security and efficiency. For instance, the BT mode 83 enables a secure exchange but is not optimized at all, while 84 the RO mode offers better efficiency but raises many security 85 concerns. 87 This draft describes a new mode called Binding Update 88 Backhauling (BUB), which has been especially designed to be 89 used in scenarios involving two mobile endpoints. This mode 90 enables a more secure and reliable way for exchanging mobility 91 signaling messages, while preserving at the same time the 92 efficiency of the routing optimization mode. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" 97 in this document are to be interpreted as described in RFC 2219 98 [3]. 100 3. Motivation 102 The route optimization (RO) mode allows two endpoints to 103 exchange data traffic by using the direct path between them. 104 This is achieved by using new mobility headers and relies on 105 exchanging mobility signaling messages each time the MN 106 switches to a new network (i.e., changes its IP address). 108 Each time a MN gets a new IP address (i.e., care-of address), 109 it needs, according to [1], to run a return routability (RR) 110 test in order to test the reachability of its new care-of 111 address and home address by the CN, prior to sending any 112 binding update (BU) message to the CN. 113 Such test is performed by exchanging two signaling messages 114 (CoTI/CoT) on the new direct path (i.e., the path used to 115 exchange data traffic), and two signaling messages (HoTI/HoT) 116 using the path going through the MNs'HA. The result of the test 117 creates a new state at the CN to be used to check the 118 authenticity of the BU sent by the MN. Only a successful test 119 allows the MN to send a BU to the CN to update its binding 120 cache entry (BCE). The CN should acknowledge the BU by sending 121 a binding acknowledgment (BA) to the MN. 122 In total, 6 messages are needed to update the CN with the new 123 MN's IP address. 125 If the CN becomes mobile, it needs to go through the same 126 procedure (i.e., exchange 6 messages) each time it gets a new 127 IP address, in order to keep the session alive. 129 Note that, for security reasons, it is stated in [1] and 130 explained in [4] that the lifetime of the state created at the 131 correspondent node is deliberately restricted to a few minutes, 132 in order to limit the potential ability of time shifting attack. 134 From the above scenario it appears that when the RO mode is 135 used between two mobile endpoints, it may create additional and 136 undesirable traffic, due to a high redundancy of unprotected 137 mobility signaling messages, thus more vulnerabilities. 138 Actually, when the CN becomes mobile, the frequency, as well as 139 the redundancy, of mobility signaling messages will increase, 140 thus making them more visible for a malicious node moving 141 nearby the two endpoints. 143 Note that when the CN is mobile, it is highly probable that a 144 malicious node may be positioned nearby, thus creating a 145 vulnerability on both sides (since another one may probably be 146 located nearby the MN). Such scenario makes the exchange of 147 signaling messages between the two endpoints more challenging 148 with regards to the security requirements. 150 If MN2 moves at the same time than MN1, mobility signaling 151 messages may get lost due to the fact that MN1's care-of address 152 and MN2's care-of address have changed at the same time. Such 153 scenario will probably increase the latency of the handover 154 process, which is not desired especially for time sensitive 155 applications. 157 To address all issues described above, any possible solution 158 should offer an efficient optimization with regards to security 159 requirements, the number of signaling messages and the handover 160 latency. 162 This document describes one such optimization which meets all 163 these requirements. 165 4. Proposed solution: 167 The Binding Update Backhauling (BUB) is a new mode designed to 168 be used between two mobile endpoints. The suggested mode should 169 be considered as an enhancement to the route optimization mode 170 since it uses the same direct path between the MN and CN for the 171 data traffic exchange. 173 The main objectives of the BUB mode are to reduce the number of 174 mobility signaling messages exchanged between the two MNs and 175 increase the security of what will remain. This is achieved by 176 eliminating the HoTI/HoT and CoTI/CoT messages, diverting the 177 BU messages to a more secure and reliable path going through 178 the two HAs and keep using the direct path for the data traffic 179 exchange. 181 The design of the proposed solution is based on the following: 183 a) The paths between the MNs and their HAs are protected by an 184 ESP tunnel [2]. 186 b) The path between the two HAs, being part of the backbone, is 187 assumed to be more secure and more stable than the dynamic 188 path between the two MNs. 190 c) A malicious node cannot be at the same time near the MNs 191 and near the path going between the two HAs. 193 By diverting the signaling messages to a more reliable path, BUB 194 addresses the following issues: 196 - Security of BUs 198 By sending the BUs through the link between the two HAs 199 and by establishing a bidirectional security association 200 (SA) between the two MNs. 202 - Double Jumping Problem 204 By avoiding the loss of mobility signaling messages, BUB 205 reduces the latency caused by such loss. 207 - Excessive Signaling 209 BUB reduces the number of signaling messages, exchanged 210 between the two MNs, by eliminating the need for the 211 HoTI/HoT and CoTI/CoT messages. 213 The mobile nodes should be able to switch to the BUB mode once 214 both nodes have moved outside their home networks. The BUB mode 215 can be applied at any time during the ongoing session. 217 5. Defining BUB 219 5.1 The BUB Test 221 When both endoints are mobile, the following four entities become 222 involved: 224 MN1 CN(MN2) 225 | | 226 | | 227 | | 228 | | 229 | | 230 HA1------------------HA2 232 In the above scenario, switching to BUB mode should not occur 233 before running a successful BUB test. The BUB test makes both 234 endpoints agree on using the link going through the two HAs for 235 exchanging the BU messages. The BUB test consists on exchanging 236 four messages and MUST be run in parallel with the RR test. 238 In the following scheme, MN1 is asking MN2 to switch to BUB 239 mode: 241 MN1 MN2 242 | | 243 _ | Do BUB | 244 | | -----------------------> | 245 | | | 246 HoTI/HoT | | BUB ACK | 247 messages |_ | <----------------------- | 248 | | 249 | | 250 | Do BUB | _ 251 | -----------------------> | | 252 | | | CoTI/CoT 253 | BUB ACK | | messages 254 | <---------------------- | _| 255 | | 256 | | 258 A successful completion of a BUB test consists of sending two 259 messages "Do BUB" and receiving two messages "BUB ACK". Each 260 request is incorporated into a HoTI and a CoTI message and each 261 reply is incorporated into a HoT and a CoT message. Using these 262 two messages enables MN1 to use two different paths to test the 263 willingness of MN2, without adding new ones. 265 If the sender gets two different responses in the CoT and the 266 HoT messages, it SHOULD re-run the RR test procedure and the BUB 267 test. In the latter case, if the sender gets again two different 268 responses, it MUST abandon switching to the BUB mode. 270 A BUB test fails if both of the "BUB ACK" messages are not 271 received after two successive tries. In this case, MN1 MUST send 272 the BUs according to the RO mode. 273 Note that in case of test failure, the endpoint, which has 274 launched the BUB test procedure MUST NOT run it again during 275 the same session. However, the other endpoint MUST always be 276 able to start a BUB test at any time during the same ongoing 277 session. 279 If one mobile node launchs a BUB test and the other endpoint 280 does not wish to switch to the BUB mode, it MUST reply to the 281 BUB test by sending two negative acknowledgments (NACK). Such 282 scenario may occur in case the other endpoint is static or it 283 has became static (i.e., it has not sent any BUs since a 284 predefined time). 286 If the two mobile endpoints agree to switch to the BUB mode, 287 they SHOULD NOT switch back at any time to the RO mode in the 288 ongoing session. 290 A positive BUB test will generate an additional message called 291 BUB Complete (BUBC) message, which will be sent by the responder 292 to the BUB test. The BUB complete message MUST follow the 293 following rules: 295 - The BUBC message is sent on the direct path to the MN's 296 care-of address used as the source address in the CoTI message 297 or as the destination address in the CoT message. 299 - The source address of the BUBC message is the same one used as 300 the source address in the CoT message. 302 - The BUBC message MUST contain a HAO including the home address 303 of the sender and the care-of init cookie sent by the MN in 304 the CoTI message. 306 - The BUBC message will contain a cookie called BUB cookie and 307 MUST be signed by the Kbm. The cookie MUST be used with the 308 Kbm to sign the DH messages. 310 - The BUBC message is sent after the CoT message. 312 If the MN receives the BUBC message before the CoT, it will 313 stop processing it and wait for the CoT message. If the CoT/BUBC 314 message is lost, then a new CoTI message is sent and the 315 responder MUST re-send a new CoT and BUBC messages. 317 The signature of the DH messages will use the Kbm as pre-shared 318 secret and the cookie sent in the BUB message. The signature 319 MUST be equal to: 321 Signature (DH_Message) = 322 First(96, HASH_SHA1(Kbm , DH_Message | cookie) 324 5.2 The BUB Option format 326 A new BUB option will be defined for carrying BUB messages. This 327 option MAY be inserted in all Return Routability test messages 328 (i.e., HoTI, HoT, CoTI, CoT). The format of the new option is 329 the following: 331 0 1 2 3 332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Option Type | Option Length | Option Data... 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Option Type 339 TBD 341 Option Length 343 Length of the option: 1 345 Option Data 347 This field can contain one of two possible messages defined 348 in three different codes as following: 350 code 0 => "Do BUB" 351 code 1 => "BUB ACK" 352 code 2 => "BUB NACK" 354 - When used in a HoTI message: the field MUST contain the code 355 "0". 357 - When used in a HoT message: the field MUST contain either 358 code "1" or code "2". 360 - When used in a CoTI message: the field MUST contain the code 361 "0". 363 - When used in a CoT message: the field MUST contain either 364 code "1" or code "2". 366 5.3 The BUB Complete Message Structure 368 A mobile node uses the BUBC message to complete a positive BUB 369 test. The BUBC message adds a cookie to the pre-shared secret 370 (i.e., Kbm) computed from the RR test. The main goal behind 371 sending the BUBC message is to force a malicious node to be at 372 the same time on the path going through the two HAs and on the 373 new direct path between the two MNs. 375 The BUB complete message uses the MH Type value 8. When this 376 value is indicated in the MH Type field, the format of the 377 Message Data field in the Mobility Header is as follows: 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Reserved | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 + Care-of Init Cookie + 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | 387 + BUB_Cookie + 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 . . 392 . Mobility Options . 393 . . 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Reserved 399 These fields are unused. They MUST be initialized to zero by 400 the sender and MUST be ignored by the receiver. 402 Care-of Init Cookie 404 64-bit field which contains the care-of init cookie. 406 BUB_Cookie 408 64 bit field which contains the cookie sent by the responder 409 to a BUB test. 411 Mobility Options 413 Variable-length field of such length that the complete 414 Mobility Header is an integer multiple of 8 octets long. 415 This field contains zero or more TLV-encoded mobility 416 options. 417 The receiver MUST ignore and skip any options which it does 418 not understand. 419 This specification does not define any options valid for the 420 BUB message. 422 If no actual options are present in this message, no padding is 423 necessary and the Header Len field will be set to 2. 425 6. The Diffie-Hellman Exchange 427 After a successful BUB test, the two MNs MUST establish a 428 bidirectional security association (SA) between them. Such SA 429 (more details in Appendix 1) MUST use a pre-shared secret 430 generated from the BUB test, to sign the DH messages. 432 The DH exchange is launched immediately after a successful BUB 433 test, by the MN, which has launched the test (e.g., MN1). 435 In order to mitigate a MiTM attack, MN1 MUST insert its IP home 436 address in a HAO attached to the first DH message and send it to 437 the MN2's home address (i.e., via HA2). 438 After receiving the first DH message, MN2 MUST duplicate the 439 second DH message and send one copy on the direct path to MN1's 440 care-of address and another copy to MN1's home address. The 441 second copy MUST be sent on the path going throught the two HAs. 442 The third DH message MUST be sent by MN1 to MN2's home address 443 on the same path than DH1. Upon receiving the third message, MN2 444 MUST comletes the DH message by sending the fourth message to 445 MN1's home address. 447 The different paths taken by the DH messages are shown in the 448 following: 450 MN1 HA1 HA2 MN2 451 | | | | 452 DH1 |======================================>|##################>| 453 | | | | 454 DH2 |<##################|<==================|<##################| 455 | | | | 456 DH2 |<==========================================================| 457 | | | | 458 DH3 |======================================>|##################>| 459 | | | | 460 DH4 |<##################|<======================================| 461 | | | | 463 ====>: denotes an authenticated message 465 ####>: denotes an encrypted message 467 7. Impact on BU/BA Messages 469 As it has been mentioned earlier, the main reasons for 470 designing BUB are the security concerns around the BU messages 471 and the high redundancy in mobility signaling messages. The 472 establishment of a bidirectional SA between the two MNs enables 473 them to substantially improve the safety of the BU messages and 474 eliminates the need for any further HoTI/HoT and CoTI/CoT 475 messages during the ongoing session. Such optimization leads to 476 a reduction of 4 messages between the two MNs each time a BU is 477 sent. 479 The different paths used to exchange the BU/BA messages appears 480 in the following scheme: 482 +------+ +------+ 483 | | BA | | 484 | MN1 |<================| MN2 | 485 | | | | 486 +------+ +------+ 487 # ^ 488 # # 489 BU# #BU 490 # # 491 V # 492 +------+ +------+ 493 | | | | 494 | HA1 |================>| HA2 | 495 | | BU | | 496 +------+ +------+ 498 ====>: denotes an authenticated message 500 ####>: denotes an encrypted message 502 When MN1 switches to a new network (i.e., gets a new care-of 503 address), it sends a BU message to MN2 on the path going through 504 the two HAs. MN1 MAY duplicate the BU message and another copy 505 on the direct path. The two BU messages MUST have the same 506 sequence number and MUST be signed with the authenticated 507 binding management (Kabm) key. 509 After switching to the BUB mode, the following rules MUST be 510 applied: 512 - The MNs MUST NOT use the alternate care-of address option in 513 the BU messages sent to each other, in order to counter 3rd 514 party bombing attack [6]. 516 - The MN MUST NOT use the nonce indices option in all new 517 binding updates messages sent after a care-of address change. 519 The MN SHOULD set the Acknowledge (A) bit in the BU message 520 after switching to OMIPv6. 522 To avoid replay attacks, the MN, which has launched the BUB test 523 will keep the sequence number sent in the first BU immediately 524 after the DH exchange and increment it in all subsequent BU 525 messages. The same rule MUST be adopted by the other mobile 526 endpoint. 528 In case the session starts with one MN and one static node (CN) 529 and OMIPv6 [7] is applied, then switching to the BUB mode (i.e., 530 the static node becomes mobile) can be done seamlessly. In such 531 scenario, the same Kabm key can be used to sign the BU message 532 sent by the CN (i.e., MN2) and MN2 MUST send its BU messages on 533 the path going through the two HAs. MN1 MUST use the same path 534 for any subsequent BU messages. Both nodes can duplicate their 535 BU messages and use the direct path to send the second copy. 537 8. Security considerations 539 This draft proposes a new mode which makes the exchange of 540 BUs more secure. It should be considered as an enhancement to 541 the security of the signaling messages exchange between two 542 mobile endpoints. 544 9. Acknowledgments 546 Authors would like to thank Laurent Marchand for his review and 547 comments on the draft. Many Thanks to Karim El-Malki and Shinta 548 Sugimoto for improving the draft. 550 10. Normative References 552 [1] D. Johnson and C. Perkins, "Mobility Support in IPv6", 553 draft-ietf-mobileip-ipv6-24.txt, June 2003. 555 [2] J.Arkko, V. Devarapalli, F. Dupont, "Using IPsec to Protect 556 Mobile IPv6 Signaling between Mobile Nodes and Home Agents", 557 draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. 559 [3] S. Bradner, "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119. 562 11. Informative References 564 [4] P. Nikander, T. Aura, J. Arkko, G.Montenegro and E. Nordmark 565 "Mobile IP version 6 Route Optimization Security Design 566 Background", draft-nikander-mobileip-v6-ro-sec-01. 568 [5] Krawczyk, H., "SIGMA: the 'SIGn-and-MAC'Approach to 569 Authenticated Diffie-Hellman and its use in the IKE 570 Protocols", in Advanceds in Cryptography - CRYPTO 2003 571 Proceedings, LNCS 2729, Springer, 2003. Available at: 572 http://www.ee.technion.ac.il/~hugo/sigma.html. 574 [6] F. Dupont, "A note about 3rd party bombing in Mobile IPv6", 575 draft-dupont-mipv6-3bombing-00, February 2004. 577 [7] W. Haddad, F. Dupont, L. Madour, S. Krishnan, S. D. Park, 578 "Optimizing Mobile IPv6 (OMIPv6)", 579 draft-haddad-mipv6-omipv6-01, February 2004. 581 12. Authors' Addresses 583 Wassim Haddad 584 Ericsson Research Canada 585 8400, Decarie Blvd 586 Town of Mount Royal 587 Quebec H4P 2N2 588 CANADA 589 Phone: +1 514 345 7900 590 Fax: +1 514 345 7900 591 E-Mail: Wassim.Haddad@ericsson.com 593 Francis Dupont 594 ENST Bretagne 595 Campus de Rennes 596 2, rue de la Chataigneraie 597 BP 78 598 35510 Cesson Sevigne Cedex 599 FRANCE 600 Fax: +33 2 99 12 70 30 601 E-Mail: Francis.Dupont@enst-bretagne.fr 603 Lila Madour 604 Ericsson Research Canada 605 8400, Decarie Blvd 606 Town of Mount Royal 607 Quebec H4P 2N2 608 CANADA 609 Phone: +1 514 345 7900 610 Fax: +1 514 345 6195 611 E-Mail: Lila.Madour@ericsson.com 613 Alan Kavanagh 614 Ericsson Research Canada 615 8400, Decarie Blvd 616 Town of Mount Royal 617 Quebec H4P 2N2 618 CANADA 619 Phone: +1 514 345 7900 620 Fax: +1 514 345 6195 621 E-Mail: Alan.Kavanagh@ericsson.com 623 Suresh Krishnan 624 Ericsson Research Canada 625 8400, Decarie Blvd 626 Town of Mount Royal 627 Quebec H4P 2N2 628 CANADA 629 Phone: +1 514 345 7900 630 Fax: +1 514 345 6195 631 E-Mail: Suresh.Krishnan@ericsson.com 633 Soohong Daniel Park 634 Mobile Platform Laboratory, Samsung Electronics 635 416. Maetan-Dong, Yeongtong-Gu, Suwon 636 Korea 637 Phone: +81 31 200 4508 638 E-Mail: soohong.park@samsung.com 640 Hannu Kari 641 Helsinki University of Technology 642 Laboratory for Theoretical Computer Science 643 P.O. Box 5400 644 FIN-02015 HUT 645 FINLAND 646 Phone: +358 9 451 2918 647 E-Mail: Hannu.Kari@hut.fi 649 13. Full Copyright Statement 651 Copyright (C) The Internet Society (2003). All Rights Reserved. 652 This document and translations of it may be copied and furnished 653 to others, and derivative works that comment on or otherwise 654 explain it or assist in its implementation may be prepared, 655 copied, published and distributed, in whole or in part, without 656 restriction of any kind, provided that the above copyright 657 notice and this paragraph are included on all such copies and 658 derivative works. However, this document itself may not be 659 modified in any way, such as by removing the copyright notice or 660 references to the Internet Society or other Internet 661 organizations, except as needed for the purpose of developing 662 Internet standards in which case the procedures for copyrights 663 defined in the Internet Standards process must be followed, or 664 as required to translate it into languages other than English. 665 The limited permissions granted above are perpetual and will not 666 be revoked by the Internet Society or its successors or 667 assignees. 668 This document and the information contained herein is provided 669 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 670 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 671 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 672 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 673 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 674 PARTICULAR PURPOSE. 676 Appendix A: Establishing the Bidirectional Security Association 678 As it has been stated in 4.3, after a successful BUB test, the 679 two MNs MUST establish a bidirectional security association 680 between them and generate a session key. The session key MUST be 681 used to authenticate BUs/BAs messages exchanged between the two 682 MNs via the path going through their two HAs. The session key 683 MAY also be used to authenticate the CoTI/CoT messages exchanged 684 via the direct path. 686 The session key is generated from a Diffie-Hellman (DH) exchange 687 which MUST be authenticated. Such authentication MAY use the Kbm 688 key as a pre-shared secret used to sign the DH messages. 689 Note that the Kbm key MUST be the last key generated from the RR 690 test (i.e., the RR test during which, the BUB test has been 691 launched). 693 The DH messages exchanged between the two MNs are described in 694 the following (for more details about the messages structure and 695 how to generate different keys, please refer to [5]): 697 sid , gX, N , info 698 MN1 MN1 MN1 MN1 MN2 699 ---------------------------------------------------------------> 701 sid , sid , gY, N , info 702 MN1 MN2 MN2 MN2 703 <--------------------------------------------------------------- 705 sid ,sid ,MN1,SIG (N ,sid ,gX,info ,info ), MAC(MN1) 706 MN1 MN2 Kbm MN2 MN1 MN1 MN2 Km 707 ---------------------------------------------------------------> 709 sid ,sid, ,info ,MN2,SIG (N ,sid ,gY,info ,info),MAC(MN2) 710 MN1 MN2 MN2 Kbm MN1 MN2 MN2 MN1 Km 711 <--------------------------------------------------------------- 713 In the above scheme, the following abbreviations have been 714 adopted: 716 -gX = shared part of MN1's secret 718 -gY = shared part of MN2's secret 720 -sid = session identifier used to specify the ongoing session. 722 -N = nonce 724 -info = additional information carried in the protocol 725 messages 727 -MN1 = Identity of MN1 (e.g., MN1's Home IP address) 729 -MN2 = Identity of MN2 (e.g., MN2's Home IP address) 731 -Kbm = key generated from the RR test 733 -SIG(msg) = denotes the signature of "msg" using the Kbm. 735 -Km = key generated from DH (known only by MN1 and MN2) 737 -MAC(msg) = denotes a message authenticated code computed from 738 Km "msg" and signed by Km.