idnits 2.17.1 draft-thomas-mobileip-ha-cookies-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 25 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 4 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 245: '... node SHOULD use the newly ship...' RFC 2119 keyword, line 307: '... SHOULD NOT encrypt the key for the ...' RFC 2119 keyword, line 329: '...iven layer 2 protection, it SHOULD NOT...' RFC 2119 keyword, line 336: '...rrespondent node MUST accept the negat...' RFC 2119 keyword, line 338: '...rrespondent node MAY defer sending pac...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 12, 2001) is 8323 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: 'PBK' is mentioned on line 1074, but not defined == Missing Reference: 'PKB' is mentioned on line 97, but not defined == Missing Reference: 'AH' is mentioned on line 476, but not defined == Missing Reference: 'ADDRARCH' is mentioned on line 692, but not defined == Missing Reference: 'MD5' is mentioned on line 765, but not defined == Missing Reference: 'SHA-1' is mentioned on line 765, but not defined == Missing Reference: 'RSA-1024' is mentioned on line 770, but not defined -- Looks like a reference, but probably isn't: '5' on line 1023 == Missing Reference: 'IKE' is mentioned on line 1048, but not defined == Unused Reference: 'IPSEC' is defined on line 1088, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-03 ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Home Agent Cookies Michael Thomas 3 Dave Oran 4 Cisco Systems 5 July 12, 2001 7 Home Agent Cookies for Binding Updates 9 draft-thomas-mobileip-ha-cookies-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo describes a means of performing authentication and 33 authorization of Mobile IP V6 binding updates. It takes advantage of 34 the pre-existing security relationship between the mobile node and 35 its home agent to allow a correspondent node to decide wether or not 36 it should believe a binding update, and to perform key distribution 37 for authorizing future binding updates. 39 The mechanism employs authenticated cookies created by the mobile 40 node using a key which it shares with its home agent. The cookie is 41 included in a binding update message to the correspondent node. The 42 correspondent node extracts the cookie and sends it in a verification 43 request sent toward the mobile node using the mobile node's home 44 address. If routing tables have not been compromised, this message 45 will visit the mobile node's home agent. The home agent intercepts 46 the verification request and cryptographically determines whether the 47 binding update was generated by one of its mobile nodes. Assuming it 48 verifies correctly, the home agent can vouch for the mobile node 49 thereby authorizing the binding update. The home agent and mobile 50 node may optionally generate a new (symmetric) key to be used by the 51 correspondent node in subsequent binding updates. This is shipped 52 back to the correspondent node in an acknowledgment message from the 53 home agent so that the correspondent node can directly verify future 54 binding updates. 56 1. Introduction 58 The advent of Mobile IPv6 brings the protential elimination of 59 triangular routing between a mobile node and its correspondent nodes. 60 In standard Mobile IPv6, this is achieved through the use of Binding 61 Update messages sent by the mobile node to the correspondent node to 62 update the mobile node's current location -- it's care of address -- 63 in the correspondent node's binding cache. Binding Updates, however, 64 introduce a security hazard. In the absence of some means to 65 authenticate and authorize Binding Updates, an unauthorized host 66 could spoof a Binding Update to the correspondent node causing all 67 further traffic send by the correspondent node to be routed to the 68 care of address that the attacker chose. At the very least, this 69 could lead to a trivial denial of service attack, an active man in 70 the middle attack, or a passive snooping attack. For this reason, 71 [MOBILEIPV6] requires that binding update destination options be 72 protected by an IPsec security association using an authentication 73 header to insure that there is end to end (i.e. MN->CN) integrity of 74 the binding messages. 76 There is a presumption made in [MOBILEIPV6] that the correspondent 77 node will be able to authenticate and authorize binding updates. The 78 object being authenticated is, in fact, the home IP address of the 79 mobile node. Therefore, in order to deploy [MOBILEIPV6] widely, there 80 is a presumption that there will exist a pervasive and well 81 established global PKI for asserting the ownership and validity of IP 82 addresses. This is what would allow any corresponent node to 83 authenticate and authorize a binding updates from a mobile node based 84 on its provable right to assert a particular home IP address. Such a 85 PKI for IP addresses does not today exist, and it is not clear that 86 such a system could be deployed quickly enough to meet the needs 87 Mobile IP users and providers. There is a lot of compelling evidence 88 that this, is either extremely difficult or even less charitably, a 89 fantasy. 91 We therefore agree with the general premise put forth in the 92 Purpose-based Keys draft [PBK] that a solution which has weaker 93 properties than provable rights to assert an IP address, but which 94 foils easy attack on Binding Updates is vitally necessary to the 95 successful deployment of Mobile IPv6. 97 The proposal put forth in the [PKB] draft, as we understand it, 98 enforces the following security property: 100 o If a mobile node successfully communicates with a correspondent 101 node some moment in time (i.e. an attacker has not yet spoofed a 102 binding update) then future communication cannot be subverted by 103 a subsequent attack. 105 This Home Agent Cookies proposal enforces a different property: 107 o If a correespondent node can successfully communicate with a 108 Mobile node using mobile node's home IP address (i.e. neither 109 routing via the home agent nor home IP address assignment has 110 been subverted), then communicating directly with the mobile 111 using its current care of address is no less secure. 113 We offer the following observations to support our contention 114 that this property is appropriate and the mechanism we propose 115 to ensure it makes a reasonable tradeoff among security, proto- 116 col complexity, and deployability. 118 o We observe that while it is difficult to deploy a global PKI, 119 PKI's within more confined bounds are a reasonable expectation. 121 o To wit, we believe that the current method of doing binding 122 updates between the mobile node and its home agent provides ade- 123 quate protection against malicious subversion since the home 124 agent can through local policy means determine whether a partic- 125 ular mobile node is authorized to change its reachability for 126 one of the subnets that the home agent subtends. 128 o We can use the property that the home agent has the responsibil- 129 ity of the reachablity of the subnets it subtends to also act as 130 an authority for other nodes which may need knowledge of a 131 mobile node's current binding status. 133 o We can also use the property that correspondent nodes will, in 134 the absence of a binding cache entry, send packets to the mobile 135 node using it's home IP address. We can use this routing 136 property to discover which router contains the mobile node's 137 current binding by simply sending a packet to the mobile node 138 itself. 140 o We generally make the observation that the routing infrastruc- 141 ture needs to be secure enough such that attacks based upon 142 being able to subvert the routing infrastructure will be viewed 143 as serious in their own right and countered. We also note that 144 home agents which do not act toward the eventual goal of routing 145 packets to their destination make little sense, especially in 146 light of routers which route packets destined for subnets which 147 have been delegated to their administrative realm. 149 Given the above observations, this memo describes a means of 150 performing authentication and authorization as well as key dis- 151 tribution for binding updates which takes advantage of the pre- 152 existing security relationship between the mobile node and its 153 home agent. The mechanism employs authenticated cookies created 154 by the mobile node using a key which it shares with its home 155 agent. The cookie is included in a binding update message to the 156 correspondent node. The correspondent node extracts the cookie 157 and sends it in a verification request sent toward the mobile 158 node using the mobile node's home address. If routing tables 159 have not been compromised, this message will visit the mobile 160 node's home agent. The home agent intercepts the verification 161 request and cryptographically determines whether the binding 162 update was generated by one of its mobile nodes. Assuming it 163 verifies correctly, the home agent can vouch for the mobile node 164 thereby authorizing the binding update. The home agent and 165 mobile node may optionally generate a new (symmetric) key to be 166 used by the correspondent node in subsequent binding updates. 167 This is shipped back to the correspondent node in an acknowledg- 168 ment message from the home agent so that the correspondent node 169 can directly verify future binding updates. 171 2. Message Flows 172 2.1 Message Flow from Mobile Node to Correspondent Node 174 MN CN HA 175 ---------------------------------------------------------------------- 177 0 <===============================================================> 178 normal HA/MN security association establishment 180 1 --------------------------------> 181 BU+cookie[mn,ha]+cookie[mn,cn] 183 2 --------- 184 -----------------------> 185 BU_QUERY+cookie[mn,ha]+PK[cn] 187 3 <--------- 188 ----------------------- 189 BU_QUERY_RESP+E(key[mn,cn],PK[cn]) 191 4 [ <-------------------------------- ] 192 [ BU_ACK ] 194 ~~~~~ 195 ~~~~~ 197 5 --------------------------------> 198 BU+cookie[mn,ha]+cookie[mn,cn] 200 6 <-------------------------------- 201 BU_ACK 203 Step_0 The mobile node and its home agent create a security associa- 204 tion. In addition to the keys generated for the base security 205 association, another set of keys derived from the SA's keys are 206 generated by both the mobile node and the home agent. In addi- 207 tion, a session identifier is also devived by both the home 208 agent and the mobile node. The derivation functions are 209 described in section 4. 211 Step_1 When the mobile node discovers that it needs to send a binding 212 update for which it cannot create a normal IPsec security asso- 213 ciation, it creates two cookies to be placed in the binding 214 update. Each cookie contains a keyed hash over the contents of 215 the binding update described in section 5. The first cookie is 216 generated for the home agent, the second cookie is generated for 217 the correspondent node itself. The mechanism for generating the 218 key for the correspondent node is described in section 4. 220 Step_2 The correspondent node receives the binding update and deter- 221 mines that it does not currently have the ability to verify the 222 update. It then takes the cookie destined for the home agent and 223 creates a Binding Update Query option -- and places either in a 224 stand alone message, or piggy backed on another message destined 225 for the mobile node. The destination address of the binding 226 update query is the mobile node itself. The Binding Update Query 227 option is inserted into the IP header to alert all of the 228 routers along the way. In this way, we make certain that the 229 mobile node's Home Agent will have an opportunity to process the 230 Binding Update Query. 232 Step_3 The Home Agent receives the packet destined for the mobile node 233 and processes the Binding Update Query option. It does this by 234 first examining the cookie and determines whether the integrity 235 check and contents are valid and fresh. If the correspondent 236 node placed its public key into the Binding Update Query mes- 237 sage, the Home Agent will generate a key for the correspondent 238 node and place it in the Binding Update Query Response message. 239 The key is generated as described in lsection 4 and contents are 240 encrypted and integrity protected per section 5. 242 Step_4 The correspondent node receives the Binding Update Query 243 Response and performs a message integrity check over the message 244 and decrypts the contents, including the key. The correspondent 245 node SHOULD use the newly shipped key to verify the contents of 246 the cookie destined for the correspondent node in the initial 247 binding update. In this way, the correspondent node can cross 248 check that the home agent which sent the BUQR shares a relation- 249 ship with the mobile node. 251 This key is subsequently used by the correspondent node to 252 directly validate the correspondent node cookie signed by the 253 mobile node. The correspondent node now alters its binding 254 cache and replies to the original binding update and the tran- 255 saction is complete. 257 As noted above in the flow diagrams, the correspondent node only 258 sends a binding update acknowledgement if the mobile node 259 requested one. 261 Step_5 On subsequent changes to its care of address, the mobile node 262 behaves identically as in step 1, creating two cookies for use 263 by the home agent and correspondent node. 265 Step_6 The correspondent node, since it received a key in step 4 now 266 has a key which it can use to verify its cookie when it receives 267 a Binding Update from the Mobile Node. Assuming the cookie veri- 268 fies correctly, the correspondent node alters its binding cache 269 and ackowledges the Binding Update. 271 2.2. A Lighter Weight Alternative 273 The previous section describes a means of authenticating the original 274 binding update as well as creating a shared secret so that subsequent 275 binding updates can be directly verified by the correspondent node. 276 There is an implicit presumption is that the cost of public key 277 operations to encrypt the key payload at the home agent, and decrypt 278 it at the correspondent node is not too onerous. There may, however, 279 be situations where this cost is not acceptible. 281 If this situation arises, the act of encrypting the key payload can 282 be omitted. Either the correspondent node can request that the key 283 payload not be encrypted by omitting the public key, or the home 284 agent can refuse to create the encrypted payload. In this scenario, 285 the correspondent node will need to repeat step 2 for each movement 286 of the mobile node since it will not share a key. The correspondent 287 node also loses the ability to cross verify the home agent's 288 response, but this may be an acceptible tradeoff given the propertiy 289 we are ensuring, since this property trusts the routing system to 290 deliver packets correctly. 292 2.3 Some Attacks 293 This section outlines some of the attacks that could be mounted by an 294 adversary against this scheme. They should be considered in any 295 scheme which attempts to solve the same problem. 297 2.3.1 Attacks by Listeners on the Mobile Network 298 The network that the mobile node is attached to may be susceptible to 299 eavesdropping in which case an attacker could capture an outgoing 300 binding update. As such, the attacker could respond to the binding 301 update with its own public key. If the mobile node is configured to 302 operate in the home agentless mode, it could unwittingly reveal the 303 secret to the attacker on its own network. This could lead to the 304 attacker forging binding updates to the unwitting correspondent node. 306 For this reason, a mobile node operating in home agentless mode 307 SHOULD NOT encrypt the key for the correspondent node cookie unless 308 it has reasonable assurance that snooping attacks are not an issue on 309 its current set of interfaces (ie, L2 mechanisms that provide ade- 310 quate privacy). 312 [there may also be ways to defend against 313 this by correlating the return address with the 314 key somehow. I think that that might run afoul 315 of the NAT friendly stuff though, so for now I've not 316 taken the time to work that out. /mat] 318 2.3.2 Attacks by Listeners on the Correspondent Node Network 319 Likewise, the network that the correspondent node is attached to may 320 be subject to attacks mounted by listeners. In this case, the 321 attacker may capture both the initial Binding Update as well as the 322 corresponent node's Binding Update Query. This leads to two possible 323 attacks. 325 CapturingLike the attack on the mobile node's network above, an attacker 326 could capture the Binding Update and send a binding update 327 request to the home agent using its own public key. Likewise as 328 above, if the Correspondent Node believes the ingress interface 329 is not suitably secure given layer 2 protection, it SHOULD NOT 330 request an encrypted key to validate subsequent binding updates. 332 SpoofingIn addition, an attacker could spoof a response to the 333 correspondent node since it will know the transaction identifier 334 of the query. If a correspondent node receives a response with a 335 positive acknowledgement followed by a response with a negative 336 acknowledgement, the correspondent node MUST accept the negative 337 acknowledgement so long as it's within the replay window. The 338 correspondent node MAY defer sending packets on the new binding 339 in order to give the intended recipient an adequate amount of 340 time to respond. This leads to a potential denial of service 341 attack, but only leads to degraded service due to having to do 342 triangular routing. 344 2.3.3 Attacks by Rogue Correspondent Nodes 345 Since there is no direct authentication between the home agent and 346 the correspondent node it may be possible for a rogue correspondent 347 node to capture a legitimate signed and fresh cookie from the mobile 348 node and either act as a man in the middle or just mount an active 349 eavesdropping attack. Such an attacker could in theory obtain the 350 verification key and use that verification key to generate signed and 351 fresh binding updates to the victim correspondent node. Note that the 352 key used to generate cookies between the mobile node and its home 353 agent is not at risk from this attack. 355 This attack requires a fair degree of sophistication and can only be 356 mounted by an attacker on the routing path between the mobile node at 357 the correspondent node. To be successful, an attacker would first 358 need to be able to capture the fresh cookie from the mobile node's 359 binding update and not only spoof the Binding Update Query to the 360 home agent, but also receive the response. Only then could it create 361 bogus cookies, and even then it would only allow it to create bogus 362 cookies to the victimized correspondent node. 364 2.4 Message Flow from Mobile Node to Home Agent 366 MN CN HA 367 ---------------------------------------------------------------------- 369 0 <===============================================================> 370 normal HA/MN security association establishment 372 1 ----------------------------------------------------------------> 373 BU+cookie[mn,ha] 375 2 <---------------------------------------------------------------- 376 BU_ACK+cookie[ha,mn] 378 Step_0 The mobile node and its home agent create a security associa- 379 tion. In addition to the keys generated for the base security 380 association, another set of keys derived from the SA's keys are 381 generated by both the mobile node and the home agent. In addi- 382 tion, a session identifier is also devived by both the home 383 agent and the mobile node. The derivation functions are 384 described in section 4. 386 Step_1 When the mobile node discovers that it needs to send a binding 387 update to its Home Agent, it creates a cookie to be placed in 388 the binding update. The cookie contains a keyed hash over the 389 contents of the binding update described in section 5. The lone 390 cookie in this case is generated for the home agent. The 391 mechanism for generating the key for the correspondent node is 392 described in section 4. 394 Step_2 The Home Agent receives the binding update and verifies the 395 cookie in the same manner as when it receives it in the binding 396 update query message. In response, the Home Agent places a 397 cookie in the binding update acknowledgment created in the same 398 manner as the mobile node. This is used by the mobile node to 399 verify that the Home Agent produced the acknowledgment. 401 2.5. Home Agentless Operation 403 It should be observed that the basic trust arrangement being enforced 404 by this memo is the return routability. While this property can be 405 enforced by a mobile node's home agent and has some desirable charac- 406 teristics such as the possibility of a disinterested third party in 407 the verification process of a binding update, this property cannot be 408 relied upon. The reason is simple: there may not be a Home Agent in 409 the path between the a supposedly mobile node and the correspondent 410 node. Also: since we are using a shared key between the home agent 411 and mobile node and the correspondent node has no means to determine 412 whether the home agent or correspondent node created the message in 413 question. This is a direct consequence of not having strong third 414 party authentication. 416 However, this could be viewed as a feature. If a Home Agent is not 417 willing or unable to authorize binding updates, we can still use the 418 mobile node itself to provide the base level return routability. In 419 fact, there are many schemes which provide this kind of test, so this 420 memo is hardly unique in that respect. For completeness, this memo 421 provides the protocol machinery which for that which was inevitable 422 consequence of the protocol. 424 MN CN 425 HA 426 ---------------------------------------------------------------------- 428 0 <===============================================================> 429 normal HA/MN security association establishment 431 1 --------------------------------> 432 BU+cookie[mn,ha]+cookie[mn,cn] 434 2 <--------------------------------- 435 BU_QUERY+cookie[mn,ha]+PK[cn] 437 3 ---------------------------------> 438 BU_QUERY_RESP+E(key[mn,cn],PK[cn]) 440 4 [ <---------------------------- ] 441 [ BU_ACK ] 443 ~~~~~ 444 ~~~~~ 446 5 --------------------------------> 447 BU+cookie[mn,ha]+cookie[mn,cn] 449 6 <-------------------------------- 450 BU_ACK 452 Note that this flow is identical to the flow in section 2.1 with the 453 exception that the mobile node takes the place of the home agent. In 454 fact, since the "home agent" functionality is discovered in the rout- 455 ing path, there is no difference in implemenation on the correspon- 456 dent node's part. Also: the mobile node may, like the home agent, 457 decide whether it wants to create a shared key with the correspondent 458 node if it supplies its public key. 460 In some sense, this memo is really just extends the base level return 461 routability test to potentially involve a disinterested third party 462 in the form of a real home agent. When the home agent is either miss- 463 ing or not willing to perform verification requests the mobile node 464 SHOULD expect that it will perform verification requests from time to 465 time. If it is incapable or unwilling to receive verification 466 requests, it MUST NOT send home agent cookies. 468 2.6. NAT Considerations 470 To understand NAT considerations, we use the following diagram to 471 describe the various possibilities of where NAT's may reside. Since 472 NAT's must do stateful inspection, we consider that the gateway from 473 which a message originates from behind a NAT is the same NAT that the 474 response will traverse. It should be noted up front that as currently 475 specified in [MOBILEIPV6], Binding Updates cannot traverse NAT's 476 whatsover when they are protected by [AH] since [AH] includes the 477 source address in its authenticator calculation. We also consider 478 that basic issues with [MOBILEIPV6] with NAT's such as the Alterna- 479 tive Care of Address binding update suboption are out of scope for 480 this discussion since they have considerations for mobile IPv6 in 481 general which need to be sorted out. 483 +------+ 484 | | 485 | HA | 486 | | 487 +------+ 488 -----N1------ 489 | 490 | +------+ 491 | | | 492 N2 | CN | 493 | | | 494 | +------+ 495 | 496 -----N3------ 497 +------+ 498 | | 499 | MN | 500 | | 501 +------+ 503 In addition, we consider the special case where the Home Agent and 504 Mobile Node are behind a single NAT; this will be denoted as N1+N3. 506 To illustrate the interactions of Mobile IP with NAT's, we first 507 declare as out of scope any situation which would produce a server 508 behind a NAT since this is not a well defined property of NAT's. Thus 509 the cases that seem important are: 511 MN->HA: MN behind N3 512 HA->MN: MN behind N3 513 CN->MN: CN behind N2, MN server behind N1 514 MN->CN: MN behind N1, CN server behind N2 515 CN->HA: CN behind N2 516 HA->CN: CN behind N2 518 MN This situation may occur if a mobile node finds itself roamed 519 into another network, but can only get a private address. It is 520 expected that NAT N3 will perform address translation on the 521 binding update's IP headers to reflect the proper address both 522 to the home agent and the correspondent nodes. This case poses 523 no additional issues for the methods described in this memo. 525 MN This case is probably the common case where a mobile device is 526 behind the same NAT as its home agent. This situation would 527 arise, for example, if a mobile device were roamed away from its 528 home, but still behind a NAT'ing firewall of a corporation. This 529 case poses no issues for the methods described in this memo. 531 CN In this case, the correspondent node is the client initiating a 532 conversation to the mobile node acting as a server. Since the 533 key agreement function between HA and MN for subsequent keys 534 which are given out to correspondent nodes is based in part on 535 the correspondent's apparent IP address, an identifier similar 536 to the session identifier is created so that the correspondent 537 node can always use the correct key. The main motivation here is 538 that the correspondent node might lose its NAT binding within 539 the lifetime of the key, and reacquire a new binding unbeknownst 540 to it. By using both the SessionID and CorrID to find the key, 541 this situation can be avoided. The only other consideration here 542 is that NAT N2 would need to translate and pass the Binding 543 Update Query Response back from the home agent. This is similar 544 to the considerations for ICMP ECHO REPLY messages. 546 MN This mode violates the "no servers behind NAT". We expect that 547 this is reasonable for the general case because a NAT may reap 548 any current address binding at any time unbeknownst to the 549 mobile node thus it is unlikely that a stable binding could for 550 the mobile node could be maintained. If it could, this memo 551 would not add any additional issues. 553 CN While this strictly violates the "no servers behind NAT" dictum, 554 there may be situations where this is actually a reasonable 555 scenario. Specifically, servers which are well known to the NAT 556 where the NAT is performing a load balancing function seem plau- 557 sible. This memo does not introduce any additional issues, how- 558 ever. 560 2.7. Comparison to Purpose Built Key Draft 562 Both this memo and draft-bradner-pbk-frame-00 are in agreement that 563 depending on a pervasive PKI for IP-address addresses to secure 564 Mobile IPv6 may be unwise, and that a means of securing binding 565 updates with weaker security properties should be considered. This 566 section tries to outline the difference in the approaches and their 567 different ramification without trying to draw any value judgements as 568 to which is preferable. For simplicity, the PBK draft will be 569 refered to as PBK and this memo will be refered to as COOKIE. 571 o PBK relies on the principle that authentication between two nodes 572 for the purpose of binding updates is not as important as insurance 573 that once a flow is initiated between two nodes, that it continue 574 to flow across binding updates. 576 COOKIE relies on a previously established security association 577 between the mobile node and the mobile node's home agent. 579 One ramification of PBK's approach is that there is an opportunity 580 for a "first in" attack where a spoofed initial binding update 581 could cause a denial of service attack for subsequent legitimate 582 binding updates. 584 o PBK does not rely on any third party infrastructure whatsoever. It 585 accepts the man in the middle risk inherent in authentication-less 586 schemes as an acceptible risk. 588 COOKIE relies on third party authentication, namely that of the 589 home agent. It uses the routing system provide a implicit means of 590 delivery to the proper home agent as opposed to explicit naming 591 mechanisms. 593 o PBK as current proposed requires public key operations on the ini- 594 tial binding and subsequent rebindings when the mobile node changes 595 care of addresses. It seems feasible that PBK can be modified to 596 remove the necessity for subsequent public key operations, however 597 the initial public key operation is always necessary. 599 COOKIE uses the security association between the home agent and the 600 mobile node to create further symmetric keys. In its simplest form 601 of operation, COOKIE does not require public key operations on 602 either the initial or subsequent binding updates. COOKIE does 603 require a public key encryption to transfer a key to the correspon- 604 dent node, but this is an explicit tradeoff of computation versus 605 message efficiency that can be made by the home agent and 606 correspondent node. 608 o COOKIE specifically delegates the problem of updating care of 609 addresses to the mobile node. Since a mobile node may, in fact, be 610 a mobile router it is important to consider the affect on the 611 potentially non-mobile hosts behind the mobile router. COOKIE in 612 particular does not require any special action on the part of non- 613 mobile hosts behind a mobile router. It's action is similar in 614 nature to any other router sending advice on the reachability of 615 the subnets it subtends. The actual authorization for mobile 616 subnets is implicit between the mobile router and its home agent, 617 and as has been previously discussed, can be made into a local pol- 618 icy matter. 620 It is unclear how the PBK draft would view the mobile router issue. 622 o [placeholder for futher comparisons............] 624 3. Home Agent Discovery 626 [MOBILEIPV6] describes a means for a mobile node to discover its home 627 agent. This is known as the Home Agent Discovery ICMP message and is 628 sent to the Home Agents Anycast address. When the HAV bit is set in 629 the home agent cookie, the correspondent node MUST form the home 630 agent anycast address by appending the subnet prefix of the source 631 address with the Home Agent Anycast address in [MOBILEIPV6]. The 632 binding update verification request message is, in fact, Home Agent 633 Discovery message with the home agent cookie appended. See section 6 634 for details. 636 3.1 Verification Without the Home Agent 638 If the HAV bit is not set, the correspondent node may perform a 639 verification directly with the mobile node. To do this, the 640 correspondent node simply addresses the binding update verification 641 request to the mobile node instead of the home agent anycast address. 642 The mobile node MUST process the message in this case. 644 4. Key Derivation 646 [this entire section needs more work. it should be 647 viewed as a general means to arrive at shared 648 keys. /mat] 650 This scheme derives keys by employing the base keying material which 651 was used to create a security association between the a mobile node 652 and its home agent. We append identifying information as well as an 653 iterator to generate enough keying material. The entire string is 654 hashed using MD5 to create the new keying material. 656 The keying material is generated as follows: 658 iterator = 0; 659 newkey [iterator] = 660 MD5(key[mn,ha]+ip_addr[targ]+SessionID+iterator); 661 iterator++; 662 newkey [iterator] = 663 MD5(key[mn,ha]+ip_addr[targ]+SessionID+iterator); 664 [...] 666 Where "targ" is the 128 bit IP address of the target of the cookie, 667 and key[mn,ha] is the shared key between the mobile node and the home 668 agent. "Interator" is a 32 bit integer, and "SessionID" is the Ses- 669 sionID described below. 671 The iteration function is performed as many times as is required to 672 generate enough keying material to encrypt and sign the cookies. For 673 128 bits of keying material for use with MD5, a single crank of the 674 generating function is needed. If 256 bits of keying material is 675 needed, two cranks of the generating function is necessary and so on. 677 sp 678 4.1 Session and Correspondent Identifiers 679 In order to work properly through NAT's and other situations where 680 the home address may not be globally unique, a keyed hash of the home 681 address is generated instead of using the IP address directly. This 682 identifier is generated simultaneously by the Home Agent and the 683 Mobile Node each time they establish a shared secret. The mechanism 684 to generate the session identifier is: 686 sessionID = MD5(key[mn,ha]+home_address[mn]); 688 Where "key" is the key that will be used by the mobile node to gen- 689 erate cookies to the home agent, and "home_address" the home address 690 of the mobile node for this home agent. IPv4 addresses would use the 691 IPv6 address range dedicated to IPv4 address as described in 692 [ADDRARCH]. 694 In addition, to avoid missynchronization problems with key genera- 695 tion, especially if the correspondent node loses a NAT binding, we 696 creates a hash to identify the correspondent node for subsequent com- 697 munication. 699 corrID = MD5(key[mn,ha]+dest_address[cn]); 701 The corr 703 4.2 Key Schedules 704 It is necessary to allow keying material to be periodically 705 refreshed. When the mobile node and the home agent rekey their secu- 706 rity association, the mobile node MUST refresh the keying material 707 used to create cookies, as well as creating a new session identifier. 708 The mechanism used to refresh keying material is simply to start 709 sending new cookies based upon a different session ID. Since the 710 correspondent node will not have a binding for that session ID, it 711 will as in normal operation send the Binding Update Query message 712 toward the mobile node's home agent. 714 To expediate generation of the keying material, the mobile node MAY 715 proactively send a binding update with a cookie reflecting the new 716 session ID. 718 5. Encryption, Authenticators, Replays and Conformance 720 Cookies are actually keyed authenticators. This section describes how 721 the checksums are generated and verified. To generate a cookie 722 authenticator, the hashing algorithm is run over the entire Binding 723 Update except with all of the checksums in the cookie suboptions 724 zeroed. The hashing algorithm is then run over the binding update and 725 is then XOR'ed with the key this cookie is bound to. If the length of 726 the autheticator is longer than the length of the key, the key should 727 be XOR'ed with the subsequent parts of the authenticator interatively 728 with the last fraction of the authentictor padded with zeros as 729 necessary. 731 [is this totally bogus? need to get out a crypto 732 book to do this right. mainly trying to capture 733 the needs of the unkeyed digest to the HA /mat] 735 To verify a cookie, the same process is undertaken and the contents 736 of the checksum for that cookie are compared. If they are equal, the 737 verify operation succeeds. In the special case of the Binding Update 738 Query, the correspondent node computes the hash of the binding update 739 and places it in the Binding Update Query message. The Home Agent 740 removes the checksum, performs the key XOR as above, and completes 741 the verification against the cookie's checksum. 743 5.1 Public Key Encryption 745 [describe how the symmetric key is encrypted using the 746 public key supplied in the BUQ] 748 [In general, we may just want to use DH here to generate a shared 749 secret between the HA and CN instead of doing public key encryption. 750 Honestly, it's whichever is cheapest since there isn't any 3rd party 751 authentication between HA and CN. There are legitimate questions of 752 DoS attacks against HA's. Since we aren't requiring the HA to sign 753 anything, it's not quite as bad as standard PK make-work DoS attacks 754 since public key encryptions aren't as expensive 755 signatures/decryptions. Also, we have the fact that the cookie must 756 be verified successfully, and since this uses relatively cheap sym- 757 metric key crypto, it would seemingly only open a DoS opportunity 758 during the replay window which doesn't seem very credible.] 760 5.2 Crypto Conformance 762 To insure interoperability, the following crypto algorithms MUST be 763 supported: 765 All: [MD5], [SHA-1] 767 The following SHOULD be supported by the correspondent node and Home 768 Agent: 770 HA, CN: [RSA-1024] 772 [should we specify ECC as a SHOULD too? it's a lot cheaper /mat] 774 5.3 Replay Attacks 776 There are several notable replay attacks present in this memo. We 777 will first describe the attacks, describe the method to detect 778 replays, and then describe the method to counter the attacks. 780 The first attack is between the mobile node and the correspondent 781 node. If an attacker captures a Binding Update, it may at a later 782 time replay the legitimate Binding Update causing the correspondent 783 node to erroneously use a stale care of address. 785 The next attack is a potential make-work attack against the home 786 agent. If a legitimate Binding Update Query message is replayed -- 787 especially if the correspondent node has requested a key to be gen- 788 erated -- the home agent may perform unnecessary public key opera- 789 tions. 791 The last attack is against the correspondent node. If an attacker 792 replays a binding update query response, it may needlessly perform 793 expensive public key decryptions. 795 5.3.1 Home Agent to Correspondent Node Attack 796 This attack is easy to counter. The correspondent node places a 797 unique XID in the Binding Update Query message and only accepts Bind- 798 ing Update Query Responses for XID's for which it has not received a 799 reply. 801 5.3.2 Cookie Replay Detection 803 Each cookie contains a sequence number. The mobile node generates an 804 initial sequence number of its choice for each new key it generates. 805 The destination (either Home Agent of Correspondent Node) MUST accept 806 the initial sequence number when it see a new key, and it MUST store 807 the current sequence number. The mobile node MUST insure that subse- 808 quent cookies generated are monotonically incrementing and MUST NOT 809 wrap around. The receiver MUST first check the validity of the 810 cookie and them MUST check its current sequence number. It MUST NOT 811 accept packets which are less than or equal to the current sequence 812 number. If a sequence number jumps forward non-monotonically but is 813 otherwise valid, the receiver MUST adjust its sequence number as well 814 and reject any stale packets. 816 5.3.3 Correspondent Node to Home Agent Attack 818 If the Home Agent detects a replay, it may in fact just be a 819 retransmission of a binding update query. Since the Correspondent 820 Node cannot recreate the cookie itself, the Home Agent SHOULD keep a 821 replay cache of Binding Update Query Responses to accommodate normal 822 retransmissions. The Home Agent prunes its replay cache by both a 823 timer based method, as well as deleting cached responses for which a 824 newer message sequence number has been detected. 826 5.3.4 Mobile Node to Correspondent Node Attack 828 For this type of replay, the Correspondent Node upon detection of a 829 replay MUST ignore the binding update as it is likely an attack. The 830 Mobile Node MUST NOT send cookies with the same sequence number. 832 6. Message Formats 834 6.1 Cookies 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | | 840 | | 841 | SessionID | 842 | | 843 +-------------------------------+-------------------------------+ 844 | | 845 | | 846 | CoorID | 847 | | 848 +-------------------------------+-------------------------------+ 849 | Sequence | 850 +---------------+---------------+-+-+-----------+---------------+ 851 | CksumLen | CkAlgorithm |H|A| Resv | 852 +---------------+---------------+-+-+-----------+---------------+ 853 | | 854 ~ Cksum ~ 855 | | 856 +-------------------------------+-------------------------------+ 858 Figure 1: Cookie Format 860 SessionID The Session ID is genererated as in section 4.1 862 CorrID The CorresponentID as genererated as in section 4.1 and is 863 used by the correspondent node to select the proper key if it 864 previously requested a key in a binding update query. To 865 select the proper key, the correspondent node MUST select the 866 key based on both the SessionID and the CorrID. 868 Sequence A monotonically incrementing number whose initial sequence is 869 set by the mobile node. See section 5.3 871 CksumLen The length of the authenticator 873 CkAlgorithmThe hashing algorithm used to compute the checksum as speci- 874 fied by [AH? IKE?]. 876 H H is the Home Agent flag. If the cookie is destined for the 877 Home Agent, this flag is set, otherwise it is zero. 879 A A is the Home Agent Anycast flag. When this flag is set, the 880 correspondent node MUST send the binding update query to the 881 home agent anycast address instead of directly to the mobile 882 node. 884 Resv Reserved for future use. 886 Cksum The checksum over the entire binding update. 888 6.2 Cookie Suboption 890 The Cookie Suboption is used for both binding updates as well as 891 binding update acknowledgments when a home agent wants to send the 892 mobile node a cookie. 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | | length | 898 +---------------+---------------+---------------+---------------+ 899 | | 900 ~ Cookie ~ 901 | | 902 +-------------------------------+-------------------------------+ 904 Figure 2: Binding Update Cookie Suboption 906 Cookie The cookie destined for the home agent that the correspondent 907 node received from the mobile node 909 6.3 Binding Update Query 911 The binding update query is in the home agent discovery ICMP message 912 as described in [MOBILEIPV6] with the addition of the cookies, etc 913 for the query. When used as a discovery message and cookies are not 914 present, the cookie, checksum and public key lengths must be set to 915 zero. 917 [mat: I've extended Identifier to 32 bits here? is that bogus 918 in ICMP? It would be better to have more to make guessing 919 attacks harder] 921 0 1 2 3 922 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Type | Code | Checksum | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Identifier | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | | 930 + Reserved + 931 | | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | | 934 + + 935 | | 936 + Home Address + 937 | | 938 + + 939 | | 940 +---------------+---------------+---------------+---------------+ 941 | CookieLen | CkSumLen | PKAlgorithm | PKlen | 942 +---------------+---------------+---------------+---------------+ 943 | | 944 ~ Cookie ~ 945 | | 946 +-------------------------------+-------------------------------+ 947 | | 948 ~ CkSum ~ 949 | | 950 +-------------------------------+-------------------------------+ 951 | | 952 ~ PublicKey ~ 953 | | 954 +-------------------------------+-------------------------------+ 956 Figure 3: Binding Update Query 958 Type 960 Code 0 962 Checksum The ICMP checksum [5]. 964 IdentifierAn identifier to aid in matching Binding Update Query Reply 965 messages to this Binding Update Query message. 967 Resv Reserved bits 969 CookieLen The length in octets of the cookie. 971 CkSumLen The length in octets of the checksum. 973 PKAlgorithmThe Public Key encryption algorithm used. [reference 974 ISAKMP/IKE IANA numbers /mat] 976 PKlen The length in octets of the public key. 978 Cookie The cookie destined for the home agent that the correspondent 979 node received from the mobile node 981 CkSum The checksum is generated by the correspondent node by running 982 the hashing algorithm specified in the cookie. This is not a 983 keyed hash. The home agent verifies this hash against the 984 checksum in the cookie as described in section 5. [this is in 985 lieu of sending the whole BU /mat] 987 PublicKey The public key that the correspondent node desires to have the 988 key encrypted with. 990 6.4 Binding Update Query Response 992 0 1 2 3 993 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 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Type | Code | Checksum | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Identifier | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | AddressLen | Reserved | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | Reserved | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | | 1004 + + 1005 . . 1006 . Home Agent Addresses . 1007 . . 1008 + + 1009 | | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | ResponseCode | EAlgorithm | Elen | 1012 +---------------+---------------+---------------+---------------+ 1013 | | 1014 ~ Encrypted Key ~ 1015 | | 1016 +-------------------------------+-------------------------------+ 1018 Figure 4: Binding Update Query Response 1020 Type 1022 Code 0 1023 Checksum The ICMP checksum [5]. 1025 IdentifierAn identifier to aid in matching Binding Update Query Reply 1026 messages to this Binding Update Query message. 1028 Resv Reserved bits 1030 AddressLenThe length in bytes of the home agent addresses that follow. 1032 Home A list of addresses of home agents on the home link for the 1033 mobile node. 1035 ResponseCode 1036 The response for the BindingUpdateQuery. Currently defined 1037 responses are: 1039 VALID: 1040 The cookie was valid 1042 INVALID: 1043 The cookie was invalid for some reason 1045 EXPIREDSID: 1046 The session id has expired [what does the CN do??? /mat] 1048 EAlgorithmThe public key encryption algorithm used as defined in [IKE] 1049 for the keying material supplied. 1051 Elen The length in octets of the encrypted key. 1053 EncryptedKey 1054 The symmetric key that the correspondent node should use to 1055 authenticate subsequent binding update messages with 1056 correspondent node cookies in them. 1058 7. Processing Considerations 1060 To minimize work, the following section describes some of the con- 1061 siderations that should be taken into account when implementing this 1062 memo. 1064 8. Security Considerations 1066 This entire memo is aimed at fulfilling the security considerations 1067 of [MOBILEIPV6]. There are a few other considerations which bear 1068 mentioning. Because of the desire to traverse NAT's, strong one-way 1069 hashes are performed to create identifiers which are used instead of 1070 directly using IP addresses. While these identifiers ought to be 1071 unique in practice, it is remotely possible that the same identifier 1072 created by one mobile node is collides with another mobile node on 1073 the same correspondent node. We note that the same considerations 1074 apply to [PBK]. The net result of such a collision is that a verify 1075 operation -- either locally at the correspondent node, or at the home 1076 agent will fail for the new mobile node requesting a binding cache 1077 update. This will only result in the second mobile node not being 1078 able to create a binding cache entry which will result in triangular 1079 routing for the losing mobile node. Given the remoteness of the pos- 1080 sibility, this does not seem to be a large problem. 1082 References 1084 [MOBILEIPV6] 1085 Mobile IP Working Group, D. Johnson, C. Perkins, "Mobility Support 1086 in IPv6" draft-ietf-mobileip-ipv6-03.txt 1088 [IPSEC] 1089 The IPsec Working Group, S. Kent, R. Atkinson, "Security Architec- 1090 ture for the Internet Protocol", RFC 2401, November 1998 1092 [IKE]The IPsec Working Group, D. Harkins, D. Carrel, "The Internet Key 1093 Exchange", RFC 2409, November 1998 1095 [PBK]Mobile IP Working Group, Bradner, Mankin, Schiller, "A Frameworks 1096 for Purpose Built Keys (PBK)" draft-bradner-pbk-frame-00.txt 1098 Author's Address 1100 Michael Thomas 1101 Cisco Systems 1102 375 E Tasman Rd 1103 San Jose, Ca, 95134, USA 1104 Tel: +1 408-525-5386 1105 email: mat@cisco.com 1107 Dave Oran 1108 Cisco Systems 1109 375 E Tasman Rd 1110 San Jose, Ca, 95134, USA 1111 email: oran@cisco.com