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]
