idnits 2.17.1 draft-zorn-eap-eval-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7863 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Glen Zorn 3 Internet-Draft Cisco Systems 4 Category: Standards Track October 2002 5 7 Specifying Security Claims for EAP Authentication Types 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This memo is an individual submission to the EAP Working Group. 31 Comments are welcome and should be submitted to the author. 33 Distribution of this memo is unlimited. It is filed as and expires April 28, 2003. 36 Copyright (C) The Internet Society 2002. All Rights Reserved. 38 Abstract 40 This document describes a method that may be used to enumerate the 41 claimed security qualities of EAP authentication types in terms of 42 well-defined objective qualities. These claims may then be used to 43 evaluate the claims against both the actual operation of the 44 authentication types themselves and the security requirements of 45 users (including other standards development organizations). 47 1. Requirements Language 49 In this document, the key words "MAY", "MUST", "MUST NOT", 50 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be 51 interpreted as described in [RFC2119]. 53 2. Defining Security Qualities 55 The terms relating to the security qualities of EAP Authentication 56 Types [RFC2284] MUST be defined in clear and unambiguous terms in a 57 publicly available document (e.g., [RFC2828]). The relevant terms 58 (i.e., those terms used to specify the security claims made; see 59 below) MUST be listed in the Terminology section of the Internet- 60 Draft or RFC defining the EAP Type, along with references to the 61 relevant documents. The authors of EAP Type specifications MAY 62 define new terms to describe the security qualities of the Type in 63 question, however all such definitions MUST be included in the 64 Terminology section as well. 66 3. Specifying Security Claims 68 All claims that the authors of EAP Authentication Type make with 69 respect to its security qualities MUST be listed and justified in the 70 Security Considerations section of the document describing the Type. 71 The claims MUST be made in terms of the qualities defined or 72 referenced in the Terminology section of the same document and SHOULD 73 be justified in as simple a manner as possible. Formal proofs are 74 encouraged; if provided, however, proofs SHOULD be relegated to an 75 appendix. The justifications included in the Security Considerations 76 section MUST stand alone and MUST be given in plain language (i.e., 77 justifications consisting of e.g. "See Appendix A.3" in toto are 78 unacceptable). If any of the claims are or later become unjustified, 79 those claims MUST be removed from the document describing the EAP 80 Type, if necessary by updating the RFC. 82 4. Evaluating the Security Claims of EAP Authentication Types 84 EAP Authentication Types can be evaluated in two ways using the 85 standard definitions: against their own operation (e.g., "Does the 86 type actually provide mutual authentication?") and against the 87 requirements of the users of the Authentication Type, provided that 88 those requirements are either stated or easily translatable to the 89 standard terms. The first evaluative mode will most likely be used 90 within the IETF itself, before the document in question attains RFC 91 status, while the second may be used to help understand the 92 suitability of a given Authentication Type in a certain environment, 93 or to compare Types. 95 5. Security Considerations 97 This document describes a method by which authentication methods may 98 be compared by using a set of claims against standard security 99 qualities. However, security "qualities" (in particular, immunity to 100 attack) are often difficult to demonstrate or prove; over time, new 101 attacks may be developed that invalidate formerly valid claims. 102 Therefore, it is important that security claims (and even proofs of 103 those claims) not be taken at face value, but scrutinized in light of 104 the most recent developments. 106 6. Normative References 108 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 109 Requirement Levels", BCP 14, RFC 2119, March 1997 111 [RFC2284] Blunk, L., J. Vollbrecht, "PPP Extensible Authentication 112 Protocol (EAP)", RFC 2284, March 1998 114 [RFC2828] R. Shirey, "Internet Security Glossary", FYI 36, RFC 2828, 115 May 2000 117 Acknowledgements 119 Author's Address 121 Questions about this memo can be directed to: 123 Glen Zorn 124 Cisco Systems, Inc. 125 500 108th Avenue N.E., Suite 500 126 Bellevue, WA 98004 127 USA 129 Phone: +1 425 471 4861 130 E-Mail: gwz@cisco.com 132 Full Copyright Statement 134 Copyright (C) The Internet Society (2002). All Rights Reserved. 136 This document and translations of it may be copied and furnished to 137 others, and derivative works that comment on or otherwise explain it 138 or assist in its implementation may be prepared, copied, published 139 and distributed, in whole or in part, without restriction of any 140 kind, provided that the above copyright notice and this paragraph are 141 included on all such copies and derivative works. However, this 142 document itself may not be modified in any way, such as by removing 143 the copyright notice or references to the Internet Society or other 144 Internet organizations, except as needed for the purpose of 145 developing Internet standards in which case the procedures for 146 copyrights defined in the Internet Standards process must be 147 followed, or as required to translate it into languages other than 148 English. The limited permissions granted above are perpetual and will 149 not be revoked by the Internet Society or its successors or assigns. 150 This document and the information contained herein is provided on an 151 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 152 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 153 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 154 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 155 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 157 Expiration Date 159 This document is filed as draft-zorn-eap-eval-00.txt and expires 160 April 28, 2003.