Network Working Group R. Atkinson, Internet Draft Editor 2 June 1997 Guidelines for Writing RFC Text on Security Considerations Status of this Memo This is an Internet Draft. Internet Drafts are publications of the IETF, its working groups, and other non-IETF groups. This document was created as output from the IAB Security Workshop held in early 1997. It is intended that the IESG or IAB would publish a revised version of this document as an RFC in future. Distribution of this memo is unlimited. 1. INTRODUCTION This memo provides guidelines on how to write a useful "Security Considerations" section for an RFC. It is intended to provide information for RFC Authors and Editors in the hope of making their job easier. Participants at the recent IAB Security Workshop came to consensus that any new protocol must not worsen the overall security of The Internet. The act of writing the "Security Considerations" section for a new protocol or technology should cause the editor of that document to reflect on the security issues and clearly document those issues. A future version of this draft might be published as a Best Current Practice (BCP) RFC by the IESG or Informational RFC by the IAB. 2. OBJECTIVES The "Security Considerations" section of an RFC is a mechanism via which the authors/editors of an RFC communicate to the reader the security issues (including threats) of the RFC topic and discuss mechanisms for mitigating or eliminating those threats. Each risk reduction mechanism not documented directly in that RFC should cite another RFC or document which describes the risk reduction mechanism. Expires in 6 months [Page 1] Internet Draft IP/CM Test Plan 2 June 1997 The "Security Considerations" should be readable and focused on the matters discussed in that particular RFC. After reading the "Security Considerations" of an RFC, the reader should have a clear understanding of the threats, methods for mitigating those threats, and the residual risks of deploying or using the procedures, technology, or protocol described in that RFC. The reader should be able to use the citations to further investigate the potential risk reduction mechanisms. [outline for the Security Section needed here] Cyfi 3. DEFINITIONS Access Control The security service that protects against unauthorised use of system resources. Active Attack An attack that is not a "passive attack". Applicability Statement A formal statement of the operational environment in which a particular procedure, protocol, or technology is reasonable to use. This statement should also clearly indicate which operational environments are unreasonable or inappropriate for that procedure, protocol, or technology to be used. Attack A threat action that results from an intelligent threat. An attack is an intentional act involving a means or method of exploiting a vulnerability. Attacks might be either passive or active. Attacker A malicious or hostile adversary with the motivation and means to carry out an attack. Authentication The security service that verifies an identity claimed by an entity. Note that in some situations, a particular mechanism that provides authentication might also provide integrity as an intrinsic by-product. Despite this, Expires in 6 months [Page 2] Internet Draft IP/CM Test Plan 2 June 1997 authentication and integrity are conceptually separate services. Availability The service ensuring that the network is accessible and usable upon demand by an authorised entity. Confidentiality The security service that protects data from disclosure to unauthorised entities. Countermeasure Something that reduces a threat or vulnerability by eliminating or preventing it, by minimising the harm it can cause, or by discovering and reporting it so that corrective action can be taken. For example, the vulnerability of a Cyclic Redundancy Check (CRC) can be reduced by suitable cryptographic techniques. Critical A communications service is critical if its denial would jeopardize its user's ability to perform a primary mission function. Denial of Service A kind of attack where the adversary seeks to deny a legitimate user access to some resource or service. For example, disrupting routing could cause packets to be lost or misdelivered, thus denying use of the network to legitimate users. Gateway Usually a synonym for "router". Hosts Computers that run full Internet protocol stacks and support application protocols. Hosts range from small personal computers to large supercomputers. In some communities these are considered 'end systems'. Infrastructure The Internet infrastructure includes networks, relays, routers, and any necessary support hosts (e.g. those hosts that provide DNS service). Integrity The security service that protects data from unauthorised alteration or destruction. Expires in 6 months [Page 3] Internet Draft IP/CM Test Plan 2 June 1997 Non-repudiation The service that protects against false denial of a communication. For example, this service would prevent the sender of a signed email message from being able to falsely deny sending that message. Passive Attack An attack that only observes the operation of network elements to learn about them or observes data and data traffic characteristics to learn the data's semantic content. Principle of Least Privilege TBD Risk An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result. Risk Analysis A systemic identification of valuable resources, threats, and countermeasures along with quantification of the loss exposures based on estimated frequencies and costs. [NBS79, HR91] The analysis then lists risks in order of cost and criticality, thereby determining where countermeasures should be applied first. Sensitive Data is sensitive if its disclosure, alteration, or destruction would adversely affect the interests or business of its owner or user. There can be different degrees of sensitivity. For example, compromise of some sensitive data might cause a death while compromise of other sensitive data might merely cause a brief disruption to normal operations. Threat A potential violation of security. A threat exists when there is a circumstance, capability, or event that could breach security and cause harm. Threats might be either accidental or intentional. CERT Advisories document threats, though not all threats are documented in CERT Advisories. Vulnerability A flaw or weakness in a system's security. A characteristic that could be exploited to cause harm by disclosing, modifying, or destroying functions or resources, or by denying service to authorised users. Existence of a vulnerability creates Expires in 6 months [Page 4] Internet Draft IP/CM Test Plan 2 June 1997 a threat. 4. MINIMAL THREAT ENVIRONMENT [This section seems mis-organised] This section describes the minimal threat environment applicable to every RFC. Alternately put, any RFC written should have a Security Considerations section that assumes the following threats (at a minimum) exist. Any class of attack described in a CERT Advisory or equivalent is considered to be a legitimate potential threat. CERT Advisories are quite predictable given knowledge of the threat. Hence, CERT Advisories are considered an existence proof of the threat, but do not constitute a threat analysis. Other known kinds of attacks (e.g. from published magazine articles, from conference papers) are also considered to be legitimate potential threats. For example, many of the recently seen attacks on the Internet use techniques and exploit vulnerabilities described in the literature some years ago. [Bellovin89] 5. GUIDELINES There should be a clear description of the kinds of threats on the described protocol or technology. This should be approached as an effort to perform "due diligence" in describing all known or foreseeable risks and threats to potential implementers and users. The methods via which those some or all of those threats are mitigated or eliminated (e.g. firewalls, packet filtering, encryption, cryptographic authentication) should be described along with an indication of the extent to which the particular method mitigates the risk. If external mechanisms (e.g. IPsec) are identified for risk reduction, the relevant RFCs or other documents should be cited so the reader knows where to obtain more information. The threat environment addressed by the Security Considerations section MUST at a minimum include deployment across the global Internet across multiple administrative boundaries without assuming that firewalls are in place. It is not acceptable to only discuss threats applicable to LANs and ignore the broader threat Expires in 6 months [Page 5] Internet Draft IP/CM Test Plan 2 June 1997 environment. All IETF standards-track protocols are considered likely to have deployment in the global Internet. In some cases, there might be an Applicability Statement discouraging use of a technology or protocol in a particular environment. Nonetheless, the security issues of broader deployment should be discussed in the document. There should be a clear description of the residual risk to the user or operator of that protocol after threat mitigation has been deployed. Such risks might arise from compromise in a related protocol (e.g. IPsec is useless if key management has been compromised), from incorrect implementation, compromise of the security technology used for risk reduction (e.g. 40-bit DES), or might be risks that are not addressed by the protocol specification (e.g. denial of service attacks on an underlying link protocol). There should also be some discussion of potential security risks arising from obvious potential misapplications of the protocol or technology described in the RFC. This might be coupled with an Applicability Statement for that RFC. 6. EXAMPLES An RFC discussing TCP should mention the SYN flooding denial of service attacks and possible implementation strategies for reducing that risk. [CERT96] An RFC discussing HTTP should discuss the potential for eavesdroppers to obtain credit card or other personal data when security techniques are not in use. Such an RFC should also recommend use of appropriate security techniques (e.g. SET, SSL, SHTTP) to mitigate that threat. [SHTTP,SSL,SET] An RFC discussing a security protocol might discuss common implementation flaws so that implementers know how to avoid those. [Atk95] 7. DESIGN SUGGESTIONS When a protocol uses cryptography to provide some security service, the protocol should be designed in a manner independent of any particular cryptographic algorithm. This permits future substitution of a new cryptographic algorithm for the originally specified cryptographic algorithm if the original is broken. This property is often referred to as "algorithm-independence". Expires in 6 months [Page 6] Internet Draft IP/CM Test Plan 2 June 1997 Also, when a protocol relies on the randomness of some number, it should clearly indicate what level of randomness is required. If cryptographic randomness is required, it would be reasonable to help implementers by citing a reference or two (e.g. ECS94) on how to obtain such randomness. REFERENCES [Bellovin89] Stephen M. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, ACM, New York, NY, March 1989. [CERT96] US DoD Computer Emergency Response Team, "TCP SYN Flooding Attacks", CERT Advisory CA-96.21, 19 September 1996. ftp://info.cert.org/pub/ cert_advisories/CA-96.21.tcp_syn_flooding [NBS79] US National Bureau of Standards, "Guideline for Automatic Data Processing and Risk Analysis", Federal Information Processing Standard (FIPS) 65, National Bureau of Standards, Gaithersburg, MD, USA, 1 August 1979. [SSL] [SHTTP] [SET] [SK] Robert W. Shirey & Stephen T. Kent, "Security Principles for Internet Architecture". [HR91] P. Holbrook, J. Reynolds, "Site Security Handbook", RFC-1244, 23 July 1991. [ECS94] D. Eastlake, S. Crocker, J. Schiller, "Randomness Recommendations for Security", RFC-1750, 29 December 1994. [Atk95] R. Atkinson, "IP Security Architecture", RFC-1825, July 1995. Expires in 6 months [Page 7] Internet Draft IP/CM Test Plan 2 June 1997 ACKNOWLEDGEMENTS This note was written after the IAB Security Workshop held in early 1997. Everyone at that workshop has contributed to this document, either via email or in the discussions at that workshop. Some of the specific text above is taken from an email message written by Fred Baker. Virtually all of the definitions in Section 3 are excerpted with permission from a document "Security Principles for Internet Architecture" by Robert W. Shirey and Stephen T. Kent [SK]. Any errors are the responsibility of the editor. Editor's Addresses: Randall Atkinson @Home Network 385 Ravendale Drive Mountain View, CA 94043 Voice: +1 (415) 944-7200 Expires in 6 months [Page 8]