idnits 2.17.1 draft-roe-mobileip-updateauth-02.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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 are 541 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 722 instances of too long lines in the document, the longest one being 1 character 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 815: '...etected the host MAY attempt duplicate...' RFC 2119 keyword, line 818: '...qual to 3. Nodes MUST NOT use values o...' RFC 2119 keyword, line 1054: '...nded that nodes on the Internet SHOULD...' RFC 2119 keyword, line 1056: '...ns to exclude potential attackers MAY...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 22 has weird spacing: '...), its areas...' == Line 26 has weird spacing: '... and may b...' == Line 30 has weird spacing: '... The list ...' == Line 33 has weird spacing: '... The list ...' == Line 38 has weird spacing: '... This memo...' == (536 more instances...) -- 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 2002) is 8104 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) -- Missing reference section? 'CN' on line 406 looks like a reference -- Missing reference section? '0' on line 585 looks like a reference -- Missing reference section? 'BU' on line 623 looks like a reference -- Missing reference section? '1' on line 745 looks like a reference -- Missing reference section? '5' on line 1030 looks like a reference -- Missing reference section? '3' on line 830 looks like a reference -- Missing reference section? '4' on line 1030 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Mobile IP Working Group 2 INTERNET DRAFT 4 M. Roe 5 T. Aura 6 G. O'Shea 7 Microsoft 8 J. Arkko 9 Ericsson 10 February 2002 11 Expires: 1 August 2002 13 Authentication of Mobile IPv6 Binding Updates and Acknowledgments 14 16 Status of this Memo 18 This document is an Internet-Draft and is subject to all provisions of 19 Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 [1]http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 [2]http://www.ietf.org/shadow.html 36 Abstract 38 This memo describes three protocols that may be used for 39 authenticating binding updates in mobile IPv6. These protocols have 40 the following goals: 42 * To prevent malicious nodes from forging binding updates for other 43 nodes; 44 * To protect other nodes on the Internet from denial of service 45 attacks in which a correspondent is tricked into sending them a 46 large amount of data that they do not want; 47 * To make it difficult for an attacker to exhaust a node's resource 48 by causing it to process large numbers of binding updates; 49 * To prevent binding updates being replayed for any of the above 50 purposes. 52 The three protocols differ in the amount of computation that they 53 require and the assumptions made about the environment in which they 54 are used. The symmetric key method is efficient, but can only be used 55 if the mobile and the correspondent have previously agreed a long-term 57 Roe [Page 1] 58 secret. The BAKE/2 method is also efficient, but only works if some of 59 the messages in the protocol take a route which is protected from 60 attack by means outside the protocol. The CAM-DH protocol needs more 61 processing power, because it involves asymmetric cryptography, but it 62 can be used in situations where the other two protocols cannot. 64 1. Threats addressed by the protocols in this memo 66 We have identified the following threats to the mobile IPv6 protocol: 68 1. A malicious mobile node might lie about its home address. 69 A malicious mobile node might send a correspondent node binding 70 updates in which the home address is set to the address of another 71 node ("the victim"). If the correspondent node accepted this 72 forged binding update, then communications between the 73 correspondent node and the victim would be disrupted, because 74 packets that the correspondent node intended to send to the victim 75 would be sent to the wrong care-of address. 76 This is a threat to confidentiality as well as availability, 77 because an attacker might redirect packets meant for another node 78 to itself in order to learn the content of those packets. 79 2. A malicious mobile node might lie about its care-of address. 80 A malicious mobile node might send a correspondent node binding 81 updates in which the care-of address is set to the address of 82 another node ("the victim node") or an address within another 83 network ("the victim network"). If the correspondent node accepted 84 this forged binding update, then the malicious mobile could trick 85 the correspondent into sending data to the victim node or the 86 victim network; the correspondent's replies to messages sent by 87 the malicious mobile will be sent to the victim host or network. 88 This could be used to cause a distributed denial of service 89 attack; the malicious mobile could trick a large number of servers 90 so that they all send a large amount of data to the same victim 91 node or network. 92 There are several variations of this threat: 93 + A malicious mobile might start off by sending the 94 correspondent node binding updates containing its true care 95 of address, and then later (once its initial home and care of 96 addresses had been authenticated) send binding updates 97 containing the victim's care of address. 98 + A malicious mobile might start of by sending the 99 correspondent node binding updates contains its true care of 100 address, and then continue to send binding updates containing 101 that care-of address even after that care of address had been 102 reallocated to a different node (the victim). This variation 103 of the threat might be regarded as less serious than the 104 previous two, because the attacker's choice of victim is 105 restricted to nodes that are currently using a care of 106 address that the attacker has used in the past. 107 3. A malicious node might send a large number of invalid binding 108 updates to a victim correspondent node. 109 If each invalid binding update took a significant amount of 110 resources (such as CPU) to process before it could be recognized 111 as invalid, then it might be possible to cause a denial of service 113 Roe [Page 2] 114 attack by sending the correspondent so may invalid binding updates 115 that it has no resources left for other tasks. 116 4. An attacker might reply an old binding update. 117 An attacker might attempt to disrupt a mobile node's 118 communications by replaying a binding update that the node had 119 sent earlier. If the old binding update was accepted, packets 120 destined for the mobile node would be sent to its old location and 121 not its current location. 123 All of the above threats are concerned with denial of service. The 124 first threat is the denial of service caused when the correspondent's 125 state (its binding cache) contains incorrect information derived from 126 forged messages. The second threat is the denial of service caused to 127 a third party when the correspondent is tricked into consuming network 128 resources. The third threat is the denial of service caused when the 129 correspondent must consume a significant amount of resource such as 130 CPU and memory to distinguish genuine updates from forged ones. 132 2. Abstract Protocols 134 2.1 Notation 136 This memo uses the following notation: 138 MN A mobile node 139 CN A correspondent node 140 A -> B Node A sends a message to B 141 A -> B(HoA) Node A sends a message to B at its home address 142 A -> B(CoA) Node A sends a message to B at its care-of address 143 HoA Mobile node's home address 144 CoA Mobile node's care-of address 145 MAC[K](m) A message authentication code computed on message m with key 146 K 147 H(m) A hash of message m 149 2.2 The Shared Key Protocol 151 Properties of the Protocol 153 The shared key protocol is used to authenticate binding updates 154 between a mobile node and a correspondent node that share a symmetric 155 key (K[h]). There are several different ways in which a correspondent 156 and a mobile can agree on a shared key for use with this protocol; 157 these will be described later. 159 The protocol has the following properties: 161 * A node needs to know the shared secret (K[h]) in order to create a 162 binding update that will be accepted by the correspondent. This 163 prevents a malicious mobile from forging binding updates 164 containing another node's home address; the malicious mobile will 165 not know the correct key. 166 * To create a binding update for a care-of address that is not equal 167 to its home address, a mobile node needs to be able to receive 169 Roe [Page 3] 170 messages sent to that care-of address. 171 * To create a binding update that deletes a binding cache entry, a 172 mobile node needs to know the secret K[h] but does not need to be 173 able to receive messages sent to a particular address. 175 Walkthrough 177 Each correspondent node has a secret key, K[CN]. This key does not 178 need to be shared with any other entity, so no key distribution 179 mechanism is needed for it. Each correspondent node also generates a 180 nonce, N[j], at regular intervals, for example every few minutes. A 181 correspondent node uses the same K[CN] and N[j] with all the mobiles 182 it is in communication with, so that it does not need to generate and 183 store a new N[j] when a new mobile contacts it. Each value of N[j] is 184 identified by the subscript j. j is communicated in the protocol, so 185 that if N[j] is replaced by N[j+1] part way through a run of a 186 protocol, the correspondent can distinguish messages that should be 187 checked against the old nonce from messages that should be checked 188 against the new nonce. Correspondent nodes keep both the current value 189 of N[j] and the previous value N[j-1]. Older values can be discarded, 190 as messages using them will in any case be rejected as replays. K[CN] 191 can be either a fixed value or regularly updated. An update of K[CN] 192 can be done at the same time as an update of N[j], so that j 193 identifies both the nonce and the key. A correspondent node can 194 generate a fresh K[CN] each time that it boots to avoid the need for 195 secure persistent storage for K[CN]. 197 1. MN -> CN : HoA, CoA 198 In step 1, the mobile node informs the correspondent node that it 199 is mobile, and gives both the mobile's home address and its 200 care-of address. 201 2. CN -> MN(CoA) : r[c], j 202 r[c] = MAC[K[CN]](CoA | N[j] | 1) 203 In step 2, the correspondent node sends a binding request to the 204 mobile node. The binding request contains a challenge (r[c]), and 205 a serial number (j) that indicates which version of N[j] was used 206 to generate the challenge. The challenge is generated from N[j] so 207 that the correspondent does not need to store state to remember 208 which challenges it has sent to which mobiles --- r[c] can be 209 recomputed from N[j] as it is needed. 210 3. MN -> CN : T[0], HoA, CoA, i, MAC[K[BU]] (T[0] | HoA | CoA | i), j 211 K[BU] = H(K[h] | r[c]) 212 In step 3, the mobile node hashes together the shared secret and 213 the challenge to form a session key (K[BU]), and then uses this 214 session key to authenticate a binding update. The binding update 215 contains j, so that the correspondent knows which value of N[j] to 216 use to recompute the session key. Once it has verified the MAC, 217 the correspondent can create a binding cache entry for the mobile. 218 This message contains a tag (T[0]) so that it can be distinguished 219 from message 1 of the variant version of the protocol (described 220 below). The binding update also contains a sequence number (i) so 221 that if more than one binding update is sent within the lifetime 222 of a single value of N[j], it is possible to determine their 223 relative ordering. 225 Roe [Page 4] 226 When the correspondent's binding cache entry for the mobile node 227 expires, the correspondent can refresh it by running the above 228 protocol again, starting at step 2. The message sent in step 2 of this 229 new run of the protocol will usually use a different value of the 230 challenge from message that was sent in step 2 of the previous run 231 with the same mobile, because the value of N[j] has changed. 233 If the mobile changes its care-of address, but is still able to 234 receive messages sent to the old care-of address, then it runs the 235 above protocol again using its new care-of address. 237 If the mobile changes its care-of address, and is unable to receive 238 messages sent to the old address, then it uses a variant of the 239 protocol to give the correspondent an earlier notification that the 240 old address is no longer valid: 242 1. MN -> CN : T[1], HoA, CoA', i', MAC[K[BU]] (T[1] | HoA | CoA', 243 i'), j 244 In step 1, the mobile node sends a binding update authenticated 245 using the key K[BU] derived from the key that was sent to the 246 mobile's old care-of address, CoA. (At this point in the protocol, 247 the mobile has not yet received a challenge sent to its new 248 care-of address, CoA). This message contains a tag (T[1]) so that 249 it can be distinguished from the binding update sent in message 3 250 of the previous protocol. 251 If the correspondent has a binding cache entry for the mobile, and 252 it is able to verify the MAC correctly, then it should mark the 253 binding cache entry as invalid. Note that the correspondent will 254 only be able to verify the MAC if it has an existing binding cache 255 entry for the mobile, because it will need to know the old 256 care-old address to reconstruct the key K[BU]. If the 257 correspondent does not have an existing binding cache entry for 258 the mobile node, then it does not need to verify the MAC because 259 the binding cache entry has already been deleted. 260 2. CN -> MN(CoA') : r'[c], j' 261 r'[c] = MAC[K[CN]](CoA' | N[j'] | 1) 262 In step 2, the correspondent sends a new challenge to the new 263 care-of address. It should send this challenge even if it was 264 unable to verify the MAC on message 1. The reason for doing this 265 is that it allows the protocol to resynchronise after messages 266 have been lost or nodes have lost their state. 267 3. MN -> CN : T[0], HoA, CoA', i'', MAC[K'[BU]] (T[0] | HoA | CoA', 268 i''), j' 269 K'[BU] = H(K[h] | r'[c]) 270 The third step if this protocol is the same as the third step of 271 the previous protocol. Once the correspondent has verified the 272 MAC, it can create a new binding cache entry for the mobile (or 273 update the existing one). 275 Optimizations 277 1. It is not necessary to encode all the bits of j in the protocol 278 messages; just the least significant bit is sufficient for the 280 Roe [Page 5] 281 correspondent to tell whether to use N[j] or N[j-1]. 282 2. The values of N[j] should be non-repeating, but do not need to be 283 unpredictable. This means that N[j] can be implemented as a 284 counter. The secret K[CN] should be changed if the counter wraps 285 or is reset (e.g. after a reboot) 286 3. It is not necessary to encode all the bits of the sequence number 287 i. It is sufficient to encode enough of the lower bits of i so 288 that it is possible to determine the relative ordering of binding 289 updates sent within the lifetime of a single N[j]. 291 Manually Configured Keys 293 This protocol can be used with a shared secret K[h] that has been 294 configured manually. This option might be appropriate for use between 295 a mobile node and its home agent; the home agent can maintain a 296 database of the keys that have been issued to the mobile nodes that it 297 serves. 299 Use with a PKI 301 This protocol can also be used with a shared secret K[h] that has been 302 agreed using a certificate-based key agreement protocol. The 303 certificates should associate a node's public key with its home 304 address. That is, the public key infrastructure should be used to 305 authenticate the node's homes address rather than its care-of address. 307 2.3 BAKE/2 309 Properties of the Protocol 311 The "Bake/2" protocol extends the shared key protocol of section 2.2 312 by providing a means to establish the shared secret dynamically. 314 This protocol is only suitable for use in an environment where 315 communication from the correspondent through the home agent to the 316 mobile node, and between the home agent and the mobile node are 317 protected from eavesdropping by means outside of this protocol. 318 Examples of ways in which this protection could be provided include 319 the use of IPSEC Encapsulating Security Payload, or a physically 320 protected network. 322 An example of a situation where it would be appropriate to use this 323 protocol is when the home agent and the correspondent node are both on 324 a physically protected corporate intranet, the mobile node is 325 connected via a public wireless network, and the mobile node has an 326 encrypted tunnel between itself and the home agent. 328 This protocol may also provide a low level of protection when the 329 correspondent node is (for example) a web server connected to the 330 public Internet by a wired connection and the mobile node is connected 331 via a wireless network. The protocol can be broken by an attacker on 332 the route between the home agent and the correspondent node, but not 333 by attackers on the wireless network or elsewhere on the Internet. 335 Roe [Page 6] 336 Walkthrough 338 1. MN -> CN : HoA, CoA 339 In the first message, the mobile node contacts the correspondent 340 node, giving both the mobile's home address and its care of 341 address. 342 2. CN -> MN(HoA) : K[h], j 343 K[h] = MAC[K[CN]](HoA | N[j] | 0) 344 In the second step, the correspondent generates a value (K[h]) 345 that will be used as a shared secret between the mobile and the 346 correspondent. This shared secret is sent to the mobile node via 347 its home agent; it is an assumption of the protocol that this 348 route is secure. K[h] also acts as a challenge to test that the 349 mobile can receive messages sent to its home address. 350 3. CN -> MN(CoA) : r[c], j 351 r[c] = MAC[K[CN]](CoA | N[j] | 1) 352 The correspondent also sends a challenge to the mobile's care-of 353 address. This step is the same as step 2 of the shared key 354 protocol described in section 2.2. 355 4. MN -> CN : T[0], HoA, CoA, i, MAC[K[BU]](T[0] | HoA | CoA | i), j 356 K[BU] = H(K[h] | r[c]) 357 In the third step, the mobile sends an authenticated binding 358 update. 360 2.4 CAM-DH 362 Properties of the Protocol 364 The "CAM-DH" protocol combines the BAKE/2 protocol with a digitally 365 signed Diffie-Hellman key exchange. In CAM-DH, each mobile node's home 366 address is generated from its public signature key. The use of 367 cryptographically-generated addresses (CGA) avoids the need for X.509 368 certificates or similar mechanisms that associate keys with addresses 369 [5]. The mobile node uses its private signature key to sign a 370 Diffie-Hellman exponent which is then used to negotiate a session key. 371 The underlying BAKE/2 protocol provides the correspondent node with 372 protection against denial of service attacks - the correspondent will 373 not perform any asymmetric cryptographic operations until it knows it 374 is talking to a mobile which has been authenticated with BAKE/2 - 375 while the signature mechanism provides a higher level of security than 376 would be available with BAKE/2 used on its own. 378 This protocol could have been simplified by deriving mobile's home 379 address from the Diffie-Hellman exponent, rather than deriving it from 380 the public key that verifies the signature on the Diffie-Hellman 381 exponent. However, the extra level of indirection allows the signature 382 key to be used to sign messages that are used with other protocols. We 383 anticipate that there will be other protocols that would like to use 384 cryptographically generated addresses. Our approach allows a node to 385 use several such protocols simultaneously. Each signed key is 386 accompanied by a tag that indicates the protocol it is used for, to 387 prevent attacks based on interactions between protocols. 389 Walkthrough 391 Roe [Page 7] 392 1. MN -> CN : HoA, CoA 393 In the first message, the mobile node contacts the correspondent 394 node, giving the mobile's home and care-of addresses. 395 2. CN -> MN(HoA) : r[h], j, gy 396 r[h] = MAC[K[CN]](HoA | N[j] | 0) 397 In the second and third messages, the correspondent node sends the 398 mobile node two challenges, one to the care-of address and one to 399 the home address. The correspondent also sends the mobile a 400 Diffie-Hellman exponent. The correspondent can use the same 401 exponent with all mobiles it is communicating with, so there is no 402 need to generate a new exponent for each protocol run. Like K[CN], 403 y can be constant (this reduces by one the number of modular 404 exponentiations that the correspondent needs) or periodically 405 updated. If y is changed, the subscript j indicates which version 406 of y to use (as well as which K[CN] and N[j]). 407 3. CN -> MN(CoA) : r[c], j 408 r[c] = MAC[K[CN]](CoA | N[j] | 1) 409 4. MN -> CN : T[0], HoA, CoA, i, MAC[K[BU]](T[0] | HoA | CoA | i), 410 gx, S[PK](TypeTag | gx | HoA), PK, MAC[K[3]](...), j 411 K[3] = h(r[h] | r[c]) 412 K[h] = h(gxy | r[h]) 413 K[BU] = h(K[h] | r[c]) 414 When it has received the two challenges, the mobile hashes them 415 together to form a key (K[3]), and then uses this key to compute a 416 message authentication code on its public key and signed 417 Diffie-Hellman parameter. The purpose of this MAC is to convince 418 the correspondent that the risk of the message being a forgery is 419 low enough that it is worthwhile expending computational resources 420 on checking the signature and calculating the Diffie-Hellman 421 exponent gxy. The mobile also uses Diffie-Hellman key agreement to 422 calculate a session key that can be used to authenticate binding 423 updates. The fourth message consists of a binding update, a 424 message authentication code on the binding update computed using 425 K[BU], the mobile's public signature key, the mobile's 426 Diffie-Hellman exponent signed with its private signature key, and 427 a message authentication code on all of the aforementioned data, 428 computed using a key derived from the two challenges. 429 When the correspondent receives the fourth message, it should 430 check the outer MAC with K[3] first. It should only attempt to 431 compute K[BU] and verify the inner MAC with it if the outer MAC 432 verifies correctly. This protects the correspondent against denial 433 of service attacks in which it is flooded with many bogus fourth 434 messages. If both MACs verify correctly, the correspondent should 435 store state related to the mobile, including the key K[h]. 436 5. CN -> MN : r'[c], j' 437 When the correspondent node's binding cache entry is about to 438 expire, the correspondent sends the mobile node a binding request 439 containing a fresh challenge. (Typically, N[j] will have changed 440 since the last time a challenge was sent to the mobile). 441 6. MN -> CN : T[0], HoA, CoA, i, MAC[K'[BU]](T[0] | HoA | CoA | i), 442 j' 443 K[h] = h(gxy | r[h]) 444 K'[BU] = h(K[h] | r'[c]) 446 Roe [Page 8] 447 The mobile node hashes the old value of K[h] together with the new 448 challenge to compute a new key K'[BU], and sends a binding update 449 authenticated using this key. 451 Optimizations 453 1. All of the asymmetric cryptographic operations that the mobile 454 carries out can be performed instead by the home agent, provided 455 that the home agent is given access to the appropriate keys. An 456 example of a situation where the optimisation might be useful is a 457 low-power wireless mobile device that does not have enough 458 computational power for asymmetric cryptography. If this 459 optimisation is used, the home agent intercepts the second message 460 (which is routed via the home agent) and performs certain 461 processing on in before forwarding it on to the mobile node. 462 That is, the second message is replaced with the following: 463 CN -> HA : r[h], j, gy 464 HA -> MN : CN's address, K[h], j 465 K[h] = h(gxy | r[h]) 466 To use this optimization, communications between the home agent 467 and the mobile node must be protected against eavesdropping (e.g. 468 by using IPSEC ESP). 469 2. In the case when the correspondent node is also a mobile node, all 470 of the asymmetric cryptographic operations that the correspondent 471 performs can instead be performed by the correspondent's home 472 agent. To enable this optimisation, the second message of the 473 protocol contains a flag that indicates to the mobile node whether 474 the correspondent is using this optimisation. When this flag is 475 set in the second message, the mobile should send the fourth 476 message to the correspondent's home address, rather than its 477 care-of address. That is, the mobile should disable route 478 optimisation when sending the third message. 480 3. New IPv6 Sub-option Types 482 This memo defines the following IPv6 destination option sub-option 483 types: 485 3.1 Care-of Address Challenge 487 Alignment requirement: none 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 492 | TBA | Length | Serial | Protocol | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Algorithm | Challenge (variable length) | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 The Care-of Address Key Challenge sub-option is valid in a Binding 498 Request destination sub-option. The Serial field contains the variable 499 j in the BAKE/2 and CAM-DH protocols. The Algorithm field indicates 500 which cryptographic algorithm should be used to compute the 502 Roe [Page 9] 503 authentication information field in the Binding Update that is sent in 504 response to this option. The Challenge field contains the challenge 505 r[c] in the shared key, BAKE/2 and CAM-DH protocols; it is the second 506 of two components which are to be concatenated and hashed to form a 507 key which is then used to authenticate binding updates. 509 The Protocol field indicates which authentication protocol the 510 correspondent requires. The following values are defined: 512 1 The shared key protocol 513 2 BAKE/2 514 3 CAM-DH 516 The Algorithm field indicates which cryptographic algorithms are to be 517 used in the authentication protocol. The following values are defined: 519 1 HMAC-SHA1 521 The Challenge field is of variable length. It is recommended that this 522 field be 4 bytes long. 524 3.2 Response to Challenge 526 Alignment requirement: none 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | TBA | Length | Serial | Protocol | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 |K| RFU | Authenticator (variable length) | 534 +---------------------------------------------------------------+ 536 The Response to Challenge sub-option is valid in a Binding Update 537 destination option. 539 The Serial field contains the variable j in the shared key, BAKE/2 and 540 CAM-DH protocols. That is, it tells the correspondent node that 541 receives the suboption which of the challenge values (N[j]) are to be 542 used to authenticate the binding update. 544 The Protocol field indicates which protocol (shared key, BAKE/2 or 545 CAM-DH) was used to construct the authenticator. The value of this 546 field is the same as the value of the Protocol field in the Challenge 547 sub-option. 549 The K bit corresponds to the tags T[0] and T[1] in the shared key 550 protocol. It is set to zero if the MAC on the binding update is to be 551 verified using the challenge that was sent to the mobile node's 552 current care-of address, and is set to 1 if the binding update is 553 authenticated using the challenge that was sent to the mobile node's 554 previous care-of address. 556 The RFU bits are reserved for future use and shall be set to zero. The 557 Authenticator field is computed by applying HMAC-SHA1-80 to the 558 following data: 560 AHSD, Reserved 3 bytes 561 Sequence Number 1 byte 562 Lifetime 4 bytes 563 Home Address 16 bytes 564 Care-of Address 16 bytes 565 K, RFU 1 byte 567 The A, H, S, D, Reserved, Sequence Number and Lifetime fields show 568 above have the same value as the corresponding fields in the Binding 569 Update. The Home Address field contains the Home Address from the Home 570 Address option earlier in the packet. The Care-Of Address field 571 contains the IP source address of the packet. The K and RFU fields 572 shown above have the same value as the corresponding fields in the 573 Response To Challenge sub-option. 575 4. Other Message Formats 577 4.1 DHChallenge 579 HomeAddressChallenge ::= 580 [0] SEQUENCE 581 { 582 serial INTEGER, 583 CHOICE 584 { 585 bake2 [0] SEQUENCE 586 { 587 key BIT STRING 588 } 589 camDH [1] SEQUENCE 590 { 591 challenge BIT STRING, 592 exponential INTEGER, 593 disableRouteOptimization BOOLEAN 594 } 595 } 596 } 598 The serial field contains the value of j. The key field contains K[h]. 599 The challenge field contains r[h]. The exponential field contains gy. 600 If the disableRouteOptimization field is set to TRUE, then the 601 response to this message should be sent to the correspondent's home 602 address, not its care-of address. 604 4.2 DHResponse 606 DHResponse ::= 607 [1] SEQUENCE 608 { 609 serial INTEGER, 610 signedExponential SIGNED SEQUENCE 611 { 612 tag OBJECT IDENTIFIER, 613 homeAddress BIT STRING, 614 exponential INTEGER 615 } 616 publicKey PublicKey, 617 innerMAC BIT STRING, 618 outerMAC BIT STRING 619 } 621 The serial field contains the value of j. The exponential field 622 contains the value of gx. The innerMAC field contains a MAC computed 623 using K[BU] with HMAC-SHA1-80. The outerMAC field contains a MAC 624 computed using K[3] with HMAC-SHA1-80. 626 The value of the tag field is to be assigned. 628 5. Assigned Numbers 630 5.1 Ports 632 UDP_PORT_CAM to be assigned 634 5.2 Object Identifiers 636 SignedExponent to be assigned 638 5.3 Binding Acknowledgement Status Values 640 AUTHENTICATION_REQUIRED to be assigned 642 6. Realisation of the Abstract Protocols 644 6.1 The Shared Key Protocol 646 1. The mobile sends the correspondent a packet containing a Binding 647 Update destination option. 648 2. The correspondent sends the mobile a packet containing a Binding 649 Acknowledgment destination option, with the status field set to 650 AUTHENTICATION_REQUIRED. The Binding Acknowledgment contains a 651 Care-Of Address Challenge sub-option. 652 3. The mobile sends the correspondent a packet containing a Binding 653 Update destination option, which in turn contains a Response to 654 Challenge sub-option. The Flags field of this sub-option will be 655 set to 0. The Serial field of this sub-option will be the same as 656 the Serial field of the Care-Of Address Challenge sub-option in 657 the previous step. The other fields are computed as described in 658 section 3.2. 659 4. The correspondent sends the mobile a Binding Acknowledgement, with 660 the status field set to indicate success. 661 5. When the correspondent's Binding Cache Entry is about to expire, 662 the correspondent sends the mobile a Binding Request containing a 663 Care-Of Address Challenge sub-option. 664 6. The mobile replies to the request by sending a Binding Update 665 containing a Response to Challenge sub-option. 666 7. When the mobile's Binding Entry is about to expire, it sends the 667 correspondent a Binding Update containing a Response to Challenge 668 sub-option. 669 8. The correspondent replies with a Binding Acknowledgment. 670 + If the value of the Serial field in the Binding Update is the 671 one which the correspondent is currently using, the status 672 field of the Binding Acknowledgement is set to indicate 673 success. 674 + If the value of the Serial field in the Binding Update is not 675 the most recent one, but is recent enough to be acceptable to 676 the correspondent, then the Binding Acknowledgment's status 677 field is set to indicate success and the Binding 678 Acknowledgment contains a Care-Of Address Challenge 679 sub-option with the most recent value in the Serial field. 680 + If the value of the Serial field in the Binding Update is too 681 old to be acceptable, the status field of the Binding 682 Acknowledgment is set to indicate failure and the Binding 683 Acknowledgment contains a Care-Of Address Challenge 684 sub-option with the most recent value in the Serial field. 685 In this case, the mobile will reply with another Binding 686 Update containing a Response to Challenge sub-option. 688 6.2 BAKE/2 690 1. The mobile sends the correspondent a packet containing a Binding 691 Update destination option. 692 2. The correspondent sends a UDP packet of format 693 HomeAddressChallenge to the mobile at the port UDP_PORT_CAM. The 694 optional exponential field is not present in this packet. 695 3. The correspondent sends to the mobile (at its care-of address) a 696 packet containing a Binding Acknowledgement destination option 697 with the status field set to AUTHENTICATION_REQUIRED. The Binding 698 Acknowledgment contains a Care-Of Address Challenge sub-option. 699 4. The mobile sends the correspondent a packet containing a Binding 700 Update destination option, which in turn contains a Response to 701 Challenge sub-option. The Authenticator field of this sub-option 702 is computed as described in section 3.2. 703 5. The correspondent sends the mobile a packet containing a Binding 704 Acknowledgment, with the status field set to indicate success. 706 The procedures taken when the correspondent's Binding Cache Entry is 707 about to expire, and when the mobile's Binding Entry is about to 708 expire, are the same as for the shared key protocol. 710 6.3 CAM-DH 712 1. The mobile sends the correspondent a packet containing a Binding 713 Update destination option. 714 2. The correspondent sends a UDP packet of format 715 HomeAddressChallenge to the mobile's home address at port 716 PORT_UDP_CAM. 717 3. The correspondent sends the mobile (at its care-of address) a 718 packet containing a Binding Acknowledgment destination option with 719 its status field set to AUTHENTICATION_REQUIRED. The Binding 720 Acknowledgment contains a Care-Of Address Challenge sub-option. 721 4. The mobile sends a UDP packet of format DHResponse to the 722 correspondent at port PORT_UDP_CAM. 723 5. The correspondent sends the mobile (at its care-of address) a 724 packet containing a Binding Request destination option, which in 725 turn contains a Care-Of Address Challenge sub-option. 726 6. The mobile sends the correspondent a packet containing a Binding 727 Update destination option, which in turn contains a Challenge 728 Serial Number sub-option. 730 7. Finite State Machines 732 7.1 The Shared Key Protocol 734 Mobile Node 736 * Event: Mobile receives a Binding Request 737 Action: Add the correspondent to the Binding Entry List, if it 738 isn't already on it. Send a Binding Update. If the Binding Request 739 contained a Care-of Address Challenge sub-option, include a 740 Response to Challenge sub-option in the Binding Update, and store 741 the value of the challenge in the Binding Entry List. 742 * Event: Mobile's Care-Of Address changes 743 Action: Send a Binding Update to all correspondents in the Binding 744 Entry List. If it is no longer possible to receive packets sent to 745 the old care-of address, set the T[1] tag in the binding update, 746 and compute the authentication field based on the challenge that 747 was sent to the old care-of address. If it is still possible to 748 receive packets sent to the old care-of address, send a binding 749 update without authentication. 750 * Event: Mobile's Binding Entry about to expire 751 Action: Send a Binding Update containing a Response to Challenge 752 sub-option to the correspondent. 753 * Event: Mobile receives a packet from the correspondent routed via 754 its home agent 755 Action: Check the Binding Entry List to see if a binding update 756 has been sent to this correspondent recently. If a binding update 757 has not been sent recently, send one. If the Binding Entry List 758 contains a recent challenge from the correspondent, use that to 759 construct a Response to Challenge sub-option that is included in 760 the Binding Update; otherwise, do not include a Response to 761 Challenge sub-option. 762 * Event: Mobile receives a Binding Acknowledgment 763 If the Binding Acknowledgment contains a Care-Of Address Challenge 764 sub-option, then the mobile stores the value of the challenge in 765 its binding entry list. If the Binding Acknowledgment contains a 766 Care-Of Address Challenge sub-option and the status field is set 767 to indicate failure, then the mobile sends a Binding Update 768 containing a Response to Challenge sub-option. 770 Correspondent Node 772 * Event: Binding Cache Entry about to expire 773 Action: Send the mobile a Binding Request containing a Care-of 774 Address Challenge sub-option 775 * Event: Receive a Binding Update 776 Action: If the Binding Update contains a Response to Challenge 777 sub-option, and the Serial field is sufficiently recent, and the 778 Authenticator field contains the right value, then update the 779 Binding Cache and send a Binding Acknowledgment with the status 780 field set to indicate success. If the value in the Serial field 781 was not the most recent one, include a Challenge sub-option in the 782 Binding Acknowledgment. 783 Otherwise, send a Binding Acknowledgment with the status field set 784 to indicate failure and containing a Care-of Address Challenge 785 sub-option. 787 8. Background to the Protocol Designs 789 8.1 IP Addresses derived from Cryptographic Keys 791 In the CAM-DH protocol, a node uses a home address that is derived 792 from the node's public key. The idea behind this is that if the 793 address is the same as the public key, nodes can work out which key 794 corresponds to an address without needing to use a secure key 795 distribution mechanism such as X.509 certificates. Such key 796 distribution mechanisms typically need to be configured manually, and 797 this conflicts with the design goal of IPv6 that it should be possible 798 to configure hosts automatically. However, it is not possible to set 799 the IP address equal to the public key, because they will normally be 800 of different length, and the network part of the address must be set 801 to the right value for the packet to be routed correctly. Instead, we 802 use a more complex relationship between the address and the key, in 803 which the last 64 bits of the address (the "Interface ID") are defined 804 as follows: 806 InterfaceId = First64(SHA1(Route Prefix | M | RFU | Public Key)) 807 & 0xfcffffffffffffff 809 The field "RFU" is reserved for future use, and shall be set to zero. 810 The field "M" is a modifier, which is used in the following way. A 811 node generates a private/public key pair, and then attempts duplicate 812 address detection for an address generated using the above equation 813 with M set to zero. It is very unlikely that a collision will occur 814 except as a result of an attack on the protocol. However, if a 815 collision is detected the host MAY attempt duplicate address detection 816 again with a different address, generated using the same public key 817 and with M equal to one. If necessary, this process may be repeated 818 with M equal to 2 and M equal to 3. Nodes MUST NOT use values of M 819 greater than three. Four collisions in a row are very, very unlikely 820 to occur by chance, and are almost certainly the result of either an 821 attack on the protocol or an error in the implementation. 823 Bit 6 of the host part of the address is the universal/local bit [3]. 824 It is set to zero to indicate that the address generated is not 825 guaranteed to be globally unique. This ensures that it will not 826 collide with an IP address derived from an ethernet address. It is 827 important to avoid such collisions, because hosts that use their MAC 828 address to derive their IP address will not expect such collisions, 829 and they might not have a means to recover from them when they occur. 830 Bit 7 of the host part of the address is the individual/group bit [3]. 831 It is set to zero to indicate that it is the address of an individual 832 node, not a group of nodes. 834 The route prefix is included in the input to the hash function to 835 prevent an attack in which the attacker expends a very large initial 836 set-up cost, but is then able to attack many different nodes at a 837 relatively low cost per node. If the route prefix was not included, an 838 attacker could, at great expense, compute a lookup table that contains 839 a suitable key pair for each of the 2^62 possible values of the 840 InterfaceId. Such a lookup table could then be used to masquerade as 841 any mobile node. Including the route prefix makes this attack not 842 economically viable (from the point of view of the attacker), because 843 it means that such a look-up table can only be used to masquerade as 844 nodes which have the same route prefix. Typically, there will not be 845 enough nodes with the same route prefix to justify the expense of 846 constructing the lookup table. 848 8.2 Resource Exhaustion and other Denial of Service Attacks 850 When designing these protocols, we found it useful to distinguish 851 between two different types of denial of service attack. Resource 852 exhaustion attacks are attacks in which the victim has only a limited 853 amount of some resource (such as network bandwidth or CPU cycles), and 854 the attack consumes some of this resource, leaving the victim with not 855 enough of it left to carry out the other work it needs to do. There 856 are denial of service attacks that are not resource exhaustion 857 attacks. For example, forged binding updates can lead to denial of 858 service, because packets will be sent to the wrong care-of address. 859 This is not an example of resource exhaustion; a host with an 860 unlimited supply of network bandwidth and CPU would still be 861 vulnerable to denial of service attacks based on forged binding 862 updates. This attack works by corrupting a host's state (its binding 863 cache), not by running it out of resources. That is, a failure of 864 integrity and authentication then leads to denial of service. 866 The binding updates that are used in mobile IPv6 are only an 867 optimisation. A mobile node can communicate with a correspondent node 868 even if the correspondent refuses to accept any of its binding 869 updates. However, performance will suffer because packets from the 870 correspondent to the mobile will be routed via the mobile's home agent 871 rather than a more direct route. A correspondent can protect itself 872 against some of the resource exhaustion attacks by stopping processing 873 binding updates when it is flooded with a large number of binding 874 updates that fail the cryptographic integrity checks. If a 875 correspondent finds that it is spending more resources on checking 876 bogus binding updates than it is likely to save by accepting genuine 877 binding updates, then it can decide to reject all binding updates 878 without performing any cryptographic operations. 880 Nodes that are willing to expend significant resources responding to 881 anyone, no matter who they are, will often be vulnerable to resource 882 exhaustion attacks. The DoS protection mechanisms described in this 883 memo will only be useful if each node has some means of deciding 884 whether it should expend resources on behalf of a particular peer. 885 This information needed to make this decision will usually originate 886 in layers above IP. For example, TCP knows if the node has a queue of 887 data that it is trying to send to a peer. It is possible to produce a 888 conforming implementation of the protocols in this memo without making 889 use of information from higher protocol layers, but implementations 890 may be able to manage resources more effectively by making use of such 891 information. 893 In general, a node will be willing to devote resources to a run of an 894 authentication protocol for one of two reasons. In the first case, the 895 node itself is trying to carry out some work, and knows that 896 completing the authentication protocol run is necessary (or helpful) 897 in getting that work done. In the second case, the node's peer is 898 trying to carry out some work for which the authentication protocol 899 run is necessary or helpful. In this case, the node does not know 900 directly that the protocol run is worthwhile, but may be prepared to 901 expend resources on behalf of certain peers when they ask it to. There 902 is a problem with this case that is specific to authentication 903 protocols, and does not occur with other types of protocol. The node 904 will only know that it is worthwhile expending resources on a protocol 905 run when it knows that the run has been initiated by a peer that is 906 willing to devote resources to. However, it will only know this when 907 the peer has been successfully authenticated, that is when protocol 908 run has been completed and the resources have already been spent. One 909 way in which this situation may be improved is to divide the 910 authentication protocol in to two phases. The first phase consumes 911 very little resources, but does not provide a very high level of 912 security. The second phase provides a higher level of security, but 913 requires more resources to provide this level of security. The second 914 phase is only started if the first phase completes successfully. In 915 this way, only attackers who can break the security of the first phase 916 can cause a resource exhaustion attack using the second phase. We have 917 used this approach in the protocols described in this memo. 919 8.3 Piggybacking and Jitter 921 The mobile IPv6 specification allows for "piggybacking". That is, 922 control messages such as binding updates may be combined with other 923 messages. Piggybacking will delay these other messages in two ways. 924 Firstly, it will make them larger, and larger messages usually take 925 longer to transmit. Secondly, it will increase the amount of 926 processing that is needed to send and receive the messages because the 927 mobility information in the message will need to be processed as well. 928 When the control messages are authenticated with asymmetric 929 cryptography, they will add a large amount of jitter, because digital 930 signatures require many bytes to represent and take many CPU cycles to 931 compute or verify. Some applications, for example real-time voice, are 932 very sensitive to jitter. 934 Some networks have "quality of service" facilities whereby an 935 application can reserve a particular amount of bandwidth. Piggybacking 936 can interfere with these facilities, because when packets are made 937 bigger by adding mobility headers they may exceed the size that has 938 been reserved, and this may cause them to be discarded or severely 939 delayed by the network. 941 Accordingly, we recommend that piggybacking should not be used when 942 quality of service facilities are in use (e.g. the IPv6 flow id is 943 nonzero) and should not be used when asymmetric cryptography is being 944 used to protect the mobility control portion of the message. This 945 recommendation has affected the design of the protocols described in 946 this memo; digital signatures are carried in UDP messages, not IPv6 947 destination options. UDP messages cannot be piggybacked, but this is 948 not a serious problem as we recommend that these messages should not 949 be piggybacked. 951 8.4 Length of Suboptions 953 The IPv6 option length limits the amount of data that may be passed in 954 a destination option or as a suboption within a destination option. 955 The maximum length of a suboption is 255 bytes, or 2040 bits excluding 956 any other data in the protocol. Since both a public key and a 957 Diffie-Hellman value needs to be passed in the CAM-DH protocol, 958 passing these in a suboption would limit the key size to 1020 bits. 959 These values are just about enough for current security needs, but 960 seem low in view of future developments. They also preclude the use of 961 the same long key for both MIPv6 and other purposes. Therefore, we 962 have chosen to run the authentication protocol as an independent 963 protocol on top of UDP. 965 8.5 Rationale for BAKE/2 967 Our motivation for designing BAKE/2 was that we wanted to add support 968 for mobile IP without creating major new security problems. We wanted 969 a protocol that would protect against the new vulnerabilities that 970 were introduced by IP mobility. It was not our goal to protect against 971 attacks that were already possible before the introduction of IP 972 mobility. This protocol does not defend against an attacker who can 973 monitor the home agent to correspondent node route. Our justification 974 for this is that if such an attacker exists, they are able to attack 975 the system before IP mobility is enabled, because they can mount an 976 active attack against the mobile node when it is at its home location. 977 Prevention of such attacks is outside the scope of this protocol. The 978 possibility of such attacks is not an impediment to the deployment of 979 mobile IP, because these attacks are possible irrespective of whether 980 mobile IP is in use or not. 982 Some of our earlier protocols for authenticating binding updates, such 983 as CAM [5], ran the complete protocol for each binding update. The 984 protocol described here establishes a session key which can then be 985 used for many binding updates between the same nodes without running 986 the whole protocol again. This can result in an efficiency saving, 987 because binding updates are resent at regular intervals. This 988 efficiency saving will usually be realised when a mobile node 989 communicates with the same correspondent node for an extended period 990 of time. If the mobile node communicates with a correspondent briefly 991 and then never talks to it again, then the establishment of a session 992 key does not result in efficiency savings. 994 This protocol protects the correspondent node against denial of 995 service attacks in which the correspondent is flooded with many bogus 996 messages. The correspondent does not have to store state or consume a 997 large amount of processing time handling messages from a source which 998 has not yet been authenticated. The protocol does not protect the 999 mobile against these attacks. This means that this protocol is 1000 suitable for use when a client on a mobile node accesses a server on a 1001 non-mobile node, but may not be suitable for use when accessing a 1002 server on a mobile node. It is an assumption of the protocol that at 1003 the start of a run the mobile node already has stored state about the 1004 correspondent (perhaps at a level above IP, such as TCP or the 1005 application), and knows that it is worthwhile expending resources on 1006 the run. There is a clear need for a protocol for the opposite case, 1007 where the correspondent has pre-existing stored state about the mobile 1008 and knows that it is worthwhile expending resources on the protocol 1009 run. This is a matter for further study. 1011 This protocol also protects against denial of service attacks in which 1012 the attacker pretends to be a mobile, but uses the victim's address as 1013 the care of address, and so causes the correspondent to send the 1014 victim traffic that it does not want. For example, suppose that the 1015 correspondent is a news site that will send a high-bandwidth stream of 1016 video to anyone who asks for it. Note that the use of flow-control 1017 protocols such as TCP does not necessarily defend against this type of 1018 attack, because the attacker can fake the acknowledgements. Even 1019 keeping TCP initial sequence numbers secret doesn't help, because the 1020 attacker can receive the first few segments (including the ISN) at its 1021 own address, and then redirect the stream to the victim's address. 1022 This protocol defends against these attacks by only completing if 1023 packets sent by the correspondent to the care of address are received 1024 and processed by an entity that is willing to participate in the 1025 protocol. Normally, this will be the mobile node. 1027 9. Intellectual Property Rights Notice 1029 The CAM-DH variant of our protocols uses public keys and hashes to 1030 prove address ownership [4,5]. In case there would be any Ericsson IPR 1031 on such methods, the Ericsson policy on IPR issues can be checked from 1032 the Ericsson General IPR statement for IETF, 1033 [3]http://www.ietf.org/ietf/IPR/ERICSSON-General. Microsoft's IPR 1034 statement concerning this memo is available at 1035 [4]http://www.ietf.org/ietf/IPR/MICROSOFT-MOBILEIP-UPDATEAUTH.txt. 1037 10. Security Considerations 1039 10.1 Risks of unauthenticated binding updates 1041 If a node accepts binding updates without authentication, then it is 1042 vulnerable to several attacks in which an attacker sends forged 1043 binding updates for other nodes. These include a denial of service 1044 attack in which the attacker sends the victim a forged binding update 1045 for a service that the victim relies on (e.g. the domain name 1046 service), and sets this service's care of address to a non-existent 1047 address. The victim will be unable to contact the service at the 1048 falsified care of address, and henceforth will be unable to make use 1049 of the service. A variation on this attack with consequences beyond 1050 denial of service is when the attacker sets the service's care of 1051 address to the attackers own address, and the attacker then provides a 1052 maliciously modified version of the service. 1054 For this reason, it is recommended that nodes on the Internet SHOULD 1055 use some form of authentication for binding updates. Nodes on private 1056 intranets that use other means to exclude potential attackers MAY 1057 accept binding updates without authentication. 1059 10.2 Risks of unauthenticated binding acknowledgements 1061 The consequences of forged binding acknowledgements are, in general, 1062 less serious that those of forged binding updates. The usual 1063 consequence of forging a binding acknowledgement is that the victim's 1064 correspondent will fail to obtain an up-to-date binding for the 1065 victim, the correspondent's previous binding for the victim will 1066 expire, and the correspond will revert to sending packets via the 1067 victim's home agent. Communications between the victim and its 1068 correspondent will still work, but may suffer degraded performance. In 1069 some circumstances this degradation of performance will be 1070 sufficiently severe to constitute a denial of service attack. 1072 Forged binding acknowledgements that appear to come from the victim's 1073 home agent have more serious consequences than forged acknowledgements 1074 that appear to come from other correspondent nodes. If a mobile node 1075 is away from home, and its home agent does not have a valid binding 1076 for it, then the mobile node will become uncontactable. As a result, 1077 it is possible to carry out a denial of service attack on a mobile 1078 node by blocking the binding updates it sends to its home agent and 1079 forging the acknowledgements. Even if the attacker cannot prevent 1080 packets getting through, they may still be able to use forged 1081 acknowledgements to cause denial of service some of the time; if a 1082 binding update is lost for normal reasons (not as a result of the 1083 attack), then the forged acknowledgements will prevent it from being 1084 retransmitted. 1086 This attack might also make it possible to intercept packets destined 1087 for a mobile node. Suppose that a particular network does not allow 1088 two nodes to have the same address at the same time, but will allow 1089 one node to take over another's address when the original user of the 1090 address has left the network. (This assumption does not hold with many 1091 network technologies). Then the attacker waits for a mobile node to 1092 leave the network, takes over its old care-of address, and uses forged 1093 binding acknowledgements and/or blocks the binding updates so that the 1094 mobile's home agent never learns that mobile's care-of address has 1095 changed. Packets sent to the mobile's home address will continue to be 1096 forwarded to the old care-of address, which is now under the control 1097 of the attacker. 1099 One possible security policy that takes into account these 1100 considerations is to require authenticated binding acknowledgments 1101 from a home agent, but to accept unauthenticated binding 1102 acknowledgments from other correspondents. 1104 10.3 Risks of not verifying the care-of address 1106 The BAKE/2 and CAM-DH protocols described in this memo verify that 1107 packets sent to a mobile node's claimed care-of address reach an 1108 entity that is willing to participate in the protocol. If this check 1109 was not performed, a malicious mobile node could perform a denial of 1110 service attack by asking a correspondent node to send it a high volume 1111 stream of data, and then sending the correspondent a binding update 1112 that redirects the stream of data to the victim of the denial of 1113 service attack. The acknowledgements and initial sequence number of 1114 TCP do not protect against this attack. A malicious mobile node can 1115 send the acknowledgements for the stream of data even if it is not 1116 actually receiving it. Unpredictable initial sequence numbers do not 1117 prevent a malicious mobile forging acknowledgements because the mobile 1118 sees the beginning of the stream of data (including the initial 1119 sequence number) before it redirects it to the victim. 1121 The BAKE/2 and CAM-DH do not authenticate the care-of address. An 1122 attacker who can intercept packets sent to the care-of address can 1123 complete the protocol and cause the care-of address to be flooded with 1124 data, even if the host that actually owns the care-of address is not 1125 willing to participate in the protocol. 1127 An alternative method of authenticating the care-of address would have 1128 been to derive the care-of address (as well as the home address) from 1129 the node's public key. We did not adopt this approach, because some 1130 subnetworks may impose constraints on the care-of addresses that can 1131 be used. 1133 10.4 Risks of Not Authenticating Home Agents 1135 If a mobile node is willing to allow anyone to act as its home agent 1136 (for example. suppose that it uses multicast to locate a suitable home 1137 agent) then it is vulnerable to a number of attacks in which the 1138 attacker pretends to be a home agent. For example, by acting as a 1139 node's home agent the attack can intercept packets sent to the node (a 1140 threat to confidentiality), and can cause denial of service. We 1141 observe that if an attacker is in a position to carry out these 1142 attacks, then it is also in a position to carry out other attacks of 1143 equal or greater seriousness, for example pretending to be a router. 1145 In environments where this is a concern, the mobile should 1146 authenticate its home agent (and the next hop router, and many other 1147 services it relies on). In this case, it is not sufficient to check 1148 that the home agent's address is statistically unique; it is also 1149 necessary to check that the address corresponds to a "good" home 1150 agent, i.e. one that will behave in a particular way. This means that 1151 the technique of deriving addresses from public keys is not sufficient 1152 for authenticating the home agent to the mobile, because it only 1153 guarantees that the address is almost certainly not being used by 1154 anyone else. An IPSEC security association established using 1155 certificate-based key management may not be sufficient either; it is 1156 not enough to know that some authority has associated a particular key 1157 with a particular IP address, as this on its own does not provide 1158 assurance that the node at that address is a good home agent. 1160 10.5 Denial of Service Attacks against Home Agents 1162 Home agents are vulnerable to denial of service attacks carried out by 1163 mobile nodes for which they are the home agent. For example, a 1164 malicious mobile node that has two different home addresses from two 1165 different home agents can create a routing loop by sending the first 1166 home agent a binding update with the mobile's second home address as a 1167 care-of address, and sending the second home agent a binding update 1168 with the mobile's first home address as a care-of address. Packets 1169 caught in this routing loop will eventually time out, but there is a 1170 considerable degree of traffic amplification: for each packet that the 1171 attacker sends into the routing loop, the home agents will have to 1172 send and receive many packets. 1174 Home agents can defend against these attacks in several ways. A home 1175 agent that will only act as home agent for mobile nodes that it knows 1176 to be trustworthy will not be vulnerable to these attacks. 1178 References 1180 1. Information processing systems - Open Systems Interconnection - 1181 Specification of Basic Encoding Rules for Abstract Syntax Notation 1182 One (ASN.1). ISO 8825, International Organization for 1183 Standardization, 1987. 1184 2. Secure hash standard. FIPS PUB 180-1, NIST, April 1995. 1185 3. R. Hinden and S. Deering. IP Version 6 Addressing Architecture. 1186 RFC 2373, July 1998. 1187 4. P. Nikander. A Scaleable Architecture for IPv6 Address Ownership. 1188 Internet draft, March 2001. 1189 5. Greg O'Shea and Michael Roe. Child-proof authentication for MIPv6 1190 (CAM). Computer Communications Review, April 2001. 1192 11. Author's Addresses 1194 Michael Roe 1195 Microsoft Research Limited 1196 7 J J Thomson Avenue 1197 Cambridge CB3 0FB 1198 UK 1199 Email: mroe@microsoft.com 1201 Tuomas Aura 1202 Microsoft Research Limited 1203 7 J J Thomson Avenue 1204 Cambridge CB3 0FB 1205 UK 1206 Email: tuomaura@microsoft.com 1208 Greg O'Shea 1209 Microsoft Research Limited 1210 7 J J Thomson Avenue 1211 Cambridge CB3 0FB 1212 UK 1213 Email: gregos@microsoft.com 1215 Jari Arkko 1216 Oy LM Ericsson Ab 1217 02420 Jorvas 1218 Finland 1220 Phone: +358 40 5079256 1221 EMail: jari.arkko@ericsson.com