One document matched: draft-zorn-eap-eval-00.txt

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]