INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
Expires: 12 May 2002 12 November 2001
Authentication Mechanisms Levels
<draft-zeilenga-auth-lvl-02.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 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
<Kurt@OpenLDAP.org>
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]