idnits 2.17.1 draft-iab-secwks-sec-guidelines-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == 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 Abstract section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security Considerations' ) ** 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 15 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 225: '...erations section MUST at a minimum inc...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (2 June 1997) is 9824 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: 'SK' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'ECS94' is defined on line 306, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellovin89' -- Possible downref: Non-RFC (?) normative reference: ref. 'CERT96' -- Possible downref: Non-RFC (?) normative reference: ref. 'NBS79' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSL' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHTTP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'SK' ** Obsolete normative reference: RFC 1244 (ref. 'HR91') (Obsoleted by RFC 2196) ** Obsolete normative reference: RFC 1750 (ref. 'ECS94') (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 1825 (ref. 'Atk95') (Obsoleted by RFC 2401) Summary: 16 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Atkinson, 2 Internet Draft Editor 3 2 June 1997 5 Guidelines for Writing RFC Text on 6 Security Considerations 8 Status of this Memo 10 This is an Internet Draft. Internet Drafts are publications of the 11 IETF, its working groups, and other non-IETF groups. This document 12 was created as output from the IAB Security Workshop held in early 13 1997. It is intended that the IESG or IAB would publish a revised 14 version of this document as an RFC in future. 16 Distribution of this memo is unlimited. 18 1. INTRODUCTION 20 This memo provides guidelines on how to write a useful "Security 21 Considerations" section for an RFC. It is intended to provide information 22 for RFC Authors and Editors in the hope of making their job easier. 24 Participants at the recent IAB Security Workshop came to consensus 25 that any new protocol must not worsen the overall security of The Internet. 26 The act of writing the "Security Considerations" section for a new protocol 27 or technology should cause the editor of that document to reflect on the 28 security issues and clearly document those issues. 30 A future version of this draft might be published as a Best Current 31 Practice (BCP) RFC by the IESG or Informational RFC by the IAB. 33 2. OBJECTIVES 35 The "Security Considerations" section of an RFC is a 36 mechanism via which the authors/editors of an RFC communicate to the 37 reader the security issues (including threats) of the RFC topic and 38 discuss mechanisms for mitigating or eliminating those threats. Each 39 risk reduction mechanism not documented directly in that RFC should 40 cite another RFC or document which describes the risk reduction 41 mechanism. 43 The "Security Considerations" should be readable and focused 44 on the matters discussed in that particular RFC. 46 After reading the "Security Considerations" of an RFC, the 47 reader should have a clear understanding of the threats, methods for 48 mitigating those threats, and the residual risks of deploying or 49 using the procedures, technology, or protocol described in that RFC. 50 The reader should be able to use the citations to further investigate 51 the potential risk reduction mechanisms. 53 [outline for the Security Section needed here] 55 Cyfi 57 3. DEFINITIONS 59 Access Control 60 The security service that protects against unauthorised 61 use of system resources. 63 Active Attack 64 An attack that is not a "passive attack". 66 Applicability Statement 67 A formal statement of the operational environment in which 68 a particular procedure, protocol, or technology is 69 reasonable to use. This statement should also clearly 70 indicate which operational environments are unreasonable 71 or inappropriate for that procedure, protocol, or 72 technology to be used. 74 Attack 75 A threat action that results from an intelligent threat. 76 An attack is an intentional act involving a means or 77 method of exploiting a vulnerability. Attacks might be 78 either passive or active. 80 Attacker 81 A malicious or hostile adversary with the motivation and 82 means to carry out an attack. 84 Authentication 85 The security service that verifies an identity claimed 86 by an entity. Note that in some situations, a particular 87 mechanism that provides authentication might also provide 88 integrity as an intrinsic by-product. Despite this, 89 authentication and integrity are conceptually separate 90 services. 92 Availability 93 The service ensuring that the network is accessible and 94 usable upon demand by an authorised entity. 96 Confidentiality 97 The security service that protects data from disclosure 98 to unauthorised entities. 100 Countermeasure 101 Something that reduces a threat or vulnerability by 102 eliminating or preventing it, by minimising the harm 103 it can cause, or by discovering and reporting it so 104 that corrective action can be taken. For example, 105 the vulnerability of a Cyclic Redundancy Check (CRC) 106 can be reduced by suitable cryptographic techniques. 108 Critical 109 A communications service is critical if its denial would 110 jeopardize its user's ability to perform a primary mission 111 function. 113 Denial of Service 114 A kind of attack where the adversary seeks to deny 115 a legitimate user access to some resource or service. 116 For example, disrupting routing could cause packets 117 to be lost or misdelivered, thus denying use of the 118 network to legitimate users. 120 Gateway 121 Usually a synonym for "router". 123 Hosts 124 Computers that run full Internet protocol stacks and 125 support application protocols. Hosts range from small 126 personal computers to large supercomputers. In some 127 communities these are considered 'end systems'. 129 Infrastructure 130 The Internet infrastructure includes networks, relays, 131 routers, and any necessary support hosts (e.g. those 132 hosts that provide DNS service). 134 Integrity 135 The security service that protects data from unauthorised 136 alteration or destruction. 138 Non-repudiation 139 The service that protects against false denial of 140 a communication. For example, this service would prevent 141 the sender of a signed email message from being able to 142 falsely deny sending that message. 144 Passive Attack 145 An attack that only observes the operation of network 146 elements to learn about them or observes data and 147 data traffic characteristics to learn the data's 148 semantic content. 150 Principle of Least Privilege 151 TBD 153 Risk 154 An expectation of loss expressed as the probability that 155 a particular threat will exploit a particular vulnerability 156 with a particular harmful result. 158 Risk Analysis 159 A systemic identification of valuable resources, threats, 160 and countermeasures along with quantification of the loss 161 exposures based on estimated frequencies and costs. 162 [NBS79, HR91] The analysis then lists risks 163 in order of cost and criticality, thereby determining 164 where countermeasures should be applied first. 166 Sensitive 167 Data is sensitive if its disclosure, alteration, or destruction 168 would adversely affect the interests or business of its owner 169 or user. There can be different degrees of sensitivity. 170 For example, compromise of some sensitive data might cause 171 a death while compromise of other sensitive data might merely 172 cause a brief disruption to normal operations. 174 Threat 175 A potential violation of security. A threat exists when 176 there is a circumstance, capability, or event that could 177 breach security and cause harm. Threats might be either 178 accidental or intentional. CERT Advisories document threats, 179 though not all threats are documented in CERT Advisories. 181 Vulnerability 182 A flaw or weakness in a system's security. A characteristic 183 that could be exploited to cause harm by disclosing, modifying, 184 or destroying functions or resources, or by denying service 185 to authorised users. Existence of a vulnerability creates 186 a threat. 188 4. MINIMAL THREAT ENVIRONMENT 190 [This section seems mis-organised] 192 This section describes the minimal threat environment 193 applicable to every RFC. Alternately put, any RFC written should 194 have a Security Considerations section that assumes the following 195 threats (at a minimum) exist. 197 Any class of attack described in a CERT Advisory or 198 equivalent is considered to be a legitimate potential threat. CERT 199 Advisories are quite predictable given knowledge of the threat. 200 Hence, CERT Advisories are considered an existence proof of the 201 threat, but do not constitute a threat analysis. 203 Other known kinds of attacks (e.g. from published magazine 204 articles, from conference papers) are also considered to be 205 legitimate potential threats. For example, many of the recently seen 206 attacks on the Internet use techniques and exploit vulnerabilities 207 described in the literature some years ago. [Bellovin89] 209 5. GUIDELINES 211 There should be a clear description of the kinds of threats 212 on the described protocol or technology. This should be approached 213 as an effort to perform "due diligence" in describing all known or 214 foreseeable risks and threats to potential implementers and users. 216 The methods via which those some or all of those threats are 217 mitigated or eliminated (e.g. firewalls, packet filtering, 218 encryption, cryptographic authentication) should be described along 219 with an indication of the extent to which the particular method 220 mitigates the risk. If external mechanisms (e.g. IPsec) are 221 identified for risk reduction, the relevant RFCs or other documents 222 should be cited so the reader knows where to obtain more information. 224 The threat environment addressed by the Security 225 Considerations section MUST at a minimum include deployment across 226 the global Internet across multiple administrative boundaries without 227 assuming that firewalls are in place. It is not acceptable to only 228 discuss threats applicable to LANs and ignore the broader threat 229 environment. All IETF standards-track protocols are considered 230 likely to have deployment in the global Internet. In some cases, 231 there might be an Applicability Statement discouraging use of a 232 technology or protocol in a particular environment. Nonetheless, the 233 security issues of broader deployment should be discussed in the 234 document. 236 There should be a clear description of the residual risk to 237 the user or operator of that protocol after threat mitigation has 238 been deployed. Such risks might arise from compromise in a related 239 protocol (e.g. IPsec is useless if key management has been 240 compromised), from incorrect implementation, compromise of the 241 security technology used for risk reduction (e.g. 40-bit DES), or 242 might be risks that are not addressed by the protocol specification 243 (e.g. denial of service attacks on an underlying link protocol). 245 There should also be some discussion of potential security 246 risks arising from obvious potential misapplications of the protocol 247 or technology described in the RFC. This might be coupled with an 248 Applicability Statement for that RFC. 250 6. EXAMPLES 252 An RFC discussing TCP should mention the SYN flooding denial of 253 service attacks and possible implementation strategies for reducing 254 that risk. [CERT96] 256 An RFC discussing HTTP should discuss the potential for 257 eavesdroppers to obtain credit card or other personal data when 258 security techniques are not in use. Such an RFC should also 259 recommend use of appropriate security techniques (e.g. SET, SSL, 260 SHTTP) to mitigate that threat. [SHTTP,SSL,SET] 262 An RFC discussing a security protocol might discuss common 263 implementation flaws so that implementers know how to avoid those. 264 [Atk95] 266 7. DESIGN SUGGESTIONS 268 When a protocol uses cryptography to provide some security 269 service, the protocol should be designed in a manner independent of 270 any particular cryptographic algorithm. This permits future 271 substitution of a new cryptographic algorithm for the originally 272 specified cryptographic algorithm if the original is broken. This 273 property is often referred to as "algorithm-independence". 275 Also, when a protocol relies on the randomness of some 276 number, it should clearly indicate what level of randomness is 277 required. If cryptographic randomness is required, it would be 278 reasonable to help implementers by citing a reference or two (e.g. 279 ECS94) on how to obtain such randomness. 281 REFERENCES 283 [Bellovin89] Stephen M. Bellovin, "Security Problems in the TCP/IP Protocol 284 Suite", ACM Computer Communications Review, Vol. 19, No. 2, ACM, 285 New York, NY, March 1989. 287 [CERT96] US DoD Computer Emergency Response Team, "TCP SYN Flooding Attacks", 288 CERT Advisory CA-96.21, 19 September 1996. ftp://info.cert.org/pub/ 289 cert_advisories/CA-96.21.tcp_syn_flooding 291 [NBS79] US National Bureau of Standards, "Guideline for Automatic Data 292 Processing and Risk Analysis", Federal Information Processing 293 Standard (FIPS) 65, National Bureau of Standards, Gaithersburg, 294 MD, USA, 1 August 1979. 296 [SSL] 297 [SHTTP] 298 [SET] 300 [SK] Robert W. Shirey & Stephen T. Kent, "Security Principles for 301 Internet Architecture". 303 [HR91] P. Holbrook, J. Reynolds, "Site Security Handbook", 304 RFC-1244, 23 July 1991. 306 [ECS94] D. Eastlake, S. Crocker, J. Schiller, "Randomness 307 Recommendations for Security", RFC-1750, 29 December 1994. 309 [Atk95] R. Atkinson, "IP Security Architecture", RFC-1825, 310 July 1995. 312 ACKNOWLEDGEMENTS 314 This note was written after the IAB Security Workshop held in 315 early 1997. Everyone at that workshop has contributed to this 316 document, either via email or in the discussions at that workshop. 317 Some of the specific text above is taken from an email message 318 written by Fred Baker. Virtually all of the definitions in Section 3 319 are excerpted with permission from a document "Security Principles 320 for Internet Architecture" by Robert W. Shirey and Stephen T. Kent 321 [SK]. 323 Any errors are the responsibility of the editor. 325 Editor's Addresses: 327 Randall Atkinson 329 @Home Network 330 385 Ravendale Drive 331 Mountain View, CA 94043 333 Voice: +1 (415) 944-7200