INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
Expires: 25 October 2001 25 April 2001
Authentication Mechanisms Levels
<draft-zeilenga-auth-lvl-01.txt>
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 <Kurt@OpenLDAP.org>.
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>.
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 being meaningful to designers and developers of these
services and associated Internet protocols.
Zeilenga Authentication Mechanisms Levels [Page 1]
INTERNET-DRAFT draft-zeilenga-auth-lvl-01 25 April 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 RFC 2119 [RFC2119].
The terms "attack", "active attack", "passive attack", and "masquerade
attack" are used as defined in RFC 2828 [RFC2828]:
$ 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 being
meaningful to designers and developers of these services and
associated Internet protocols.
Zeilenga Authentication Mechanisms Levels [Page 2]
INTERNET-DRAFT draft-zeilenga-auth-lvl-01 25 April 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. Use of
WEAK or NONE (excepting anonymous) authentication mechanisms SHOULD
NOT be used, especially on the Internet. Use of anonymous mechanisms
SHOULD only be used for read-only access to non-sensitive information.
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.
When disabling access, mechanisms at or below the indicated level
SHOULD be viewed as sufficient 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 may 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.
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 may be found
after development of an administrative interface, it is also
Zeilenga Authentication Mechanisms Levels [Page 3]
INTERNET-DRAFT draft-zeilenga-auth-lvl-01 25 April 2001
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 can 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 may 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
Plain password mechanisms offer no protection from eavesdroppers.
Such mechanisms are categorized at level WEAK.
Examples: FTP USER/PASS [RFC959], POP3 USER/PASS [RFC1939]
Zeilenga Authentication Mechanisms Levels [Page 4]
INTERNET-DRAFT draft-zeilenga-auth-lvl-01 25 April 2001
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.
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]
4.8. Secure Remote Password (SRP)
SRP [RFC2945] is a relatively new user/password based mechanism which
resists passive attacks, including passive dictionary attacks. The
Zeilenga Authentication Mechanisms Levels [Page 5]
INTERNET-DRAFT draft-zeilenga-auth-lvl-01 25 April 2001
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 and hence is categorized as a STRONG mechanism.
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
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].
Zeilenga Authentication Mechanisms Levels [Page 6]
INTERNET-DRAFT draft-zeilenga-auth-lvl-01 25 April 2001
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.
6. Acknowledgment
This document is based upon input from numerous members of the IETF.
7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
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.
[RFC1704] N. Haller, R. Atkinson, "On Internet Authentication", RFC
1704, October 1994.
Zeilenga Authentication Mechanisms Levels [Page 7]
INTERNET-DRAFT draft-zeilenga-auth-lvl-01 25 April 2001
[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.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, March 1997.
[RFC2195] J. Klensin, R. Catoe, and P. Krumviede, "IMAP/POP AUTHorize
Extension for Simple Challenge/Response", RFC 2195,
September 1997.
[RFC2196] B. Fraser, "Site Security Handbook", FYI 8, 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.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2504] E. Guttman, L. Leong, G. Malkin, "Users' Security Handbook",
FYI 34, February 1999.
[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.
[RFC2828] R. Shirey, "Internet Security Glossary", FYI 36, May 2000.
[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.
Zeilenga Authentication Mechanisms Levels [Page 8]
INTERNET-DRAFT draft-zeilenga-auth-lvl-01 25 April 2001
[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
"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 9]