Network Working Group Glen Zorn Internet-Draft Cisco Systems Category: Standards Track October 2002 <draft-zorn-eap-eval-00.txt> Specifying Security Claims for EAP Authentication Types Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This memo is an individual submission to the EAP Working Group. Comments are welcome and should be submitted to the author. Distribution of this memo is unlimited. It is filed as <draft-zorn- eap-eval-00.txt> and expires April 28, 2003. Copyright (C) The Internet Society 2002. All Rights Reserved. Abstract This document describes a method that may be used to enumerate the claimed security qualities of EAP authentication types in terms of well-defined objective qualities. These claims may then be used to evaluate the claims against both the actual operation of the authentication types themselves and the security requirements of Zorn [Page 1]
Internet-Draft EAP Type Security Claims October 2002 users (including other standards development organizations). 1. Requirements Language In this document, the key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 2. Defining Security Qualities The terms relating to the security qualities of EAP Authentication Types [RFC2284] MUST be defined in clear and unambiguous terms in a publicly available document (e.g., [RFC2828]). The relevant terms (i.e., those terms used to specify the security claims made; see below) MUST be listed in the Terminology section of the Internet- Draft or RFC defining the EAP Type, along with references to the relevant documents. The authors of EAP Type specifications MAY define new terms to describe the security qualities of the Type in question, however all such definitions MUST be included in the Terminology section as well. 3. Specifying Security Claims All claims that the authors of EAP Authentication Type make with respect to its security qualities MUST be listed and justified in the Security Considerations section of the document describing the Type. The claims MUST be made in terms of the qualities defined or referenced in the Terminology section of the same document and SHOULD be justified in as simple a manner as possible. Formal proofs are encouraged; if provided, however, proofs SHOULD be relegated to an appendix. The justifications included in the Security Considerations section MUST stand alone and MUST be given in plain language (i.e., justifications consisting of e.g. "See Appendix A.3" in toto are unacceptable). If any of the claims are or later become unjustified, those claims MUST be removed from the document describing the EAP Type, if necessary by updating the RFC. 4. Evaluating the Security Claims of EAP Authentication Types EAP Authentication Types can be evaluated in two ways using the standard definitions: against their own operation (e.g., "Does the type actually provide mutual authentication?") and against the requirements of the users of the Authentication Type, provided that those requirements are either stated or easily translatable to the Zorn [Page 2]
Internet-Draft EAP Type Security Claims October 2002 standard terms. The first evaluative mode will most likely be used within the IETF itself, before the document in question attains RFC status, while the second may be used to help understand the suitability of a given Authentication Type in a certain environment, or to compare Types. 5. Security Considerations This document describes a method by which authentication methods may be compared by using a set of claims against standard security qualities. However, security "qualities" (in particular, immunity to attack) are often difficult to demonstrate or prove; over time, new attacks may be developed that invalidate formerly valid claims. Therefore, it is important that security claims (and even proofs of those claims) not be taken at face value, but scrutinized in light of the most recent developments. 6. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC2284] Blunk, L., J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998 [RFC2828] R. Shirey, "Internet Security Glossary", FYI 36, RFC 2828, May 2000 Acknowledgements Author's Address Questions about this memo can be directed to: Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 USA Phone: +1 425 471 4861 E-Mail: gwz@cisco.com Zorn [Page 3]
Internet-Draft EAP Type Security Claims October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expiration Date This document is filed as draft-zorn-eap-eval-00.txt and expires April 28, 2003. Zorn [Page 4]