One document matched: draft-irtf-cfrg-advice-00.txt
Crypto Forum Research Group C. Meadows
Internet Draft NRL
Document: draft-irtf-cfrg-advice-00.txt October 2002
Category: Informational
Expires: April 2003
Advice on Writing an Internet Draft Amenable to Security Analysis
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [2].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
In this document we give guidelines for writing Internet Drafts in
order to facilitate their security analysis. By "security analysis"
we mean, not only informal analyses, but formal analyses using
automated tools, and mathematical analysis of the cryptographic
protocols used in an Internet Draft.
Table of Contents
1. Introduction.............................................2
2. What is a Security Analysis?.............................3
3. Information Needed for a Security Analysis...............4
3.1 Types of Information Needed..............................4
3.2 What a Protocol Does and How it Operates.................4
3.3 Protocol Environment.....................................4
Meadows [Page 1]
INTERNET DRAFT October 2002
3.3.1 Specification of Security Services Used by the
Protocol.............................................4
3.3.2 Specification of the Attacker............................5
3.4 Protocol Security Requirements...........................5
4 Conclusion.................................................7
Security Considerations........................................7
References.....................................................7
1. Introduction
The acceptance of a protocol as a standard can be greatly speeded up
by having a good security analysis done early on. Since not all
Internet Draft writers are experts in security analysis, it often
makes sense to have such an analysis done by outside experts.
Moreover, the use of independent experts to perform a security
analysis can provide added credibility that can also help speed a
draft through the standardization process.
Unfortunately, most Internet Drafts are not written in a way to make
such an analysis easy. Information that is crucial to the analysis,
such as the nature of the threat environment, what security services
a protocol provides or depends upon, and the security requirements
for the protocol, may be left out or only described in vague terms.
In this document we provide some guidelines for writing Internet
Drafts that are amenable to security analysis.
Much of the information in this document is based on the author's own
experience in applying formal methods to the analysis [5,6] of IETF
security protocols such as IKE [3] and GDOI [1]. However, most of
the information that we provide is general enough so that we believe
that it could be applied to informal security analyses, as well as,
to a certain extent, cryptographic analysis of a security protocol
used in an Internet Draft.
Moreover, although the primary aim of this document is to facilitate
the writing of security protocols that use cryptography, we believe
that it also provides useful information to writers of Internet
Drafts describing protocols that are not directly involved in
security. Even when a protocol is not used to enforce security
properties itself, it may depend upon other protocols for security
services, and it is necessary to ascertain that it uses them
correctly. Furthermore, certain security issues such as denial of
service are relevant to all protocols, whether or not they are
directly involved in enforcing security. In all such cases, a
security analysis can be helpful.
Meadows [Page 2]
INTERNET DRAFT October 2002
2. What is a Security Analysis?
Briefly, a security analysis is an assessment of how well a protocol
performs its functions in face of a hostile intruder. A security
analysis can be applied at a very low level of abstraction (e.g. an
analysis of the cryptographic algorithms used by the protocol) or at
a very high level (e.g. a security analysis of the protocol
architecture). But what all of these have in common is that they
provide evidence that, given certain assumptions about a protocol's
requirements, and certain assumptions about the capability of the
intruder and about the environment in which a protocol operates, an
intruder cannot prevent a protocol from performing its critical
functions.
In general, there are three major types of security analyses:
informal, formal analyses that may or may not make use of automated
tools, and what we will loosely call "reduction-based." In an
informal analysis, one usually posits a set of attack scenarios and
provides informal arguments that the scenarios are not feasible. In
a formal analysis one builds a logical model of the system and
defines what is meant by a secure or insecure state or condition. One
either uses logical means (either with or without automated
assistance) to demonstrate that the insecure states unreachable, or
uses an automated tool such as a model checker to generate attack
scenarios. In a reduction-based analysis, one describes an intruder
with very general capabilities, and then provides a mathematical
proof that the intruder's breaking the protocol would be equivalent
to solving an intractable problem.
All three approaches have their advantages and disadvantages. An
informal analyses provides less assurance than the other two kinds,
but on the other hand it also may provide greater scope, since there
are security problems that we do not yet know how to model
mathematically. A formal analysis provides a greater degree of
assurance than an informal one, but it relies on assumptions about
the cryptographic algorithms used that may not be possible to verify.
A reduction-based analysis can be used to provide assurance the
cryptographic part of the protocol is sound, but may not be
applicable to evaluating the way in which a protocol is used. For
example, it may be possible to demonstrate mathematically that a
protocol authenticates information correctly, but not whether or not
it authenticates the information that is necessary for it to perform
its security services, since this will depend upon the correct
definition of the security services as well.
Since no type of analysis provides a panacea, having all three types
can provide real benefits. However, even if only one type of analysis
is done, it can still provide helpful information for the protocol
Meadows [Page 3]
INTERNET DRAFT October 2002
designers.
3. Information Needed for a Security Analysis.
3.1 Types of information needed
In general, there are three types of information that need to be
provided for a security analysis: information on what the protocol
does and how it operates, information on the environment in which a
protocol operates (including information about the expected
attackers), and information about the protocol's security
requirements. In this section we will consider each of these types of
information in detail.
3.2 What a Protocol Does and How it Operates
Internet Drafts are generally written with the protocol implementer
and interoperability in mind. Thus, although they may provide
detailed information about formatting and other information necessary
to interoperability, they tend to leave out some higher-level
information that could be helpful in a security analysis. In
particular:
1. Who or what are the principals involved in the protocol? What are
the identifiers bound to? If cryptographic information (e.g. keys)
is involved, what is it bound to?
2. How does a protocol behave in the case of failure? In many cases
failure modes can be exploited in denial of service attacks.
3. What information are the principals expected to know at the
beginning of the protocol? For example, what information are the
principals expected to know about each other before the protocol
begins?
3.3 Protocol Environment
There are two things that are most important to know about a
protocol's environment when doing a security analysis. One is what
security services a protocol obtains from other protocols. The other
is the goals and capabilities of any intruder that may be present. In
this section we describe the requirements for both of these in
detail.
3.3.1 Specification of Security Services Used by the Protocol
Often a protocol relies upon other protocols for security services.
If that is the case, it is helpful if it is stated exactly what
Meadows [Page 4]
INTERNET DRAFT October 2002
services are supplied by the other protocol. For example, if the
protocol relies upon IPSeC for authentication, but not for
encryption, this should be stated. It should also be made clear
where and how IPSeC is to be applied.
In many cases, a draft will leave the question open as to which
protocol it will rely upon to supply security service. In such a
case, it should be made clear that this is the case. However, it
should still be made clear what security services are expected, and,
as much as possible, how they are to be provided.
3.3.2 Specification of the Attacker
Protocols will be designed to be resistant to attackers of various
degrees of strength, and it is important to have this information in
order for an analysis to be useful. In general a protocol will be
designed so that different security properties may be secure against
attackers of different strengths, so one may have to specify
different classes of attacker. This will be covered in more detail in
Section 3.4.
Below, we give some of the questions that one may ask about an
attacker.
1. What are the attacker's capabilities? Can it read old traffic,
read traffic in real time, or intercept and alter traffic?
2. What parts of the systems may be vulnerable? Can old keys be
compromised? Can previously honest principals go bad?
3. What are the attacker's resources? Does it control part of the
network? Are any assumptions made about the computational resources
of the attacker?
4. What are the attacker's goals assumed to be? Is it to find out
information, to impersonate other principals, to disrupt the network?
Is there a threshold of effort above which we may assume that the
attacker will consider the goal not worth the trouble?
3.4 Protocol Security Requirements
It is very important to give the security requirements of a protocol.
There are numerous cases of "attacks" being found in a security
analysis of a protocol, which, after consultation with the protocol's
designers, turned out to be attacks on requirements that had never
intended to be guaranteed. Specifying your requirements up front can
save time and embarrassment.
Meadows [Page 5]
INTERNET DRAFT October 2002
For any requirement, it is necessary to be explicit about the type of
attacker against which that requirement is intended to be guarantee
security. The specification of attacker can be on a per-requirement
basis. For example, one might design a protocol to protect secret
keys against a very strong attacker, but anonymity against a
relatively weak attacker. The granularity of the mapping from
requirement to attacker can be quite fine. For example, IKEv2 [4]
protects the initiator's identity against an active attacker, but the
responder's identity only against a passive attacker.
The three main classes of security requirements are secrecy,
authentication, and availability. We consider each of these in more
detail.
Secrecy:
Which data are intended to be kept secret? Who is supposed to be
allowed to know the secret? Are there any conditions that must be
satisfied before a principal can learn a secret? Are there any
conditions under which a secret may be revealed to the world at
large?
Authentication:
What data or properties of data are intended to be authenticated? Is
it origin of data, timeliness of data, the intended purpose of the
data, or some other property? If it is origin of data, who is the
originator? If it is the timeliness of the data, what timeliness
properties are being guaranteed? Is it the age of the data (i.e.
when it was created), the fact that the data has not been used before
(replay prevention), the fact that the data was created later than
some other data, or some other property? Finally, if it is the
intended purpose of the data that is being authenticated, then this
too needs to be spelled out. Who is the data intended for? Is there
other data to which it is relevant, and if so, what is it and how is
the relationship to be authenticated?
Availability:
A protocol will generally need to have some mechanisms for resisting
denial of service attacks. What types of services is the protocol
intended to be able to provide under attack, and against what kind of
attacker? Is the service intended to be secure against resource
exhaustion attacks, or is it intended to be secure against more
sophisticated redirection attacks as well? How is the protocol
supposed to behave under attack? Are services intended to degrade
gracefully under attack, and if so, how?
Meadows [Page 6]
INTERNET DRAFT October 2002
4. Conclusion
In this document we have listed some of the information that could be
included in an Internet Draft to make security analysis easier. It
is not intended to be complete, but to provide a starting point for
someone who is might be interested in having a security analysis done
on their draft.
Security Considerations
We make no claim that following the principles outlined in this
document will guarantee security, merely that they will facilitate a
security analysis. However, thinking about the questions we have
raised should help a draft writer keep a clear idea of the security
objectives that he or she has in mind.
References
[1] Baugher, M., T. Hardjono, H. Harney, and B. Weis. The Group
Domain of Interpretation. Internet Engineering Task Force, draft-
ietf-msec-gdoi-06.txt, October 2002.
[2] Bradner, S. The Internet Standards Process -- Revision 3. BCP 9,
RFC 2026, October 1996.
[3] Harkins, D. and D. Carrel. The Internet Key Exchange (IKE). RFC
2409, November 1998.
[4] Kaufman, C. Internet Key Exchange (IKEv2) Protocol. Internet
Engineering Task Force, RFC 2409, November 1998.
[5] C. Meadows. "Analysis of the Internet Key Exchange Protocol Using
the NRL Protocol Analyzer." Proceedings of the 1999 IEEE Symposium on
Security and Privacy, IEEE Computer Society Press, May 1999.
[6] C. Meadows, P. Syverson, and I. Cervesato. "Formal Specification
and Analysis of the Group Domain of Interpretation Protocol Using
NPATRL and the NRL Protocol Analyzer." Submitted for publication,
2002.
Author's Address:
Catherine Meadows
Naval Research Laboratory
Code 5543
Washington, DC 20375
Email: meadows@itd.nrl.navy.mil
Meadows [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 06:03:51 |