INTERNET-DRAFT Kurt D. Zeilenga Intended Category: Informational OpenLDAP Foundation Expires: 12 May 2002 12 November 2001 Authentication Mechanisms Levels Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is intended to be, after appropriate review and revision, submitted to the RFC Editor as an Informational document. Distribution of this memo is unlimited. Comments may sent directly to the author . 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 . The list of Internet-Draft Shadow Directories can be accessed at . Copyright 2001, The Internet Society. All Rights Reserved. Please see the Copyright section near the end of this document for more information. Abstract Numerous authentication mechanisms are in use today on the Internet. It is desirable to give administrators the choice of which mechanisms to support in their deployments and to give users the choice which mechanisms to use. This document offers terminology designed to be easily understandable by users and administrators of Internet services while remaining meaningful to designers and developers of these services and associated Internet protocols. Zeilenga Authentication Mechanisms Levels [Page 1] INTERNET-DRAFT draft-zeilenga-auth-lvl-02 12 November 2001 Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119]. The terms "attack", "active attack", "passive attack", and "masquerade attack" are used as defined in FYI 36 [RFC2828] as follows: $ attack (I) An assault on system security that derives from an intelligent threat, i.e., an intelligent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system. - Active vs. passive: An "active attack" attempts to alter system resources or affect their operation. A "passive attack" attempts to learn or make use of information from the system but does not affect system resources. $ masquerade attack (I) A type of attack in which one system entity illegitimately poses as (assumes the identity of) another entity. This document use of other terms as defined in RFC 2828, excepting "strong" authentication (as this used as defined below). 1. Introduction There are many authentication mechanisms in use today on the Internet. These mechanisms range from no or very weak authentication to very strong authentication. Developers of internet applications and services often provide a wide range of authentication mechanisms to address differing demands from their user community. The choice of which mechanisms to use is often left to the service administrator and/or the user. While some administrators and even some users might have knowledge of the applicable security considerations for each mechanism available to them, this is often not the case. This document offers terminology designed to be easily understandable by users and administrators of Internet services while remaining meaningful to designers and developers of these services and associated Internet protocols. Zeilenga Authentication Mechanisms Levels [Page 2] INTERNET-DRAFT draft-zeilenga-auth-lvl-02 12 November 2001 2. Authentication Levels This document defines four levels of authentication mechanisms based upon the types of attacks they are prone to. In increasing strength, the four levels are: NONE - Prone to masquerade attacks. Also, absence of authentication (anonymous). WEAK - Prone to active and passive attacks, LIMITED - Prone to active attacks but resists passive attacks, and STRONG - Resists active and passive attacks. Use of STRONG authentication mechanisms is strongly RECOMMENDED, especially on the Internet. Use of LIMITED authentication mechanisms MAY be acceptable when the threat of active attack is minimal. WEAK or NONE (excepting anonymous) authentication mechanisms SHOULD NOT be used, especially on the Internet. Anonymous mechanisms may be used when and where appropriate. Additionally, mechanisms MAY be assigned reduced levels due to obsolescence or deprecation or other appropriate reasons. 3. Use of Authentication Levels It is intended that authentication levels be used to restrict the set of authentication used or allowed for a specific purpose. When enabling access to services or resources, mechanisms at or above the indicated level SHOULD be viewed as sufficient to grant access. That is, grant access at LIMITED indicates that use of LIMITED or higher is needed to grant access. When disabling access, mechanisms at or below the indicated level SHOULD be viewed as sufficient to deny access. That is, deny access at LIMITED indicates that use of LIMITED or lower is needed to deny access. 3.1. Authentication Levels in User Interfaces Interfaces can provide a means for the user to select authentication mechanisms to use by level. It is recommended that user also be given the ability to select specific mechanisms. As flaws can be found after development of an user interface, it is also recommended that the user be provided with a means for disabling a mechanism and/or lowering the level associated with the mechanism. Zeilenga Authentication Mechanisms Levels [Page 3] INTERNET-DRAFT draft-zeilenga-auth-lvl-02 12 November 2001 3.2. Authentication Levels in Administrative Interfaces Interfaces can provide a means for the administrator to select authentication mechanisms to allow by level. As flaws can be found after development of an administrative interface, it is also recommended that the administrator be provided with a means for disabling a mechanism and/or lowering the level associated with the mechanism. 3.3. Authentication Levels in Access Control Services Access control services can grant or deny access to resources based upon a number of factors. The level of authentication mechanism used to establish the user's identity may be used as a contributing factor to access control decisions. 4. Categorization of Authentication Mechanisms This section provides an example categorization of a few common authentication mechanisms based upon current accumulation of knowledge. As significant flaws can be discovered in the mechanism categorized below or in their implementation, the assigned authentication level of a particular implementation of a specific mechanism should be repeatedly reevaluated. 4.1. Anonymous Mechanisms Anonymous mechanisms provide no authentication (by design) and hence are categorize at level NONE. Example: SASL ANONYMOUS [RFC2245] 4.2. Non-verified Identity Mechanisms Non-verified identity mechanisms do not require information proving the claimed identity. Such mechanisms are categorized at level NONE. Examples: LDAP "unauthenticated" bind [RFC2251] and mechanism which use unauthenticated protocol elements such as IP source addresses. 4.3. Plain Password Mechanisms Zeilenga Authentication Mechanisms Levels [Page 4] INTERNET-DRAFT draft-zeilenga-auth-lvl-02 12 November 2001 Plain password mechanisms offer no protection from eavesdroppers. Such mechanisms are categorized at level WEAK. Examples: FTP USER/PASS [RFC959], POP3 USER/PASS [RFC1939] 4.4. Plain Password Mechanisms over Protected Transport Services The categorization of "protected" plain password mechanisms depends on ciphers used to protect transport services and the mechanisms used to establish cipher keys. Generally such mechanisms can be categorized as LIMITED or STRONG. Example: LDAP "simple" bind over TLS [RFC2829,RFC2830] 4.5. Simple Challenge-Response Mechanisms A number of simple Challenge-Response mechanisms have been developed over the years. These include a variety of simple mechanisms such as APOP [RFC1725] and CRAM-MD5 [RFC2195]. Though these mechanisms generally protect against eavesdropping and replay attacks, the mechanisms are subject to a variety of active attacks. Though this mechanisms could be categorized as LIMITED based upon their resistance to passive attacks, we categorize them as WEAK as they is generally viewed as deprecated in favor of DIGEST based mechanisms [RFC2831]. Example: IMAP/POP Challenge/Response [RFC2195] 4.6. Digest based Challenge-Response mechanisms Digest mechanisms protect against passive attacks but are subject to a number of active attacks. Digest mechanisms are categorized at level LIMITED. Example: HTTP Digest Access Authentication [RFC2617], SASL DIGEST-MD5 Mechanism [RFC2831] 4.7. One Time Passwords (OTP) OTP [RFC2289] based mechanisms generally only protect against passive eavesdropping and replay attacks but are subject to a number of active attacks. For these reasons, OTP based mechanisms are categorized at level LIMITED. Example: SASL One-Time-Password Mechanism [RFC2444] Zeilenga Authentication Mechanisms Levels [Page 5] INTERNET-DRAFT draft-zeilenga-auth-lvl-02 12 November 2001 4.8. Secure Remote Password (SRP) SRP [RFC2945] is a relatively new user/password based mechanism which resists passive attacks. SRP resists dictionary attacks. The mechanism also resists active attacks. For these reasons, it is categorized as a STRONG mechanism. Example: Telnet Authentication: SRP [RFC2944] 4.9. Kerberos V The Kerberos [RFC1510] authentication service resists both active and passive attacks, however Kerberos is prone to off-line dictionary attacks. There are mechanisms, such as pre-authentication, which may be used to resist such attacks. When such mechanisms are used, Kerberos V can be categorized as a STRONG mechanism. If such a mechanism is not in use (or it cannot be determined if one is in use), categorization at a lower level is appropriate. Example: SASL GSSAPI Mechanism [RFC2222] 4.10. Public Key based authentication In general, public key based authentication services resist both active and passive attacks and hence are categorized as a STRONG mechanism. Example: Simple Public Key GSS-API Mechanism [RFC2025] 4.11. SASL EXTERNAL The SASL EXTERNAL mechanism itself provides no authentication, but is a request to use an identity established by an underlying authentication mechanism. Hence, the authentication level of the EXTERNAL mechanism is the authentication level of underlying authentication mechanism. While it is common for the underlying authentication to be Public Key based authentication via TLS, it just as easily could be a non-verified identity mechanisms. EXTERNAL should be classified at the level of weakest underlying authentication mechanism which the application supports EXTERNAL use with. Example: BEEP SASL EXTERNAL [RFC3080] 5. Security Considerations Zeilenga Authentication Mechanisms Levels [Page 6] INTERNET-DRAFT draft-zeilenga-auth-lvl-02 12 November 2001 Security issues are discussed throughout this document. This section details additional security considerations which the reader should be aware of. Additional general security considerations related to authentication can be found in "On Internet Authentication" [RFC1704], as well as the "Users' Security Handbook" [RFC2504] and the "Site Security Handbook" [RFC2196]. 5.1. Confidentiality of Authentication Information It is often desirable to select an authentication mechanism which protects the confidentiality of authentication information. In some situations, services may be obligated by law to protect the privacy of the user. In such cases, use of a mechanism which protects the identity of the user from eavesdropping can be used. Authentication levels defined by this document are not indicative of the level of confidentiality of authentication information provided by the mechanism. 5.2. Data Integrity and Confidentiality It is often desirable to select an authentication mechanism based upon the kind of integrity and confidentiality services they provide after successful authentication. Mechanisms which provide data integrity protection are resistant against hijacking and similar attacks. Authentication levels defined by this document are not explicitly indicative of the kind of integrity and confidentiality services offered by the mechanism. However, most STRONG and many LIMITED mechanisms provide both integrity and confidential services. It may be appropriate categorize mechanisms which resist passive and active attacks but are subject to hijacking and similar attacks as LIMITED. 6. Acknowledgment This document is based upon input from numerous members of the IETF. 7. Author's Address Kurt D. Zeilenga OpenLDAP Foundation Zeilenga Authentication Mechanisms Levels [Page 7] INTERNET-DRAFT draft-zeilenga-auth-lvl-02 12 November 2001 8. Normative References [RFC1704] N. Haller, R. Atkinson, "On Internet Authentication", RFC 1704, October 1994. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14 (also RFC 2119), March 1997. [RFC2196] B. Fraser, "Site Security Handbook", FYI 8 (also RFC 2196), September 1997. [RFC2504] E. Guttman, L. Leong, G. Malkin, "Users' Security Handbook", FYI 34 (also RFC 2504), February 1999. [RFC2828] R. Shirey, "Internet Security Glossary", FYI 36 (also RFC 2828), May 2000. 9. Informative References [RFC959] J. Postel, J.K. Reynolds, "File Transfer Protocol", STD 9, October 1985. [RFC1510] J. Kohl, and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC1939] J. Myers, M. Rose, "Post Office Protocol - Version 3", STD 53, May 1996. [RFC2025] C. Adams, "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996. [RFC2195] J. Klensin, R. Catoe, and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997. [RFC2222] J. Myers, "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997 [RFC2244] C. Newman, "The One-Time-Password SASL Mechanism", RFC 2244, November 1997. [RFC2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2245] C. Newman, "Anonymous SASL Mechanism", RFC 2245, November 1997. Zeilenga Authentication Mechanisms Levels [Page 8] INTERNET-DRAFT draft-zeilenga-auth-lvl-02 12 November 2001 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000. [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000. [RFC2831] P. Leach, C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000. [RFC2944] T. Wu, "Telnet Authentication: SRP", RFC 2944, September 2000. [RFC2945] T. Wu, "The SRP Authentication and Key Exchange System", RFC 2944, September 2000. [RFC3080] M. Rose, "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. Full Copyright Copyright 2001, The Internet Society. 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 Zeilenga Authentication Mechanisms Levels [Page 9] INTERNET-DRAFT draft-zeilenga-auth-lvl-02 12 November 2001 "AS IS" basis and THE AUTHORS, 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. Zeilenga Authentication Mechanisms Levels [Page 10]