idnits 2.17.1 draft-etienne-ripv2-auth-flaws-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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([5], [6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 (May 2001) is 8381 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) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') ** Obsolete normative reference: RFC 1771 (ref. '4') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2082 (ref. '5') (Obsoleted by RFC 4822) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Etienne 3 Internet-Draft May 2001 4 Expires: October 30, 2001 6 Flaws in RIPv2 packet's authentication 7 draft-etienne-ripv2-auth-flaws-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any 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 This Internet-Draft will expire on October 30, 2001. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 The current strongest authentication method for RIPv2 (RFC2453[6]) 39 is the MD5 authentication (RFC2082[5]) which uses shared secret key 40 to authenticate the packets. This memo explains the different 41 security flaws we found in the anti-replay and the MACs calculation. 42 The second part presents practical exploitations of these 43 weaknesses: an attacker directly connected to a link, can (i) 44 break neighborhood, (ii) flap routes and (iii) inject obsolete 45 routes. 47 Table of Contents 49 1. Threat model . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Current authentications . . . . . . . . . . . . . . . . . . 4 51 2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.2 Anti Replay Protection . . . . . . . . . . . . . . . . . . . 5 53 2.2.1 a timestamp as sequence number . . . . . . . . . . . . . . . 5 54 2.2.2 a counter as sequence number . . . . . . . . . . . . . . . . 5 55 2.3 MAC calculation . . . . . . . . . . . . . . . . . . . . . . 6 56 2.3.1 secret-suffix method . . . . . . . . . . . . . . . . . . . . 6 57 2.3.2 Unprotected IP header . . . . . . . . . . . . . . . . . . . 6 58 2.3.3 Unprotected UDP header . . . . . . . . . . . . . . . . . . . 6 59 2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3. Exploits . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1 breaking neighborhood . . . . . . . . . . . . . . . . . . . 8 62 3.1.1 Higher sequence number . . . . . . . . . . . . . . . . . . . 8 63 3.2 Route flapping . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2.1 route flapping by repeatdely breaking the neighborhood . . . 9 65 3.2.2 route flapping thanks to poisoned reverse . . . . . . . . . 9 66 3.3 Inject obsolete routes . . . . . . . . . . . . . . . . . . . 9 67 3.3.1 higher sequence number . . . . . . . . . . . . . . . . . . . 10 68 3.3.2 lower sequence number . . . . . . . . . . . . . . . . . . . 10 69 4. Security considerations . . . . . . . . . . . . . . . . . . 11 70 References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 74 1. Threat model 76 In this memo, we assume the attacker can read and write packets on 77 the network link. He hasn't the secret key and he is unable to 78 produce a valid MAC without it. 80 If the attacker knows the secret key of a link, he becomes an 81 insider and the security of the whole routing domain is compromised. 82 Resisting to insider's attacks requires deep modifications of the 83 protocol and it is outside the scope of this memo. 85 2. Current authentications 87 The RIPv2's authentication is configured on a per-interface basis. 88 Each router connected to a given link shares the same parameters 89 (i.e. key value, key lifetime and authentication algorithm). RIP has 90 3 authentication methods: 92 1. The NULL authentication which doesnt authenticate the packet. 94 2. The Simple password authentication (RFC2453.4.1[6]) uses a 95 password sent in clear in each packet. If the attacker can read 96 the packets, he has the password and can freely forge new 97 packets. 99 3. The MD5 authentication(RFC2082[5]) which uses a shared secret 100 key to include a MAC in each packet. 102 Because the null and the simple password authentication are already 103 known to be weak, we focus on the MD5 authentication. 105 2.1 Description 107 The MD5 authentication provides a secure way to authenticate the 108 packet's generator as a key owner and some protections against 109 packet's replay. The packets include a Message Authentication 110 Code(MAC) calculated with the secret suffix method using MD5 111 (RFC1321[3]). The MAC is obtained by applying MD5 over the payload 112 and, then, the secret key : MAC = MD5( RIP payload | secret key ). 113 An external attacker can't generate a valid MAC because we assume it 114 ignores the secret key and it is believed to be infeasible to 115 recompute the key from the MAC and the packet. 117 The anti-replay is handled by a sequence number set in sent packets 118 and verified during packet reception. The sequence number must be 119 non-decreasing and is suggested to be a counter, or a timestamp 120 (RFC2082.3.2.1[5]). A received packet is accepted only if its 121 sequence number is greater or equal to the last one accepted from 122 the same source. 124 In brief, when a router sends a packet, it sets the sequence number, 125 stores it in a routing entry with a special address family for 126 compatibility reason(RFC2453.5.2[6]), then computes the MAC and 127 appends it to the packet. When a router receives a packet, it is 128 accepted only if the MAC and the sequence number are valid. 129 Unfortunately, the MD5 authentication has flaws in the anti-replay, 130 the MAC algorithm, and the MAC coverage. 132 2.2 Anti Replay Protection 134 The following features of the MD5 authentication allow a packet to 135 be replayed: 137 o A received packet is accepted if its sequence number is greater 138 than or equal to the previous one (RFC2082.3.2.2[5]). For 139 example, a packet can be replayed just after itself. 141 o The sequence numbers can be reused after a roll over or a boot 142 (e.g. a packet counter RFC2082.3.2.1[5]). 144 o The keying is static and the sequence numbers aren't necessarily 145 stored in a non-volatile memory. When a router goes off-line, its 146 neighbors forget its sequence numbers and an attacker can replay 147 its packets. 149 Each reason is independently sufficient to permit a packet's replay. 150 The sequence number is the base of the anti-replay mechanism, so we 151 present the different possibilities. RFC2082.3.2.1[5] suggests to 152 use a timestamp or a packet counter. 154 2.2.1 a timestamp as sequence number 156 Using a timestamp as sequence number forces one to either accept 157 several successive packets with the same sequence numbers or to 158 assume that no more than one packet is sent during a clock period.It 159 would unnecessarily create a dependency between the clock frequency 160 and the network throughput. RIPv2 has chosen the former and this 161 likely causes the "greater than or equal to" vulnerability 162 (RFC2082.3.2.2[5]). 164 RFC2082[5] doesn't require to store the timestamp on a stable 165 storage. If it is, it will roll over in the future. The 166 implementations i have seen use the number of seconds since the 167 first january 1970, so the roll over would happen in 2038. RIPv2 168 will likely no more be used at this time. Nevertheless it is still 169 possible to successfully replay a packet multiple times until the 170 destination accepts a higher sequence number. This delay can be up 171 to 30 seconds (default periodical update interval from 172 RFC2453.3.8[6]) and more in case of packet loss. Not having the time 173 on a stable storage, doesn't solve the previous vulnerability and 174 adds a new one because sequences numbers are reused after each 175 reboot. 177 2.2.2 a counter as sequence number 179 With a timestamp, packets played in the same time slice (e.g. pkt1 180 then pkt2) can be replayed in disorder (i.e. pkt2, then pkt1). Using 181 a packet counter makes this impossible. Nevertheless the last packet 182 (pkt2) can still be replayed. 184 If the counter isn't stored on a stable storage it will be reused 185 across reboot. Even if it is, a large router may send 2^32 RIP 186 packets during its lifetime and the sequence number would roll over. 187 So a packet counter still has flaws. 189 2.3 MAC calculation 191 The MAC calculation of the MD5 authentication has two problems: it 192 uses the secret-suffix method which is known to be weak and applies 193 it only on the RIP payload, leaving the UDP and IP headers 194 unprotected. Surprisingly, RFC2082[5] doesn't specify where the 195 coverage starts but the implementations we checked start at the 196 beginning of the RIP payload. We consider this behavior as a 197 De-facto standard. 199 2.3.1 secret-suffix method 201 [9] considers the secret-suffix method possibly weak. [8] and [7] 202 explains that an attacker may search for MD5( RIP packet ) 203 collisions, and then use them for any key. This search is efficient 204 because it can be parallelized and done off-line. Nevertheless, this 205 weakness is theoretical and unlikely to be turned into an practical 206 attack. 208 2.3.2 Unprotected IP header 210 The IP header(RFC0791.3.1[2]) isn't covered by the MAC so a 211 modification would not be detected. If the protocol relies on its 212 fields, it may be the base of an attack. We focus on the fields that 213 may influence RIP and not prevent the packet from reaching the RIP 214 layer (i.e. pass the UDP/IP layers). The matching fields are: 216 o The source address indicates the origin of the packet and is used 217 by RIP to know which neighbor sent the packet(RFC2453.3.9.2[6]). 219 o The destination address indicates the destination of the packet. 220 The IP layer uses it to accept or reject the packets. 222 2.3.3 Unprotected UDP header 224 An attacker can modify the UDP header (RFC0768[1]) without being 225 detected as well. Nevertheless, the only field used by RIP is the 226 length and any modification, shorter or longer, will cause the 227 authentication verification to fail. 229 2.4 Summary 231 In short, a RIPv2 packet authenticated by RFC2082[5], the current 232 strongest method, can be replayed and it can be done between routers 233 which aren't necessarily the original ones. The anti replay 234 protection has several flaws (see Section 2.2) and the MAC don't 235 cover the UDP and IP headers (see Section 2.3). The next section 236 describes the attacks we found based on these vulnerabilities. 238 3. Exploits 240 Using the weaknesses described in Section 2.2 and in Section 2.3, an 241 attacker directly connected to a single link, can (i) break 242 neighborhood (A neighborhood is the term we use to designate 2 243 routers seeing each other), (ii) flap routes and (iii) inject 244 obsolete routes. 246 3.1 breaking neighborhood 248 The router's neighborhood is the base of the anti-replay of MD5 249 authentication in RIPv2 and we present an attack able to break it 250 using packet replay and ip address spoofing. An attacker can break 251 the neighborhood between R1 and R2 by preventing R1 from seeing R2: 253 1. The attacker obtains a packet with a sequence number higher than 254 R2 one (see Section 3.1.1). 256 2. It replays it to R1 faking the R2 source address, R1 accepts it. 258 3. R1 no more accepts legitimates packets from R2 as their sequence 259 numbers are lower than the last accepted one. 261 4. R1 eventually breaks the neighborhood considering R2 unreachable. 263 3.1.1 Higher sequence number 265 As this attack assumes the attacker has a packet with a higher 266 sequence number, this section explains how to obtain such packet. 268 o If the R2 sequence number is a time since a fixed date (typically 269 number of second since 01/01/70), it will likely be much higher 270 than sequences numbers reset at each reboot (e.g. packet counter 271 or time since reboot). If R2 hasn't the highest time of the 272 router connected to the link, an attacker can take a packet from 273 a source with a time ahead from the R2 one. Else an attacker may 274 hope the R2 clock will drift and the R2 administrator will adjust 275 it, but it is unlikely. 277 o If the R2 sequence number is reset as each reboot (e.g. packet 278 counter or time since reboot), the attacker may use a packet from 279 a previous boot or from another router with a higher sequence 280 number (e.g. longer boot or time since a fixed date). 282 3.2 Route flapping 284 It is possible to flap routes by (i) repeatdely breaking 285 neighborhood (see Section 3.2.1) if the attacker has a packet with a 286 higher sequence number or by (ii) using poisoned reverse (see 287 Section 3.2.2) if all the routers have similar sequence numbers. 289 The consequences of flapping a route is to have suboptimal routing. 290 Moreover, in the AS(autonomous system), each trigger update consumes 291 network when it is flooded, and CPU when it triggers a route 292 recalculation. Outside the AS, the cost of this attack will depend 293 on the protocols used. If the route is exported with BGP, it may be 294 dampened (RFC1771.apx6[4]). 296 3.2.1 route flapping by repeatdely breaking the neighborhood 298 If an attacker uses the Section 3.1 method, it may break the 299 neighborhood between R1 and R2, so all the R1 routes using R2 as 300 next hop will be timed out and advertised as infinite. R1 will send 301 triggered update on each of the connected links and the AS will try 302 to converge to a slower route no more using R2. After a short moment 303 (WORK: how long), R1 forgets the fake R2 sequence number, accepts 304 again the R2 packets. As R2 offers a faster route, R1 uses it as 305 next hop and sends a triggered update to announce the change. then 306 the attacker breaks the neighborhood again and the route is 307 flapping. 309 3.2.2 route flapping thanks to poisoned reverse 311 If the all routers have similar values of sequences number, an 312 attacker can't use them for breaking a neighborhood but can still do 313 route flapping thanks to the poisoned reverse(RFC2453.3.4.3[6]). 315 If the router R1 uses a router R2 as next hop for a route, it will 316 advertise this route with a infinite metric on the link between R1 317 and R2. It prevents from creating 2 hops loop. An attacker can 318 replay the packet with infinite metric back to R1 and fakes the R2 319 source address, so R1 will accept the packet and update its metric 320 to infinite. The next periodic update from R2 will be accepted as 321 well and R1 will update again with a real metric. If the attacker 322 does it again, the route is flapping. 324 3.3 Inject obsolete routes 326 An attacker can inject obsolete routes by (i) capturing a packet 327 advertising a route with a given metric (say X), (ii) then waiting 328 for this route to be announced with a metric Y different than X, and 329 (iii) replays the packet with the metric X. The effect of this 330 attack depends on the sequence number of the replayed packet 331 compared to the current one of the connected routers: (i) if the 332 replayed packet has a smaller sequence number, Y needs to be greater 333 than X or (ii) if it has a greaters one, it can be done 334 independantly of Y. 336 3.3.1 higher sequence number 338 If the sequence number of the replayed packet is greater than the 339 current one of connected routers, the attacker sends the packet 340 faking the source address of the current next hop. The packet will 341 be accepted and the new metric will be used, even if it is higher 342 than the former one. 344 3.3.2 lower sequence number 346 If the sequence number of the replayed packet is lower, the attacker 347 can still fake an unused source address. The destination will accept 348 it because they have no memory of a sequence number. If the replayed 349 metric X is lower than the current one Y, they will use the new fake 350 router as next hop and the attacker can perform any man in the 351 middle attacks (e.g. traffic analysis, black-holes). The attraction 352 of the black-hole depends on the metric delta (i.e Y-X). 354 4. Security considerations 356 This memo presents weaknesses in the current strongest method of 357 authentication. The MD5 authentication anti-replay was known to be 358 weak but its flaws were believed harmless. We found a new flaw in 359 the MAC calculation which allows an attacker to fake the source and 360 destination IP addresses. Combined, these weaknesses allow efficient 361 DoS and the injection of obsolete routes. We present some of the 362 attacks but we strongly suspect there are others as well. 364 We have designed the "anti-replay authentication" (WORK: ref) that 365 fixes these flaws, without, to the best of our knowledge, adding new 366 ones. This method isn't described in this draft, because it isn't 367 yet fully specified in the RIP context. The MAC covers the IP header 368 preventing an attacker from forging it. This method provides a new 369 way to handle anti-replay with static key which is safe across 370 reset. Keeping the core structure of the MD5 authentication, it can 371 be easily plugged in an existing implementation so we think it may 372 be a good replacement of the MD5 authentication. 374 References 376 [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 28 August 377 1980. 379 [2] Postel, J., "Internet Protocol", STD 5, RFC 791, Sep 1981. 381 [3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 382 1992. 384 [4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 385 RFC 1771, March 1995. 387 [5] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication", RFC 388 2082, January 1997. 390 [6] Malkin, G.S., "RIP Version 2", STD 56, RFC 2453, November 1998. 392 [7] Bellare, M., Canetti, R. and H. Crawczyk, "Keying hash function 393 for Message Authentication", Advances in cryptology Crypto 96 394 vol 1109, 1996. 396 [8] Preneel, B. and P. Van Oorshot, "MDX-MAC and building fast MACs 397 from hash functions", Advances in cryptology Crypto 96 , 1995. 399 [9] Kaliski, B. and M. Robshaw, "Message authentication with MD5", 400 Cryptobyte Vol1 no1, 1995. 402 Author's Address 404 Jerome Etienne 406 EMail: jme@off.net 407 URI: http://w3.arobas.net/~jetienne 409 Full Copyright Statement 411 Copyright (C) The Internet Society (2001). All Rights Reserved. 413 This document and translations of it may be copied and furnished to 414 others, and derivative works that comment on or otherwise explain it 415 or assist in its implementation may be prepared, copied, published 416 and distributed, in whole or in part, without restriction of any 417 kind, provided that the above copyright notice and this paragraph 418 are included on all such copies and derivative works. However, this 419 document itself may not be modified in any way, such as by removing 420 the copyright notice or references to the Internet Society or other 421 Internet organizations, except as needed for the purpose of 422 developing Internet standards in which case the procedures for 423 copyrights defined in the Internet Standards process must be 424 followed, or as required to translate it into languages other than 425 English. 427 The limited permissions granted above are perpetual and will not be 428 revoked by the Internet Society or its successors or assigns. 430 This document and the information contained herein is provided on an 431 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 432 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 433 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 434 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 435 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 437 Acknowledgement 439 Funding for the RFC editor function is currently provided by the 440 Internet Society.