idnits 2.17.1 draft-nikander-ipng-address-ownership-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 816 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 57 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** 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 169: '...itionally, IPsec MAY be used to protec...' RFC 2119 keyword, line 188: '...itionally, IPsec MAY be used to protec...' 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 (February 2001) is 8471 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) == Unused Reference: 'RFC2401' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'RFC2473' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC2894' is defined on line 600, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-13 == Outdated reference: A later version (-02) exists of draft-arkko-manual-icmpv6-sas-00 -- Possible downref: Normative reference to a draft: ref. 'ICMP-IPSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'Nikander01' Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT P. Nikander 2 Ericsson NomadicLab 3 Expires September 2001 February 2001 4 Track: Informational 6 An Address Ownership Problem in IPv6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document seeks to clarify a number of problems related to 32 authorization of changing local routing information in the current 33 IPv6 architecture. This document does not (currently) cover actual 34 routing protocols. Instead, in IPv6, there are a number of 35 additional mechanisms that allow local routing information to be 36 changed. Some mechanisms are meant to be used only locally, while 37 someof them allow changes to be initiated from a remote location; 38 in the latter case, IPsec is used to protect the relevant 39 signalling messages. However, the current specifications are 40 partially obscure about the actual authorization requirements that 41 must be met in order to be actually secure. The purpose of this 42 document is to clarify the situation, and foster understanding of 43 the potential attacks and required countermeasures. 45 In this document, we first collect together and summarize the 46 non-routing-protocol mechanisms that allow routing information to 47 be changed. After that, we classify the mechanisms using a couple 48 of orthogonal dimensions. Finally, we discuss the authorization 49 requirements for the different mechanisms. 51 It is important to note that the security problems discussed in 52 this document become relevant only when we start to consider 53 multiple security domains. As long as the mechanisms are used only 54 within a single security domain, where all nodes are equally 55 trusted, the problem does not exist. However, if several security 56 domains are connected together, or if anything like "opportunistic 57 IPsec", as promoted by John Gilmore, becomes reality, the problems 58 discussed in this document will become very real. 60 An other way of expressing the scope of the problems is to say that 61 the attacks can be characterized as insider attacks. In general, 62 the IPsec architecture, as it stands today, is relatively good in 63 keeping outsiders out. However, it is currently not nearly as good 64 at dealing with attacks from within. In a way, when IPsec is used 65 to protect application level traffic, the applications are assumed 66 to take care of their specific protection needs, e.g., in the form 67 of user names, passwords, and application or operating system 68 access control lists. Unfortunately, when IPsec is used to protect 69 traffic signalling, as discussed in this document, the controls do 70 not seem to be adequate. Basically, this is an authorization 71 problem. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 76 2. Mechanisms for Changing Routing Information . . . . . . . . . . 77 2.1. ICMP Router Discovery . . . . . . . . . . . . . . . . . . 78 2.2. ICMP Redirect . . . . . . . . . . . . . . . . . . . . . . 79 2.3. Generic and IPsec Tunneling . . . . . . . . . . . . . . . 80 2.4. Router Renumbering . . . . . . . . . . . . . . . . . . . 81 2.5. Reversing Routing Header . . . . . . . . . . . . . . . . 82 2.6. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 83 2.7. Inverse Neighbour Discovery . . . . . . . . . . . . . . . 84 2.8. SCTP and address sets . . . . . . . . . . . . . . . . . . 85 3. Classifications of the Mechanism . . . . . . . . . . . . . . . 86 3.1. Locality of origination . . . . . . . . . . . . . . . . . 87 3.2. Extent of effect . . . . . . . . . . . . . . . . . . . . 88 3.3. Classification summary . . . . . . . . . . . . . . . . . 89 4. Authorization requirements . . . . . . . . . . . . . . . . . . 90 4.1. ICMP Router Discovery and Redirect . . . . . . . . . . . 91 4.2. Inter-domain tunneling, Binding Updates, and Routing 92 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.3. Proving address ownership when dynamically creating SAs . 94 5. Security and Privacy Considerations . . . . . . . . . . . . . . 95 6. Intellectual Property Right Notice . . . . . . . . . . . . . . 96 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 97 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99 Appendix A. An address "stealing" attack example . . . . . . . . . 100 Appendix B. A crypto oracle attack example . . . . . . . . . . . . 102 1. Introduction 104 The basic routing and packet forwarding mechanisms in IPv6 are 105 supposed to be similar to those of IPv4. However, there are 106 considerable differences in the mechanisms how the hosts and 107 routers learn and alter the information used for constructing the 108 actual routing tables entries and other related data structures. 109 The differences are especially large when considering individual 110 hosts, but there are also differences in the way the routers are 111 supposed to be configured. When compared to the current practise 112 in IPv4, the distribution and discovery of this routing information 113 is planned to be highly dynamic in IPv6. While this dynamic 114 approach makes network administration much easier, it is also a 115 potential source of a number of security vulnerabilities. The 116 purpose of this document is to clarify the current situation from 117 the security point of view. 119 Particularly problematic are the cases where a remote node is able 120 to establish exceptions to the default routing rules. The Mobile 121 IPv6 Binding Update (BU) is a prime example of this; with a Binding 122 Update, a remote node may inform any other node that all traffic 123 sent to the remote node's home address should be currently sent to 124 another address, the so called care-of-address. Unless properly 125 authorized, this and other related mechanisms are potential sources 126 of impersonation, man-in-the-middle, and denial-of-service attacks. 128 2. Mechanisms for Changing Routing Information 130 In this section, we discuss a number of mechanisms that allow 131 modification of the effective routing information in IPv6 nodes. 132 The focus on mechanisms that have effect on hosts, but some router 133 related mechanisms are also discussed. It should be noted that not 134 all of these mechanisms are supposed to make changes to the actual 135 routing tables (e.g. Destination Cache) but that some specify the 136 desired alternations in terms of additional data structures. The 137 end effect, however, is always that the effective next hop of for a 138 host or a prefix is changed. 140 2.1. ICMP Router Discovery 142 In IPv6, hosts are able to dynamically learn the identity and 143 abilities of local routers dynamically [RFC2461]. Basically, the 144 hosts listen to Router Advertisement messages, and alter their 145 routing information as specified in Section 6.3.4. of RFC2461. 147 The specification describes the relevant information in terms of a 148 Prefix List and a Default Router List. Basically, the Prefix List 149 contains IPv6 address prefixes that are considered to be on-link, 150 or directly reachable via a physical or pseudo interface. All 151 other IPv6 address prefixes are considered to be off-link, 152 requiring that a router must be selected to forward the packets. 153 The Default Router List contains routers that are directly 154 reachable. The suggested way of using the Router List is to select 155 routers from the Router List in a round robin fashion for new 156 destinations. 158 When a Router Advertisement is received, the host updates its 159 Prefix List and Default Router List. Basically, this allows the 160 sender of the Router Advertisement to create new local routes and 161 new default routes. Consequently, a simple way of launching a 162 denial-of-service attack is to claim that a specific prefix is 163 on-link even if it is not. As a result, the host will try to learn 164 the link-level address of the destination trough Neighbor 165 Discovery, and fail. More advanced attacks are easy to imagine. 167 A basic level of security is achieved by requiring that Router 168 Advertisement messages must have been locally sent (RFC2461 169 Section 6.1.2.). Additionally, IPsec MAY be used to protect Router 170 Advertisements. Unfortunately, such a practice seems to be quite 171 hard in reality; see [ICMP-IPSEC] for relevant discussion. 173 2.2. ICMP Redirect 175 The purpose of the ICMP Redirect [RFC2461] is to inform a host that 176 a particular destination is better reachable through a different 177 router or that the destination happens to be on-link. In effect, a 178 Redirect creates a host specific routing table entry, specifying 179 the next hop for the specific address. 181 A basic level of security is achieved by requiring that Redirect 182 messages must be have been locally sent, the IP source address of 183 the Redirect is the same as the current default router, the 184 destination address is not a multicast address, and that the target 185 address is a link local address of a local router or that the 186 target address is the destination address, informing that the 187 destination is actually at the local link (RFC2461, Section 8.1). 188 Additionally, IPsec MAY be used to protect the Redirect messages. 190 2.3. Generic and IPsec Tunneling 192 RFC2473 specifies a generic tunneling mechanism for IPv6. 193 Currently there are no automatic mechanisms defined for creating 194 Generic Tunnels. Thus, all Generic Tunnels are supposed to be 195 created though administrative actions. However, at the endpoints, 196 a Generic Tunnel is handled as a standard interface. Thus, it is 197 possible to send local ICMP packets through a tunnel to the other 198 tunnel endpoint. Together with Router Advertisement and ICMP 199 Redirect, this may cause unwanted behaviour unless care is taken to 200 screen the packets received from the tunnel. 202 RFC2401 specifies IPsec tunnel mode. Opposed to Generic Tunneling, 203 IPsec tunnels may be automatically created as a result of IKE 204 negotiation. This creates some potential vulnerabilities. First, 205 care must be taken that IPsec tunnels are only created to 206 authorized destination subnets; a tunnel creates a routing entry 207 for the specified subnet, leading to similar attacks outlined 208 above. Second, care must be taken to specify the local IKE 209 policies in such a way that the tunnel cannot be used as a source 210 of launching other attacks outlined in this document. 211 Specifically, the SPD rules should be configured in such a fashion 212 that undesired ICMP messages are not accepted from the tunnel exit 213 point. In a way, this latter problem is just one specific case of 214 a larger problem. That is, the IP nodes should be able to handle 215 received ICMP packets differently depending on which interface 216 (physical or virtual) they were received through. 218 Thus, from the routing information point of view, the ability to 219 automatically create IPsec tunnels with IKE seems to create a new 220 potential vulnerability. Depending on the way policy management is 221 implemented in the IKE, it may be possible to create tunnels that 222 inappropriately divert traffic. That is, if the implementation 223 does not sufficiently bind the credentials of IKE Phase 1 with the 224 client identifiers presented in IKE Phase 2, it may be possible to 225 divert IP traffic to a "wrong" tunnel. 227 2.4. Router Renumbering 229 RFC2894 specifies a method for instructing a number of routers to 230 be dynamically configured and reconfigured. All Router Renumbering 231 (RR) packets must be authenticated with IPsec. The specification 232 suggests that the relevant SAs ans SPD entries are created 233 manually, and that the SPD entries explicitly allowing RR ICMP 234 messages. If implemented properly, the suggested practice seems to 235 be appropriate. 237 However, care must be taken as there seems to exist at least two 238 related potential vulnerabilities. First, unless the default 239 policy for _other_ SAs and related SPDs is to drop RR ICMP 240 messages, it may be possible to make the router to accept 241 unauthorized RRs. In particular, the default set of SPD and SAD 242 entries defined in Section 7 of RFC2894 does not seem to make any 243 distinction between SAs that are authorized to send RRs and other 244 SAs. This may be sufficient if the router does not have Security 245 Associations with any other nodes but those authorized to send RRs. 246 However, if that is not the case, or if the router may create SAs 247 dynamically with IKE, the policy is not sufficient. The alternate 248 policy of explicitly specifying SPD and SAD for each management 249 station and/or trusted routers' unicast addresses, together with a 250 separate default SPD/SAD entry discarding the rest of traffic, 251 seems to be sufficient. 253 In our humble opinion, a basic problem in RFC2894 is the failure of 254 explicitly classifying the Security Associations into ones trusted 255 as sources of RRs and ones not trusted so. Especially in the IPv6 256 world, the source address does not necessarily have any security 257 relevance [Nikander01]. From the security point of view, the 258 sender of the RR must be authorized as well as authenticated. This 259 is especially true if an untrustworthy attacker could pass an 260 authentication challenge, but still mount an attack against the 261 router by sending RR's for which it is not authorized. 263 The second related potential vulnerability may be created through a 264 a use of dynamic SAs, i.e., if IKE and/or a future multicast key 265 agreement protocol is used. Unless the management protocol 266 requires proper authorization when creating new SAs, the result may 267 be SAs that inappropriately allow RRs to be applied. 269 2.5. Reversing Routing Header 271 In Section 8.4 of RFC2460, the cases when a Routing Header may be 272 reversed are specified. As the specification stands today, if a 273 received packet has been authenticated and integrity protected with 274 IPsec, the reply packets may carry a reversed routing header. 276 The intention of the specification seems to be that reversed 277 routing headers are never cached. Thus, they do not directly 278 change the permanent routing information within the host. However, 279 depending of the actual host implementation, a number of 280 vulnerabilities may be exposed. 282 First, an otherwise passive attacker may effectively turn itself 283 into an active one by replying sending packets with authenticated 284 routing headers. That is, a passive attacker is able to eavesdrop 285 communication, but it may be inable to effectively block it. 286 However, using authenticated routing headers, it may be able to 287 send forged packets in such a way that the replies are sent back 288 directly to it. As a result, the original destination will not 289 receive these replies, making it much harder for it to detect the 290 attack. 292 Second, depending on the way the routing header handling and IPsec 293 interact with each other at the end host, authenticated routing 294 headers may be used to make a remote host to act as a cryptographic 295 oracle (see Appendix B). Other attacks may also be possible. 297 2.6. Mobile IPv6 299 In Mobile IPv6 [MIP6], a Mobile Node (MN) may send a Binding Update 300 (BU) to any host it communicates with. Customarily, the other host 301 is called the Correspondent Node (CN). Basically, the BU creates a 302 temporary routing table entry specifying that all traffic sent to 303 the MN's so called home address is sent to its so called 304 care-of-address (CoA). In Mobile IPv6 terminology, such routing 305 table entries are called Binding Cache entries. The BU must be 306 authenticated and integrity protected with AH. 308 A vulnerability may be created if the CN has separate AH SAs with 309 several independent nodes. Unless the CN properly checks that the 310 MN sending a BU is actually authorized to specify new routing 311 information for the claimed home address, any host (that has an SA 312 with the CN) may be able to create arbitrary new Binding Cache 313 entries. 315 At the IPsec level, the proper way to address the situation is to 316 record the home addresses for each SA and to make sure that Binding 317 Updates are only accepted for the recorded home address. The 318 current situation effectively depends on the implementation. The 319 specification requires that the Home Address Destination Option is 320 inserted in the packet _before_ the AH header. This, in a typical 321 implementation the Home Address Destionation Option is processed 322 before AH, thereby making sure that the AH processing finds the 323 home address in the IP header source address field. Respectively, 324 a Binding Update is placed on a separate Destination Option header 325 inserted _after_ the AH header, and therefore typically processed 326 after AH processing. 328 Now, if the IPsec implementation is strict in its policy filtering, 329 and if the SPD rule associated with the SA only allows packets from 330 a single specified source address, then the rules in Section 331 8.2. of [MIP6] make sure that the Binding Update actually applies 332 to the address specified in the SPD rule. That is, since the Home 333 Address Destination Option is processed before AH, the AH 334 processing passes or drops the packet based on the home address, 335 only passing packets whose home address equals with the allowed 336 source address specified in the SPD Entry. As a result, the BUs 337 will be processes only in packets whose Home Address Destionation 338 Option has positively matched with the expected source address, as 339 specified in the SPD. 341 The vulnerability is exposed if the SPD filtering is not performed 342 correctly, or if the SPD rule allows more than a single source 343 address. In the latter cases, the hosts passed by the SPD rule may 344 modify the Binding Update entries for each other. 346 The larger problem becomes apparent once we consider how the SAs 347 and SPDs are created. As long as Mobile IPv6 is used within a 348 single administrative domain, the problem does not become 349 apprarent. However, as a part of the Mobile IPv6 motivation, it is 350 noted that at least a substantial factor of IPv6 hosts are assumed 351 to be mobile. Therefore, it would be important that Mobile IPv6 352 can be used between any CN and MN. Indeed, in Section 2. of [MIP6] 353 it is stated that "integration of Route Optimization functionality 354 allows direct routing from any correspondent node to any mobile 355 node, without needing to pass through the mobile node's home 356 network and be forwarded by its home agent, ..." 358 Thus, since MIP6 Binding Updates are assumed to be used between any 359 CN and MN, it must be possible to create IPsec SAs between any CN 360 and MN. That may not be so easy. However, at least in theory, the 361 ability of running IKE between any nodes may be achieved through 362 various means, e.g., by establishing a global PKI, by using 363 "opportunistic IPsec", etc. Unfortunately, as describe in Section 364 4. in detail, even a PKI is not necessarily enough in order to make 365 sure that the SPD entries have the right Home Address recorded. 367 2.7. Inverse Neighbour Discovery 369 [TBD.] 371 2.8. SCTP and address sets 373 [TBD.] 375 3. Classifications of the Mechanism 377 In this section, we classify the above discussed mechanisms. 378 First, in Section 3.1. we discuss the locality of the possible 379 origins of the packets. In Section 3.2. we classify the mechanisms 380 based on the extend of the effect of the mechanisms. Here the 381 extent denotes whether the mechanism effects a host's idea of whole 382 subnets or just single hosts. Finally, Section 3.3. contains a 383 table summarizing the classification 385 3.1. Locality of origination 387 The ICMP Router Discovery and Redirect mechanisms are designed to 388 be available only to nodes on-link. However, inappropriate 389 tunneling may change the situation. 391 Generic Tunnels may currently only be created through 392 administrative actions. Thus, the source of origin is meant to be 393 a human administrator. 395 IPsec tunnels may be created automatically through IKE. In theory, 396 the peer node may be anywhere in the Internet. 398 Router Renumbering messages may be issued by any authorized node. 399 Consequently, the origin may potentially be anywhere in the 400 Internet. However, the obvious intent is to use RR only within a 401 single security domain. 403 Authorized Routing Headers may be used by anyone having an SA, and 404 SAs may be created with IKE with anyone in the Internet. Thus, 405 the potential scope of the origin is again the whole Internet. 406 Furthermore, they would be useful between security domains. 408 Mobile IPv6 Binding Updates are _meant_ to be sent by any Mobile 409 Node anywhere in the Internet, and having their home address 410 anywhere in the Internet. Thus, the locality of the source is the 411 whole Internet both in the actual BU level and in the level of SA 412 creation. Clearly, there is a strong need to use BUs between 413 security domains. 415 Inverse ND and SCTP are TBD. 417 3.2. Extent of effect 419 Router Discovery messages change hosts' idea of what prefixes are 420 local and what not. Thus, in the extreme, it may be used to claim 421 that all globally routable addresses are in fact local and on-link. 422 In the other end, Router Discovery may be used to claim that a 423 single address (/128 prefix) is on-link. 425 Redirect messages always affect routing for single hosts. 427 Tunneling mechanisms may be specified for various prefix lengths, 428 ranging, at least in theory, from /0 to /128. 430 Router Renumbering changes the routers' idea of prefixes. 432 Routing Header does not actually create permanent routing 433 information. It only affects the immediate reply packet. 435 A Mobile IPv6 Binding Update changes the routing information of a 436 single home address. 438 Inverse ND and SCTP are TBD. 440 3.3. Classification summary 442 \ Extent | Any prefix | Any prefix | Single | Reply | 443 Origin \ | in routers | in hosts | dest only | packet | 444 ---------------+------------+------------+-----------+----------+ 445 | | | | 446 Admin only | Generic Tunnels | | | 447 | | | | 448 ---------------+------------+------------+-----------+----------+ 449 | | Router | | | 450 On-link *) | | Discovery | Redirect | | 451 | | | | | 452 ---------------+------------+------------+-----------+----------+ 453 Internet, | Router | | | | 454 limited | Renumber, | IPsec | | | 455 domains | IPsec | tunnels | | | 456 | tunnels | | | | 457 ---------------+------------+------------+-----------+----------+ 458 Internet, | | | | Routing | 459 multiple | | | MIP6 BU | Header | 460 domains | | | | | 461 ---------------+------------+------------+-----------+----------+ 463 *) The mechanisms are designed to be available only on-link. 464 However, interaction with tunnels may make them available from 465 anywhere in the Internet. 467 4. Authorization requirements 469 In this section, we discuss the authorization requirements for the 470 mechanisms covered above. In this section we only cover the cases 471 where there are several security domains involved. In the case of 472 on-link mechanisms this means, in practice, that some of the nodes 473 are assumed to be potentially hostile towards the others. There 474 clearly are situations where this assumption may be appropriate, 475 e.g., public wireless LAN access. 477 Due to our exclusion of mechanisms intented to be used within a 478 single domain, or to be configured only manually, we only cover 479 ICMP Router Discovery and Redirect, inter-domain IPsec tunneling, 480 Mobile IPv6 Binding Updates, and reversable Routing Headers. 482 Our focus is on clarifying the requirements for dynamically 483 creating IPsec Security Associations for various purposes. 485 4.1. ICMP Router Discovery and Redirect 487 TBD. See also [ICMP-IPSEC]. 489 4.2. Inter-domain tunneling, Binding Updates, and Routing Headers 491 In the case of creating inter-domain tunnels, processing Mobile 492 IPv6 Binding Updates, and possibly even when reversing properly 493 authenticated and integrity protected Routing Headers, it becomes 494 important to check that the operation is properly authorized. 495 Let us consider the authorization requirements case-by-case. 497 - For inter-domain tunnels, the tunnel endpoint must know that the 498 other end is authorized for the addresses that it claims to be 499 reachable through the tunnel. That is, unless otherwise manually 500 configured, the other end must "prove" that it "owns" the 501 addresses that it wants to receive through the tunnel. 503 For example, if the remote endpoint is a router, and the actual 504 route to the 3ffe:200:8:3f01::/64 goes through it, it indeed is 505 authorized to request all addresses within 3ffe:200:8:3f01::/64 506 to be tunneled to it. That is, whether the packets are sent 507 directly or tunneled does not have any impact on the effective 508 routing. 510 - For Mobile IPv6 Binding Updates, the CN must know that the MN is 511 authorized to the change routing information for its home 512 address. In other words, it must "prove" that it "owns" its home 513 address. 515 - For reversible Routing Headers, the reversal is safe only if the 516 replying node knows that the SA used to protect the Routing 517 Header is authorized to specify alternate routing information for 518 the final destination. That is, when creating the SA, the peer 519 should "prove" that it "owns" the address to whom alternate 520 routing information may be specified. Even though this practice 521 does not seem to be absolutely necessary, it would certainly stop 522 the attacks outlined in Section 2.5. 524 In each of the cases, we clearly should check the proper 525 "ownership" of an IP address or prefix. Furthermore, in the case 526 of Mobile IPv6 and Routing Headers this check must be made in two 527 distinct phases: First, when creating the SA, it must be recorded 528 what operations the SA is authorized for. Second, when processing 529 a BU or reversing a Routing Header, it must be checked that the SA 530 is actually authorized for the operation. (For inter-domain 531 tunnels, the second phase is already built in to the IPsec policy 532 filtering mechanism.) 534 The hardest problem is faced when considering how to create the SAs 535 between two arbitrary security domains. This is discussed next. 537 4.3. Proving address ownership when dynamically creating SAs 539 Let us consider the situation where two previously unrelated nodes 540 want to create an IPsec SA with IKE. If they have some common 541 point of reference, such as an X.509v3 CA, they are able to do so 542 subject to their local policy definitions. However, such an SA 543 does not provide any assurance about the honesty and competency 544 levels of the nodes. It only allows packets to be exchanged 545 between the nodes in a secure manner. 547 Clearly, an IPsec SA created in such a manner is insufficiently 548 authorized for the purposes discussed elsewhere in the document. 549 That is, the nodes cannot trust each other for changing their 550 internal routing information unless otherwise authorized by the 551 local configuration. For example, if one of the nodes is a Mobile 552 Node, the Correspondent Node must not accept Binding Updates from 553 it since it has now way of actually knowing that the claimed home 554 address really belongs to the Mobile Node. 556 An other way of expressing the situation is the following. In 557 order to accept messages (or mechanisms) that alter internal 558 routing information, the receiving node must know that the 559 originator of each specific message (or application of a mechanism) 560 is authorized to perform the specific suggested change. In other 561 words, the receiving node must know that the originating know is 562 authorized to alter routing information for the specified address 563 or address prefix. One way of expressing this is to say that the 564 originator must "own" the address or address prefix. 566 Currently there exists no specified mechanism for proving address 567 ownership in Internet-wide scale. Proposing solutions goes beyond 568 the scope of this document. 570 5. Security and Privacy Considerations 572 This document discusses security throught the document. Some other 573 related privacy issues are briefly covered in [Nikander01]. 575 6. Intellectual Property Right Notice 577 For Ericsson policy on IPR issues, see the Ericsson General IPR 578 statement for IETF, http://www.ietf.org/ietf/IPR/ERICSSON-General 580 Acknowledgements 582 We want to express our thanks to Michael Thomas and Jari Arkko for 583 their fruitful comments in the initial phases of this work. 585 References 587 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the 588 Internet Protocol, RFC 2401, Internet Engineering Task 589 Force, November 1998. 591 [RFC2460] S. Deering and R. Hindeng, "Internet Protocol, 592 Version 6 (IPv6) Specification, RFC2460, December 1998. 594 [RFC2461] T. Narten, E. Nordmark, W. Simpson, "Neinghor 595 Discovery for IP Version 6 (IPv6), RFC2461, December 1998. 597 [RFC2473] A. Conta and S. Deering, "Generic Packet Tunneling in 598 IPv6 Specification", RFC2473, December 1998. 600 [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC2894, 601 August 2000. 603 [MIP6] David B. Johnson and Charles Perkings, "Mobility 604 Support In IPv6", work in progress, 605 draft-ietf-mobileip-ipv6-13.txt 607 [ICMP-IPSEC] Jari Arkko et al., "Manual SA Configuration for IPv6 608 Link Local Messages", work in progress, 609 draft-arkko-manual-icmpv6-sas-00.txt 611 [Nikander01] Pekka Nikander, "IPv6 Source Addresses Considered 612 Harmful," unpublished manuscript submitted for 613 publication, February 2001. Available from the author 614 on request. 616 Authors' Addresses 618 Pekka Nikander 619 Ericsson Research NomadicLab 620 phone: +358-40-721 4424 621 email: Pekka.Nikander@nomadiclab.com 623 Appendix A. An address "stealing" attack example 625 Let us consider a server serving a number of future mobile 626 terminals. The actual nature of the server is not important. The 627 terminals and the server communicate with Mobile IPv6. The server 628 is meant to be open, i.e., to serve any hosts using Mobile or 629 non-mobile IPv6. 631 Following the cryptographic tradition, let us call the server 632 Alice. To simplify the situation, let us have only two clients: 633 Bob, who is honest, and Mallory, who is malicious and whose aim is 634 to "steal" or at least disturb communication with Alice and Bob. 635 It is important to notice that Mallory has selected Bob as his 636 target, and he attempts to perform his attack in such a way that 637 neither Alice or Bob are aware of the attack; the result of a 638 succesfull attack is that Mallory controls, at least to a degree, 639 all communication between Alice and Bob. 641 Now, if we assume that the MIP6 implementation that Alice uses 642 fully conforms to the standards but is simple minded, the following 643 attack would work. 645 1. Mallory contacts Alice and creates a pair of AH SAs with her. 647 2. Using the SAs created in Step 1, Mallory sends a MIP6 Binding 648 Update to Alice, claiming that his Home Address is that of Bob's 649 and that Bob (the Home Address) is currently visiting at 650 Mallory's (care-of-address). 652 3. Since the Binding Update is protected with AH (see MIPv6 Sec 4.4 653 and 8.2), Alice accepts the Binding Update. (Note that this 654 is a mistake at Alice's part. However, giving Alice the 655 required knowledge to make the right decision is hard. 656 For more discussion, see [address-ownership-problem]. 658 4. As part of the Binding Update processings (sec 8.3), Alice 659 creates a new Binding Cache entry telling that all future 660 communications to Bob's Home Address should be sent to the 661 address Mallory gave (the CoA). 663 Now, let us assume that Bob now wants to create a TCP connection 664 with Alice. Thus, he sends a TCP SYN packet, using his home 665 address, to Alice. Alice receives this packet normally, and passes 666 it to TCP. Alice's TCP creates a new TCB and sends a SYN ACK 667 packet, using Bob's home address as the destination address. 669 5. Now, as a part of output processing (MIP6 sec 8.9), Alice checks 670 its Binding Cache, find a Binding matching the destination 671 address, and adds a Routing Header to route the packet 672 through Mallory to Bob. 674 6. Mallory receives the SYN ACK packet from Alice. 676 7. Mallory has now a number of options to further fool Bob. 678 a) Mallory may choose to claim Bob that Alice is a mobile node 679 herself, and currently at the location where Mallory is. 680 To do this, he creates a pair of IPsec SAs with Bob (or 681 uses existing ones), and sends a Binding Update claiming 682 that Alice is currently at his address. (This assumes, of 683 course, that Bob makes the same mistake Alice made above 684 at step 3.) 686 b) Mallory may choose to claim Bob that Alice is currently 687 (better) reachable through him. To do this, he replaces 688 the routing header that Alice inserted with his own, and 689 uses an existing AH SA (or creates a new) between himself 690 and Bob to protect the routing header to get replies back, 691 as specified in RFC2460 section 8.4. The real difference 692 between this and the a) alternative is that Bob does not 693 insert a Home Address destination option or a Binding 694 Update, but relies on Bob reversing the Routing Header 695 since it is protected with AH. 697 8. Independent on whether Mallory decides use Binding Updates 698 or Routing Headers, he further has two options on how to 699 handle the data stream in the future 701 a) Mallory may decide to act as a man-in-the-middle, passing 702 data between Alice and Bob, and modifying it at need. 703 Furthermore, if the IPsec implementation Alice and Bob are 704 using is simple minded enough, he _may_ be able to fool 705 Alice that she is securely (i.e. with IPSec) talking with 706 Bob, and fool Bob that he is securely talking with Alice. 708 b) Mallory may decide to play Alice to Bob, and completely 709 terminate Bob's session with Alice. 711 This ends the attack description; the only purpose of it is 712 to be illustrate the problem. 714 A.2. Attack analysis 716 Even an superficial analysis on the attack description reveals the 717 basic problem: Alice is using an "untrustworthy" SA to accept Binding 718 Updates concerning Bob, and Bob is using equally "untrustworthy" SA to 719 verify Binding Updates or Routing Headers. If we look at a little bit 720 closer to steps 3. and 7. above, we can describe the problem as an 721 authorization problem. 723 First, in step 3., the SA that Mallory has created with Alice 724 should NOT be authorized to create a Binding Cache entry for Bob's 725 home address. Similarily, in step 7a., the SA that Mallory has 726 created with Bob should NOT be authorized to create a Binding Cache 727 entry for Alice. Still, in step 7b., the SA that Mallory has 728 created with Bob should NOT be authorized to accept the Routing 729 Header as a reversible Routing Header (RFC2460 sec 8.4.). 731 Appendix B. A crypto oracle attack example 733 As mentioned in Section 2.5., depending on the details of the 734 implementation, reversable routing headers may be misused so that a 735 remote host will act as a cryptographic oracle. The attack 736 described is by no means new; a similar kind of attack may, under 737 certain conditions, to be easily launched by a local host without 738 needed routing headers. The noteworthy issue here is that the 739 routing headers allow a remote host to launch such an attack. 741 For the purposes of this example, a cryptoraphic oracle is an 742 entity that encrypts or integrity protects a given piece of code. 743 To an attacer, the main benefit of an oracle is to allow the 744 attacker to use selected plain text based cryptoanalysis. 746 Let us consider a situation where Mallory, a Malicious node, wants 747 to cryptanalyse traffic between Alice and Bob. To ease the 748 analysis task, his aim is to use Alice as an cryptographic oracle, 749 thereby makeing his cryptanalysis task easier. However, since 750 Mallory is not local to Alice nor Bob, nor does sit on the path 751 between them, he has to use some other means in order to fool Alice 752 to perform cryptographic operations on his behalf. In this 753 example, we show how the IPv6 Routing Header, under a specific set 754 of conditions, may allow him to do so. It should be understood 755 that this specific example is not an exhaustive study of the 756 problem, but simply a way to illustrate the dangers of not 757 performing proper authorization on all IPsec Security Associations. 759 In the beginning, Alice and Bob communicate using an IPsec SA. For 760 illustrative purposes, we may assume that this SA is an ESP SA that 761 includes both confidentiality and integrity protection. To allow 762 such communication, Alice has an IPsec SPD Entry specifying that 763 all data to be sent to Bob must be protected with the given SA. 765 To launch his attack, Mallory first sets up an AH SA with Alice. 766 Taking advantage of the lack of proper authorization checks in many 767 of the current IKE implementations, he establishes an 768 unidirectional SA which looks like being one from Bob to Alice. 769 That is, the SPD entry in the SA specifies that the source address 770 in the received packets must be that of Bob's. 772 In the second step, Mallory creates a packet that has a Routing 773 Header, AH header, an UDP header directing the packet to the UDP 774 echo service, and a payload that he wants Alice to protect with the 775 existing ESP SA between Alice and Bob. The Routing Header claims 776 that the packet has been originated by Bob, but that is currently 777 being routed through Mallory. 779 When Alice receives Mallory's packet, she notices that there is a 780 routing header but that the packet is already arriving in its 781 final destination (i.e. she herself). Therefore she processes the 782 packet normally, verifying the integrity and authentication. Since 783 the packet is authenticated, and appears to be originally from Bob, 784 it passes the host local packet filters and is passed to UDP. 785 Depending on the implementation, the packet may be annotated with 786 metadata containing the authenticated routing header. As a final 787 step of the receival process, UDP passes the packet to the echo 788 service. 790 The echo service simply echos back the UDP payload. In some 791 implementation dependent way, the underlying UDP or IP layer is 792 aware that the packet is a reply to the packet above. Thus, they 793 reverse the authenticated routing header (found in the metadata), 794 creating a routing header that routes the packet to Bob through 795 Mallory. The resulting packet is passed to the IPsec layer. 796 Because the final destination is Bob, the IPsec layer decides that 797 the packet must be protected with the ESP SA that exists between 798 Alice and Bob. The resulting ESP protected packet is sent to the 799 first hop in the route, i.e., Mallory. 801 Thus, as a result, Mallory receives an encrypted packet that 802 contains an easily predictable UDP header and the payload that it 803 originally sent. In other words, Mallory is efectively using Alice 804 as a cryptographic oracle crypting any plaintext that Mallory 805 chooses. 807 The example above depends on many implementation details and on some 808 configuration choices. The specific attack is easy to block by 809 modifying some of these. Unfortunately, it seems like that there 810 exists many different cases where similar kinds of attacks are 811 possible. The only real way of preventing these kinds of attacks 812 is to perform proper authorization when creating the SA between 813 Mallory and Alice, and to enforce the authorized permissions in the 814 SPD level.