idnits 2.17.1 draft-richardson-saag-onpath-attacker-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4949, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4949, updated by this document, for RFC5378 checks: 2004-08-23) -- 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 (22 February 2021) is 1151 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: 'Dolev-Yao' is mentioned on line 247, but not defined == Unused Reference: 'RFC4949' is defined on line 282, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4949 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Security Area Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Updates: 4949 (if approved) J. Hoyland 5 Intended status: Standards Track Cloudflare Ltd. 6 Expires: 26 August 2021 22 February 2021 8 A taxonomy of eavesdropping attacks 9 draft-richardson-saag-onpath-attacker-02 11 Abstract 13 The terms on-path attacker and Man-in-the-Middle Attack have been 14 used in a variety of ways, sometimes interchangeably, and sometimes 15 meaning different things. 17 This document offers an update on terminology for network attacks. A 18 consistent set of terminology is important in describing what kinds 19 of attacks a particular protocol defends against, and which kinds the 20 protocol does not. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 26 August 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Three kinds of attack . . . . . . . . . . . . . . . . . . . . 3 57 2.1. First Kind of attack . . . . . . . . . . . . . . . . . . 3 58 2.2. Second Kind of attack . . . . . . . . . . . . . . . . . . 4 59 2.3. Second Kind of attack with bypass . . . . . . . . . . . . 4 60 2.4. Third Kind of attack . . . . . . . . . . . . . . . . . . 5 61 3. Three proposals on terminology . . . . . . . . . . . . . . . 5 62 3.1. QUIC terms . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Malory/Man in various places . . . . . . . . . . . . . . 5 64 3.3. Council of Attackers . . . . . . . . . . . . . . . . . . 6 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 8.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 A number of terms have been used to describe attacks against 78 networks. 80 In the [dolevyao] paper, the attacker is assumed to be able to: 82 * view messages as they are transmitted 84 * selectively delete messages 86 * selectively insert or modify messages 88 Some authors refer to such an attacker as an "on-path" attacker 89 [reference], or a "Man-in-the-Middle" [reference]. This type of 90 attack is also refered to as a "monster-in-the-middle" attack. 92 Despite a broad consensus on what is meant by a MITM attack, there is 93 less agreement on the how to describe its variants. The term 94 "passive attacker" has been used in many cases to describe situations 95 where the attacker can only observe messages, but can not intercept, 96 modify or delete any messages. 98 Another variant is the case where an eavesdropper is not on the 99 network path between the actual correspondants, and thus cannot drop 100 messages, they may be able to inject packets faster than the 101 correspondants, and thus beat legitimate packets in a race. 103 As summarised, there are three broad variations of the MITM attacker: 105 1. An on-path attacker that can view, delete and modify messages. 106 This is the Dolev-Yao attack. 108 2. An off-path attacker that can view messages and insert new 109 messages. 111 3. An off-path attacker that can only view messages. 113 2. Three kinds of attack 115 The attacks are numbered in this section as no consensus on naming 116 the attacks yet. In the diagrams below, the sender is named "Alice", 117 and the recipient is named "Bob", as is typical in many cryptographic 118 protocols [alicebob], as first introduced by [digisign]. 120 The attacker is named "Mallory" 122 .-------. .-----. 123 | Alice |------------------>| Bob | 124 '-------' '-----' 126 Figure 1: Alice communicating with Bob 128 2.1. First Kind of attack 130 In this attack, the attacker is involved with the forwarding of the 131 packets. A firewall or network router is ideally placed for this 132 attack. 134 .-------. *********** .-----. 135 | Alice |------* Mallory *------>| Bob | 136 '-------' *********** '-----' 138 Figure 2: The first kind of attack 140 In this case Mallory can: 142 * view all packets 144 * selectively forward or drop any packet 145 * modify any packets that is forwarded 147 * insert additional packets 149 2.2. Second Kind of attack 151 In this attack, the attacker is not involved with the forwarding of 152 the packets. The attacker receives a copy of packets that are sent. 153 This could be from, for instance, a mirror port or SPAN [span]. 154 Alternatively, a copy of traffic may be obtained via passive 155 (optical) tap [fibertap]. This kind of attack is often associated 156 with Pervasive Monitoring [RFC7258]. 158 .-------. .-----. 159 | Alice |---------.------------->| Bob | 160 '-------' | '-----' 161 v 162 *********** 163 * Mallory * 164 *********** 166 Figure 3: The second kind of attack 168 In this case Mallory can: 170 * view all packets 172 2.3. Second Kind of attack with bypass 174 In some cases, Mallory may be able to send messages to Bob via 175 another route which due to some factor will arrive at Bob prior to 176 the original message from Alice. 178 .-------. .->--. .-----. 179 | Alice |---------------| | | .>| Bob | 180 '-------' | | | | | '-----' 181 | | | v | ^ 182 | | | | | | 183 v '--> '->| | 184 *********** | 185 * Mallory *---------------------' 186 *********** 188 Figure 4: The second kind of attack with bypass 190 In that case Mallory can: 192 * view all packets 193 * insert additional/copied packets into the stream 195 But Mallory will be unable to drop or modify the original packets. 196 Bob however, may be unable to distinguish packets from Alice vs 197 packets sent from Mallory that purport to be from Alice. 199 2.4. Third Kind of attack 201 The third kind of attack is one in which Mallory can not see any 202 packets from Alice. This is usually what is meant by an "off-path" 203 attack. Mallory can usually forge packets purporting to be from 204 Alice, but can never see Alice's actual packets. 206 .-------. .-----. 207 | Alice |--------------------------->| Bob | 208 '-------' '-----' 209 ^ 210 | 211 | 212 *********** | 213 * Mallory *---------------------' 214 *********** 216 Figure 5: The third kind of attack 218 In this case Mallory can: 220 * insert additional packets 222 3. Three proposals on terminology 224 This document aspires to pick a single set of terms and explain them. 226 3.1. QUIC terms 228 [quic] ended up with a different taxonomy: 230 * on-path [Dolev-Yao] 232 * Limited on-path (cannot delete) 234 * Off-path 236 3.2. Malory/Man in various places 238 [malory] proposes: 240 * man-in-the-middle [Dolev-Yao] 241 * man-on-the-side 243 * man-in-the-rough 245 Alternatively: 247 * Malory-in-the-middle [Dolev-Yao] 249 * Malory-on-the-side 251 * Malory-in-the-rough 253 3.3. Council of Attackers 255 [alliteration] proposes the "the council of attackers" 257 * malicious messenger [Dolev-Yao: who rewrites messages sent] 259 * oppressive observer [who uses your information against you] 261 * off-path attacker 263 4. Security Considerations 265 This document introduces a set of terminology that will be used in 266 many Security Considerations sections. 268 5. IANA Considerations 270 This document makes no IANA requests. 272 6. Acknowledgements 274 The SAAG mailing list. 276 7. Changelog 278 8. References 280 8.1. Normative References 282 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 283 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 284 . 286 8.2. Informative References 288 [alicebob] "Alice and Bob", 2020, 289 . 291 [alliteration] 292 "Council of Attackers", 2020, 293 . 296 [digisign] Rivest, R.L., Shamir, A., and L. Adleman, "A method for 297 obtaining digital signatures and public-key 298 cryptosystems", February 1978, 299 . 301 [dolevyao] "On the Security of Public Key Protocols", 1983, 302 . 305 [fibertap] "Fiber Tap", 2020, 306 . 308 [malory] "Man-in-the-Middle", 2020, 309 . 312 [quic] "QUIC terms for attacks", 2020, 313 . 316 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 317 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 318 2014, . 320 [span] "Port Mirroring", 2020, 321 . 323 Contributors 325 Authors' Addresses 327 Michael Richardson 328 Sandelman Software Works 330 Email: mcr+ietf@sandelman.ca 332 Jonathan Hoyland 333 Cloudflare Ltd. 335 Email: jhoyland@cloudflare.com