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 <rja@home.net>
@Home Network
385 Ravendale Drive
Mountain View, CA 94043
Voice: +1 (415) 944-7200
Expires in 6 months [Page 8]
