idnits 2.17.1 draft-savola-distsec-threat-model-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 409. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. 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 (October 24, 2005) is 6752 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) -- Possible downref: Normative reference to a draft: ref. '1' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet-Draft CSC/FUNET 4 Expires: April 27, 2006 October 24, 2005 6 Distributed Security Threat Model 7 draft-savola-distsec-threat-model-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 27, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 The distributed security framework document describes an approach 41 where hosts take greater responsibility for protecting against 42 attacks on security vulnerabilities targeted at themselves. This 43 memo analyzes the threat model of the distributed security approach, 44 in particular pointing out areas which the mechanism cannot protect 45 against. 47 XXX: generic comment from JariA: "The main issue that I could see is 48 that its still rather simple presentation of the issues, e.g. does 49 not necessarily go as deep as some other ongoing work goes." 51 XXX: generic comment from EKR: "I found the organization rather 52 confusing. It seems to me like a lot of the material in the 53 framework document would make more sense in the threat model. 54 Without that context, it's fairly hard to understand what you're 55 trying to accomplish." (Similar comment from others: addressing this 56 would require significant(?) text duplication from the framework 57 doc..) 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Main Goal: Prevention and Damage Control . . . . . . . . . . . 3 63 3. Generic Threats . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Mitigating the Consequences of a Security Breach . . . . . 4 65 4. Assumptions About the Threat Model . . . . . . . . . . . . . . 5 66 4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.2. Users and Privilege levels . . . . . . . . . . . . . . . . 5 68 4.3. Users Have Physical Access to the Hosts . . . . . . . . . . 6 69 4.4. L2/L3 Network Access Authorization . . . . . . . . . . . . 6 70 4.5. Host Identification and Blocking . . . . . . . . . . . . . 6 71 4.6. Policy Implementation and Correctness . . . . . . . . . . . 7 72 4.7. Protocol mechanism security . . . . . . . . . . . . . . . . 8 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 Intellectual Property and Copyright Statements . . . . . . . . . . 9 82 1. Introduction 84 Distributed security framework [1] described an approach where hosts 85 take larger responsibility in protecting against security 86 vulnerabilities targeted to themselves. This approach is aimed to 87 lower the chance of breaches and to reduce the extent of spreading 88 the vulnerabilities (by increasing the resistance of neighboring 89 hosts) in the event that (inevitably) an individual host is breached. 91 This memo analyzes the threat model of the distributed security 92 approach, in particular pointing out areas which the mechanism cannot 93 protect against. 95 2. Main Goal: Prevention and Damage Control 97 Like any other security mechanism, distributed security is not 98 bullet-proof. The goal is to significantly reduce the likelihood of 99 a security breach and significantly reduce the damage inflicted by a 100 breach. The failings of standard firewalls are described in Section 101 2.1 of [1]. 103 As a specific example, viruses/worms ("malware") and other 104 misbehavior by laptops which move in and out of the "protected" 105 network has come up as a problem: when infected, such hosts may also 106 easily infect the network's "soft underbelly" behind the firewalls. 108 The key concepts of distributed security framework are to reduce the 109 chance of a security breach, minimize damage in the local network 110 environment should one occur, and to isolate the misbehaving or 111 vulnerable nodes from the network. 113 The main factor in reducing vulnerability is reduction of the size of 114 the smallest security perimeter so that it only encloses a single 115 node. By eliminating components which are externally (network) 116 accessible from the interior of the security perimeter, the scope for 117 attacks is reduced. This contrasts with today's most common paradigm 118 where the security perimeter encloses network connections as well as 119 nodes which allow attacks to be mounted from compromised or 120 introduced nodes within the security perimeter: these attacks 121 represent a significant fraction of the threats to today's networks. 123 Each node in this model will have intrusion detection capabilities 124 and the ability to block those malware, but a key feature of 125 distributed security is minimized security risk in the local network 126 environment from listed threats. 128 3. Generic Threats 130 Below we describe the main threats which the security mechanism aims 131 to mitigate. 133 XXX: "I think you need to explain how these threats work in more 134 detail, and why they're a big problem in current architectures (or 135 not)" 137 XXX: Sam Hartman: "I would recommend working on the following issues: 138 1) Better articulate your threats, and 2) Better show how the 139 technology can actually address these threats." 141 o Viruses (including those carried over email or in application 142 payloads, for example word processor or spreadsheet files which 143 contain active content). 145 o Worms, especially ones exploiting already known security 146 vulnerabilities in the local networks and elsewhere. 148 o An "inside host" under unauthorized remote control (e.g., in a 149 "botnet"), for DDoS, sending of unsolicited mail, etc. 151 o Port scanning and other forms of aggressive probing which could be 152 a sign of an infected or otherwise questionably behaving host. 154 o Other defined security breaches originating inside the host, e.g., 155 trying to access services the user is not authorized to access. 157 3.1. Mitigating the Consequences of a Security Breach 159 XXX: seems a bit like material for the framework or other places in 160 the spec? 162 Since it is probably impossible to prevent a security breach ever 163 happening, the distributed security framework aims to prevent a 164 possible breach propagating from one host to another, and to reduce 165 the value of the information that might become accessible in the 166 event of a breach. 168 This requires that the framework should include intrusion detection 169 mechanisms and security level checking. The intrusion detection and 170 security level checking should be connected to secure ways of 171 blocking access by the host to the rest of the netwoek and means to 172 render the data contained within a security perimeter of no value to 173 an attacker if an intrusion is detected or the security level of the 174 host drops below an acceptable threshold. This might be achieved by 175 rendering the security keys needed inaccessible, provided that the 176 data is encrypted (and adequate backups are held elsewhere!). 178 4. Assumptions About the Threat Model 180 4.1. Applicability 182 Laptop hosts, especially those connected through wireless 183 infrastructure, have the greatest need of the distributed security 184 mechanism. It is also very useful on servers which are designed to 185 be access through specific pinholes in the normal perimeter 186 firewalls, as exploiting the server is as easy as finding an exploit 187 in the protocol or the implementation. 189 XXX: "I'm not sure why this mechanism would be better in these 190 cases." 192 Routers, switches and other similar equipment may need to participate 193 in the distributed security framework (e.g., in enforcement). 194 However, we consider protecting such equipment itself with 195 distributed security out of scope because securing the equipment with 196 existing tools is much easier than hosts. 198 4.2. Users and Privilege levels 200 Users are often keen (and even instructed by helpdesks) to turn off 201 firewalls, virus scanners, etc. when debugging a problem or when such 202 behavior is deemed undesirable (e.g., hampering playing a network- 203 based game or running a peer-to-peer software). 205 In enterprise scenarios, or where this is recognized as a problem, a 206 solution typically is to withhold administrator privileges from 207 ordinary users preventing them from performing these actions. 209 If the user has administrator access to the system, it is not 210 possible to prevent these actions, short of more extensive security 211 framework (e.g., "trusted computing"). 213 Therefore we assume that the users are either knowledgeable enough or 214 must not have the privileges to turn off the required security 215 services. 217 XXX: "How well do these policies get enforced now with stuff like 218 HIDS or AV?" 220 4.3. Users Have Physical Access to the Hosts 222 In case of laptops and workstations, the users are expected to have 223 physical access to the systems. In some environments, the IT support 224 will have password-protected BIOS setups or implemented other 225 countermeasures to prevent users from, e.g., booting a system and 226 performining administrative password recovery. While these 227 countermeasures and policies might mitigate the threat of misbehaving 228 users, we cannot assume the hosts would be physically safe from the 229 user. 231 If a host falls into the wrong hands (e.g., a stolen laptop), we 232 assume that the system would be sufficiently encrypted. 233 Alternatively, configurations must not include secrets which would be 234 of significant information value in assisting a security breach. 236 4.4. L2/L3 Network Access Authorization 238 It is assumed that the security of network access has been chosen 239 according to the requirements of a site. 241 For example, one could use 802.1x and EAP to control network access, 242 using certificates and/or usernames and passwords. Some sites might 243 view this as an overkill in their environment (e.g., where there is 244 deemed to be sufficient physical security) and have no protections, 245 or just perform MAC-address locking in the switch equipment. Other 246 sites might require no or only minimal L2 authorizationm but require 247 encrypted VPNs from all the hosts to VPN gateways to eliminate 248 eavesdropping and hijacking. 250 Sites may also have different requirements for layer 3 network access 251 controls, i.e., which IP address the user gets and whether the 252 address can be changed/spoofed by the user if need be. In some rare 253 cases, DHCP authentication may be in use, though it does not prevent 254 manual configuration of another address. In IPv6, SEND [2] may be 255 applicable. Other solutions may exist. 257 Distributed security should be able to work within any of these 258 scenarios according to the security requirements. 260 4.5. Host Identification and Blocking 262 XXX: "This is, of course, a standard technique in modern 802 263 networks." 265 When security policy is communicated and applied, the hosts need to 266 be reliably identified. 268 The mechanisms by which this is done depend on the security 269 requirements of the site. IP address, hostname, MAC-address, etc. or 270 some combination thereof may or may not be sufficient; sometimes 271 certificates may need to be used; if 802.1x and EAP was used for L2 272 network access or VPNs for L3 access, the user identification 273 credentials used there could be used here as well. 275 We also need to consider how access to the host can be blocked 276 reliably (e.g., because its security is not at a sufficiently high 277 level, because it has been compromised or or because it hasn't been 278 checked yet). 280 o The most reliable way would be using strong identification (XXX: 281 need spelling out?), but that cannot be expected to be readily 282 available (and inspecting it on the wire would probably require 283 that each host would use VPNs). 285 o The easiest way is to use IP addresses. However, the user could 286 just change an IP address and try again; presumably, all IP 287 addresses (until verified) would need to be blocked by default. 288 Then the user could try to hijack another, already-authorized 289 user's IP address. However, this can often be noticed and even 290 prevented, depending on the security requirements of the site. 292 4.6. Policy Implementation and Correctness 294 Distributed security uses policies and checks to verify that the host 295 should be secure enough. There are a couple of assumptions 296 associated with this requirement: 298 o The host (even if infected) will not lie about the checks. This 299 is a bit of stretch, and in the absence of "trusted computing", 300 there may be security problems which could be exploited in 301 conjunction with kernel vulnerabilities, allowing an attacker to 302 hide their presence or activities. We assume that such hosts 303 would be detected by unnatural external behaviour or by other 304 means. 306 o The policy language and mechanisms are expressive enough. For 307 example, it may not always be possible to identify "good" and 308 "bad" versions just by looking at a version string (especially as 309 may be the case for "backported" updates). The implementations 310 would need to include more extensive mechanisms for noticing and 311 reporting problems. There are potential managerial problems in 312 ensuring that, for example, the correct checksums of software are 313 known. There are also potential combinatorial problems: it may 314 not just be a matter of having specific versions of software but 315 ensuring that the correct combination of versions are present. 317 4.7. Protocol mechanism security 319 Distributed security mechanisms need to be able to block the hosts at 320 policy enforcement points. If there is communication between the 321 IDSs or other mechanisms detecting anomalous behaviour, the 322 communication should be at least authenticated and integrity- 323 protected. 325 The communication of a host and policy controllers should be 326 sufficiently secure that the information cannot be altered by man-in- 327 the-middle or other attackers. Typically this calls for encryption, 328 integrity protection and sufficient authentication. 330 5. Acknowledgements 332 Satoshi Kondo provided useful feedback for the initial version of 333 this memo. Elwyn Davies, Jari Arkko, Eric Rescorla, and Sam Hartman 334 provided a number of very helpful comments. 336 6. Security Considerations 338 This memo is all about the distributed security threat models. 340 The most important thing to note is that distributed security is not 341 a perfect solution; as it needs to rely on (to some degree) the 342 users' and the host OS's correct behavior. In cases where this 343 assumption does not hold stricter measures will be necessary. 345 7. IANA Considerations 347 This memo does not require any IANA action. 349 8. References 351 8.1. Normative References 353 [1] Vives, A., "Distributed Security Framework", 354 draft-vives-distsec-framework-00 (work in progress), 355 August 2005. 357 8.2. Informative References 359 [2] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 360 Neighbor Discovery (SEND)", RFC 3971, March 2005. 362 Author's Address 364 Pekka Savola 365 CSC/FUNET 366 Espoo 367 Finland 369 Email: psavola@funet.fi 371 Full Copyright Statement 373 Copyright (C) The Internet Society (2005). 375 This document is subject to the rights, licenses and restrictions 376 contained in BCP 78, and except as set forth therein, the authors 377 retain all their rights. 379 This document and the information contained herein are provided on an 380 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 381 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 382 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 383 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 384 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 385 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 387 Intellectual Property 389 The IETF takes no position regarding the validity or scope of any 390 Intellectual Property Rights or other rights that might be claimed to 391 pertain to the implementation or use of the technology described in 392 this document or the extent to which any license under such rights 393 might or might not be available; nor does it represent that it has 394 made any independent effort to identify any such rights. Information 395 on the procedures with respect to rights in RFC documents can be 396 found in BCP 78 and BCP 79. 398 Copies of IPR disclosures made to the IETF Secretariat and any 399 assurances of licenses to be made available, or the result of an 400 attempt made to obtain a general license or permission for the use of 401 such proprietary rights by implementers or users of this 402 specification can be obtained from the IETF on-line IPR repository at 403 http://www.ietf.org/ipr. 405 The IETF invites any interested party to bring to its attention any 406 copyrights, patents or patent applications, or other proprietary 407 rights that may cover technology that may be required to implement 408 this standard. Please address the information to the IETF at 409 ietf-ipr@ietf.org. 411 Acknowledgment 413 Funding for the RFC Editor function is currently provided by the 414 Internet Society.