idnits 2.17.1 draft-perkins-bake-00.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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 35) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 202: '...respondent nodes MUST implement the al...' RFC 2119 keyword, line 317: '... The protocol MUST fulfill the a set...' RFC 2119 keyword, line 466: '...ck, the protocol MUST NOT require the ...' RFC 2119 keyword, line 557: '... correspondent, the mobile node SHOULD...' RFC 2119 keyword, line 560: '... of the mobile node. This packet MUST...' (83 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 217 has weird spacing: '... Cookie a t...' ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [1], but that reference does not seem to mention RFC 2119 either. -- 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 (12 April 2001) is 8414 days in the past. Is this intentional? 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 (-24) exists of draft-ietf-mobileip-ipv6-13 ** Obsolete normative reference: RFC 2406 (ref. '3') (Obsoleted by RFC 4303, RFC 4305) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Normative reference to a draft: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '8') Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Mobile IP Working Group Pekka Nikander 2 INTERNET-DRAFT Ericsson Research NomadicLab 3 Charles Perkins 4 Nokia Research Center 5 12 April 2001 7 Binding Authentication Key Establishment Protocol for Mobile IPv6 8 10 Status of This Memo 12 This document is a submission by the mobile-ip Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the mobile-ip@sunroof.eng.sun.com mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Abstract 36 A method is proposed for providing key information for use between 37 a mobile node and correspondent node, to be used for the purpose of 38 authenticating Mobile IPv6 Binding Updates. The key distribution 39 is secure except against man-in-the-middle attacks, when the 40 attacker resides along the routing path between the correspondent 41 node and the mobile node's home agent. The key can be used for 42 authenticating subsequent Binding Updates from the same mobile node, 43 substantially reducing the number of key establishment cycles needed 44 for maintaining efficient communication paths between the mobile node 45 and correspondent node. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Introduction 1 55 2. Terminology 2 56 2.1. Specific Document Terminology . . . . . . . . . . . . . . 2 57 2.2. Abbreviations and Symbolic Names . . . . . . . . . . . . 3 59 3. Design goals 4 60 3.1. Beliefs held by the CN . . . . . . . . . . . . . . . . . 5 61 3.2. Beliefs held by the MN . . . . . . . . . . . . . . . . . 5 62 3.3. Optional Beliefs . . . . . . . . . . . . . . . . . . . . 6 64 4. Design principles 6 65 4.1. Low computational overhead . . . . . . . . . . . . . . . 6 66 4.2. Minimal Messaging . . . . . . . . . . . . . . . . . . . . 7 67 4.3. DoS resistance . . . . . . . . . . . . . . . . . . . . . 7 68 4.4. Optional Active Participation of HA . . . . . . . . . . . 8 69 4.5. No single message alone gives keying material out . . . . 8 70 4.6. Randomness included by both MN and CN . . . . . . . . . . 9 71 4.7. Inband creation for BKSA . . . . . . . . . . . . . . . . 9 72 4.8. Protection against "future address stealing" . . . . . . 9 74 5. Protocol overview 9 75 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Cryptographic Design Analysis 12 79 6.1. Message 1: Binding Warning . . . . . . . . . . . . . . . 13 80 6.2. Message 2: Binding Request . . . . . . . . . . . . . . . 13 81 6.2.1. Optional Processing by the Home Agent . . . . . . 14 82 6.2.2. Processing by the Mobile Node . . . . . . . . . . 15 83 6.3. Message 3: Binding Key Establishment (with Binding 84 Update) . . . . . . . . . . . . . . . . . . . . . . . 16 85 6.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 17 86 6.5. Correspondent Node Initiated Operation . . . . . . . . . 18 88 7. Protocol Processing 20 89 7.1. Initiation of the protocol . . . . . . . . . . . . . . . 20 90 7.2. Processing a received Binding Warning . . . . . . . . . . 21 91 7.3. Generating data for the Binding Request . . . . . . . . . 22 92 7.3.1. Encoding TCP connection . . . . . . . . . . . . . 22 93 7.4. Sending the Binding Request . . . . . . . . . . . . . . . 23 94 7.5. Forgetting State . . . . . . . . . . . . . . . . . . . . 24 95 7.6. Processing Binding Request at the Home Agent . . . . . . 24 96 7.7. Processing Binding Request by the Mobile Node . . . . . . 24 97 7.8. Establishing the BKSA . . . . . . . . . . . . . . . . . . 25 98 7.9. Sending Binding Key Establishment (and Binding Update) . 26 99 7.10. Receiving Binding Key Establishment . . . . . . . . . . 27 100 7.11. Establishing the CN Security Associations . . . . . . . . 27 101 7.12. Processing the rest of the packet . . . . . . . . . . . . 28 102 7.13. Reduced operations when the Mobile Node is at home . . . 28 103 7.14. Processing For Correspondent Node Initiation . . . . . . 28 104 7.14.1. Initiating the protocol by sending a Binding 105 Request . . . . . . . . . . . . . . . . . 29 106 7.14.2. Handling a CN initiated Binding Request by a HA . 29 107 7.14.3. Handling a CN initiated Binding Request by a MN . 29 108 7.14.4. Further operations at the CN end . . . . . . . . 30 109 7.15. Simultanous operation by two Mobile Nodes . . . . . . . . 31 111 8. Cryptographic Algorithms 31 112 8.1. Algorithm for Computing Token T0 . . . . . . . . . . . . 31 113 8.2. Algorithm for computing token T1 . . . . . . . . . . . . 32 114 8.3. Algorithm for computing nonce N2 . . . . . . . . . . . . 32 115 8.4. Algorithm for computing token T2 . . . . . . . . . . . . 32 116 8.5. Algorithm for computing key material BK . . . . . . . . . 33 118 9. Protocol Data Unit Formats 33 119 9.1. Binding Warning Message . . . . . . . . . . . . . . . . . 33 120 9.2. Binding Request Message . . . . . . . . . . . . . . . . . 34 121 9.3. Binding Key Establishment Destination Option . . . . . . 35 123 Acknowledgements 36 125 References 37 127 Chair's Address 38 129 Authors' Addresses 39 130 1. Introduction 132 Mobile IPv6 specifies the use of a Binding Update destination option 133 for use between a correspondent node and a mobile node. This Binding 134 Update associates a "care-of address" to the mobile node's "home 135 address" enabling direct routing of packets to the current point 136 of attachment in use by the mobile node. Unfortunately, there may 137 be many instances where no pre-existing security association is 138 available for use by the correspondent node to authenticate a Binding 139 Update from the mobile node. 141 In order to solve this problem, we propose a method by which a 142 correspondent node supplies some random data for use by the mobile 143 node as input to an algorithm for creating a security association. 144 This security association, once established between the mobile node 145 and the correspondent node, is then used to create the authentication 146 data that is required to be supplied as one of the security fields of 147 the Binding Update destination option. 149 Without introducing reliance upon use of certifiable public keys, it 150 is quite difficult to avoid all attacks against the correspondent 151 node that might allow some malicious third part to masquerade as 152 the mobile node. However, we can at least make sure that any such 153 malicious node would have to reside along the routing path between 154 the correspondent node and the home agent. This substantially 155 reduces to the vulnerability to such attacks, since the specific 156 routing path required amounts to an extremely small proportion of the 157 Internet. 159 Some of the security features of this protocol rely on requiring 160 that the correspondent node must send the Binding Requests to the 161 home network. This gives some measure of assurance that subsequent 162 protocol actions could avoid interference by nodes not along the 163 natural routing path between the correspondent node and the home 164 network. 166 DISCUSSION. If the security associations created are AH 167 security associations, most IPSec implementations would need 168 to change their policy engine. However, we would consider 169 AH better than a special purpose protection since using 170 AH would allow IKE/AAA/whatever to be used to create the 171 SAs between the MN and the HA without too many changes. 172 On the other hand, nothing prevents from specifying a new 173 DOI/whatever to create BKSAs with IKE/AAA/whatever. Thus, 174 from that point of view, this protocol is just a special 175 purpose key management protocol, able to create only BKSAs. 177 In this protocol specification, several new messages are introduced: 179 Binding Warning 180 which is sent by a mobile node to a correspondent node 181 as an indication that a new care-of address should be 182 obtained for the one of the mobile node's addresses. 184 Binding Request 185 which is sent by a correspondent node to the home 186 address of the mobile node in order to elicit a Binding 187 Update. 189 Binding Key Establishment Extension 190 which supplies a key to be used by the correspondent 191 node when verifying authentication data supplied by 192 the mobile node to ensure the integrity of the Binding 193 Update data. 195 Subsequent sections provide an overview of the operation of the key 196 establishment mechanism, discussion about the cryptological analysis 197 motivating the design of the protocol, the format of the protocol 198 messages, and detailed specification for the message formats. 199 Although a specific authentication key establishment algorithm is 200 proposed, it should be noted that other key establishment algorithms 201 may be proposed in the future. Nevertheless, for interoperability, 202 all correspondent nodes MUST implement the algorithm specified in 203 this document. 205 2. Terminology 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in [1]. Furthermore, 210 this document makes use of many general terms defined in the protocol 211 specification for Mobile IPv6 [2]. 213 2.1. Specific Document Terminology 215 Other specific terms are defined as follows. 217 Cookie a tasty morsel with random bits of goodness 219 Hash a way to scramble tasty morsels of data; often used as a 220 message digest or message authentication code (MAC) 222 Key a secret number that enables operation of a 223 cryptographic algorithm. 225 Binding Key 226 a key used for authenticating Binding Update messages. 228 Security Association 229 a security object shared between two nodes which 230 includes the data mutually agreed on for operation of 231 some cryptographic algorithm (typically including a key, 232 as defined above). 234 Binding Key Security Association (BKSA) 235 a security association established specifically for the 236 purpose of producing and verifying authentication data 237 passed with a Binding Update destination option. 239 Tunnel Protection 240 protecting tunneled data against attackers, either by 241 encryption, inserting additional integrity checking, or 242 by modifying the data in some unforgeable fashion. 244 2.2. Abbreviations and Symbolic Names 246 The protocol messages defined in this specification use some opaque 247 data generated according to the needs of various cryptographic 248 algorithms. These data are referred to by symbolic names. In 249 order to reduce confusion, we attempt to use the same symbolic 250 names throughout the document. These names are gathered together 251 here for easy reference. We also include various abbreviations for 252 completeness. 254 CN The correspondent node 256 HA The home agent 258 MN The mobile node 260 HoA The home address of the mobile node 262 CNA The IPv6 address of the correspondent node 264 KeyMat Data computed for use in generating the Binding Key 265 which defines the BKSA 267 BK The binding key 269 BKE The Binding Key Establishment destination option 271 K_CN A secret value maintained (and reselected periodically) 272 by the correspondent node for use in generating nonce N2 274 K_(MN,HA) A key shared between mobile node and home agent. 276 PCB Protocol Control Block (used by TCP) 277 N1 A nonce created by the mobile node for use in the 278 Binding Warning, and eventually used to identify the 279 Binding Request 281 N2 A nonce, reproducible from K_CN and T1, for use by the 282 correspondent node when producing token T2. It is 283 used to validate an eventual Binding Key Establishment 284 message. 286 R A random number created by the mobile node after 287 reception of the Binding Request message, and used when 288 creating BK. 290 T0 A token computed in order to assure data integrity, and 291 to provide a temporarily hidden input for token T1 293 T1 A token computed from T0, and made publicly visible in 294 protocol messages, in order to assure data integrity. 296 T2 The first part of the key generation material, 297 calculated by the correspondent node, and delivered to 298 the mobile node in the Binding Request message. 300 HASH_T0 A cryptographic algorithm used to produce the token T0 301 (see section 8.1) 303 HASH_T1 A cryptographic algorithm used to produce the token T1 304 (see section 8.2) 306 HASH_N2 A cryptographic algorithm used to produce the nonce N2 307 (see section 8.3) 309 HASH_T2 A cryptographic algorithm used to produce the token T2 310 (see section 8.4) 312 HASH_BK A cryptographic algorithm used to produce the desired 313 Binding Key (see section 8.5) 315 3. Design goals 317 The protocol MUST fulfill the a set of defined goals. The goals can 318 be expressed in terms of beliefs that the parties may hold after a 319 successful protocol run. These beliefs are outlined in Sections 3.1 320 through 3.3, below. 322 The primary goal of the protocol is to create unauthenticated but 323 appropriately authorized keying material that may be reasonably 324 used to secure future Binding Updates between a MN and a CN. By 325 "unauthenticated" we mean that the protocol does not give any 326 assurance about any identity of the MN to the CN or vice versa. By 327 "appropriately authorized" we mean that the CN has reasonable bases 328 to believe that it is sharing the keying material with the MN, i.e., 329 with a party that is reachable through the home address that it 330 claims to "own", and that the MN has reasonable bases to believe that 331 it is sharing the keying material with the CN, i.e., with the party 332 who is reachable through the address that the MN expects the CN to 333 have. 335 By "reasonable bases" we mean that the protocol does not aim to be 336 fully secure in any stronger means of the term "secure" but that it 337 does protect against attacks that some unrelated third party might 338 be able to launch from an arbitrary location in the Internet. In 339 particular, the protocol does not aim to protect the parties against 340 attackers that are able to eavesdrop all traffic flowing between the 341 MN, CN and HA. 343 3.1. Beliefs held by the CN 345 In this section, we list the beliefs that the correspondent node is 346 expected to act upon during its part of the protocol operation. 348 - The CN is able to believe that the MN has the given home address, 349 since it has checked that MN eventually receives packets sent to 350 the Home Address, and that the MN is (was) able to reply to them. 352 - The CN is able to believe that the MN wants to provide the given 353 CoA for use in routing headers for data to be sent to mobile 354 node. 356 - The CN believes that the key it holds with an MN is only known to 357 the MN unless there is some third party who is able to either 359 * eavesdrop all traffic send and received by the CN, or 361 * eavesdrop all traffic sent by both the CN and MN, or 363 * eavesdrop all traffic send and received by the MN, and the 364 traffic between the MN and the HA is in clear. 366 No other passive or active attack scenarios are believed to be 367 tolerated by this protocol. 369 3.2. Beliefs held by the MN 371 In this section, we list the beliefs that the mobile node is expected 372 to act upon during its part of the protocol operation. 374 - The MN believes that packets sent to the CN address are 375 (eventually) received by the CN, and that the CN is able to reply 376 to them. 378 - The MN believes that the key it holds with the CN is only 379 known to the CN unless there is some third party who is able to 380 eavesdrop traffic as specified in section 3.1. 382 3.3. Optional Beliefs 384 [XXX: Should we allow the HA have optional beliefs?] 386 [XXX: Should we allow the MN have optional beliefs about endorsement 387 by the HA?] 389 4. Design principles 391 In the following sections, we discuss the following design principles 392 which have been used in the construction of this protocol. 394 - Low computational overhead 396 - Minimal messaging: MN->CN, CN->HA->MN, MN->CN 398 - Resistant to DoS attacks 400 CN does not need to create state before the third message 402 - Allows active participation of HA but does not require it 404 - No single message alone gives keying material out 406 - Randomness included by both MN and correspondent node 408 - Allows inband establishment for the Binding Key Security 409 Association (BKSA) 411 - Protection against "future address stealing" 413 - Allows initation by the correspondent node. 415 4.1. Low computational overhead 417 The protocol should have low computational overhead. In particular, 418 it must not require any heavy computation by the CN before it has 419 some assurance that the MN is actually there and that the MN is able 420 to receive messages sent to the Home Address. Furthermore, it should 421 not require any heavy computation by the MN as the MN may have severe 422 computational limitations. 424 On the other hand, optional extensions to the protocol may enable the 425 HA to assist the MN in computations. That is, if the MN and the HA 426 trust each other, and the HA has much more computational power than 427 the MN, then the MN may rely on the HA to perform heavy computations 428 on its behalf. 430 4.2. Minimal Messaging 432 The protocol is conveyed by three messages, namely: 434 1. Binding Warning: sent by a MN to a CN (MN->CN) 436 2. Binding Request: sent by a CN to the MN through the HA 437 (CN->HA->MN) 439 3. Binding Key Establishment: sent by a MN to the CN (MN->CN) 441 A two message variant of this, initiated by the CN, is also needed; 442 this is defined in Section 7.14. 444 4.3. DoS resistance 446 The protocol can be made resistant to "denial of service" (DoS) 447 attacks by using the following principles. 449 1. The involved parties must minimize state creation before they 450 obtain assurance that the alleged peer is on-line. That is, 451 state is created only when a such a message is received that the 452 party creating the state can verify that it has itself recently 453 been involved in sending a message to which the received message 454 is a reply. 456 2. The amount of computation performed by a responding party should 457 be limited until it is able to check that the initiating party 458 has been performed an equal or larger amount of computation. 460 As a particular design principle, we want to make it possible for a 461 MN to send the first message to the CN before any prior communication 462 between the MN and the CN (see section 4.7. For example, this first 463 message could be included in a TCP SYN sent by the MN to the CN. 465 In order not to create a possibility for a new TCP SYN flooding type 466 of attack, the protocol MUST NOT require the CN to create any state 467 before it receives its final protocol message. This is a particular 468 instance of the first DoS design principle, in the context of the 469 three-message protocol we specify in this document. Additionally, 470 we would like to design the protocol in such a way that the CN could 471 optionally defer even TCP state creation until it receives the third 472 protocol message. Specifying such mechanism is beyond the scope of 473 this document; for here, it suffices to merely create a transparent 474 mechanism that could be used for that and other similar purposes. 476 4.4. Optional Active Participation of HA 478 We envision a future with various relationships between the MN and 479 the HA, and therefore very different kinds of HAs. Some of the HAs 480 may be mere packet reflectors, tunneling all packets sent to them 481 to the MN. For example, HAs used for temporary packet forwarding 482 are likely to be like this. However, some HAs may be much more 483 intelligent, and even provide computation services to the MNs. 485 In order not to rely on any specific properties of the HAs, but allow 486 space for utilizing them, we want to design the protocol in such a 487 way that it allows participation of HAs but does not require it. We 488 also expect that some HAs will encrypt encapsulated packets when 489 tunneling them to the mobile nodes, providing additional security. 491 4.5. No single message alone gives keying material out 493 Since we do not want to assume any existing security associations 494 between the MN and the CN or between the HA and the CN, the protocol 495 cannot create properly authenticated keying material out of nothing. 496 That is, in the light of currently established wisdom, the protocol 497 cannot create keying material in such a way that the participating 498 parties would have enough grounds to believe that only they and no 499 one else possess the keying material. 501 DISCUSSION: For the purposes of appropriate authorization 502 (but not authentication), something like the protocol 503 presented in draft-nikander-ipng-pbk-addresses-00.txt could 504 be used to create keying material in such a way that it 505 would be protected against passive attackers and even (at 506 least most if not all) active attackers. However, the 507 protocol requires public key computations. 509 Thus, the protocol has to be designed in such a way that an attacker 510 that is only able to eavesdrop any single message is unable to create 511 the keying material. This gives reasonable protection against 512 passive attackers. In practice, an attacker would have to be on the 513 same link with the CN, on the same link with the MN and the traffic 514 between the HA and the MN be unprotected, or be able to eavesdrop 515 traffic between both the MN and CN and CN and HA. This drastically 516 reduces the number of locations from which a malicious node can mount 517 an attack. 519 4.6. Randomness included by both MN and CN 521 To protect against possible bad random number generators, the keying 522 material includes randomness generated both by the MN and the CN. 524 4.7. Inband creation for BKSA 526 We wish to avoid requiring extensive changes to the current Mobile 527 IPv6 specification. Therefore, the protocol is designed in such a 528 way that the MN creates a Binding Key Security Association (BKSA) 529 after receiving the message from the correspondent node, and that the 530 CN is able to create the same BKSA after receiving its final message. 531 This makes it possible to send an authenticated BU along with the 532 third message. Furthermore, in this way the normal data flow between 533 the two endpoints (mobile node and correspondent node) experiences 534 minimal disruption. 536 4.8. Protection against "future address stealing" 538 To protect against "future address stealing" [7], the mobile nodes 539 should use random CoAs [6]. 541 5. Protocol overview 543 This section gives an overview of the protocol from an implementation 544 (engineering) point of view. A corresponding cryptographic (security 545 point of view) description is given in Section 6. We first outline 546 the message exchanges, and then discuss the protocol steps one by 547 one. Section 7 specifies the processing rules, and Section 9 the 548 exact message formats. 550 5.1. Protocol Messages 552 The protocol uses the Binding Warning, Binding Request, and the 553 Binding Key Establishment (BKE) destination options, as follows. 555 1. If no security association between a mobile node and a 556 correspondent node exists for the purpose of authenticating a 557 Binding Update to that correspondent, the mobile node SHOULD 558 send a Binding Warning to the correspondent node, asking it to 559 start the process of establishing the needed security association 560 with the indicated address of the mobile node. This packet MUST 561 contain the Home Address Destination Option, informing the CN 562 about the alleged Home Address (HoA) of the MN. 564 2. If the Correspondent Node wants to continue the exchange, it 565 sends a Binding Request to the Home Address of the MN. The packet 566 MUST be sent to the Home Address independent on any possibly 567 existing Bindings. As the default action, the Home Agent SHOULD 568 tunnel the packet to the Mobile Node. The tunnel SHOULD be 569 protected using ESP [3], or some other means. 571 3. When the Mobile Node receives a Binding Request, passed via the 572 tunnel and originated by the Correspondent Node, it creates 573 a BKSA that will be used to secure Binding Updates. It then 574 generates a packet that contains at least the following headers 575 in the following order: 577 IP header 578 Routing Header, if present 579 Destination Options header, containing 580 Home Address option 581 Binding Key Establishment option 582 Fragmentation Header, if present 583 IPSec headers, if present 584 Destination Options header, including 585 Binding Update 586 Upper layer data, if present 588 The Binding Key Establishment Destination Option allows the 589 Correspondent Node to perform checks to reduce the risk that the 590 peer is not the right Mobile Node "owning" the Home Address to 591 a reasonable level, and to create the same BKSA that the Mobile 592 Node created after the second message. 594 At the conclusion of the protocol, a BKSA will have been established, 595 for use to create and verify the data containing in Binding Update 596 destination options. 598 5.2. Prerequisites 600 We assume that certain conditions are in place before the actual 601 protocol is run. This is a standard practice in security protocols, 602 which usually build upon existing security relationships. However, 603 in the case of this protocol those relationships are relatively weak, 604 at least if compared to typical security protocols. 606 Briefly, there are two requirements: 608 - There is a relationship between the Mobile Node and the Home 609 Agent. 611 - The Correspondent Node has to generate random keys, K_CN, known 612 only to itself. 614 In the simplest form, the relationship between the Mobile Node and 615 the Home Agent may be the implicit agreement that the Home Agent 616 will tunnel received packets to the Mobile Node. Such an agreement 617 could be arranged without having any explicit security association 618 between the MN and the HA; for example, a temporary HA might just 619 forward packets to a fixed address for a period of time. Using 620 Mobile IPv6 [2], a mobile node can update the tunnel point (in 621 the Binding Cache) which the home agent maintains for it, using a 622 pre-established BKSA. Often, the Mobile Node and Home Agent have 623 an IPSec ESP security association, and the Home Agent is able to 624 encrypt and integrity protect the tunneled packets. The protocol 625 in this document also allows more advanced security relationships 626 between the Home Agent and the Mobile Node, enabling some of the 627 crypto processing to be performed by the Home Agent instead of the 628 Mobile Node. The specification of such processing is outside this 629 specification. 631 The present protocol enables the use of a key, K_(MN,HA), shared 632 between the MN and the HA, whose sole purpose SHOULD be to be used 633 within this protocol. Before using the key for any other purposes, 634 the possibility of unwanted interactions must be eliminated. 636 With some loss of security, it is also possible to run a variation 637 of the protocol where the key K_(MN,HA) belongs solely to the Mobile 638 Node, and is not known by the HA or any other party. 640 The random keys, K_CN, generated by the Correspondent Node are 641 assumed to be short lived; a typical lifetime of such a key might be 642 e.g. 10 seconds or one minute. As the key is local to the CN, the 643 exact policy and mechanism for generating such keys is not specified. 644 For example, one possibility is to generate a completely new key only 645 every few minutes or hours, and just keep incrementing the key until 646 it is the time to create a completely new key. To add robustness, 647 the Correspondent Node MUST remember a number of previous K_CN 648 values. The exact number of remembered values is a matter of local 649 policy. 651 6. Cryptographic Design Analysis 653 From the cryptographic point of view, we have a three-party 654 protocol where one of the parties may be a passive forwarder, 655 only optionally taking part of the protocol run in any other way 656 than reflecting messages. To emphasize the difference between the 657 parties and their addresses, we denote the Mobile Node's current 658 address (care-of-address) as CoA, its Home Address as HoA, and the 659 Correspondent Node's address as CNA. The parties are the Mobile Node 660 (MN), the Corresponding Node (CN) and the Home Agent (HA), assumed 661 connected in a triangular manner: 663 HA 664 / ^ 665 / \ 666 / \ 667 V \ 668 MN <-----> CN 670 The MN and CN are able to directly exchange messages. However, for 671 the purposes of this protocol we assume that the links between the 672 CN and the HA, and between the HA and MN are unidirectional. By 673 default, we assume only that the HA can act as a passive reflector, 674 tunneling any packets sent to themobile node's home address (HoA) to 675 the MN's care-of address (CoA). 677 The messages tunneled by the HA to the MN may or may not be 678 encrypted. If they are encrypted, the encryption is assumed to 679 effectively defeat eavesdropping on the links along the tunnel's 680 path. The links between the MN and the CN and leading from CN to HA 681 are assumed to be clear and vulnerable to eavesdropping. 683 From the security point of view, the purpose of the protocol can be 684 described as follows. The protocol starts from an initial situation 685 where the MN and HA have a security association with each other. 686 More formally, the MN knows that it is currently using the address 687 CoA and that its home address is HoA, and that there is the Home 688 Agent HA at the home address HoA. Likewise, the HA knows that it is 689 currently reflecting packets sent to HoA to the care-of-address CoA, 690 and that the MN is assumed to be currently reachable through CoA. 691 Furthermore, they may share a secret key K_(MN,HA). Furthermore, the 692 MN has (recently) learned an address CNA that it assumes to belong 693 to some corresponding node CN. The HA does not have any information 694 about the CN. The CN does not have any information about the MN or 695 HA.This initial state can be described as the following knowledge sets. 697 MN: { CoA, HoA, K_(MN,HA), CNA } 698 HA: { CoA, HoA, K_(MN,HA) } 699 CN: { K_CN, CNA } 701 6.1. Message 1: Binding Warning 703 The protocol is triggered by the MN deciding that it wants to 704 exchange a binding key with whatever CN happens to currently be at 705 CNA. To ensure message freshness the MN creates a nonce, N1, and adds 706 it to its knowledge set. 708 MN: { CoA, HoA, K_(MN,HA), N1 } 709 HA: { CoA, HoA, K_(MN,HA) } 710 CN: { CNA, K_CN } 712 After that, it uses the algorithms in section 8.1 and 8.2 to create 713 cryptographic tokens T0 and T1. T1 may be optionally authenticated 714 by the HA if the HA knows the key K_(MN,HA). The reason for this two 715 step process of creating the token T1 is that later, in the third 716 message, T0 is used to authenticate the MN. 718 The first message contains the addresses, the nonce N1 and the 719 token T1. (Note that the addresses are already available in the IP 720 headers, and they MUST NOT be repeated in the payload.) 722 MN->CN: < CoA, CNA, HoA, N1, T1 > 724 When the CN receives the message, it learns the addresses CoA, HoA, 725 the nonce N1 and the token T1. These are tabulated as a separate 726 knowledge set since the CN should forget them after it has sent 727 the reply. The reason why we want the CN to forget these data is 728 denial-of-service resistance. Basically, we want the CN to handle 729 the packet effectively and fast, and then forget about it. 731 MN: { CoA, HoA, K_(MN,HA), N1 } 732 HA: { CoA, HoA, K_(MN,HA) } 733 CN: { CNA, K_CN } + { CoA, HoA, N1, T1 } 735 6.2. Message 2: Binding Request 737 For the next message, the CN prepares a structured nonce N2 and an 738 authentication token T2. The first of these, N2, is sent to the MN 739 through the HA, and used by the MN as a part of creating the new 740 keying material. The second token, N2, is passed by the HA and MN 741 back to the CN, allowing it to authenticate the third message as it 742 arrives. Furthermore, the CN must be able to reconstruct the nonce 743 N2, based on the authenticated third message, so that it can create 744 the same keying material as the MN does. 746 N2 := HASH_N2 ( K_CN ; 0 || T1 ) (see section 8.3) 747 T2 := HASH_T2 ( K_CN ; T1 || CoA || CNA || HoA) 748 (section 8.4) 750 In creating the tokens, CN uses only information that will 751 be available to it when it receives the third message. The 752 authentication token T2 must include all information whose integrity 753 must be protected, as well as T1 since its inclusion helps to block 754 active attacks later in the protocol. On the other hand, the content 755 of the nonce N2 is not that critical; the only requirements are that 756 it is hard to predict (hence K_CN) and it can be easily recomputed 757 upon arrival of the third message. The (relative) freshness of the 758 key K_CN supplies freshness to the nonce N2 and the token T2. 760 In the second message, CN sends its address, the nonces N1 and N2 and 761 the tokens T1 and T2 to the home network, by way of the Home Address 762 HoA. 764 CN->HA: < CNA, HoA, N1, T1, N2, T2 > 766 6.2.1. Optional Processing by the Home Agent 768 A simple HA will simply forward the second message to the CN through 769 tunneling (ESP or non-ESP). 771 A more intelligent HA may want to authenticate the packet, and 772 perhaps also perform other functions. After the HA receives the 773 message its knowledge set is as follows: 775 HA: { CoA, HoA, K_(MN,HA), CNA, N1, T1, N2, T2 } 777 By receiving the message, the HA has already implicitly checked that 778 the HoA in the message matches a home address for a known mobile 779 node. It MAY now proceed to check validity of T1. 781 T1 =? HASH_T1( K_(MN,HA) ; N1 || CoA || CNA || HoA ) 783 This check allows the HA to verify that the token T1 was generated by 784 the MN, and that MN meant it to be used for a protocol run between 785 CoA, CNA and HoA. 787 The HA may also perform other activities, like logging some of the 788 information to an audit trail. Additionally, based on a mutual 789 agreement between the MN and HA, it may also change the contents of 790 N1 and T1 to something that allows MN to determine that the message 791 has been processed by the HA. For example, the HA might want to 792 replace N1 and T1 with NewN1 and NewT1, where 794 NewN1 := N1 + 1 795 NewT1 := HASH_T1( K_(MN,HA) ; NewN1 || CoA || CNA || HoA ) 797 However, such practices are beyond the scope of this protocol. 799 In any case, the HA forwards a message (through a tunnel) a message 800 that has the same format as the message it received. 802 HA->MN: TUNNEL < CNA, HoA, N1, T1, N2, T2 > 804 After processing the message, the home agent SHOULD reduce its 805 knowledge set by discarding information that it no longer needs. 807 HA: { CoA, HoA, K_(MN,HA) } 809 6.2.2. Processing by the Mobile Node 811 Before the mobile node receives the Binding Request, it has the 812 following knowledge set: 814 MN: { CoA, HoA, CNA, K_(MN,HA), N1 } 816 The mobile node must first check that the addresses match. The 817 CoA is implicitly checked by receiving the message. The MN 818 must explicitly check that the message was properly received 819 through a tunnel from the HA, and that the inner header in the 820 tunneled packet contains CNA as the source address and HoA as the 821 destination address. After that, it SHOULD check that the nonce N1' 822 received with the Binding Request equals the nonce N1 generated in 823 section 6.1. This protects the MN against replay attacks. Finally, 824 it SHOULD check that the received token T1' authenticates correctly. 826 T1' =? HASH_T1 ( K_(MN,HA) ; N1' || CoA || CNA || HoA ) ) 828 These checks allow the the MN to verify the following. 830 - The initial message was received by some party that is able to 831 receive messages sent by the MN to CNA. 833 - If the tunneling check was strong (the MN-HA tunnel is ESP) or 834 if the pair was modified according to a mutual agreement 835 between the MN and the HA, the party that received the initial 836 message sent a reply to the correct HA, who forwarded the message 837 back to the MN. 839 Any of the messages may have been intercepted and modified by an 840 active attacker. If the active attacker was able to intercept the 841 first message, the above statements still hold since it then acts as 842 "some party that is able to receive messages sent by the MN to CNA." 843 On the other hand, if the active attacker is only able to intercept 844 messages at the CN->HA or HA->MN link, it still cannot modify the 845 pair without knowing the key K_(MN,HA), and therefore T1 846 authenticates the address triple. Consequently, a securely tunneled 847 packet or a correctly transformed pair indicates that the 848 message was indeed processed by the HA, and therefore that the 849 message was received and forwarded by the HA. On the other hand, an 850 active attacker may have changed the nonce N2 and token T2. 852 Note that, within the design principles, no simple means that we are 853 aware of allows the MN or the CN to be protected against an active 854 attacker present in the same network with the MN. That is, an active 855 attacker can play the role of CN towards the MN, and therefore also 856 the role of MN towards the CN, and even send packets directly to 857 the HA using the CN address as the source address without having 858 the CN involved at all. On the other hand, having the HA involved 859 (either through secure tunneling or explicitly) does provide a level 860 of protection for the CN against passive attackers close to the MN. 861 [XXX: More work is needed to determine the real limitations of the 862 approach.] 864 After the checks, the MN proceeds to create the keying material 865 BK. To do that, it first creates a fresh random number R, and then 866 combines the nonce N2 with it, according to the algorithm HASH_BK: 868 BK := HASH_BK( R || N2 ) (see section 8.5) 870 Even though both N2 and R are not private information, since that 871 they have to be sent in clear over some unsecure link, they are 872 never sent together or over the same link. N2 is only sent through 873 CN->HA->MN, where even the HA->MN link may be encrypted, and R is 874 sent through MN->CN. As a result, the only viable points where 875 eavesdropping is easy are the local link where the CN is located 876 and (if the tunnel is unprotected) the local link where the MN is 877 located. 879 If the CN is a stationary server, getting access to its local link is 880 probably hard. On the other hand, if the CN is a mobile node itself, 881 the MN is most probably sending the first and third messages to the 882 CN through the CN's Home Agent, and therefore the first and third 883 messages may well be encrypted as they arrive at the CN. 885 Perhaps the weakest point lies near to the MN, since the local link 886 of the MN is likely to be wireless. If the HA uses the protected 887 tunnel between HA and MN, this link is effectively secured. [XXX: 888 but we need more security analysis on this point.] 890 6.3. Message 3: Binding Key Establishment (with Binding Update) 892 In the third message, the MN sends the pre-image of the token T1, the 893 authentication token T2 and the new random number R to the CN. 895 MN->CN: < CoA, CNA, HoA, T0, T2, R > 897 As the correspondent node receives the message, it first generates 898 T1 according to the algorithm in section 8.2. Then CN verifies the 899 message's authenticity and freshness by verifying the token T2, using 900 the algorithm in section 8.4. This verification allows the CN to 901 establish the following beliefs: 903 - Some party received the second message that it sent to HoA, and 904 is now replying to that message. That party also allegedly 905 received N2 and generated R, and therefore may be expected to 906 have calculated and stored the keying material BK. 908 - Second, that same party also knew T0, which the MN is not 909 supposed to reveal before it sends the third message. 911 Thus, to fool the check the attacker must have intercepted the BKE 912 option sent by the MN and replaced it with its own. Furthermore, 913 in order to possess the BK it must have been able to eavesdrop the 914 Binding Request in order to learn N2. 916 6.4. Discussion 918 Unless there are holes (but taking into account how new this protocol 919 is, we aren't so confident yet), the protocol seems fairly secure 920 from the CN's point of view. Basically, there are two ways an 921 attacker can break the protocol. 923 1. If the attacker, acting alone, is able to break the home agent 924 check in the sense that no packets flow through the home agent, 925 then the attacker is apparently able to create bindings for 926 whatever address. 928 2. If the attacker, attacking while there is an MN running the 929 protocol, is able either to learn the newly created keying 930 material (BK) or to replace the correct keying material with 931 something else, the the attacker will be able to later replace 932 the Binding for that particular MN with something else. 934 In order to break the home agent check, the attacker must be able to 935 eavesdrop packets flowing from the CN to the HA. If it can do that, 936 then it can play the part of the MN even when it does not receive 937 the packets forwarded by the HA. The only remedy against this would 938 be to enhance the protocol in such a way that the CN can actually 939 check that the real HA was involved. Unfortunately, this seems to 940 be impossible since there does not exist any security associations 941 between the MN and CN. 943 [XXX: It might be possible, though, to use the Home Address as a 944 pre-established security context, as indirectly suggested in [7]. 945 There are two problems with such practice. First, there may be IPR 946 problems. Second, the practice goes beyond the currently established 947 security mechanisms, and requires rigorous peer review before its 948 security can be considered known. However, maybe a mechanism based 949 on that idea should be an optional extension? Such an extension 950 would not do any harm (other than slightly add complexity), but it 951 might provide better protection for those hosts that do implement 952 it.] 954 To passively learn the BK, an attacker must be able to eavesdrop both 955 the second packet containing N2 and the third packet containing R. If 956 the attacker is able to do this, it could most probably play the part 957 of CN as well. 959 To replace the real BK with falsified one that it knows, an active 960 attacker must be able to eavesdrop the second packet containing N2, 961 and then produce a new third packet containing falsified R. However, 962 producing falsified third packet is hard unless the attacker is able 963 to intercept the real third packet. That is, in order to pass the 964 authentication check, the attacker would have to be able to reverse a 965 one-way function and produce T0 from T1. 967 6.5. Correspondent Node Initiated Operation 969 From the security analysis point of view, the CN initiated variant of 970 the protocol is a separate protocol from the MN initiated one. Thus, 971 it must be analyzed separately. Furthermore, since we are sharing 972 much of the implementation between these two protocols, it is also 973 necessary to analyze the protocols together in order to discover 974 potential pitfalls. In this section, we analyze the CN initiated 975 protocol variant in isolation. 977 In the CN initiated case, we have two possibilities. The first 978 possibility is that the MN already knows the CN, and therefore the 979 initial knowledge sets can be expressed as follows. 981 MN: { CoA, HoA, K_(MN,HA), CNA } 982 HA: { CoA, HoA, K_(MN,HA) } 983 CN: { CNA, HoA } 985 In this case the main threat seems to be replay attacks. That is, 986 resource exhausting DoS is fairly hard since both the MN and the CN 987 already have their peer's address, and no actual new state must be 988 preserved. On the other hand, unless proper freshness of the BKSA 989 keying material can be assured, various replay attacks seem to be 990 fairly easy. 992 The shortened protocol can be described as follows. (Zero elements 993 have been removed.) 995 CN->HA: < CNA, HoA, N2, T2 > 996 HA->MN: TUNNEL < CNA, HoA, N2, T2 > 997 MN->CN: < CoA, CNA, HoA, T2, R > 999 Here the token T2 assures freshness of the BKE message. On the other 1000 hand, the MN has no way of determining if the first BR is fresh or 1001 not. XXX: More analysis needed. 1003 The case when the MN does not know the CN is more difficult. The 1004 initial knowledge sets can be described as follows. 1006 MN: { CoA, HoA, K_(MN,HA) } 1007 HA: { CoA, HoA, K_(MN,HA) } 1008 CN: { CNA, HoA } 1010 Thus, the MN learns the CN address CNA only by receiving the 1011 Binding Request. If it were to simply accept it and proceed with 1012 establishing state, this would open up a trivial denial-of-service 1013 attack. Furthermore, as the MN may be a small device with limited 1014 storage capacity, such an attack would be even more serious. 1016 The first and safest option for the MN is simply ignore such a 1017 Binding Request. A second option is to proceed much in the same way 1018 as the CN works when it receives an unsolicited Binding Warning, 1019 i.e., in a way that does not necessitate creating state. The basic 1020 protocol can be expressed as follows. 1022 First Binding Update: 1023 CN->HA: < CNA, HoA, N2, T2 > 1024 HA->MN: TUNNEL < CNA, HoA, N2, T2 > 1025 Binding Warning: 1026 MN->CN: < CoA, CNA, HoA, N1, T1 > 1027 Binding Request: 1028 CN->HA: < CNA, HoA, N1, T1, N2', T2' > 1029 HA->MN: TUNNEL < CNA, HoA, N1, T1, N2', T2' > 1030 Binding Key Exchange: 1031 MN->CN: < CoA, CNA, HoA, T0, T2', R > 1033 As said, the crucial issue here is to ensure that the MN does not 1034 need to create state when it receives the first Binding Request. 1035 Following the principles that we used in the MN initiated variant of 1036 the protocol, it would be best to compute the the hash value T1 so 1037 that it covers N2 and/or T2 in addition to the addresses and N1 that 1038 it usually covers, to require that the CN uses the same N2 and T2 1039 when sending the second Binding Request, and let the MN to check this 1040 coverage upon receiving the second Binding Request. 1042 DISCUSSION. Including T2 to T1 and requiring that T2' == T2 1043 is not included in the spec below, but perhaps it should be. 1044 Further protocol analysis is required in any case. In order 1045 to ease initial implementations, we have simply specified 1046 that the protocol flows as usual. We need more experience 1047 about the actual implementation. 1049 [XXX: Add full protocol analysis here.] 1051 7. Protocol Processing 1053 In this section, processing details for protocol messages are 1054 specified. 1056 7.1. Initiation of the protocol 1058 A Mobile Node may initiate the protocol at any convenient moment. 1059 To do so, it includes a Binding Warning Destination Option into any 1060 packet containing the Home Address Destination Option. 1062 The Binding Warning contains two 128-bit pieces of data: a nonce 1063 N1, i.e., a newly generated random number, and a cryptographic token 1064 T1, calculated over the nonce and the addresses involved. The key 1065 K_(MN,HA), shared between the MN and the HA, is also used in the 1066 token generation, allowing the HA to check T1 if it wishes (see 1067 section 6.2.1). The token is generated in such a way that it also 1068 allows the Correspondent Node to check whether the Binding Warning 1069 and the Binding Key Establishment messages have been sent by the 1070 same party. This is done by sending a value (here called T0) in the 1071 latter message that is could only have been produced with knowledge 1072 possessed by the party that created T1. If the latter was MN, and 1073 if MN does not share this information, then the correspondent node 1074 can be assured that both the Binding Warning and the Binding Key 1075 Establishment messages were both sent by the same mobile node. 1077 Instead of being a random number, it is also possible to use 1078 a counter as the nonce N1. In that case, the Mobile Node MUST 1079 increment the counter every time it sends a Binding Warning to any 1080 node. Using a counter instead of a nonce allows the Home Agent to 1081 check T1 against replay attacks. By special agreement between the MN 1082 and the HA, more complex arrangements are possible; for instance, the 1083 uppermost 64 bits of N1 could be randomly generated and the lower 64 1084 bits a counter. 1086 [XXX: Should we be more specific about N1, and define that it 1087 consists of a 32-bit counter and 96-bit random number?] 1089 The mobile node computes T0, the pre-image of the token T1, using the 1090 algorithm specified in section 8.1. This pre-image will be sent to 1091 the Corresponding Node as a part of the Binding Key Establishment, 1092 and therefore the Mobile Node may want to save it. An alternative to 1093 saving is to recompute it when needed. After creating T0, the mobile 1094 node creates token T1 using the algorithm specified in section 8.2. 1096 Once the MN has generated N1 and computed T1, it is ready create the 1097 Binding Warning. Along with the Binding Warning option, the packet 1098 MUST also contain the Home Address option. Thus, the packet will 1099 have the following headers, in the following order. 1101 IP header 1102 destination address := Correspondent Node address (CNA) 1103 source address := Care-of-Address (CoA) 1104 Routing Header, if present 1105 Destination Options header, containing 1106 Home Address option 1107 Binding Warning option 1108 Fragmentation Header, if present 1109 IPSec headers, if present 1110 Upper layer data, if present 1112 As shown, the packet MAY also contain higher-level protocol payload. 1113 For example, the upper layer data could be a TCP SYN packet, 1114 Furthermore, the Mobile Node SHOULD save a pair so that 1115 it can more effectively match the Binding Request to be received. 1116 It MAY also want to save T0 and/or T1. In any case, it MUST store 1117 enough data so that T0 can be later retrieved, either by recomputing 1118 it or by remembering it. 1120 If, after transmitting the Binding Warning, the mobile node does not 1121 receive a Binding Request, it MAY retransmit the Binding Warning up 1122 to BW_RETRIES times. The first retransmission MUST be delayed for 1123 BW_REXMIT_DELAY seconds, and every subsequent retransmission must 1124 be delayed for twice the amount of additional time as the previous 1125 retransmission was delayed. 1127 7.2. Processing a received Binding Warning 1129 When a Correspondent Node receives a packet containing a Binding 1130 Warning, it SHOULD process the Binding Warning and send a Binding 1131 Request based on that. However, it SHOULD limit creation of state 1132 until it receives the Binding Key Establishment packet back from the 1133 Mobile Node. 1135 The reason for not creating a state is to protect the CN from 1136 memory exhausting Denial-of-Service attacks. Furthermore, the 1137 present protocol MAY be used to defer state creation for upper layer 1138 protocols as well. 1140 The incoming Binding Warning requires very little processing. 1141 The nonce N1 is basically just a random number, and since the 1142 correspondent node does not have the key K_(MN,HA), the token T1 1143 looks like a random number as well. However, the Correspondent Node 1144 MAY record the fact that is has recently received T1 so that it can 1145 later check that a Binding Key Establishment really matches with some 1146 recent Binding Warning. 1148 7.3. Generating data for the Binding Request 1150 To avoid creating state, the Correspondent Node encodes the relevant 1151 information into a cryptographic token T2. The same token will be 1152 included in the Binding Key Establishment, allowing the Correspondent 1153 Node to check that the Binding Key Establishment actually contains 1154 the same pieces of information that the Binding Warning did. 1156 In addition to creating the the token T2, the CN also creates a 1157 structured nonce N2. From the protocol point of view, the nonce N2 1158 is a random number, eventually used to create the keying material 1159 needed for the BKSA. However, due to the requirement of not creating 1160 state at this point, the CN cannot simply generate a new random 1161 number and use it, since that would require that the CN remembered 1162 the generated number. Thus, instead, the CN cryptographically 1163 combines its key K_CN and the received token T1 to create N2. This 1164 allows the CN to later reconstruct N2. N2 inherits randomness from 1165 both K_CN and T1. 1167 The CN first generates N2, using the received 128-bit token T1, 1168 according to the algorithm in section 8.3. Then T2 is generated 1169 using the nonce N2, according to the algorithm in section 8.4. 1171 The implementation MAY also use some other method for generating the 1172 token T2, or include more information in the generation (like TCP 1173 port numbers), depending on the state that it wants to protect and 1174 forget. 1176 7.3.1. Encoding TCP connection 1178 As an OPTIONAL implementation issue, we describe how the 1179 Corresponding Node MAY encode initial TCP state into the token T2, 1180 allowing it to forget TCP state after sending a TCP SYN-ACK along the 1181 Binding Request. 1183 Basically, the TCP protocol control block (PCB) created as a result 1184 of receiving a TCP SYN would contain the following information 1186 - 16-bit local port number 1188 - 16-bit remote port number 1190 - 32-bit local sequence number 1191 - 32-bit remote sequence number 1193 Since these will be received in a reconstructible way in the 1194 forthcoming first ACK packet, the implementation MAY opt to encode 1195 this information into the token T2, and cease creating an explicit 1196 protocol control block. The eventual ACK packet will allow this 1197 information to be reconstructed, and reception of T2 allows the host 1198 to check that the reconstructed state matches with what is expected. 1200 To encode the state into T2, [XXX: the details need to be written.] 1202 7.4. Sending the Binding Request 1204 Once the CN has the nonces N1 and N2 and the tokens T1 and T2 1205 available, N1 and T1 from the received Binding Warning and N2 and 1206 T2 as generated above, it is ready send the Binding Request. The 1207 Binding Request MUST be sent to the Home Address of the Mobile 1208 Node, i.e., the address indicated in the Home Address destination 1209 option of the received packet. The transmission MUST bypass any 1210 possibly existing Binding Cache entry for that specific Home Address, 1211 and there MUST NOT be any mobility related routing headers in the 1212 resulting packet. 1214 Allowing non-mobility related routing headers, such as ones 1215 configured through manual means, should be considered very 1216 carefully. There might be legitimate reasons for doing so. 1217 Likewise, explicit tunneling requires careful study, and 1218 there are a number of good reasons to permit it. 1220 That packet has the following headers, in the following order, and 1221 NOT including any routing header entry formulated from any binding 1222 cache entry for the mobile node: 1224 IP header 1225 destination address := mobile node's Home Address (HoA) 1226 source address := Correspondent Node address (CNA) 1227 Routing Header, if present 1228 Destination Options header, containing 1229 Home Address option 1230 Binding Request option 1231 Fragmentation Header, if present 1232 IPSec headers, if present 1233 Upper layer data, if present 1235 As an example, the upper layer data could be a TCP SYN-ACK packet, 1236 i.e. the second packet in TCP three-way handshake. 1238 7.5. Forgetting State 1240 Once the CN has sent the Binding Request to the Home Address, it 1241 SHOULD forget all state created. It can simply discard all Binding 1242 related data since T0 and T2 are given as part of the Binding Key 1243 Establishment option; together with the key K_CN, this will allow it 1244 to reconstruct all necessary state variables. Furthermore, if the CN 1245 has coded the upper layer state in the T2, it MAY also opt to discard 1246 upper layer state such as a TCP protocol control block. 1248 7.6. Processing Binding Request at the Home Agent 1250 As a minimal requirement, Home Agent MUST forward the Binding Request 1251 to the Mobile Node through the established tunnel, unless it follows 1252 any of the more specific strategies outlined below. 1254 The construction of the token T1 makes it possible to the Home 1255 Agent to verify that the Mobile Node has once generated T1 for the 1256 very purpose of communicating from the named CoA with the named 1257 Corresponding Node. Furthermore, if there is a counter component in 1258 N1, the Home Agent may also check against replay attacks. The exact 1259 details of such a verification are beyond the scope of this document. 1261 [XXX: Should we give some outline? I think we should if we decide 1262 to give a recommendation for the N1 structure. If we don't, then I 1263 think that there is no reason to specify the checking here either.] 1265 In addition to OPTIONALLY checking T1, the Home Agent MAY also modify 1266 N1, and correspondingly T1, as per mutual agreement between the Home 1267 Agent and the Mobile Node. However, such practices go beyond the 1268 current scope of this specification. 1270 7.7. Processing Binding Request by the Mobile Node 1272 The Mobile Node will receive the Binding Request as tunneled by the 1273 Home Agent. Whenever the Mobile Node is away from home, it MUST 1274 NOT accept Binding Requests that are sent directly to it instead of 1275 being tunneled by the Home Agent. Additionally, if the MN has an 1276 ESP protected tunnel with the HA, it MUST silently discard Binding 1277 Requests unless they have been protected with _that_particular ESP 1278 security association. 1280 As a part of accepting the Binding Request, the Mobile Node MUST 1281 check that the outer header has the CoA as the destination address 1282 and the Home Address as the source address. If ESP is used, this 1283 check is typically performed as a part of the ESP policy processing. 1284 Additionally, it MUST check that the inner header has the Home 1285 Address as the destination address and the Correspondent Node address 1286 as the source address. The check over the inner header destination 1287 address MAY also be performed as a part of the ESP policy processing. 1288 However, checking of the source address of the inner header typically 1289 has to be performed separately. The Mobile Node MUST silently drop 1290 the packet if it fails the tunneling checks. 1292 Once the Binding Request has passed the tunneling checks, additional 1293 checks are made. First, if the MN saved an when making 1294 calculations for sending the Binding Warning (see section 7.1), it 1295 SHOULD check that the received nonce N1' matches the saved nonce N1, 1296 taking into account the OPTIONAL modification(s) by the HA, if used. 1297 Next, the Mobile Node SHOULD check that the received token T1 matches 1298 with the saved token T1. In the basic case (no special arrangements 1299 between the MN and the HA), to perform the check the MN simply either 1300 uses its saved T1 value or recomputes it, and compares that "right" 1301 T1 value with the received T1'. If the MN knows that the HA may have 1302 changed the T1, the method for verifying T1 depends on the mutual 1303 agreement between the MN and the HA, and goes beyond the scope of 1304 this document. 1306 Once the MN has accepted the Binding Request, it proceeds to 1307 establish the MN's end of a security association and prepare data for 1308 the Binding Key Establishment 1310 7.8. Establishing the BKSA 1312 To establish the Mobile Node's end of the BKSA that is used to 1313 authenticate the future Binding Updates, the MN generates a new 1314 random number R. Then it proceeds to create BK from this new 1315 random number and the nonce N2 received in the Binding Request (see 1316 section 8.5). 1318 BK := HASH_BK( R || N2 ) 1320 The MN sets up an outgoing BKSA using the BK as the keying material. 1321 The policy of the AH security association MUST be set as follows. 1323 1. The BKSA MUST be only applied if the outgoing packet contains a 1324 Binding Update. It MUST NOT be applied if there are no BUs. 1326 2. The destination address of the packet MUST be the address of the 1327 Correspondent Node. 1329 Correspondingly, the MN sets up an incoming BKSA using the BK as the 1330 keying material. The policy of this security association MUST be set 1331 as follows. 1333 1. The BKSA only protects Binding Acknowledgements. Unless there 1334 are additional IPSec protection, the packet is NOT considered 1335 integrity protected for any other purpose but informing the MN 1336 that the CN has received and processed the BU. The BKSA MUST NOT 1337 be used for authenticating other packet data, or any fields in 1338 packets not containing a Binding Acknowledgement. 1340 DISCUSSION: Should we require that the IPv6 header has some 1341 particular source or destination IP addresses? The BKSA 1342 should already be considered to identify the sender of the 1343 Binding Update. 1345 7.9. Sending Binding Key Establishment (and Binding Update) 1347 In addition to R, the Binding Key Establishment option also needs 1348 T0, the pre-image of the token T1. Thus, the MN must provide this, 1349 either by recomputing it from N1 and the addresses, or by saving 1350 it after making the calculation during processing of the Binding 1351 Warning, as described in section 6.1. 1353 To finish its part of the protocol run, the MN sends a packet that 1354 MUST contain at least the Binding Key Establishment (BKE) option and 1355 the Home Address option, located in the Destination Options header. 1356 The BKE option MUST immediately follow the Home Address option. 1358 Typically the same packet would contain also the Binding Update that 1359 the MN initially wanted to send. If so, that Binding Update MUST 1360 be protected with the newly protected BKSA. The packet would also 1361 typically contain upper layer data such as a the first real data 1362 packet within a TCP connection. 1364 Thus, the packet containing the BKE would appear as follows: 1366 IP header 1367 source address := mobile node's care-of Address (CoA) 1368 destination address := Correspondent Node address (CNA) 1369 Routing Header, if present 1370 Destination Options header, containing 1371 Home Address option 1372 Binding Key Establishment option 1373 Fragmentation Header, if present 1374 IPSec headers, if present 1375 Destination Options Header, containing 1376 Binding Update 1377 Upper layer data, if present 1379 This packet structure leads to natural processing of the packet 1380 at the receiver end, allowing it to first verify the Binding 1381 Key Establishment and create the BKSA before processing the 1382 Authentication Header. 1384 7.10. Receiving Binding Key Establishment 1386 The CN may, effectively, receive a Binding Key Establishment (BKE) 1387 option at any time, since it forget about previous Binding Warning 1388 messages. 1390 When the CN starts to process the BKE option, it MUST check that 1391 there has been a Home Address Destination Option earlier in the 1392 packet. 1394 To authenticate the BKE option, the CN collects the MN's current 1395 Care-of-Address from the IP header, the MN's home address from the 1396 Home Address destination option, and its own IP address from the 1397 IP header. It first calculates the token T1, according to the 1398 algorithm in section 8.2, using the received token T0 from the BKE 1399 option. It then recomputes the token T2 according to the algorithm 1400 in section 8.4, and compares the recomputed T2 with the received T2', 1401 as found in the received BKE option. If they are equal, the check 1402 succeeds. 1404 Otherwise, if the comparison fails, take the previous K_CN value, 1405 and recompute the token T2. The exact number of previous saved 1406 previous keys and repeated checking attempts is a local policy 1407 issue. However, it is RECOMMENDED that at most two previous K_CN 1408 values are tried. This limits the amount of resources that a 1409 resource-exhausting denial-of-service attack may consume. 1411 As an additional measure against resource-exhausting 1412 denial-of-service attacks, the host MAY limit the rate in 1413 which it checks Binding Key Establishment messages. It MAY also 1414 dynamically modify the number of additional checking steps that it is 1415 ready to perform in the case the the first check fails. 1417 [XXX: Should we just include a random nonce, N3, in the Binding 1418 Request and BKE? The CN could generate them on short intervals 1419 similar to the key K_CN. It would be simply sent in clear, and when 1420 the CN receives it, it would just check that it is recent. That 1421 would limit the resource-exhausting DoS attacks.] 1423 7.11. Establishing the CN Security Associations 1425 Once the Binding Key Exchange has been verified, the CN proceeds to 1426 establish its BKSA. To do so, it first recomputes the nonce N2, using 1427 the algorithm in section 8.3, and then combines the nonce N2 with 1428 the random number R received in the BKE option to generate the same 1429 keying material (BK) that the MN generated. 1431 The CN sets up an incoming BKSA using BK as the keying material. The 1432 policy of this security association MUST be set as follows. 1434 1. The BKSA only protects the Binding Update. Unless there is 1435 additional IPSec protection, the data within the packet is NOT 1436 integrity protected for any other purpose except entering a new 1437 care-of address into the CN's binding cache. 1439 2. The destination address of the packet SHOULD be the CN's address. 1441 The CN sets up an outgoing BKSA using the BK as the keying material. 1442 The policy of the security association MUST be set as follows. 1444 1. The BKSA MUST be only applied if the outgoing packet contains a 1445 Binding Acknowledgement. It MUST NOT be applied otherwise. 1447 2. The destination address of the packet MUST be a home address of 1448 the Mobile Node. 1450 7.12. Processing the rest of the packet 1452 The rest of the packet MAY contain an AH header to protect the other 1453 headers and the payload. Thus, the rest of the packet is processed 1454 normally according to the rules in RFC 2406 [3]. The Binding 1455 Update, including the authentication data, MUST be included in the AH 1456 computation if the AH is present. 1458 7.13. Reduced operations when the Mobile Node is at home 1460 If the Mobile Node wants to run the described protocol while it is 1461 still at home, it MAY do so. In that case, the Care-of-Address and 1462 the Home Address will be the same. However, the packets containing 1463 the Binding Warning and Binding Key Establishment MUST still contain 1464 the Home Address destination option. Thus, the CN implementation 1465 does not need to care about whether the MN is at home or away from 1466 home while running the protocol -- from its point of view, the 1467 protocol will still run the same. 1469 [XXX: Check SHA-1 and HMAC-SHA-1 input and output sizes.] [XXX: 1470 Check source and dest address order in IPv6 header, and update their 1471 inclusion order in hashes so that you can copy both with a single 1472 copy instead of requiring two.] 1474 [XXX: Decide whether to use an additional nonce N3 or not; see the 1475 discussion in Section 7.10] 1477 7.14. Processing For Correspondent Node Initiation 1479 In addition to the Mobile Node, the Correspondent Node MAY also want 1480 to initiate the protocol. However, in that case some of the threats 1481 are different. Especially, since the CN is the initiator and the MN 1482 is the responder, it is important to protect the MN from resource 1483 exhausting denial-of-service attacks. Thus, from the security point 1484 of view, the MN initiated and the CN initiated versions of the 1485 protocol are different cryptographic protocols. However, the CN 1486 initiated version has been designed in such a way that almost all of 1487 the implementation is shared between these two protocol variants. 1489 7.14.1. Initiating the protocol by sending a Binding Request 1491 When the CN wants to initiate the protocol, it assigns zero for the 1492 Nonce N1, assigns zero for the Token T1, and generates the Nonce N2 1493 and Token T2 as defined in Section 7.3. The values for Nonce N1 1494 and Token T1 MUST be zero as they signal the MN that this is a CN 1495 initiated version of the protocol. 1497 Note that since the key K_CN and the Home Address are used in the 1498 computation, the generated N2 is hard to predict even when T1 is 1499 fixed to zero. On the other hand, since the CN will be creating 1500 state and therefore will remember N2, it MAY just simply use a random 1501 number generator to create N2. The same applies for T2. 1503 Once the CN has prepared values for nonces N1 and N2 and tokens T1 1504 and T2, it proceeds to send a Binding Request as usual. The Binding 1505 Request MUST be sent to the Home Address of the Mobile Node. 1507 Since the CN is initiating the protocol, it MUST NOT clear its 1508 internal state. Instead it MUST remember that it has initiated the 1509 protocol with the MN. 1511 7.14.2. Handling a CN initiated Binding Request by a HA 1513 A Home Agent cannot do much for a CN initiated Binding Request. The 1514 optional check of token T1 would fail, but the fact that N1 and T1 1515 are zero indicate that the protocol was initiated by the CN. In 1516 particular, the Home Agent SHOULD NOT replace the value T1 with 1517 another value that would pass the integrity test at the MN. 1519 [XXX: There may be problems with this approach and the various ways 1520 we have thought the Home Agent could possibly participate to the 1521 protocol. More work is needed here.] 1523 7.14.3. Handling a CN initiated Binding Request by a MN 1525 When a MN receives a CN initiated Binding Request, zero N1 indicates 1526 it that it has not itself initiated the protocol this time. 1528 Now, the MN has basically two different paths to follow. If it 1529 determines that it already has traffic going on with the CN, it MAY 1530 proceed the fast way and send a Binding Key Establishment packet 1531 immediately (see below). For example, the implementation MAY scan 1532 the active protocol control blocks, and finding a PCB with the CN 1533 as the remote address can be considered as positive indication that 1534 there is already traffic going on with the CN. 1536 On the other hand, if the MN determines that it does not recognize 1537 the CN, it SHOULD defer creating state and continue in a stateless 1538 fashion. Again, there are two options here. First, the Mobile Node 1539 MAY decide to ignore the Binding Request completely. Second, it MAY 1540 send a Binding Warning in a stateless fashion. 1542 If the MN decides to create state and send a Binding Key 1543 Establishment message, it cannot compute T0. On the other hand, it 1544 knows that the CN has state. Thus, to allow the CN to recognize the 1545 case, it simply sets T0 to zero. T2 is copied over from the Binding 1546 Request as usual, and R is a random number as usual. 1548 If the MN decides to send a Binding Warning in a stateless fashion, 1549 it proceeds as defined in Section 7.1. However, in this case the 1550 Mobile Node SHOULD NOT save the N1 or any other information about 1551 the fact that it has sent the Binding Warning. That is, when the MN 1552 receives a Binding Request from the MN the second time, it notices 1553 that the Token T1 is a valid one but that there does not exist any 1554 state, and continues to establish the state (i.e. BKSA) and send the 1555 BKE. 1557 In either case, the resulting BKSA should have fairly short 1558 timeout. The timeout can be extended once the MN receives a properly 1559 authenticated Binding Acknowledgement from the CN. 1561 7.14.4. Further operations at the CN end 1563 As the CN has state, it will be expecting a Binding Warning or 1564 Binding Key Establishment. It will recognize the received Binding 1565 Warning simply by the addresses. In that case proceeds normally 1566 other than that it SHOULD NOT forget its state after sending the 1567 (second) Binding Request, simplifying checks later on when the BKE is 1568 received. 1570 On the other hand, if the CN receives a Binding Key Establishment, 1571 it will recognize the BKE as a reply to its Binding Request since T0 1572 is zero, and again use the addresses to find its saved state. After 1573 that, it simply checks the received T2' against the remembered T2, 1574 and proceeds normally. 1576 7.15. Simultanous operation by two Mobile Nodes 1578 In this section, we present a nonexistent discussion about various 1579 issues when two Mobile Nodes, both acting as a Correspondent Node to 1580 each other, want to run this protocol at the same time. 1582 8. Cryptographic Algorithms 1584 The various algorithms for creating tokens and keys are collected in 1585 this section. This is done for three reasons: 1587 - To make sure the same algorithm is used even when specified at 1588 different places in the document 1590 - To allow for easy modifications if consensus develops within the 1591 working group 1593 - For easy cross-reference throughout the document 1595 8.1. Algorithm for Computing Token T0 1597 The input for the algorithm HASH_T0 is created by concatenating the 1598 following data: 1600 1. N1, the nonce generated by the mobile node for this purpose. 1602 2. CoA, the mobile node's 128-bit care-of-address 1604 3. CNA, the 128-bit Correspondent Node address 1606 4. HoA, the mobile node's 128-bit home-address 1608 This concatenation (N1 || CNA || CoA || HoA) results in a 512-bit 1609 bitstring. 1611 Calculate a hashed MAC, as defined in [4], over the 512-bit 1612 bitstring, using the key K_(MN,HA). The RECOMMENDED algorithm is 1613 HMAC-SHA-1 [5], but since the exact algorithm is an issue private 1614 to the MN and HA, other algorithms can be used according to mutual 1615 agreement. 1617 Obtain the result by taking the rightmost 128 bits of the resulting 1618 HMAC code. This is called the pre-image of the token T1, called T0. 1619 This pre-image will be sent to the Corresponding Node as a part of 1620 the Binding Key Establishment, and therefore the Mobile Node may want 1621 to save it. An alternative to saving is to recompute it when needed. 1623 8.2. Algorithm for computing token T1 1625 The input for the algorithm HASH_T1 is created by padding the 128-bit 1626 T0 to the left with 32 zero bits to form a bitstring with 160 bits. 1628 Apply basic SHA-1 [5] over the bitstring. 1630 Obtain T1 (the result) by taking the rightmost 128 bits of the the 1631 SHA-1 result. 1633 8.3. Algorithm for computing nonce N2 1635 The data for algorithm HASH_N2 is obtained by concatenating a 128-bit 1636 (16 byte) zero value and the received 128-bit token T1, resulting in 1637 a bitstring with 256 bits. 1639 Calculate a hashed MAC, as defined in [4], over the bitstring, using 1640 tke key K_CN. The RECOMMENDED algorithm is HMAC-SHA-1 [5], but since 1641 the exact algorithm is an issue private to the correspondent node, 1642 the implementation MAY elect to use some other algorithm. 1644 Obtain the result by taking the rightmost 128 bits of the resulting 1645 HMAC code. This is the nonce N2. 1647 8.4. Algorithm for computing token T2 1649 The input data for algorithm HASH_T2 is obtained by concatenation of 1650 the following values: 1652 1. T1, the received 128-bit token generated by the mobile node in 1653 the Binding Warning destination option 1655 2. CoA, the mobile node's 128-bit care-of-address, and 1657 3. CNA, the 128-bit Correspondent Node address from the IP header 1658 destination address field 1660 4. HoA, the 128-bit home-address from the Home Address destination 1661 option 1663 This concatenation (T1 || CoA || CNA || HoA) results in a 512-bit 1664 bitstring. 1666 Calculate a hashed MAC, as defined in [4], over the 512-bit 1667 bitstring, using the key K_CN. The RECOMMENDED algorithm is 1668 HMAC-SHA-1 [5], but since the exact algorithm is an issue private to 1669 the CN, the implementation MAY select to use some other algorithm. 1671 Obtain the result by taking the rightmost 128 bits of the resulting 1672 HMAC code. This is the token T2. 1674 8.5. Algorithm for computing key material BK 1676 The data for algorithm HASH_T2 is obtained by concatenation of the 1677 following values: 1679 1. R, the random number generated for this purpose by the mobile 1680 node and included in the Binding Key Establishment message 1682 2. N2, the 128-bit nonce calculated by the correspondent node and 1683 delivered to the mobile node in the Binding Request message. 1685 This concatenation (R || N2) results in a 256-bit input bitstring. 1687 KeyMat := MD5( R || N2 ) 1689 Obtain the result by hashing (using MD5 [8]) the 256-bit input. This 1690 is the desired key material BK. 1692 9. Protocol Data Unit Formats 1694 9.1. Binding Warning Message 1696 A mobile node may use the Binding Warning destination option to 1697 enable a correspondent node to initiate the process of establishing a 1698 Binding Key for use when authenticating its Binding Update messages. 1700 0 1 2 3 1701 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 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 | Option Type | Option Length | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | Nonce N1 (128 bits) | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | Cryptographic Token T1 (128 bits) | 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 Figure 1: The Binding Warning Destination Option format 1712 Nonce N1 A 128-bit opaque value. 1714 Token T1 A 128-bit hashed value, computed over the addresses 1715 involved. 1717 See section 7.1 for processing details on the selection of the Nonce 1718 N1, and the calculation of the Cryptographic Token T1. 1720 9.2. Binding Request Message 1722 A correspondent node may use the Binding Request destination option 1723 to transmit key material to a mobile node. 1725 0 1 2 3 1726 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 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Option Type | Option Length | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | Nonce N1 (128 bits) | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | Cryptographic Token T1 (128 bits) | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | Structured Nonce N2 (128 bits) | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Cryptographic Token T2 (128 bits) | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 Figure 2: The Binding Request Destination Option format 1741 Nonce N1 A 128-bit opaque value, copied over from corresponding 1742 value in the Binding Warning sent from the mobile node. 1744 Token T1 A 128-bit hashed value, copied over from corresponding 1745 value in the Binding Warning sent from the mobile node. 1747 Nonce T2 A 128-bit hashed value created using a new nonce and 1748 the information from the mobile node. 1750 Token T2 A 128-bit authentication token which includes all 1751 information whose integrity must be protected, as well 1752 as T1 1754 See sections 7.3 and 6.2 for details on the the calculation of the 1755 Structured Nonce N2, and the Cryptographic Token T2. Including T1 1756 into the authentication token T2 helps to block active attacks later 1757 in the protocol. 1759 9.3. Binding Key Establishment Destination Option 1761 A mobile node may use the Binding Key Establishment destination 1762 option to transmit key material to a correspondent node. 1764 Lifetime A 32-bit value specifying the lifetime of the BKSA in 1765 seconds. 1767 Nonce N1 A 128-bit opaque value, copied over over from the 1768 information in the Binding Request. 1770 Token T0 A 128-bit hashed value, previously computed and 1771 possibly saved when sending the Binding Warning. 1773 Token T2 A 128-bit authentication token which is copied over 1774 from the information in the Binding Request. 1776 Random R A 128-bit random number, used as the second half of the 1777 keying material to be created. 1779 See sections 6.2 and 8 for details on the the calculation of the 1780 Cryptographic Tokens T0 and T2. The mobile node SHOULD check that 1781 the nonce N1 corresponds to the nonce which it sent in the Binding 1782 Warning message to the correspondent node. 1784 0 1 2 3 1785 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 1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1787 | Option Type | Option Length | 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 | Lifetime (32 bits) | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Nonce N1 (128 bits) | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Cryptographic Token T0 (128 bits) | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | Cryptographic Token T2 (128 bits) | 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 | Random Number (128 bits) | 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 Figure 3: The Binding Key Establishment 1801 Destination Option format 1803 Acknowledgements 1805 We would like to thank the members of the Mobile IP and IPng Working 1806 Groups for their comments and suggestions on this work. We would 1807 particularly like to thank (in alphabetical order) Francis Dupont 1808 (ENST Bretagne) 1810 References 1812 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 1813 Levels. Request for Comments (Best Current Practice) 2119, 1814 Internet Engineering Task Force, March 1997. 1816 [2] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in 1817 progress). 1818 draft-ietf-mobileip-ipv6-13.txt, October 2000. 1820 [3] S. Kent and R. Atkinson. IP Encapsulating Security Payload 1821 (ESP). Request for Comments (Proposed Standard) 2406, Internet 1822 Engineering Task Force, November 1998. 1824 [4] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for 1825 Message Authentication. Request for Comments (Informational) 1826 2104, Internet Engineering Task Force, February 1997. 1828 [5] C. Madson and R. Glenn. The Use of HMAC-SHA-1-96 within ESP and 1829 AH. Request for Comments (Proposed Standard) 2404, Internet 1830 Engineering Task Force, November 1998. 1832 [6] T. Narten and C. E. Perkins. Privacy Extensions for Stateless 1833 Address Autoconfiguration in IPv6, January 2001. 1835 [7] P. Nikander. An Address Ownership Problem in IPv6 (work in 1836 progress). draft-nikander-ipng-address-ownership-00.txt, 1837 February 2001. 1839 [8] R. Rivest. The MD5 Message-Digest Algorithm. Request for 1840 Comments (Informational) 1321, Internet Engineering Task Force, 1841 April 1992. 1843 Chair's Address 1845 The Working Group can be contacted via its current chairs: 1847 Phil Roberts 1848 Motorola 1849 1501 West Shure Drive 1850 Arlington Heights, IL 60004 1852 Phone: +1 847 632-3148 1853 E-mail: qa3445@email.mot.com 1855 Basavaraj Patil 1856 Nokia 1857 6000 Connection Drive 1858 M/S M8-540 1859 Irving, TX 75039 1860 USA 1862 Phone: +1 972 894-6709 1863 Fax: +1 972 894-5349 1864 E-mail: raj.patil@nokia.com 1866 Authors' Addresses 1868 Questions about this document can also be directed to the authors: 1870 Pekka Nikander 1871 Ericsson Research NomadicLab 1872 Espoo, Finland 1873 phone: +358-40-721 4424 1874 email: Pekka.Nikander@nomadiclab.com 1876 Charles Perkins 1877 Nokia 1878 313 Fairchild Drive 1879 Mountain View, CA 94043 1880 USA 1882 Phone: +1 650 625-2986 1883 Fax: +1 650 625-2502 1884 E-mail: charliep@iprg.nokia.com