WDIFF

draft-ietf-ldapbis-authmeth-08.txt --> draft-ietf-ldapbis-authmeth-09.txt

INTERNET-DRAFT Editor: R. Harrison
draft-ietf-ldapbis-authmeth-08.txt
draft-ietf-ldapbis-authmeth-09.txt Novell, Inc.
Obsoletes: 2251, 2829, 2830 26 October 5 December 2003
Intended Category: Draft Standard

LDAP: Authentication Methods
and
Connection Level Security Mechanisms

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 a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of
this document will take place on the IETF LDAP Extension Working
Group mailing list <ietf-ldapbis@OpenLDAP.org>. Please send
editorial comments directly to the author
<roger_harrison@novell.com>.

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.

Abstract

This document describes authentication methods and connection level
security mechanisms of the Lightweight Directory Access Protocol
(LDAP).

This document details the simple Bind authentication method
including anonymous, unauthenticated, and plain-text password
methods and the SASL (Simple Authentication and Security Layer) Bind
authentication method including the use of DIGEST-MD5 and EXTERNAL
mechanisms.

Harrison Expires April June 2004 [Page 1]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

This document also details establishment of TLS (Transport Layer
Security) using the Start TLS operation.

This document describes various authentication and authorization
states through which a connection to an LDAP server may pass and the
actions that trigger these state changes.

This document also prescribes DIGEST-MD5 as LDAP's mandatory-to-
implement strong authentication mechanism.

1. Introduction

The Lightweight Directory Access Protocol (LDAP) [Protocol] is a
powerful access protocol for directories. It offers means of
searching, retrieving and manipulating directory content, and ways
to access a rich set of security functions.

It is vital that these security functions be interoperable among all
LDAP clients and servers on the Internet; therefore there has to be
a minimum subset of security functions that is common to all
implementations that claim LDAP conformance.

Basic threats to an LDAP directory service include:

(1) Unauthorized access to directory data via data-retrieval
operations,

(2) Unauthorized access to reusable client authentication
information by monitoring others' access,

(3) Unauthorized access to directory data by monitoring others'
access,

(4) Unauthorized modification of directory data,

(5) Unauthorized modification of configuration information,

(6) Unauthorized or excessive use of resources (denial of service),
and

(7) Spoofing of directory: Tricking a client into believing that
information came from the directory when in fact it did not,
either by modifying data in transit or misdirecting the client's
connection. Also, tricking a client into sending privileged
information to a hostile entity that appears to be the directory
but is not.

Threats (1), (4), (5) and (6) are due to hostile clients. Threats
(2), (3) and (7) are due to hostile agents on the path between
client and server or hostile agents posing as a server.

LDAP can be protected with the following security mechanisms:

Harrison Expires April 2004 [Page 2]

Internet-Draft LDAP Authentication Methods 7 October 2003

(1) Client authentication by means of the Secure Authentication and
Security Layer (SASL) [SASL] mechanism set, possibly backed by
the Transport Layer Security (TLS) [TLS] credentials exchange
mechanism,

Harrison Expires June 2004 [Page 2]

Internet-Draft LDAP Authentication Methods 5 December 2003

(2) Client authorization by means of access control based on the
requestor's authenticated identity,

(3) Data integrity protection by means of TLS or SASL mechanisms
with security layers that provide data integrity services,

(4) Data confidentiality protection against snooping by means of the
TLS protocol or SASL mechanisms that provide data
confidentiality services,

(5) Server resource usage limitation by means of administrative
service limits configured on the server, and

(6) Server authentication by means of the TLS protocol or SASL
mechanism.

At the moment, imposition of access controls is done by means
outside the scope of LDAP.

It seems clear that allowing any implementation, faced with the
above requirements, to simply pick and choose among the possible
alternatives is not a strategy that is likely to lead to
interoperability. In the absence of mandates, clients will be
written that do not support any security function supported by the
server, or worse, they will support only mechanisms like the LDAP
simple bind using clear text passwords that provide inadequate
security for most circumstances.

Given the presence of the Directory, there is a strong desire to see
mechanisms where identities take the form of an LDAP distinguished
name [LDAPDN] and authentication data can be stored in the
directory. This means that this data must be updated outside the
protocol or only updated in sessions well protected against
snooping. It is also desirable to allow authentication methods to
carry authorization identities based on existing--non-LDAP DN--forms
of not represented as LDAP DNs that are familiar to
the user identities for backwards compatibility with non-LDAP-based
authentication services. or that are used in other systems.

The set of security mechanisms provided in LDAP and described in
this document is intended to meet the security needs for a wide
range of deployment scenarios and still provide a high degree of
interoperability among various LDAP implementations and
deployments. Appendix A contains example deployment scenarios that
list the mechanisms that might be used to achieve a reasonable
level of security in various circumstances.

1.1. Relationship to Other Documents

This document is an integral part of the LDAP Technical
Specification [Roadmap].

This document replaces RFC 2829 and
portions of RFC 2830 and obsoletes RFC 2251. 2829.

Harrison Expires April June 2004 [Page 3]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
remainder of RFC 2830 is obsoleted by this document.

2. Conventions Used in this Document

2.1. Glossary of Terms

The following terms are used in this document. To aid the reader,
these terms are defined here.

- "user" represents any human or application entity which is
accessing the directory using a directory client. A directory
client (or client) is also known as a directory user agent
(DUA).

- "connection" and "LDAP connection" both refer to the underlying
transport protocol connection between two protocol peers.

- "TLS connection" refers to a TLS-protected LDAP connection.

- "association" and "LDAP association" both refer to the
association of the LDAP connection and its current
authentication and authorization state.

2.2. Security Terms and Concepts

In general, security terms in this document are used consistently
with the definitions provided in [RFC2828]. In addition, several
terms and concepts relating to security, authentication, and
authorization are presented in Appendix B of this document. While
the formal definition of these terms and concepts is outside the
scope of this document, an understanding of them is prerequisite to
understanding much of the material in this document. Readers who are
unfamiliar with security-related concepts are encouraged to review
Appendix B before reading the remainder of this document.

2.3. Keywords

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].

3. Bind Operation

The Bind operation defined in section 4.2 of [Protocol] allows
authentication information to be exchanged between the client and
server to establish a new LDAP association. The new LDAP association
is established upon successful completion of the authentication
exchange.

3.1. Implied Anonymous Bind on LDAP Association

Prior to the successful completion of a Bind operation and during
any subsequent authentication exchange, the session has an anonymous

Harrison Expires April June 2004 [Page 4]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

LDAP association. Among other things this implies that the client
need not send a Bind Request in the first PDU of the connection. The
client may send any operation request prior to binding, and the
server MUST treat it as if it had been performed after an anonymous
bind operation. This authentication state on an LDAP association is
sometimes referred to as an implied anonymous bind.

3.2. Simple Authentication

The simple authentication choice provides minimal facilities for
establishing an anonymous association or for establishing an LDAP
association based upon credentials consisting of a name (in the form
of an [LDAPDN] and a password.

The simple authentication choice provides two different methods
for establishing an anonymous association: anonymous bind and
unauthenticated bind (see section 6.1). 5.1).

The simple authentication choice provides one method for
establishing a non-anonymous association: simple password bind.

3.3. SASL Authentication Profile

LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
includes native anonymous and plaintext authentication methods, the
"ANONYMOUS"
ANONYMOUS [ANONYMOUS] and "PLAIN" PLAIN [PLAIN] SASL mechanisms are
typically not used with LDAP.

Each protocol that utilizes SASL services is required to supply
certain information profiling the way they are exposed through the
protocol ([SASL] section 5). This section explains how each of these
profiling requirements are met by LDAP.

3.3.1. SASL Service Name for LDAP

The SASL service name for LDAP is "ldap", which has been registered
with the IANA as a GSSAPI service name.

3.3.2. SASL authentication initiation and protocol exchange

SASL authentication is initiated via an LDAP bind request
([Protocol] section 4.2) with the following parameters:

- The version is 3.
- The AuthenticationChoice is sasl.
- The mechanism element of the SaslCredentials sequence contains
the value of the desired SASL mechanism.
- The optional credentials field of the SaslCredentials sequence
may be used to provide an initial client response for
mechanisms that are defined to have the client send data first
(see [SASL] sections 5 and 6.1). 5.1).

In general, a SASL authentication protocol exchange consists of a
series of server challenges and client responses, the contents of

Harrison Expires April June 2004 [Page 5]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

which are specific to and defined by the SASL mechanism. Thus for
some SASL authentication mechanisms, it may be necessary for the
client to respond to one or more server challenges by invoking the
BindRequest multiple times. A challenge is indicated by the server
sending a BindResponse with the resultCode set to
saslBindInProgress. This indicates that the server requires the
client to send a new bind request, with the same sasl mechanism to
continue the authentication process.

To the encapsulating protocol, these challenges and responses are
opaque binary tokens of arbitrary length. LDAP servers use the
serverSaslCreds field, an OCTET STRING, in a bind response message
to transmit each challenge. LDAP clients use the credentials field,
an OCTET STRING, in the SaslCredentials sequence of a bind request
message to transmit each response. Note that unlike some Internet
application
protocols where SASL is used, LDAP is not text-based, thus no Base64
transformations are performed on these challenge and response
values.

Clients sending a bind request with the sasl choice selected SHOULD
NOT send a value in the name field. Servers receiving a bind request
with the sasl choice selected SHALL ignore any value in the name
field.

A client may abort a SASL bind negotiation by sending a BindRequest
with a different value in the mechanism field of SaslCredentials, or
an AuthenticationChoice other than sasl.

If the client sends a BindRequest with the sasl mechanism field as
an empty string, the server MUST return a BindResponse with
authMethodNotSupported as the resultCode. This will allow clients to
abort a negotiation if it wishes to try again with the same SASL
mechanism.

The server indicates completion of the SASL challenge-response
exchange by responding with a bind response in which the resultCode
is either success, or an error indication.

The serverSaslCreds field in the bind response can be used to
include an optional challenge with a success notification for
mechanisms which are defined to have the server send additional data
along with the indication of successful completion.

3.3.3. Octet where negotiated security mechanisms take effect

When negotiated, SASL security layers take effect following the
transmission by the server and reception by the client of the final
BindResponse in the exchange.

Once a SASL security layer providing integrity or confidentiality
services takes effect, the layer remains in effect until a new layer
is installed (i.e. at the first octet following the final
BindResponse of the bind operation that caused the new layer to take
effect).

Harrison Expires April June 2004 [Page 6]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

3.3.4. Determination of supported SASL mechanisms

An LDAP client may determine the SASL mechanisms a server supports
by performing a search request on the root DSE, requesting the
supportedSASLMechanisms attribute. The values of this attribute, if
any, list the mechanisms the server supports.

3.3.5. Rules for using SASL security layers

If a SASL security layer is negotiated, the client SHOULD discard
information about the server fetched it obtained prior to the initiation of
the SASL negotiation and not obtained through secure mechanisms.

If the client is configured to support multiple SASL mechanisms, it
SHOULD fetch the supportedSASLmechanisms list both before and after
the SASL security layer is negotiated. This allows the client to
detect active attacks that remove supported SASL mechanisms from the
supportedSASLMechanisms list and allows the client to ensure that it
is using the best mechanism supported by both client and server. (In
particular, this allows for environments where the
supportedSASLMechanisms list is provided to the client through a
different trusted source, e.g. as part of a digitally signed
object.)

If a lower level security layer (such as TLS) is negotiated, any
SASL security services SHALL be layered on top of such security
layers regardless of the order of their negotiation. In all other
respects, SASL security services and other security layers act
independently, e.g. if both TLS and SASL security service are in
effect removing the SASL security service does not affect the
continuing service of TLS and vice versa.

Because SASL mechanisms provide critical security functions, clients
and servers should allow the user to specify what mechanisms are
acceptable and allow only those mechanisms to be used.

3.3.6. Use of EXTERNAL SASL Mechanism

A client can use the "EXTERNAL" EXTERNAL SASL [SASL] mechanism to request the
LDAP server to make use of security credentials exchanged by a lower
layer.
security layer (such as by TLS authentication or IP-level security
[RFC2401]).

If the client's authentication credentials have not been established
at a lower level (such as by TLS authentication or IP-level security
[RFC2401]), layer, the SASL EXTERNAL bind MUST fail with a
resultCode of inappropriateAuthentication. Any client
authentication and authorization state of the LDAP association is
lost, so the LDAP association is in an anonymous state after the
failure (see [Protocol] section 4.2.1).

3.4. SASL Authorization Identity

When the "EXTERNAL" SASL mechanism is being negotiated, if In such a situation, the
SaslCredentials credentials field
state of any established security layer is present, unaffected.

A client may either implicitly request that its LDAP authorization
identity be derived from a lower layer or it contains may explicitly provide
an authorization identity. Other mechanisms define the location of the
authorization identity and assert that it be used in combination
with its authenticated TLS credentials. The former is known as an
implicit assertion, and the credentials field. In either case, the latter as an explicit assertion.

3.3.6.1. Implicit Assertion

An implicit authorization identity assertion is represented in performed by
invoking a Bind request of the authzId SASL form described
below.

3.4.1. Authorization Identity Syntax using the EXTERNAL
mechanism name that SHALL NOT include the optional credentials octet
string (found within the SaslCredentials sequence in the Bind
Request). The server will derive the client's authorization identity is a string of [UTF-8] encoded [Unicode]
characters corresponding to the following ABNF grammar [RFC2234]:

Harrison Expires April June 2004 [Page 7]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

; Specific predefined authorization (authz) id schemes

from the authentication identity supplied by the security layer
(e.g., a public key certificate used during TLS establishment)
according to local policy. The underlying mechanics of how this is
accomplished are
; defined below -- new schemes may implementation specific.

3.3.6.2. Explicit Assertion

An explicit authorization identity assertion is performed by
invoking a Bind request of the SASL form using the EXTERNAL
mechanism name that SHALL include the credentials octet string. This
string MUST be defined constructed as documented in the future.

authzId = dnAuthzId section 3.4.1.

The server MUST that the client's authentication identity as
supplied in its TLS credentials is permitted to be mapped to the
asserted authorization identity. The server MUST reject the Bind
operation with an invalidCredentials resultCode in the Bind response
if the client is not so authorized.

3.3.6.3. SASL Authorization Identity

When the EXTERNAL SASL mechanism is being negotiated, if the
SaslCredentials credentials field is present, it contains an
authorization identity. Other mechanisms define the location of the
authorization identity in the credentials field. In either case, the
authorization identity is represented in the authzId form described
below.

3.3.6.4 Authorization Identity Syntax

The authorization identity is a string of [UTF-8] encoded [Unicode]
characters corresponding to the following [ABNF] grammar:

authzId = dnAuthzId / uAuthzId

DNCOLON = %x64 %x6e %x3a ; "dn:"
UCOLON = %x75 %x3a ; "u:"

; distinguished-name-based authz id.
dnAuthzId = DNCOLON dn
dn = utf8string ; with syntax defined in [LDAPDN] section 3. distinguishedName

; unspecified authorization id, UTF-8 encoded.
uAuthzId = UCOLON userid
userid = utf8string *UTF8 ; syntax unspecified

where the <distinguishedName> production is defined in section 3 of
[LDAPDN] and <UTF8> production is defined in section 1.3 of
[Models].

In order to support additional specific authorization identity
forms, future updates to this specification may add new choices
supporting other forms may be added to the authzId production.

The dnAuthzId choice allows client applications clients to assert authorization
identities in the form of a distinguished name to be matched in

Harrison Expires June 2004 [Page 8]

Internet-Draft LDAP Authentication Methods 5 December 2003

accordance with the distinguishedName matching rule [Syntaxes]. The
decision to allow or disallow an authentication identity to have
access to the requested authorization identity is a matter of local
policy ([SASL] section 4.2). For this reason there is no requirement
that the asserted dn be that of an entry in directory.

The uAuthzId choice allows for compatibility with client
applications clients that wish
to assert an authorization identity to a local directory but do not
have that identity in distinguished name form. The value contained
within a uAuthzId MUST be prepared using
SASLprep [SASLPrep] before being
compared octet-wise. The format of utf8string is defined as only a
sequence of of [UTF-8] encoded [Unicode] characters, and further
interpretation is subject to prior agreement between the client and
server.

For example, the userid could identify a user of a specific
directory service or be a login name or the local-part of an RFC 822
email address. A uAuthzId SHOULD NOT be assumed to be globally
unique.

Additional authorization identity schemes may be defined in future
versions of this document.

4. Start TLS Operation

The Start Transport Layer Security (StartTLS) (Start TLS) operation defined in
section 4.13 of [Protocol] provides the ability to establish [TLS]
on an LDAP association.

4.1. Sequencing of the Start TLS Operation

This section describes the overall procedures clients and servers
must follow for TLS establishment. These procedures take into

Harrison Expires April 2004 [Page 8]

Internet-Draft LDAP Authentication Methods 7 October 2003
consideration various aspects of the overall security of the LDAP
association including discovery of resultant security level and
assertion of the client's authorization identity.

Note that the precise effects, on a client's authorization identity,
of establishing TLS on an LDAP association are described in detail
in section 4.2.

4.1.1. Requesting to Start TLS on an LDAP Connection Request

The client MAY send the Start TLS extended request at any time after
establishing an LDAP connection, except:

- when TLS is currently established on the connection,
- when a multi-stage SASL negotiation is in progress on the
connection, or
- when there are one or more outstanding LDAP operations on the
connection.

The result of violating any of these requirements is a resultCode of
operationsError, as described in [Protocol] section 4.13.2.2. Client
implementers should note that it is possible to receive a resultCode
of success for a Start TLS operation that is sent on a connection
with outstanding LDAP operations and the server has sufficient time

Harrison Expires June 2004 [Page 9]

Internet-Draft LDAP Authentication Methods 5 December 2003

to process them prior to its receiving the Start TLS request.
Implementors of clients should ensure that they do not inadvertently
depend upon this race condition for proper functioning of their
applications. condition.

In particular, there is no requirement that the client have or have
not already performed a Bind operation before sending a Start TLS
operation request. The client may have already performed a Bind
operation when it sends a Start TLS request, or the client might
have not yet bound.

If the client did not establish a TLS connection before sending any
other requests, and the server requires the client to establish a
TLS connection before performing a particular request, the server
MUST reject that request by sending a resultCode of
confidentialityRequired or strongAuthRequired.

4.1.2. Starting Start TLS Response

The server will return an extended response with the resultCode of
success if it is willing and able to negotiate TLS. It will return
other resultCodes resultCode values (documented in [Protocol] section 4.13.2.2)
if it is unwilling or unable to do so.

In the successful case, the client (which has ceased to transfer
LDAP requests on the connection) MUST either begin a TLS negotiation
or close the connection. The client will send PDUs in the TLS Record
Protocol directly over the underlying transport connection to the
server to initiate [TLS] negotiation.

Harrison Expires April 2004 [Page 9]

Internet-Draft LDAP Authentication Methods 7 October 2003

4.1.3. TLS Version Negotiation

Negotiating the version of TLS or SSL to be used is a part of the
[TLS] Handshake Protocol. Please refer to that document for details.

4.1.4. Discovery of Resultant Security Level

After a TLS connection is established on an LDAP association, both
parties MUST must individually decide whether or not to continue based on
the security level achieved. Ascertaining the TLS connection's
security level is implementation dependent and accomplished by
communicating with one's respective local TLS implementation.

If the client or server decides that the level of authentication or
security is not high enough for it to continue, it SHOULD gracefully
close the TLS connection immediately after the TLS negotiation has
completed (see [Protocol] section 4.13.3.1 and section 4.2.3 below).
If the client decides to continue, it may gracefully close the TLS
connection and attempt to Start TLS again, it may send an unbind
request, or it may send any other LDAP request.

4.1.5. Server Identity Check

Harrison Expires June 2004 [Page 10]

Internet-Draft LDAP Authentication Methods 5 December 2003

The client MUST check its understanding of the server's hostname
against the server's identity as presented in the server's
Certificate message in order to prevent man-in-the-middle attacks.

Matching is performed according to these rules:

- The client MUST use the server provided by the user (or other
trusted entity) as the value to compare against the server name
as expressed in the server's certificate. A hostname derived
from the user input is to be considered provided by the user
only if derived in a secure fashion (e.g., DNSSEC).

- If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's
identity.

- Matching is case-insensitive.

- The "*" wildcard character is allowed. If present, it applies
only to the left-most name component.

For example, *.bar.com would match a.bar.com and b.bar.com, but
it would not match a.x.bar.com nor would it match bar.com. If
more than one identity of a given type is present in the
certificate (e.g. more than one dNSName name), a match in any
one of the set is considered acceptable.

If the hostname does not match the dNSName-based identity in the
certificate per the above check, user-oriented clients SHOULD either
notify the user (clients may give the user the opportunity to
continue with the connection in any case) or terminate the

Harrison Expires April 2004 [Page 10]

Internet-Draft LDAP Authentication Methods 7 October 2003
connection and indicate that the server's identity is suspect.
Automated clients SHOULD close the connection, returning and/or
logging an error indicating that the server's identity is suspect.

Beyond the server identity checks described in this section, clients
SHOULD be prepared to do further checking to ensure that the server
is authorized to provide the service it is observed to provide. The
client may need to make use of local policy information in making
this determination.

4.1.6. Refresh of Server Capabilities Information

Upon TLS session establishment, the client SHOULD discard or refresh
all information about the server fetched it obtained prior to the initiation
of the TLS negotiation and not obtained through secure mechanisms.
This protects against active-intermediary attacks that may have
altered any server capabilities information retrieved prior to TLS
establishment.

The server may advertise different capabilities after TLS
establishment. In particular, the value of supportedSASLMechanisms
may be different after TLS has been negotiated (specifically, the

Harrison Expires June 2004 [Page 11]

Internet-Draft LDAP Authentication Methods 5 December 2003

EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
after a TLS negotiation has been performed).

4.2. Effects of TLS on a Client's Authorization Identity

This section describes the effects on a client's authorization
identity brought about by establishing TLS on an LDAP association.
The default effects are described first, and next the facilities for
client assertion of authorization identity are discussed including
error conditions. Finally, the effects of closing the TLS connection
are described.

Authorization identities and related concepts are described in
Appendix B.

4.2.1. Default Effects

Upon establishment of the TLS session onto Connection Establishment Effects

The decision to keep or invalidate the LDAP association, any
previously established authentication
and authorization identities
MUST remain in force, including anonymous state. This holds even in
the case where the place after TLS is negotiated is a
matter of local server requests client policy. If a server chooses to invalidate
established authentication via and authorization identities after TLS --
e.g. is
negotiated, it MUST reply to subsequent valid operation requests
until the next TLS closure or successful bind request with a
resultCode of strongAuthRequired to indicate that the client needs
to supply bind to reestablish its certificate during TLS
negotiation. authentication. If the client attempts to
bind using a method the server is unwilling to support, it responds
to the with a resultCode of authMethodNotSupported (per [Protocol])
to indicate that a different authentication method should be used.

4.2.2. Client Assertion of Authorization Identity

The client MAY, upon receipt of

After successfully establishing a Start TLS response indicating
success, assert that session, a specific authorization identity client may request
that its credentials exchanged during the TLS establishment be
utilized
in determining to determine the client's authorization status. The client
accomplishes this via an LDAP Bind request specifying a SASL
mechanism of "EXTERNAL" EXTERNAL [SASL]. A client may either implicitly
request that its LDAP authorization identity be derived from its

Harrison Expires April 2004 [Page 11]

Internet-Draft LDAP Authentication Methods 7 October 2003

authenticated See section 3.3.6 for additional
details.

4.2.3. TLS credentials Connection Closure Effects

The decision to keep or it may explicitly provide an
authorization identity invalidate the established authentication
and assert that it be used authorization identities in combination
with its authenticated place after TLS credentials. The former closure is known as an
implicit assertion, a matter
of local server policy. If a server chooses to invalidate
established authentication and the latter as an explicit assertion.

4.2.2.1. Implicit Assertion

An implicit authorization identity assertion is accomplished identities after TLS establishment by invoking a Bind is
negotiated, it MUST reply to subsequent valid operation requests
until the next TLS closure or successful bind request with a
resultCode of the SASL form using
the "EXTERNAL" mechanism name [SASL] [Protocol] strongAuthRequired to indicate that SHALL NOT
include the optional credentials octet string (found within client needs
to bind to reestablish its authentication. If the
SaslCredentials sequence in client attempts to
bind using a method the Bind Request). The server will
derive the client's authorization identity from the authentication
identity supplied in is unwilling to support, it responds
to the client's TLS credentials (typically with a
public key certificate) according to local policy. The underlying
mechanics resultCode of how this is accomplished are implementation specific.

4.2.2.2. Explicit Assertion

An explicit authorization identity assertion is accomplished after
TLS establishment by invoking authMethodNotSupported (per [Protocol])
to indicate that a Bind request of the SASL form using
the "EXTERNAL" mechanism name [SASL] [Protocol] different authentication method should be used.

5. Anonymous Authentication

Harrison Expires June 2004 [Page 12]

Internet-Draft LDAP Authentication Methods 5 December 2003

Directory operations that SHALL include
the credentials octet string. This string modify entries or access protected
attributes or entries generally require client authentication.
Clients that do not intend to perform any of these operations
typically use anonymous authentication.

LDAP implementations MUST be constructed support anonymous authentication, as
documented
defined in section 3.4.1.

The server MUST verify that the client's 5.1.

LDAP implementations MAY support anonymous authentication identity with TLS,
as
supplied defined in its TLS credentials is permitted to section 5.2.

While there may be mapped access control restrictions to the
asserted authorization identity. The prevent access to
directory entries, an LDAP server MUST reject the Bind
operation with SHOULD allow an invalidCredentials resultCode in the Bind response
if the client is not so authorized.

4.2.2.3. Error Conditions

Additionally, with either form of assertion, if a TLS session has
not been established between the anonymously-bound
client and server prior to making
the SASL EXTERNAL Bind request and there is no other external source
of authentication credentials (e.g. IP-level security [RFC2401]), or
if during retrieve the process supportedSASLMechanisms attribute of establishing the TLS session, the root
DSE.

An LDAP server
did not request may use other information about the client's authentication credentials, client provided
by the SASL
EXTERNAL bind MUST fail with lower layers or external means to grant or deny access even
to anonymously authenticated clients.

5.1. Anonymous Authentication Procedure

Prior to successfully completing a resultCode of
inappropriateAuthentication.

After the above Bind operation failures, any client authentication
and authorization state of operation, the LDAP
association is lost (see
[Protocol] anonymous. See section 4.2.1), so the 3.1.

An LDAP association is in client may also explicitly establish an anonymous state after the failure. The TLS session state is
unaffected, though
association by sending a server MAY end Bind Request with the TLS session, via simple authentication
option and a TLS
close_notify message, based on the Bind failure (as it MAY at any
time).

4.2.3. TLS Connection Closure Effects

Closure password of zero length. A bind request where both the TLS session MUST cause the LDAP association to move
name and password are of zero length is said to be an anonymous authentication and authorization state regardless of

Harrison Expires April 2004 [Page 12]

Internet-Draft LDAP Authentication Methods 7 October 2003
bind. A bind request where the state established over TLS and regardless name, a DN, is of the authentication non-zero length,
and authorization state prior to TLS session establishment.

5. LDAP Association State Transition Tables

To comprehensively diagram the various authentication and TLS states
through which password is of zero length is said to be an LDAP association may pass, this unauthenticated
bind. Both variations produce an anonymous association.

Unauthenticated binds can have significant security issues (see
section provides 10). Servers SHOULD by default reject unauthenticated bind
requests with a
state transition table resultCode of invalidCredentials, and clients may
need to represent a state diagram for the various
states through which actively detect situations where they would make an
unauthenticated bind request.

5.2. Anonymous Authentication and TLS

An LDAP association client may pass during use the course Start TLS operation (section 5) to
negotiate the use of its existence and [TLS] security. If the actions that cause these changes in state.

5.1. LDAP Association States

The following table lists client has not bound
beforehand, then until the valid LDAP association states and
provides a description client uses the EXTERNAL SASL mechanism
to negotiate the recognition of each state. The ID for each state is used
in the state transition table in section 5.4.

ID State Description
-- --------------------------------------------------------------
S1 Anonymous
no Authentication ID is associated with client's certificate, the LDAP connection
no Authorization ID is in force
No security layer client
is anonymously authenticated.

Recommendations on TLS ciphersuites are given in effect.
No section 9.

An LDAP server which requests that clients provide their certificate
during TLS credentials have been provided
TLS: no Creds, OFF]
S2 no Auth ID
no AuthZ ID
[TLS: no Creds, ON]
S3 no Auth ID
no AuthZ ID
[TLS: Creds Auth ID "I", ON]
S4 Auth ID = Xn
AuthZ ID= Y
[TLS: no Creds, OFF]
S5 Auth ID = Xn
AuthZ ID= Yn
[TLS: no Creds, ON]
S6 Auth ID = Xn
AuthZ ID= Yn
[TLS: Creds Auth ID "I", ON]
S7 Auth ID = I
AuthZ ID= J
[TLS: Creds Auth ID "I", ON]
S8 Auth ID = I
AuthZ ID= K
[TLS: Creds Auth ID "I", ON]

5.2. Actions that Affect LDAP Association State

The following table lists the actions that can affect the state of
an LDAP association. The ID for each action is used in negotiation MAY use a local security policy to determine
whether to successfully complete TLS negotiation if the state
transition table in section 5.4. client did
not present a certificate which could be validated.

Harrison Expires April June 2004 [Page 13]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

ID Action
-- ------------------------------------------------
A1 Client binds anonymously
A2 Inappropriate authentication: client attempts an anonymous
bind

6. Password-based Authentication

This section discusses various options for performing password-based
authentication to LDAP compliant servers and the environments
suitable for their use.

The transmission of passwords in the clear--typically for
authentication or modification--poses a significant security risk.
This risk can be avoided by using SASL bind without supplying credentials to [SASL] mechanisms that
do not transmit passwords in the clear and by negotiating transport
or session layer confidentiality services before transmitting
password values.

To mitigate the security risks associated with the use of passwords,
a server implementation MUST implement a configuration that
requires at the client to provide some form
time of credentials.
A3 Client Start TLS request
Server: client auth NOT required
A4 Client: Start TLS request
Server: client creds requested
Client: [TLS creds: Auth ID "I"]
A5 Client authentication or Server: send TLS closure alert ([Protocol] section
X)
A6 Client: Bind w/simple password or SASL modification, requires:

1) A Start TLS encryption layer has been successfully negotiated.

2) Some other confidentiality mechanism (e.g. DIGEST-
MD5 password, Kerberos, etc., except EXTERNAL [Auth ID "X"
maps to AuthZ ID "Y"]
A7 Client Binds SASL EXTERNAL with credentials: AuthZ ID "J"
[Explicit Assertion (section 4.2.1.2.2)]
A8 Client Bind SASL EXTERNAL without credentials [Implicit
Assertion (section 4.2.1.2.1)]
A9 Client abandons a bind operation or bind operation fails

5.3. Decisions Used in Making LDAP Association State Changes

Certain changes in the state of an LDAP association are only allowed
if that protects the password
value from snooping has been provided.

3) The server can affirmatively answer returns a question. These questions
are applied as part resultCode of the criteria confidentialityRequired for allowing or disallowing
the operation (i.e. simple bind with password value, SASL bind
transmitting a
state change password value in the state transition table in section 5.4.

ID Decision Question
-- --------------------------------------------------------------
D1 Can TLS Credentials Auth ID "I" be mapped to AuthZ ID "J"?
D2 Can clear, add or modify
including a valid AuthZ ID "K" be derived from TLS Credentials Auth
ID "I"?

5.4. LDAP Association State Transition Table userPassword value, etc.), even if the password
value is correct.

6.1. Simple Authentication

The LDAP Association table below lists the valid states "simple" authentication choice is not suitable for an LDAP
association and the actions that could affect them. For any given
row
authentication in the table, the Current State column gives the state of an environments where there is no network or
transport layer confidentiality. LDAP association, implementations SHOULD support
authentication with the Action column gives an action that could
affect "simple" authentication choice when the state of an
connection is protected against eavesdropping using TLS, as defined
in section 4. LDAP assocation, and the Next State column
gives implementations SHOULD NOT support authentication
with the resulting state of an LDAP association after "simple" authentication choice unless the action
occurs.

The initial state for data on the state machine described in this table
connection is
S1.

Current Next
State Action State Comment
------- ------------- ----- -----------------------------------
S1 A1 S1 protected using TLS or other data confidentiality and
data integrity protection.

6.2. Digest Authentication

LDAP servers that implement any authentication method or mechanism
(other than simple anonymous bind) MUST implement the SASL
DIGEST-MD5 mechanism [DIGEST-MD5]. This provides client
authentication with protection against passive eavesdropping
attacks, but does not provide protection against active intermediary
attacks. DIGEST-MD5 also provides data integrity and data
confidentiality capabilities.

Harrison Expires April June 2004 [Page 14]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

S1 A2 S1 Error: Inappropriate

Support for subsequent authentication
S1 A3 S2
S1 A4 S3
S1 A6 S4
S1 A7 ? identity could be provided by
another underlying mechanism such
as IPSec.
S1 A8 ? identity could be provided by
another underlying mechanism such
as IPSec.
S2 A1 S2
S2 A2 S2 Error: Inappropriate is OPTIONAL in clients and
servers.

Implementors must take care to ensure that they maintain the
semantics of the DIGEST-MD5 specification even when handling data
that has different semantics in the LDAP protocol.
For example, the SASL DIGEST-MD5 authentication
S2 A5 S1
S2 A6 S5
S2 A7 ? identity could be provided by
another underlying mechanism such
as IPSec.
S2 A8 ? identity could be provided by
another underlying mechanism such
as IPSec.
S3 A1 S3
S3 A2 S3 Error: Inappropriate authentication
S3 A5 S1
S3 A6 S6
S3 A7 utilizes
realm and D1=NO S3 Error: InvalidCredentials
S3 A7 username values ([DigestAuth section 2.1) which are
syntactically simple strings and D1=YES S7
S3 A8 semsantically simple realm and D2=NO S3 Error: InvalidCredentials
S3 A8
username values. These values are not LDAP DNs, and D2=YES S8
S4 A1 S1
S4 A2 S1 Error: Inappropriate Authentication
S4 A3 S5
S4 A4 S6
S4 A5 S1
S4 A6 S4
S4 A7 ? identity could be provided by
another underlying mechanism such
as IPSec.
S4 A8 ? identity could be provided by
another underlying mechanism such
as IPSec.
S5 A1 S2
S5 A2 S2 Error: Inappropriate Authentication
S5 A5 S1
S5 A6 S5
S5 A7 ? identity could be provided by
another underlying mechanism such
as IPSec.
S5 A8 ? identity could be provided by
another underlying mechanism such
as IPSec.
S6 A1 S3
S6 A2 S2 Error: Inappropriate Authentication

Harrison Expires April 2004 [Page 15]

Internet-Draft LDAP Authentication Methods 7 October 2003

S6 A5 S1
S6 A6 S6
S6 A7 and D1=NO S6 Error: InvalidCredentials
S6 A7 and D1=YES S7
S6 A8 and D2=NO S3 Error: InvalidCredentials
S6 A8 and D2=YES S8
S7 A1 S3
S7 A2 S2 Error: Inappropriate Authentication
S7 A5 S1
S7 A6 S6
S7 A7 S7
S7 A8 and D2=NO S3 Error: InvalidCredentials
S7 A8 and D2=YES S8
S8 A1 S3
S8 A2 S2 Error: Inappropriate Authentication
S8 A5 S1
S8 A6 S6
S8 A7 and D1=NO S6 Error: InvalidCredentials
S8 A7 and D1=YES S7
S8 A8 S8
Any A9 S1 See [Protocol] section 4.2.1.

6. Anonymous Authentication

Directory operations that modify entries or access protected
attributes or entries generally require client authentication.
Clients that do not intend to perform any of these operations
typically use anonymous authentication. Servers SHOULD NOT allow
clients with anonymous authentication to modify directory entries or
access sensitive information in directory entries.

LDAP implementations MUST support anonymous authentication, as
defined in section 6.1.

LDAP implementations MAY support anonymous authentication with TLS,
as defined in section 6.2.

While there MAY be access control restrictions to prevent access to
directory entries, an LDAP server SHOULD allow an anonymously-bound
client to retrieve the supportedSASLMechanisms attribute of the root
DSE.

An LDAP server MAY use other information about the client provided
by the lower layers or external means to grant or deny access even
to anonymously authenticated clients.

6.1. Anonymous Authentication Procedure

Prior to successfully completing a Bind operation, the LDAP
association is anonymous. See section 3.1.

Harrison Expires April 2004 [Page 16]

Internet-Draft LDAP Authentication Methods 7 October 2003

An LDAP client may also explicitly establish an anonymous
association. A client no
requirement that wishes to do so MUST choose the simple
authentication option in the Bind Request and set the password to they be
of zero length. (This is often done by LDAPv2 clients.) Typically
the name is also of zero length. A bind request where both represented or treated as such. Username
and realm values that look like LDAP DNs in form, e.g. <cn=bob,
dc=example,dc=com>, are syntactically allowed, however DIGEST-MD5
treats them as simple strings for comparison purposes. To illustrate
further, the name two DNs <cn=Bob,dc=example,dc=com> (upper case "B") and password
<cn=bob,dc=example,dc=com> (lower case "b") are of zero length equivalent when
being compared semantically as LDAP DNs because the cn attribute is said
defined to be an anonymous bind. A
bind request where case insensitive, however the name, a DN, is of non-zero length, and two values are not
equivalent if they represent username values in DIGEST-MD5 because
[SASLPrep] semantics are used by DIGEST-MD5.

6.3. simple authentication choice under TLS encryption

Following the
password is negotiation of zero length is said to be an unauthenticated bind.
Both variations produce an anonymous association.

6.2. Anonymous Authentication and appropriate TLS

An LDAP ciphersuite
providing connection confidentiality, a client MAY authenticate to a
directory that supports the simple authentication choice by
performing a simple bind operation

Simple authentication with TLS encryption protection is performed as
follows:

1. The client will use the Start TLS operation (section 5) [Protocol] to
negotiate the use of TLS security [TLS] security. If on the connection to
the LDAP server. The client has need not have bound
beforehand, then until the client uses the EXTERNAL SASL mechanism to negotiate the recognition of
directory beforehand.

For the client's certificate, subsequent authentication procedure to be performed
securely, the client
is anonymously authenticated. and server MUST negotiate a ciphersuite
which contains a bulk encryption algorithm of appropriate
strength. Recommendations on TLS ciphersuites cipher suites are given in
section 9.

An LDAP server which requests that clients provide their certificate
during TLS negotiation MAY use a local security policy to determine
whether to successfully complete

2. Following the successful completion of TLS negotiation if negotiation, the
client did
not present a certificate which could be validated.

7. Password-based Authentication

This section discusses various options for performing password-based
authentication to LDAP compliant servers and the environments
suitable for their use.

7.1. Simple Authentication

The LDAP "simple" authentication choice is not suitable for
authentication in environments where there is no network or
transport layer confidentiality. MUST send an LDAP implementations SHOULD support
authentication bind request with the "simple" authentication choice when version number
of 3, the
connection is protected against eavesdropping using TLS, as defined
in section 4. LDAP implementations SHOULD NOT support authentication
with name field containing a DN, and the "simple" simple
authentication choice unless choice, containing a password.

6.3.1. simple Authentication Choice

DSAs that map the data on DN sent in the
connection is protected using TLS bind request to a directory entry
with an associated set of one or other data confidentiality and
data integrity protection.

7.2. Digest Authentication

LDAP servers more passwords will compare the
presented password to the set of passwords associated with that implement
entry. If the presented password matches any authentication method or mechanism
(other than simple anonymous bind) MUST implement member of that set,

Harrison Expires June 2004 [Page 15]

Internet-Draft LDAP Authentication Methods 5 December 2003

then the SASL
DIGEST-MD5 mechanism [DigestAuth].

Support for subsequent server will respond with a success resultCode, otherwise
the server will respond with an invalidCredentials resultCode.

6.4. Other authentication choices with TLS

It is OPTIONAL in clients and
servers.

Harrison Expires April 2004 [Page 17]

Internet-Draft LDAP Authentication Methods 7 October 2003

Implementors must take care also possible, following the negotiation of TLS, to ensure perform a
SASL authentication that they maintain does not involve the
semantics exchange of plaintext
reusable passwords. In this case the DIGEST-MD5 specification even when handling data client and server need not
negotiate a ciphersuite that has different semantics in provides confidentiality if the only
service required is data integrity.

7. Certificate-based authentication

LDAP protocol.
For example, the SASL DIGEST-MD5 server implementations SHOULD support authentication mechanism utilizes
realm and username values ([DigestAuth via a
client certificate in TLS, as defined in section 2.1) 7.1.

7.1. Certificate-based authentication with TLS

A user who has a public/private key pair in which are
syntactically simple strings and semsantically simple realm and
username values. These values are not LDAP DNs, and there the public key has
been signed by a Certification Authority may use this key pair to
authenticate to the directory server if the user's certificate is no
requirement that they
requested by the server. The user's certificate subject field SHOULD
be represented or treated as such. Username the name of the user's directory entry, and realm values the Certification
Authority that look like LDAP DNs in form, e.g. "cn=bob,
o=Ace Industry ", are syntactically allowed, however DIGEST-MD5
treats them as simple strings for comparison purposes. To illustrate
further, issued the two DNs "cn=bob, o=Ace Industry" (space between RDNs)
and "cn=bob,o=Ace Industry" (no space between RDNs) would user's certificate must be
equivalent when being compared semantically as LDAP DNs, however
they are not equivalent if they were used to represent username
values sufficiently
trusted by the directory server in DIGEST-MD5 because simple octet-wise comparision semantics
are used order for the server to process
the certificate. The means by DIGEST-MD5.

7.3. "simple" authentication choice under TLS encryption

Following which servers validate certificate
paths is outside the negotiation scope of an appropriate TLS ciphersuite
providing connection confidentiality, a client this document.

A server MAY authenticate to a support mappings for certificates in which the subject
field name is different from the name of the user's directory that entry.
A server which supports the simple authentication choice by
performing a simple bind operation

Simple authentication with TLS encryption protection mappings of names MUST be capable of being
configured to support certificates for which no mapping is performed as
follows:

1. required.

The client will use the Start TLS operation [Protocol] to negotiate
the use of TLS security [TLS] on the connection to the LDAP server.
The client need not have bound to the directory beforehand.

For the subsequent authentication procedure to be performed
securely, the client and server MUST negotiate a ciphersuite
which contains a bulk encryption algorithm of appropriate
strength. Recommendations on cipher suites are given in
section 9.

2. Following

In the successful completion of TLS negotiation, the
client server MUST send an LDAP bind request with the version number
of 3, the name field containing a DN, certificate. The
client will provide its certificate to the server, and the "simple"
authentication choice, containing server
MUST perform a password.

7.3.1. "simple" Authentication Choice

DSAs that map the DN sent in private key-based encryption, proving it has the bind request to a directory entry
with an
private key associated set of one or more passwords will compare the
presented password to with the set certificate.

In deployments that require protection of passwords associated with sensitive data in transit,
the client and server MUST negotiate a ciphersuite that
entry. If the presented password matches any member contains a
bulk encryption algorithm of appropriate strength. Recommendations
of cipher suites are given in section 9.

The server MUST verify that set,
then the client's certificate is valid. The
server will respond with normally check that the certificate is issued by a success resultCode, otherwise known
certification authority (CA), and that none of the certificates on
the client's certificate chain are invalid or revoked. There are
several procedures by which the server will respond with an invalidCredentials resultCode. can perform these checks.

Harrison Expires April June 2004 [Page 18] 16]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

7.4. Other authentication choices with TLS

It is also possible, following the negotiation of TLS, to perform a
SASL authentication that does not involve

Following the exchange successful completion of plaintext
reusable passwords. In this case TLS negotiation, the client and server need not
negotiate a ciphersuite that provides confidentiality if
will send an LDAP bind request with the only
service required is data integrity. SASL EXTERNAL mechanism.

8. Certificate-based authentication LDAP server implementations SHOULD support authentication via a
client certificate in TLS, as defined in section 8.1.

8.1. Certificate-based Association State Transition Tables

To comprehensively diagram the various authentication with and TLS

A user who has a public/private key pair in which the public key has
been signed by a Certification Authority states
through hich an LDAP association may use pass, this key pair to
authenticate section provides a
state transition table to represent a state diagram for the directory server if the user's certificate is
requested by the server. The user's certificate subject field SHOULD
be the name of various
states through which an LDAP association may pass during the user's directory entry, course
of its existence and the Certification
Authority actions that issued the user's certificate must be sufficiently
trusted by the directory server cause these changes in order for the server to process
the certificate. state.

8.1. LDAP Association States

The means by which servers validate certificate
paths is outside following table lists the scope valid LDAP association states and
provides a description of this document.

A server MAY support mappings each state. The ID for certificates each state is used
in which the subject
field name state transition table in section 8.4.

ID State Description
-- --------------------------------------------------------------
S1 Anonymous
no Authentication ID is different from associated with the name of LDAP connection
no Authorization ID is in force
S2 Authenticated
Authentication ID = I
Authorization ID = X
S3 Authenticated SASL EXTERNAL, implicit authorization ID
Authentication ID = J
Authorization ID = Y
S4 Authenticated SASL EXTERNAL, explicit authorization ID
Authentication ID = J
Authorization ID = Z

8.2. Actions that Affect LDAP Association State

The following table lists the user's directory entry.
A server which supports mappings of names MUST be capable actions that can affect the
authentication and authorization state of being
configured to support certificates an LDAP association. The
ID for which no mapping each action is required. used in the state transition table in section
8.4.

ID Action
-- --------------------------------------------------------------
A1 Client bind request fails
A2 Client successfully performs anonymous simple bind
A3 Client successfully performs unauthenticated simple bind
A4 Client successfully performs simple bind with name and
password OR SASL bind with any mechanism except EXTERNAL using
an authentication ID = I that maps to authorization ID X
A5 Client Binds SASL EXTERNAL with implicit assertion of
authorization ID (section 3.3.6.1)]. The client will use the Start TLS operation [Protocol] current
authentication ID maps to negotiate
the use authorization ID = Y.
A6 Client Binds SASL EXTERNAL with explicit assertion of TLS security [TLS] on the connection to the
authorization ID = Z (section 3.3.6.2)]

Harrison Expires June 2004 [Page 17]

Internet-Draft LDAP server.
The client need not have bound to Authentication Methods 5 December 2003

A7 Client abandons a bind operation, and server processes the directory beforehand.

In
abandon
A8 Client abandons a bind operation, and server does not process
the abandon
A9 Client Start TLS negotiation, the server MUST request a certificate. The
client will provide its certificate to fails
A10 Client Start TLS request succeeds
A11 Client or Server: graceful TLS closure ([Protocol] section
4.13.3.1.)

8.3. Decisions Used in Making LDAP Association State Changes

Certain changes in the server, authentication and authorization state of an
LDAP association are only allowed if the server
MUST perform can affirmatively
answer a private key-based encryption, proving it has the
private key associated with the certificate.

In deployments that require protection question. These questions are applied as part of sensitive data in transit, the client and server MUST negotiate a ciphersuite that contains
criteria for allowing or disallowing a
bulk encryption algorithm of appropriate strength. Recommendations
of cipher suites are given state transition in section 9.

The server MUST verify that the client's certificate is valid. state
transition table in section 8.4.

ID Decision Question
-- --------------------------------------------------------------
D1 Are lower-layer credentials available?
D2 Can lower-layer credentials for Auth ID "K" be mapped asserted
AuthZID "L"?

8.4. LDAP Association State Transition Table

The
server will normally check that LDAP Association table below lists the certificate is issued by a known
certification authority (CA), valid authentication and
authorization states for an LDAP association and the actions that none of
could affect them. For any given row in the certificates on table, the client's certificate chain are invalid or revoked. There are
several procedures by which Current State
column gives the server can perform these checks.

Following state of an LDAP association, the successful completion Action column
gives an action that could affect the state of TLS negotiation, an LDAP assocation,
and the client
will send Next State column gives the resulting state of an LDAP bind request with
association after the SASL "EXTERNAL" mechanism.

9. TLS Ciphersuites action occurs.

S1, the initial state for the state machine described in this table,
is the authentication state when an LDAP connection is initially
established.

Current Next
State Action State Comment
------- ------- ----- ---------------------------------------
Any A1 S1 [Protocol] section 4.2.1
Any A2 S1 Section 6
Any A3 S1 Section 6
Any A4 S2 Sections 6.1, 6.2
Any A5, S1 Failed bind, section 3.3.6
D1=no
Any A5, S3
D1=yes
Any A6, S1 failed bind, section 3.3.6
D1=no
Any A6, S1 failed bind, section 3.3.6.2
D1=yes,
D2=no

Harrison Expires April June 2004 [Page 19] 18]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

Any A6, S4
D1=yes,
D2=yes
Any A7 S1 [Protocol] section 4.2.1. Clients
cannot detect this state.
Any A8 no [Protocol] section 4.2.1. Clients
change cannot detect this state.
Any A9 no [Protocol] section 4.13.2.2
change
Any A10 no Section 4.2.1
change
Any A11 S1 Section 4.2.3

9. TLS Ciphersuites

A client or server that supports TLS MUST support
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites
offering equivalent or better protection.

Several issues should be considered when selecting TLS ciphersuites
that are appropriate for use in a given circumstance. These issues
include the following:

- The ciphersuite's ability to provide adequate confidentiality
protection for passwords and other data sent over the LDAP
connection. Client and server implementers should recognize that
some TLS ciphersuites provide no confidentiality protection
while other ciphersuites that do provide confidentiality
protection may be vulnerable to being cracked using brute force
methods, especially in light of ever-increasing CPU speeds that
reduce the time needed to successfully mount such attacks.

Client and server implementers SHOULD carefully consider the
value of the password or data being protected versus the level
of confidentially protection provided by the ciphersuite to
ensure that the level of protection afforded by the ciphersuite
is appropriate.

- The ciphersuite's vulnerability (or lack thereof) to man-in-the-
middle attacks. Ciphersuites vulnerable to man-in-the-middle
attacks SHOULD NOT be used to protect passwords or sensitive
data, unless the network configuration is such that the danger
of a man-in-the-middle attack is tolerable.

9.1. TLS Ciphersuites Recommendations

As of the writing of this document, the following recommendations
regarding TLS ciphersuites are applicable. Because circumstances are
constantly changing, this list must not be considered exhaustive,
but is hoped that it will serve as a useful starting point for
implementers.

Harrison Expires June 2004 [Page 19]

Internet-Draft LDAP Authentication Methods 5 December 2003

The following ciphersuites defined in [TLS] MUST NOT be used for
confidentiality protection of passwords or data:

TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA

The following ciphersuites defined in [TLS] can be cracked easily
(less than a day of CPU time on a standard CPU in 2000) and are NOT
RECOMMENDED for use in confidentiality protection of passwords or
data.

TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA

Harrison Expires April 2004 [Page 20]

Internet-Draft LDAP Authentication Methods 7 October 2003
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

The following ciphersuites are vulnerable to man-in-the-middle
attacks:

TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

10. Security Considerations

Security issues are discussed throughout this memo; the
(unsurprising) conclusion is that mandatory security is important
and that session confidentiality protection is required when
snooping is a problem.

Servers are encouraged to prevent modifications by anonymous users.

Servers may also wish to can minimize denial of service attacks by timing out idle
connections, and returning the unwillingToPerform resultCode rather
than performing computationally expensive operations requested by
unauthorized clients.

The use of cleartext passwords and other unprotected authentication
credentials is strongly discouraged over open networks when the
underlying transport service cannot guarantee confidentiality.

Operational experience shows that clients can (and frequently do)
misuse unauthenticated
access (simple bind with name but no password). (see section 5.1). For example, a
client program might authenticate a user via LDAP and then might make a decision to grant access to information not stored in the non-

Harrison Expires June 2004 [Page 20]

Internet-Draft LDAP Authentication Methods 5 December 2003

directory information on the basis of completing a successful bind. bind
operation. Some LDAP server implementations will return a success
response to a simple bind that consists of a user name and an empty password unauthenticated bind thus leaving the client with the
impression that the client server has successfully authenticated the
identity represented by the user name, when in reality, the directory server has simply performed effect, an anonymous bind. For this reason, servers SHOULD by default reject
authentication requests
LDAP association has been created. Clients that have use the results from
a DN with an simple bind operation to make authorization decisions should
actively detect unauthenticated bind requests (via the empty
password with
an error of invalidCredentials. value) and react appropriately.

Access control SHOULD always be applied when reading sensitive
information or updating directory information.

A connection on which the client has not performed the Start TLS
operation or negotiated a suitable SASL mechanism for connection

Harrison Expires April 2004 [Page 21]

Internet-Draft LDAP Authentication Methods 7 October 2003
integrity and encryption services is subject to man-in-the-middle
attacks to view and modify information in transit.

10.1. Start TLS Security Considerations

The goals of using the TLS protocol with LDAP are to ensure
connection confidentiality and integrity, and to optionally provide
for authentication. [TLS] expressly provides these capabilities.

All security gained via use of the Start TLS operation is gained by
the use of TLS itself. The Start TLS operation, on its own, does not
provide any additional security.

Once established, TLS only provides for and ensures confidentiality
and integrity of the operations and data in transit over the LDAP
association--and only if the implementations on the client and
server support and negotiate it. The use of TLS does not provide or
ensure for confidentiality and/or non-repudiation of the data housed
by an LDAP-based directory server. Nor does it secure the data from
inspection by the server administrators.

The level of security provided though the use of TLS depends
directly on both the quality of the TLS implementation used and the
style of usage of that implementation. Additionally, an active-
intermediary attacker can remove the Start TLS extended operation
from the supportedExtension attribute of the root DSE. Therefore,
both parties SHOULD independently ascertain and consent to the
security level achieved once TLS is established and before beginning
use of the TLS connection. For example, the security level of the
TLS connection might have been negotiated down to plaintext.

Clients SHOULD either warn the user when the security level achieved
does not provide confidentiality and/or integrity protection, or be
configurable to refuse to proceed without an acceptable level of
security.

Client and server implementors SHOULD take measures to ensure proper
protection of credentials and other confidential data where such
measures are not otherwise provided by the TLS implementation.

Harrison Expires June 2004 [Page 21]

Internet-Draft LDAP Authentication Methods 5 December 2003

Server implementors SHOULD allow for server administrators to elect
whether and when connection confidentiality and/or integrity is
required, as well as elect whether and when client authentication
via TLS is required.

Additional security considerations relating to the EXTERNAL
mechanism to negotiate TLS can be found in [SASL] and [TLS].

11. IANA Considerations

The following IANA considerations apply to this document:

Please update the GSSAPI service name registry to point to [Roadmap]
and this document.

Harrison Expires April 2004 [Page 22]

Internet-Draft LDAP Authentication Methods 7 October 2003

[To be completed]

Contributors

Acknowledgements

This document combines information originally contained in RFC 2829
and RFC 2830. The editor acknowledges the work of Harald Tveit
Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan ,
and Mark Wahl, each of whom authored one or more of these documents.

Acknowledgements

This document is based upon input of the IETF LDAP Revision working
group. The contributions and suggestions made by its members in
shaping the contents and technical accuracy of this document is
greatly appreciated.

Normative References

[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2234]

[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[DigestAuth]

[DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism", draft-ietf-sasl-rfc2831bis-
xx.txt, a work in progress.

[LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in
progress.

[Model]

[Models] Zeilenga, Kurt D. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in progress.

[Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
ldapbis-protocol-xx.txt, a work in progress.

[Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.

Harrison Expires June 2004 [Page 22]

Internet-Draft LDAP Authentication Methods 5 December 2003

[SASL] Melnikov, A. (editor), "Simple Authentication and Security
Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in
progress.

[SASLPrep] Zeilenga, K., "Stringprep profile for user names and
passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
progress).

[StringPrep] Hoffman P. and M. Blanchet, "Preparation of
Internationalized Strings ('stringprep')", draft-hoffman-
rfc3454bis-xx.txt, a work in progress.

[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.

[TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.

[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.

Harrison Expires April 2004 [Page 23]

Internet-Draft LDAP Authentication Methods 7 October 2003 3629, STD 63, November 2003.

[Unicode] International Organization for Standardization, "Universal
Multiple-Octet Coded Character Set (UCS) - Architecture The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as
amended by the "Unicode Standard Annex #27: Unicode 3.1"
(http://www.unicode.org/reports/tr27/) and
Basic Multilingual Plane", ISO/IEC 10646-1 : 1993. by the �Unicode
Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).

Informative References

[ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-zeilenga-
sasl-anon-xx.txt, a work in progress.

[PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-sasl-
plain-xx.txt, a work in progress.

[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
2000.

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.

Author's Address

Roger Harrison
Novell, Inc.
1800 S. Novell Place
Provo, UT 84606
+1 801 861 2642
roger_harrison@novell.com

Full Copyright Statement

Harrison Expires June 2004 [Page 23]

Internet-Draft LDAP Authentication Methods 5 December 2003

Appendix A. Example Deployment Scenarios

This document and translations of it may be copied following scenarios are typical for LDAP directories on the
Internet, and furnished have different security requirements. (In the
following discussion, "sensitive data" refers to
others, and derivative works that comment on information whose
disclosure, alteration, destruction, or otherwise explain it loss would adversely affect
the interests or assist in business of its implementation owner or user. Also note that there
may be prepared, copied, published data that is protected but not sensitive.) This is not
intended to be a comprehensive list; other scenarios are possible,
especially on physically protected networks.

(1) A read-only directory, containing no sensitive data, accessible
to "anyone", and distributed, in whole TCP connection hijacking or IP spoofing is not
a problem. Anonymous authentication, described in part, without restriction section 7, is
suitable for this type of any
kind, provided deployment, and requires no additional
security functions except administrative service limits.

(2) A read-only directory containing no sensitive data; read access
is granted based on identity. TCP connection hijacking is not
currently a problem. This scenario requires data confidentiality
for sensitive authentication information AND data integrity for
all authentication information.

(3) A read-only directory containing no sensitive data; and the
client needs to ensure the identity of the directory server and
that the above copyright notice directory data is not modified while being returned
from the server. A data origin authentication service AND data
integrity service are required.

(4) A read-write directory, containing no sensitive data; read
access is available to "anyone", update access to properly
authorized persons. TCP connection hijacking is not currently a
problem. This scenario requires data confidentiality for
sensitive authentication information AND data integrity for all
authentication information.

(5) A directory containing sensitive data. This scenario requires
data confidentiality protection AND secure authentication.

Appendix B. Authentication and Authorization: Definitions and Concepts

This appendix defines basic terms, concepts, and this paragraph
are included on all such copies interrelationships
regarding authentication, authorization, credentials, and derivative works. However, this
document itself may not be modified identity.
These concepts are used 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 describing how various security
approaches are utilized in which case client authentication and authorization.

B.1. Access Control Policy

An access control policy is a set of rules defining the procedures for
copyrights defined protection
of resources, generally in terms of the Internet Standards process must be
followed, capabilities of persons 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 entities accessing those resources. A common expression of an
access control policy is provided on an
"AS IS" basis access control list. Security objects
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 mechanisms, such as those described here, enable the expression
of access control policies and their enforcement. Access control

Harrison Expires April June 2004 [Page 24]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR

policies are typically expressed in terms of access control factors
as described below.

B.2. Access Control Factors

A PARTICULAR PURPOSE.

Appendix A. Example Deployment Scenarios request, when it is being processed by a server, may be associated
with a wide variety of security-related factors (section 4.2 of
[Protocol]). The following scenarios are typical for LDAP directories on the
Internet, server uses these factors to determine whether and have different security requirements. (In the
following discussion, "sensitive data" refers
how to information whose
disclosure, alteration, destruction, or loss would adversely affect process the interests or business request. These are called access control factors
(ACFs). They might include source IP address, encryption strength,
the type of its owner or user. Also note that there operation being requested, time of day, etc. Some
factors may be data that is protected but not sensitive.) This is not
intended specific to the request itself, others may be a comprehensive list; other scenarios are possible,
especially on physically protected networks.

(1) A read-only directory, containing no sensitive data, accessible
to "anyone", and TCP
associated with the connection hijacking or IP spoofing via which the request is not
a problem. Anonymous authentication, described transmitted,
others (e.g. time of day) may be "environmental".

Access control policies are expressed in section 7, is
suitable for this type terms of deployment, and requires no additional
security functions except administrative service limits.

(2) A read-only directory containing no sensitive data; read access
is granted based control
factors. E.g., a request having ACFs i,j,k can perform operation Y
on identity. TCP connection hijacking is not
currently resource Z. The set of ACFs that a problem. This scenario requires data confidentiality
for sensitive authentication information AND data integrity server makes available for
all authentication information.

(3) A read-only directory containing no sensitive data;
such expressions is implementation-specific.

B.3. Authentication, Credentials, Identity

Authentication credentials are the evidence supplied by one party to
another, asserting the identity of the supplying party (e.g. a user)
who is attempting to establish an association with the other party
(typically a server). Authentication is the process of generating,
transmitting, and verifying these credentials and thus the
client needs to ensure the identity
they assert. An authentication identity is the name presented in a
credential.

There are many forms of authentication credentials -- the directory server form used
depends upon the particular authentication mechanism negotiated by
the parties. For example: X.509 certificates, Kerberos tickets,
simple identity and password pairs. Note that an authentication
mechanism may constrain the directory data is not modified while being returned
from the server. A data origin form of authentication service AND data
integrity service are required.

(4) A read-write directory, containing no sensitive data; read
access identities used
with it.

B.4. Authorization Identity

An authorization identity is available to "anyone", update one kind of access control factor. It
is the name of the user or other entity that requests that
operations be performed. Access control policies are often expressed
in terms of authorization identities; e.g., entity X can perform
operation Y on resource Z.

The authorization identity bound to properly
authorized persons. TCP connection hijacking an association is not currently a
problem. This scenario requires data confidentiality for
sensitive often exactly
the same as the authentication information AND data integrity for all identity presented by the client, but
it may be different. SASL allows clients to specify an authorization
identity distinct from the authentication information.

(5) A directory containing sensitive data. This scenario requires
data confidentiality protection AND secure authentication.

Appendix B. Authentication and Authorization: Definitions and Concepts identity asserted by the
client's credentials. This appendix defines basic terms, concepts, and interrelationships
regarding authentication, authorization, permits agents such as proxy servers to
authenticate using their own credentials, and identity.
These concepts are used in describing how various security
approaches yet request the access
privileges of the identity for which they are utilized in client proxying [SASL]. Also,
the form of authentication and authorization.

B.1. Access Control Policy

An identity supplied by a service like TLS
may not correspond to the authorization identities used to express a

Harrison Expires June 2004 [Page 25]

Internet-Draft LDAP Authentication Methods 5 December 2003

server's access control policy is policy, requiring a set of rules defining server-specific mapping
to be done. The method by which a server composes and validates an
authorization identity from the protection authentication credentials supplied
by a client is implementation-specific.

Appendix C. RFC 2829 Change History

This appendix lists the changes made to the text of resources, generally RFC 2829 in terms
preparing this document.

C.0. General Editorial Changes
Version -00

- Changed other instances of the capabilities term LDAP to LDAP where v3 of persons or
other entities accessing those resources. A common expression the
protocol is implied. Also made all references to LDAP use the
same wording.

- Miscellaneous grammatical changes to improve readability.

- Made capitalization in section headings consistent.

Version -01

- Changed title to reflect inclusion of material from RFC 2830 and
2251.

C.1. Changes to Section 1

Version -01

- Moved conventions used in document to a separate section.

C.2. Changes to Section 2

Version -01

- Moved section to an appendix.

C.3. Changes to Section 3

Version -01

- Moved section to an appendix.

C.4 Changes to Section 4

Version -00

- Changed "Distinguished Name" to "LDAP distinguished name".

C.5. Changes to Section 5

Version -00

Harrison Expires April June 2004 [Page 25] 26]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

access control policy is an access control list. Security objects
and mechanisms, such as those described here, enable

- Added the expression
of access control policies and their enforcement. Access control
policies are typically expressed in terms of access control factors
as described below.

B.2. Access Control Factors

A request, when it is being processed by a server, may be associated following sentence: "Servers SHOULD NOT allow clients
with a wide variety of security-related factors (section 4.2 of
[Protocol]). The server uses these factors to determine whether and
how anonymous authentication to process the request. These are called modify directory entries or
access control factors
(ACFs). They might include source IP address, encryption strength,
the type of operation being requested, time of day, etc. Some
factors may be specific to the request itself, others may be
associated with the connection via which the request is transmitted,
others (e.g. time of day) may be "environmental".

Access control policies are expressed sensitive information in terms of access control
factors. E.g., a request having ACFs i,j,k can perform operation Y
on resource Z. The set of ACFs that a server makes available for
such expressions is implementation-specific.

B.3. Authentication, Credentials, Identity

Authentication credentials are the evidence supplied by one party directory entries."

C.5.1. Changes to
another, asserting Section 5.1

Version -00

- Replaced the identity of text describing the supplying party (e.g. procedure for performing an
anonymous bind (protocol) with a user)
who is attempting reference to establish section 4.2 of RFC
2251 (the protocol spec).

Version -01

- Brought text describing procedure for performing an association with the other party
(typically a server). Authentication is the process anonymous
bind from section 4.2 of generating,
transmitting, and verifying these credentials and thus the identity
they assert. An authentication identity is RFC 2251 bis. This text will be
removed from the name presented draft standard version of that document.

C.6. Changes to Section 6.

Version -00

Reorganized text in section 6.1 as follows:

1. Added a
credential.

There are many forms new section (6.1) titled "Simple Authentication" and
moved one of authentication credentials -- the form used
depends upon the particular authentication mechanism negotiated by two introductory paragraphs for section 6 into
section 6.1. Added sentences to the parties. For example: X.509 certificates, Kerberos tickets, paragraph indicating:

a. simple identity and password pairs. Note that an authentication
mechanism may constrain the form of authentication identities used
with it.

B.4. Authorization Identity

An authorization identity is one kind of access control factor. It not suitable for environments where
confidentiality is the name of the user or other entity that requests that
operations be performed. Access control policies not available.

b. LDAP implementations SHOULD NOT support simple
authentication unless confidentiality and data integrity
mechanisms are often expressed in terms force.

2. Moved first paragraph of authorization identities; e.g., entity X can perform
operation Y on resource Z.

The authorization identity bound to an association is often exactly
the same as the section 6 (beginning with "LDAP
implementations MUST support authentication identity presented by the client, but
it may be different. SASL allows clients with a password...")
to section on Digest Authentication (Now section 6.2).

C.6.1. Changes to specify an authorization
identity distinct Section 6.1.

Version -00 Renamed section to 6.2

- Added sentence from original section 6 indicating that the authentication identity asserted by the
client's credentials. This permits agents such as proxy servers
DIGEST-MD5 SASL mechanism is required for all conforming LDAP
implementations

C.6.2. Changes to
authenticate using their own credentials, yet request the access Section 6.2

Version -00

- Renamed section to 6.3

Harrison Expires April June 2004 [Page 26] 27]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

privileges of

- Reworded first paragraph to remove reference to user and the identity for which they are proxying [SASL]. Also,
userPassword password attribute Made the form of authentication identity supplied first paragraph more
general by simply saying that if a directory supports simple
authentication that the simple bind operation MAY performed
following negotiation of a service like TLS
may ciphersuite that supports
confidentiality.

- Replaced "the name of the user's entry" with "a DN" since not correspond
all bind operations are performed on behalf of a "user."

- Added Section 6.3.1 heading just prior to paragraph 5.

- Paragraph 5: replaced "The server" with "DSAs that map the authorization identities used DN
sent in the bind request to express a
server's access control policy, requiring directory entry with a server-specific mapping
userPassword attribute."

C.6.3. Changes to be done. The method by which a server composes and validates an
authorization identity from the authentication credentials supplied
by a client is implementation-specific.

Appendix C. RFC 2829 Change History

This appendix lists the changes made section 6.3.

Version -00

- Renamed to the text of RFC 2829 in
preparing this document.

C.0. General Editorial section 6.4.

C.7. Changes to section 7.

none

C.7.1. Changes to section 7.1.

Version -00

- Changed other instances of Clarified the term LDAP to LDAP where v3 of entity issuing a certificate by moving the
protocol is implied. Also made all references to LDAP use phrase
"to have issued the
same wording.

- Miscellaneous grammatical changes certificate" immediately after
"Certification Authority."

C.8. Changes to improve readability. section 8.

Version -00

- Made capitalization Removed the first paragraph because simple authentication is
covered explicitly in section headings consistent.

Version -01 6.

- Changed title to reflect inclusion of material from RFC 2830 and
2251.

C.1. Changes Added section 8.1. heading just prior to Section 1

Version -01 second paragraph.

- Moved conventions used in document to a separate section.

C.2. Changes Added section 8.2. heading just prior to Section 2

Version -01 third paragraph.

- Moved Added section 8.3. heading just prior to an appendix.

C.3. Changes to Section 3 fourth paragraph.

Version -01

- Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL
for Other Security Services) to an appendix.

C.4 Changes to Section 4

Version -00

- Changed "Distinguished Name" to "LDAP distinguished name".

C.5. bring material on SASL
mechanisms together into one location.

C.9. Changes to Section 5 section 9.

Harrison Expires April June 2004 [Page 27] 28]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

Version -00

- Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL
mechanism."

- Added section 9.1. heading.

- Modified a comment in the following sentence: "Servers SHOULD NOT allow clients
with anonymous authentication ABNF from "unspecified userid" to
"unspecified authz id".

- Deleted sentence, "A utf8string is defined to be the UTF-8
encoding of one or more ISO 10646 characters," because it is
redundant.

- Added section 9.1.1. heading.

- Added section 9.1.2. heading.

Version -01

- Moved entire section 9 to modify directory entries or
access sensitive information in directory entries."

C.5.1. become section 3.5 so that it would be
with other SASL material.

C.10. Changes to Section 5.1 10.

Version -00

- Replaced the text describing the procedure for performing an
anonymous bind (protocol) with a Updated reference to section 4.2 of RFC
2251 (the protocol spec).

Version -01

- Brought text describing procedure for performing an anonymous
bind cracking from section 4.2 a week of RFC 2251 bis. This text will CPU time in 1997 to
be
removed from the draft standard version a day of that document.

C.6. Changes to Section 6.

Version -00

Reorganized text CPU time in section 6.1 as follows:

1. 2000.

- Added a new section (6.1) titled "Simple Authentication" text: "These ciphersuites are NOT RECOMMENDED for use...
and
moved one server implementers SHOULD" to sentence just prior the
second list of two introductory paragraphs for section 6 into
section 6.1. ciphersuites.

- Added sentences text: "and MAY support other ciphersuites offering
equivalent or better protection," to the paragraph indicating:

a. simple authentication is not suitable for environments where
confidentiality is not available.

b. LDAP implementations SHOULD NOT support simple
authentication unless confidentiality and data integrity
mechanisms are in force.

2. Moved first last paragraph of section 6 (beginning with "LDAP
implementations MUST support authentication with a password...")
to section on Digest Authentication (Now section 6.2).

C.6.1. the
section.

C.11. Changes to Section 6.1. 11.

Version -00 Renamed section to 6.2 -01

- Added sentence from original Moved to section 6 indicating that the
DIGEST-MD5 SASL mechanism is required for all conforming LDAP
implementations

C.6.2. 3.6 to be with other SASL material.

C.12. Changes to Section 6.2 12.

Version -00

- Inserted new section 12 that specifies when SASL protections
begin following SASL negotiation, etc. The original section 12
is renumbered to become section 13.

Version -01

Harrison Expires April June 2004 [Page 28] 29]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

- Renamed Moved to section 3.7 to 6.3

- Reworded first paragraph be with other SASL material.

C.13. Changes to remove reference Section 13 (original section 12).

None

Appendix D. RFC 2830 Change History

This appendix lists the changes made to user and the
userPassword password attribute Made text of RFC 2830 in
preparing this document.

D.0. General Editorial Changes

- Material showing the first paragraph more
general by simply saying that if a directory supports simple
authentication that PDUs for the simple bind operation MAY performed
following negotiation of a Start TLS ciphersuite that supports
confidentiality. response was broken
out into a new section.

- Replaced "the name The wording of the user's entry" with "a DN" since not
all bind operations are performed on behalf definition of a "user."

- Added Section 6.3.1 heading just prior to paragraph 5.

- Paragraph 5: replaced "The server" with "DSAs that map the DN
sent in the bind Start TLS request and Start
TLS response was changed to a directory entry with a
userPassword attribute."

C.6.3. Changes to section 6.3.

Version -00

- Renamed to section 6.4.

C.7. Changes to section 7.

none

C.7.1. Changes make them parallel. NO changes were
made to section 7.1.

Version -00

- Clarified the entity issuing a certificate by moving the phrase
"to have issued ASN.1 definition or the certificate" immediately after
"Certification Authority."

C.8. Changes to section 8.

Version -00

- Removed associated values of the first paragraph because simple authentication is
covered explicitly in section 6.
parameters.

- Added A separate section 8.1. heading just prior to second paragraph.

- Added for graceful TLS closure was added
for parallelism with section 8.2. heading just prior on abrupt TLS closure.

Appendix E. RFC 2251 Change History

This appendix lists the changes made to third paragraph. the text of RFC 2251 in
preparing this document.

E.0. General Editorial Changes

- Added All material from section 8.3. heading just prior to fourth paragraph.

Version -01 4.2 of RFC 2251 was moved into this
document.

- Moved entire A new section 8 was created for the Bind Request

- Section 4.2.1 of RFC 2829 into 2251 (Sequencing Bind Request) was moved
after the section 3.4 (Using SASL on the Bind Response for Other Security Services) parallelism with the
presentation of the Start TLS operations. The section was also
subdivided to bring material on explicitly call out the various effects being
described within it.

- All SASL
mechanisms together into one location. profile information from RFC 2829 was brought within
the discussion of the Bind operation (primarily sections 4.4 -
4.7).

Appendix F. Change History to Combined Document

F.1. Changes for draft-ldap-bis-authmeth-02

General

Harrison Expires April June 2004 [Page 29] 30]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

C.9. Changes to section 9.

Version -00

- Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL
mechanism."

- Added section 9.1. heading.

- Modified a comment in the ABNF from "unspecified userid" references to
"unspecified authz id".

- Deleted sentence, "A utf8string is defined other LDAP standard documents, to be sections
within the UTF-8
encoding of one or more ISO 10646 characters," because it is
redundant. document, and fixed broken references.

- Added section 9.1.1. heading. General editorial changes--punctuation, spelling, formatting,
etc.

Section 1.

- Added section 9.1.2. heading.

Version -01 glossary of terms and added sub-section headings

Section 2.

- Moved entire section 9 to become section 3.5 so that it would be Clarified security mechanisms 3, 4, & 5 and brought language in
line with other SASL material.

C.10. Changes to IETF security glossary.

Section 10.

Version -00 3.

- Updated reference to cracking from a week of CPU time Brought language in 1997 to
be a day of CPU time requirement (3) in 2000. line with security
glossary.

- Added text: "These ciphersuites are NOT RECOMMENDED for use...
and server implementers SHOULD" to sentence just Clarified that information fetched prior the
second list of ciphersuites.

- Added text: "and MAY support other ciphersuites offering
equivalent or better protection," to the last paragraph initiation of the
section.

C.11. Changes to Section 11.

Version -01

- Moved to section 3.6 TLS
negotiation must be discarded

-Clarified that information fetched prior to initiation of SASL
negotiation must be with other discarded

- Rewrote paragraph on SASL material.

C.12. Changes negotiation requirements to clarify
intent

Section 12.

Version -00 4.4.

- Inserted new section 12 Added stipulation that specifies when sasl choice allows for any SASL protections
begin following mechanism
not prohibited by this document. (Resolved conflict between this
statement and one that prohibited use of ANONYMOUS and PLAIN
SASL negotiation, etc. The original section 12
is renumbered mechanisms.)

Section 5.3.6

- Added a.x.bar.com to wildcard matching example on hostname
check.

Section 6

- Added LDAP Association State Transition Tables to show the
various states through which an LDAP association may pass along
with the actions and decisions required to become section 13. traverse from state
to state.

Appendix A

- Brought security terminology in line with IETF security glossary
throughout the appendix.

F.2. Changes for draft-ldap-bis-authmeth-03

Harrison Expires April June 2004 [Page 30] 31]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

Version -01

General

- Moved to section 3.7 Added introductory notes and changed title of document and
references to be with other SASL material.

C.13. Changes conform to Section 13 (original section 12).

None

Appendix D. RFC 2830 Change History

This appendix lists WG chair suggestions for the overall
technical specification.

- Several issues--G.13, G.14, G.16, G.17--were resolved without
requiring changes made to the text of RFC 2830 in
preparing this document.

D.0. General Editorial Changes

Section 3

- Material showing the PDUs for the Start TLS response was broken
out into a new section. Removed reference to /etc/passwd file and associated text.

Section 4

- The wording of the definition Removed sections 4.1, 4.2 and parts of section 4.3. This
information was being duplicated in the Start TLS request protocol specification
and Start
TLS response was will now reside there permanently.
Section 4.2

- changed words, "not recommended" to make them parallel. NO changes were
made to the ASN.1 definition or the associated values of the
parameters. "strongly discouraged"

Section 4.3

- A separate section heading for graceful TLS closure was Based on ldapbis WG discussion at IETF52 two sentences were
added
for parallelism indicating that clients SHOULD NOT send a DN value when
binding with section on abrupt TLS closure.

Appendix E. RFC 2251 Change History

This appendix lists the changes made to the text of RFC 2251 sasl choice and servers SHALL ignore any value
received in
preparing this document.

E.0. General Editorial Changes

- All material from section 4.2 of RFC 2251 was moved into this
document.

- A new section was created for the Bind Request circumstance.
-

Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved
after the section on the Bind Response for parallelism with 8.3.1

- Generalized the
presentation language of the Start TLS operations. The this section was also
subdivided to explicitly call out not refer to any
specific password attribute or to refer to the various effects being
described within it. directory entry
as a "user" entry.

Section 11

- All SASL profile information from RFC 2829 was brought within
the discussion Added security consideration regarding misuse of the Bind operation (primarily sections 4.4 unauthenticated
access.

-
4.7).

Appendix F. Change History Added security consideration requiring access control to Combined Document

F.1. be
applied only to authenticated users and recommending it be
applied when reading sensitive information or updating directory
information.

F.3. Changes for draft-ldap-bis-authmeth-02 draft-ldap-bis-authmeth-04

General

- Changed references to use [RFCnnnn] format wherever possible.
(References to works in progress still use [name] format.)

Harrison Expires April June 2004 [Page 31] 32]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

- Added references Various edits to other correct typos and bring field names, etc. in
line with specification in [Protocol] draft.

- Several issues--G.13, G.14, G.16, G.17--were resolved without
requiring changes to the document.

Section 4.4.1.

- Changed ABNF grammar to use productions that are like those in
the model draft.

Section 5

- Removed sections 5.1, 5.2, and 5.4 that will be added to
[Protocol]. Renumbered sections to accommodate this change.
-

Section 6

- Reviewed LDAP standard documents, Association State table for completeness and
accuracy. Renumbered actions A3, A4, and A5 to sections
within be A5, A3, and A4
respectively. Re-ordered several lines in the document, table to ensure
that actions are in ascending order (makes analyzing the table
much more logical). Added action A2 to several states where it
was missing and fixed broken references.

- General editorial changes--punctuation, spelling, formatting,
etc.

Section 1.

- valid. Added glossary of terms actions A7 and added sub-section headings

Section 2.

- Clarified security mechanisms 3, 4, & 5 A8 placeholders to
states S1, S2, S4 and brought language in
line with IETF security glossary. S5 pending resolution of issue G.28.

Section 3. 11

- Brought language in requirement (3) in line with Modified security
glossary.

- Clarified that information fetched prior consideration (originally added in -03)
requiring access control to initiation of TLS
negotiation must be discarded

-Clarified that information fetched prior applied only to initiation of SASL
negotiation must be discarded

- Rewrote paragraph on SASL negotiation requirements authenticated
users. This seems nonsensical because anonymous users may have
access control applied to clarify
intent limit permissible actions.
-
Section 4.4. 13

- Added stipulation that sasl choice allows Verified all normative references and moved informative
references to a new section 14.

F.4. Changes for any SASL mechanism
not prohibited by this document. (Resolved conflict between this
statement draft-ldap-bis-authmeth-05

General

- General editory changes to fix punctuation, spelling, line
length issues, etc.
- Verified and one that prohibited use of ANONYMOUS updated intra- and PLAIN
SASL mechanisms.)

Section 5.3.6 inter-document references
throughout.
- Added a.x.bar.com Document-wide review for proper usage of RFC 2119 keywords with
several changes to wildcard matching example on hostname
check.

Section 6 correct improper usage.

Abstract
- Added LDAP Association State Transition Tables Updated to show the
various states through which an LDAP association may pass along
with the actions and decisions required match current contents of documents. This was needed
due to traverse from state movement of material on Bind and Start TLS operations to state.

Appendix A

- Brought security terminology
[Protocol] in line with IETF security glossary
throughout the appendix. this revision.

Harrison Expires April June 2004 [Page 32] 33]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

F.2. Changes for draft-ldap-bis-authmeth-03

General

Section 3.

- Added introductory notes and changed title of document and
references to conform Renamed section to WG chair suggestions "Rationale for LDAP Security Mechanisms" and
removed text that did not support this theme. Part of the overall
technical specification.

- Several issues--G.13, G.14, G.16, G.17--were resolved without
requiring changes
motivation for this change was to remove the document.

Section 3

- Removed reference to /etc/passwd file and associated text.

Section 4

- Removed sections 4.1, 4.2 and parts implication of the
previous section title, "Required Security Mechanisms", and
other text found in the section that everything in the section 4.3. This
information
was being duplicated a requirement

- Information from several removed paragraphs that describe
deployment scenarios will be added Appendix A in the protocol specification next
revision of the draft.

- Paragraph beginning, " If TLS is negotiated, the client MUST
discard all information..." was moved to section 5.1.7 and will now reside there permanently.
Section
integrated with related material there.

- Paragraph beginning, "If a SASL security layer is negotiated..."
was moved to section 4.2

Section 4.l.

- changed words, "not recommended" Changed wording of first paragraph to "strongly discouraged" clarify meaning.

Section 4.3 4.2.
- Based on ldapbis WG discussion at IETF52 two sentences were
added indicating that clients SHOULD NOT send Added paragraph from section 3 of -04 beginning, "If a DN value when
binding with the sasl choice and servers SHALL ignore any value
received in this circumstance.
- SASL
security layer is negotiated..."

Section 8.3.1 4.3.3.
- Generalized Renamed to "Other SASL Mechanisms" and completely rewrote the language of this
section (one sentence) to not refer to any
specific password attribute or to refer to generalize the directory entry
as a "user" entry.

Section 11

- Added security consideration regarding misuse treatment of unauthenticated
access. SASL
mechanisms not explicitly mentioned in this document.

Section 4.4.1.

- Added security consideration requiring access control paragraph beginning, "The dnAuthzID choice allows client
applications..." to be
applied only clarify whether DN form authorization
identities have to authenticated users and recommending it be
applied when reading sensitive information or updating also have a corresponding directory
information.

F.3. Changes entry.
This change was based on editor's perception of WG consensus.

- Made minor clarifying edits in the paragraph beginning, "The
uAuthzID choice allows for draft-ldap-bis-authmeth-04

General compatibility..."

Section 5.1.1.

- Made minor clarifying edits in the last paragraph of the
section.

Section 5.1.7.

Harrison Expires April June 2004 [Page 33] 34]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

- Changed references to use [RFCnnnn] format wherever possible.
(References to works in progress still use [name] format.)
- Various edits to correct typos Wording from section 3 paragraph beginning " If TLS is
negotiated, the client MUST discard all information..." was
moved to this section and bring field names, etc. in
line integrated with specification in [Protocol] draft.

- Several issues--G.13, G.14, G.16, G.17--were resolved without
requiring changes to the document. existing text.

Section 4.4.1. 5.2.

- Changed ABNF grammar usage of "TLS connection" to use productions that are like those in
the model draft.

Section 5 "TLS session" throughout.

- Removed sections 5.1, 5.2, empty section 5.2.1 and 5.4 that will be added to
[Protocol]. Renumbered renumbered sections to accommodate this change. it had
previously contained.

Section 8.

- Added introductory paragraph at beginning of section.

Section 6 8.1.

- Reviewed LDAP Association State table for completeness and
accuracy. Renumbered actions A3, A4, and A5 Changed term "data privacy" to "data confidentiality" to be A5, A3, and A4
respectively. Re-ordered several lines
consistent with usage in the table rest of document.

Section 8.2.

- Changed first paragraph to ensure require implementations that actions are in ascending order (makes analyzing the table
much more logical). Added action A2 to several states where it
was missing and valid. Added actions A7 and A8 placeholders
implement *password-based* authentication to
states S1, S2, S4 implement and S5 pending resolution of issue G.28.
support DIGEST-MD5 SASL authentication.

Section 11 11.

- Modified security consideration (originally added in -03)
requiring access control First paragraph: changed "session encryption" to be applied only "session
confidentiality protection" to authenticated
users. This seems nonsensical because anonymous users may have
access control applied be consistent with usage in rest
of document.

Appendix A.

- Began changes to limit permissible actions. incorporate information on deployment scenarios
removed from section 3.

F.5. Changes for draft-ldap-bis-authmeth-06

General

- Combined Section 13

- Verified all normative references 2 (Introduction) and Section 3 (Motivation) and
moved informative
references Introduction to a new section 14.

F.4. Changes for draft-ldap-bis-authmeth-05

General 1. All following sections numbers
were decremented by one as result.

- General editory changes Edits to fix punctuation, spelling, line
length issues, typos, I-D nits, etc.

- Verified and updated intra- and inter-document references
throughout.
- Document-wide review for proper usage of RFC 2119 keywords with Opened several changes to correct improper usage.

Abstract new issues in Appendix G based on feedback from
WG. Some of these have been resolved. Others require further
discussion.

Section 1

Harrison Expires April June 2004 [Page 34] 35]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

- Updated to match current contents Added additional example of documents. This was needed
due to movement spoofing under threat (7).

Section 2.1

- Changed definition of material on Bind "LDAP association" and Start TLS operations added terms,
"connection" and "TLS connection" to
[Protocol] bring usage in this revision. line with
[Protocol].

Section 3. 4.1.6

- Renamed section to "Rationale for LDAP Security Mechanisms" and
removed text Clarified sentence stating that did not support this theme. Part of the
motivation for this change was to remove the implication client MUST NOT use derived
forms of the
previous section title, "Required Security Mechanisms", and
other text found in the section that everything in the section
was a requirement DNS names.

Section 5.1

- Information from several removed paragraphs that describe
deployment scenarios will be added Appendix A in the next
revision Began edits to LDAP Association state table to clarify meaning
of the draft. various states and actions.

- Paragraph beginning, " If TLS is negotiated, the client MUST
discard all information..." was moved Added action A9 to section 5.1.7 cover abandoned bind operation and
integrated with related material there.

- Paragraph beginning, "If a SASL security layer is negotiated..."
was moved added
appropriate transitions to section 4.2 the state transition table to
accommodate it.

Section 4.l. 7.2

- Changed wording of Replaced first paragraph to clarify meaning.

Section 4.2.
- Added paragraph from section 3 of -04 beginning, "If a that the "DIGEST-MD5" SASL
security layer
mechanism is negotiated..." required to implement.

Section 4.3.3. 9

- Renamed to "Other SASL Mechanisms" and completely rewrote Rewrote the section (one sentence) to generalize make the treatment advice more applicable over the
long term, i.e. more "timeless." The intent of SASL
mechanisms not explicitly mentioned content in this document. the
original section was preserved.

Section 4.4.1. 10

- Added paragraph beginning, "The dnAuthzID choice allows client
applications..." to clarify whether DN form authorization
identities have to also have a corresponding directory entry.
This change was based on editor's perception of WG consensus.

- Made minor clarifying edits in the paragraph beginning, "The
uAuthzID choice allows for compatibility..."

Section 5.1.1.

- Made minor clarifying edits in example to the last paragraph consideration regarding misuse
of the
section.

Section 5.1.7.

Harrison Expires April 2004 [Page 35]

Internet-Draft LDAP Authentication Methods 7 October 2003 unauthenticated access.

F.6. Changes for draft-ldap-bis-authmeth-07

General

- Wording from section 3 paragraph beginning " If TLS is
negotiated, the client MUST discard all information..." was
moved to this section Updated external and integrated with existing text.

Section 5.2.

- Changed usage of "TLS connection" internal references to "TLS session" throughout. accommodate changes
in recent drafts.

- Removed empty section 5.2.1 and renumbered sections it had
previously contained. Opened several new issues in Appendix G based on feedback from
WG. Some of these have been resolved. Others require further
discussion.

Section 8. 3

- Added introductory paragraph at beginning Rewrote much of section.

Section 8.1. section 3.3 to meet the SASL profile
requirements of draft-ietf-sasl-rfc2222bis-xx.txt section 5.

Harrison Expires June 2004 [Page 36]

Internet-Draft LDAP Authentication Methods 5 December 2003

- Changed term "data privacy" to "data confidentiality" treatement of SASL ANONYMOUS and PLAIN mechanisms to be
consistent with usage
bring in rest of document. line with WG consensus.

Section 8.2. 4

- Changed first paragraph Note to require implementations that
implement *password-based* implementers in section 4.1.1 based on operational
experience.

- Clarification on client continuing by performing a Start TLS
with TLS already established in section 4.1.4.

- Moved verification of mapping of client's authentication ID to implement and
support DIGEST-MD5 SASL authentication.

Section 11.

- First paragraph: changed "session encryption"
asserted authorization ID to "session
confidentiality protection" apply only to be consistent with usage explicit assertion.
The local policy in rest
of document.

Appendix A. place for implicit assertion is adequate.

Section 7

- Began changes to incorporate Removed most of section 7.2 as the information on deployment scenarios
removed from is now covered
adequately via the new SASL profile in section 3.

F.5. Changes for draft-ldap-bis-authmeth-06

General 3.3. Added note
to implementors regarding the treatment of username and realm
values in DIGEST-MD5.

- Combined Section 2 (Introduction) and 7.3. Minor clarifications in wording.

- Section 3 (Motivation) and
moved Introduction 7.3.1. Clarification that a match of the presented value
to section 1. All following sections numbers
were decremented by one as result. any member of the set of stored passwords constitutes a
successful authentication.

F.6. Changes for draft-ldap-bis-authmeth-08

General

- Edits Changed usage from LDAPv3 to fix typos, I-D nits, etc. LDAP for usage consistency across
LDAP technical specification.

- Opened several new issues Fixed a number of usage nits for consistency and to bring doc in Appendix G
conformance with publication guidelines.

Abstract

- Significant cleanup and rewording of abstract based on feedback from
WG. Some WG
feedback.

Section 2.1

- New definition of these have been resolved. Others require further
discussion. user.

Section 1 3

- Added 1.5 sentences at end of introductory paragraph indicating
the effect of the Bind op on the LDAP association.

Harrison Expires April June 2004 [Page 36] 37]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

- Added additional example of spoofing under threat (7).

Section 2.1 3.1

- Changed definition of "LDAP association" and added terms,
"connection" Retitled section and "TLS connection" to bring usage in line with
[Protocol]. clarified wording

Section 4.1.6 3.2

- Clarified sentence stating that the client MUST NOT use derived
forms simple authentication choice provides three types
of DNS names. authentication: anonymous, unauthenticated, and simple
password.

Section 5.1 3.3.3

- Began edits to LDAP Association state table to clarify meaning
of various states and actions. New wording clarifying when negotiated security mechanisms take
effect.

Section 3.3.5

- Added action A9 Changed requirement to cover abandoned bind operation and added
appropriate transitions discard information about server fetched
prior to the state transition table SASL negotiation from MUST to
accommodate it. SHOULD to allow for
information obtained through secure mechanisms.

Section 7.2 3.3.6

- Replaced Simplified wording of first paragraph to clarify based on suggestion from
WG.

Section 3.4

- Minor clarifications in wording.

Section 3.4.1

- Minor clarifications in wording in first sentence.
- Explicitly called out that the "DIGEST-MD5" SASL
mechanism DN value in the dnAuthzID form is required
to implement.

Section 9 be matched using DN matching rules.
- Rewrote Called out that the section uAuthzID MUST be prepared using SASLprep
rules before being compared.
- Clarified requirement on assuming global uniqueness by changing
a "generally... MUST" wording to make the advice more applicable over the
long term, i.e. more "timeless." The intent of content in the
original section was preserved. "SHOULD".

Section 10 4.1.1

- Added a clarifying example Simplified wording describing conditions when Start TLS cannot
be sent.
- Simplified wording in note to the consideration implementers regarding misuse
of unauthenticated access.

F.6. Changes for draft-ldap-bis-authmeth-07

General race
condition with outstanding LDAP operations on connection.

Section 4.1.5

- Updated external Removed section and internal references moved relevant text to accommodate changes
in recent drafts.

- Opened several new issues in Appendix G based on feedback from
WG. Some of these have been resolved. Others require further
discussion. section 4.2.2.

Section 3 4.1.6

- Renumbered to 4.1.5.

Harrison Expires April June 2004 [Page 37] 38]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

- Rewrote much of section 3.3 Updated server identity check rules for server's name based on
WG list discussion.

Section 4.1.7

- Renumbered to mee the SASL profile requirements 4.1.6
- Changed requirement to discard information about server fetched
prior to TLS negotion from MUST to SHOULD to allow for
information obtained through secure mechanisms.

Section 6.1

- Clarified wording.
- Added definition of draft-ietf-sasl-rfc2222bis-xx.txt anonymous and unauthenticated binds.

Section 10

- Added security consideration (moved from elsewhere) discouraging
use of cleartext passwords on unprotected communication
channels.

Section 11

- Added an IANA consideration to update GSSAPI service name
registry to point to [Roadmap] and [Authmeth]

F.7. Changes for draft-ldap-bis-authmeth-09

General

- Updated section 5. references within document
- Changed treatement of SASL ANONYMOUS and PLAIN mechanisms reference tags to
bring match other docs in line with WG consensus.

Section 4 LDAP TS
- Note to implementers in section 4.1.1 based on operational
experience. Used non-quoted names for all SAL mechanisms

Abstract

- Clarification on client continuing by performing a Start TLS
with TLS already established Inspected keyword usage and removed several improper usages.

- Removed sentence saying DIGEST-MD5 is LDAP's mandatory-to-
implement mechanism. This is covered elsewhere in section 4.1.4. document.

- Moved verification section 5, authentication state table, of mapping -08 draft to
section 8 of client's authentication ID -09 and completely rewrote it.

Section 1

- Reworded sentence beginning, "It is also desireable to
asserted authorization ID allow
authentication methods to apply only carry identities based on existing�
non-LDAP DN�forms..."
- Clarified relationship of this document to explicit assertion.
The local policy other documents in place for implicit assertion is adequate.
the LDAP TS.

Section 7 3.3.5

Harrison Expires June 2004 [Page 39]

Internet-Draft LDAP Authentication Methods 5 December 2003

- Removed most of section 7.2 as paragraph beginning,"If the information client is now covered
adequately via the new configured to
support multiple SASL profile mechanisms..." because the actions
specified in section 3.3. Added note
to implementors regarding the treatment paragraph do not provide the protections
indicated. Added a new paragraph indicating that clients and
server should allow specification of username acceptable mechanisms and realm
values in DIGEST-MD5.
only allow those mechanisms to be used.

- Section 7.3. Minor clarifications Clarified independent behavior when TLS and SASL security layers
are both in wording.

- Section 7.3.1. Clarification that a match of force (e.g. one being removed doesn't affect the presented value
to any member
other).

Section 3.3.6

- Moved most of the set section 4.2.2, Client Assertion of stored passwords constitutes a
successful authentication.

F.6. Changes for draft-ldap-bis-authmeth-08

General Authorization
Identity, to sections 3.3.6, 3.3.6.1, and 3.3.6.2.

Section 3.3.6.4

- Changed usage from LDAPv3 Moved some normative comments into text body.

Section 4.1.2

- Non success resultCode values are valid if server is *unwilling*
or unable to LDAP for usage consistency across
LDAP technical specification. negotiate TLS.

Section 4.2.1

- Fixed a number Rewrote entire section based on WG feedback.

Section 4.2.2

- Moved most of usage nits for consistency and this section to bring doc in
conformance with publication guidelines.

Abstract 3.3.6 for better document flow.

Section 4.2.3

- Significant cleanup and rewording of abstract Rewrote entire section based on WG feedback.

Section 2.1 5.1

- New definition of user. Moved imperative language regarding unauthenticated access from
security considerations to here.

Section 3 6

- Added 1.5 sentences at end of introductory paragraph indicating several paragraphs regarding the effect risks of transmitting
passwords in the Bind op on the LDAP association. clear and requiring server implementations to
provide a specific configuration that reduces these risks.

Section 6.2

- Added sentence describing protections provided by DIGEST-MD5
method.
- Changed DNs in exmple to be dc=example,dc=com.

Harrison Expires April June 2004 [Page 38] 40]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

Section 3.1

- Retitled section and clarified wording

Section 3.2 10

- Clarified that simple Updated consideration on use of cleartext passwords to include
other unprotected authentication choice provides three types credentials
- Substantial rework of authentication: anonymous, unauthenticated, consideration on misuse of unauthenticated
bind.

Appendix G. Issues to be Resolved

This appendix lists open questions and simple
password. issues that need to be
resolved before work on this document is deemed complete.

G.1.

Section 3.3.3

- New wording clarifying when negotiated 1 lists 6 security mechanisms take
effect.

Section 3.3.5

- that can be used by LDAP
servers. I'm not sure what mechanism 5, "Resource limitation by
means of administrative limits on service controls" means.

Status: resolved. Changed requirement to discard information about server fetched
prior to SASL negotion from MUST wording to SHOULD "administrative service limits"
to allow for
information obtained through secure mechanisms. clarify meaning.

G.2.

Section 3.3.6

- Simplified wording of first 2 paragraph based on suggestion from
WG.

Section 3.4

- Minor clarifications in wording.

Section 3.4.1

- Minor larifications in wording in first sentence.
- Explicitly called out that 1 defines the DN value term, "sensitive." Do we want to
bring this term and other security-related terms in alignment with
usage with the dnAuthzID form is
to be matched using DN matching rules.
- Called out IETF security glossary (RFC 2828)?

Status: resolved. WG input at IETF 51 was that we should do this, so
the uAuthzID MUST be prepared using SASLprep
rules before being compared.
- Clarified requirement on assuming global uniqueness appropriate changes have been made.

G.3.

Section 2, deployment scenario 2: What is meant by changing the term "secure
authentication function?"

Status: resolved. Based on the idea that a "generally... MUST" wording to "SHOULD".

Section 4.1.1

- Simplified wording describing conditions when Start TLS cannot "secure authentication
function" could be sent.
- Simplified provided by TLS, I changed the wording in note to implementers regarding race
condition with outstanding LDAP operations on connection. require
data confidentiality for sensitive authentication information and
data integrity for all authentication information.

G.4.

Section 4.1.5

- Removed section 3, deployment scenario 3: What is meant by the phrase,
"directory data is authenticated by the server?"

Status: resolved. I interpreted this to mean the ability to ensure
the identity of the directory server and moved relevant text the integrity of the data
sent from that server to section 4.2.2.

Section 4.1.6 the client, and explictly stated such.

G.5.

Harrison Expires April June 2004 [Page 39] 41]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

- Renumbered to 4.1.5.
- Updated server identity check rules for server's name based on
WG list discussion.

Section 4.1.7

- Renumbered to 4.1.6
- Changed requirement to discard information about server fetched
prior to TLS negotion from MUST to SHOULD to allow 4 paragraph 3: What is meant by the phrase, "this means that
either this data is useless for
information obtained through secure mechanisms.

Section 6.1

- Clarified wording.
- Added definition of anonymous and unauthenticated binds.

Section 10

- Added security consideration (moved from elsewhere) discouraging
use of cleartext passwords on unprotected communication
channels.

Section 11

- Added an IANA consideration to update GSSAPI service name
registry to point to [Roadmap] and [Authmeth]

Appendix G. Issues faking authentication (like the Unix
"/etc/passwd" file format used to be Resolved

This appendix lists open questions and issues be)?"

Status: resolved. Discussion at IETF 52 along with discussions with
the original authors of this material have convinced us that need to be
resolved before work on this document
reference is deemed complete.

G.1.

Section 1 lists 6 security mechanisms that can simply too arcane to be used by LDAP
servers. I'm not sure what mechanism 5, "Resource limitation by
means left in place. In -03 the text
has been modified to focus on the need to either update password
information in a protected fashion outside of administrative limits on service controls" means. the protocol or to
update it in session well protected against snooping, and the
reference to /etc/passwd has been removed.

G.6.

Section 4 paragraph 7 begins: "For a directory needing session
protection..." Is this referring to data confidentiality or data
integrity or both?

Status: resolved. Changed wording to "administrative service limits"
to clarify meaning.

G.2. say, "For a directory needing
data security (both data integrity and data confidentiality)..."

G.7.

Section 2 4 paragraph 1 defines 8 indicates that "information about the term, "sensitive." server
fetched prior to the TLS negotiation" must be discarded. Do we want
to
bring explicitly state that this term and other security-related terms in alignment with
usage with applies to information fetched prior
to the IETF security glossary (RFC 2828)? *completion* of the TLS negotiation or is this going too far?

Status: resolved. WG input at Based on comments in the IETF 51 was LDAPBIS WG
meeting, this has been changed to explicitly state, "fetched prior
to the initiation of the TLS negotiation..."

G.8.

Section 4 paragraph 9 indicates that we should do this, so clients SHOULD check the
supportedSASLMechanisms list both before and after a SASL security
layer is negotiated to ensure that they are using the best available
security mechanism supported mutually by the client and server. A
note at the end of the paragraph indicates that this is a SHOULD
since there are environments where the client might get a list of
supported SASL mechanisms from a different trusted source.

I wonder if the intent of this could be restated more plainly using
one of these two approaches (I've paraphrased for the appropriate changes have been made.

G.3.

Section 2, deployment scenario sake of
brevity):

Approach 1: Clients SHOULD check the supportedSASLMechanisms
list both before and after SASL negotiation or clients SHOULD
use a different trusted source to determine available supported
SASL mechanisms.

Approach 2: What is meant by Clients MUST check the term "secure
authentication function?" supportedSASLMechanisms list
both before and after SASL negotiation UNLESS they use a

Harrison Expires April June 2004 [Page 40] 42]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

Status: resolved. Based on the idea that a "secure authentication
function" could be provided by TLS, I changed the wording

different trusted source to require
data confidentiality for sensitive authentication information and
data integrity for all authentication information.

G.4.

Section 3, deployment scenario 3: What is meant by the phrase,
"directory data is authenticated by the server?" determine available supported SASL
mechanisms.

Status: resolved. WG input at IETF 51 was that Approach 1 was
probably best. I interpreted this to mean ended up keeping the ability basic structure similar to ensure
the identity of the directory server and the integrity of the data
sent from that server
original to the client, and explictly stated such.

G.5. meet this intent.

G.9.

Section 4 paragraph 3: What is meant by the phrase, "this means 6.3.1 states: "DSAs that
either this data is useless for faking authentication (like map the Unix
"/etc/passwd" file format used DN sent in the bind request
to be)?"

Status: resolved. Discussion at IETF 52 along with discussions a directory entry with a userPassword attribute will... compare
[each value in the original authors of this material have convinced us named user's entry]... with the presented
password." This implies that this
reference is simply too arcane applies only to be left user entries with
userPassword attributes. What about other types of entries that
might allow passwords and might store in place. In -03 the text
has been modified to focus on the need to either update password information in a protected fashion outside of the protocol or
other attributes? Do we want to
update it make this text more general?

Status: resolved in session well protected against snooping, -03 draft by generalizing section 8.3.1 to not
refer to any specific password attribute and by removing the
reference to /etc/passwd has been removed.

G.6.

Section 4 paragraph 7 begins: "For a directory needing session
protection..." Is this term
"user" in referring to data confidentiality or data
integrity or both?

Status: resolved. Changed wording to say, "For a the directory needing
data security (both data integrity and data confidentiality)..."

G.7.

Section 4 paragraph 8 indicates that "information about entry specified by the server
fetched fetched prior to DN in
the TLS negotiation" must be discarded. Do
we want bind request.

G.10 userPassword and simple bind

We need to explicitly state be sure that this applies we don't require userPassword to information fetched
prior be the only
attribute used for authenticating via simple bind. (See 2251 sec 4.2
and authmeth 6.3.1. Work with Jim Sermersheim on resolution to this.
On publication state something like: "This is the *completion* specific
implementation of the TLS negotiation or is this going
too far?

Status: resolved. Based on comments what we discussed in our general reorg
conversation on the IETF 51 LDAPBIS WG
meeting, this has been changed list." (Source: Kurt Zeilenga)

Status: resolved in -03 draft by generalizing section 8.3.1 to explicitly state, "fetched prior not
refer to the initiation of the TLS negotiation..."

G.8.

Section 4 paragraph 9 indicates that clients SHOULD check the
supportedSASLMechanisms list both before any specific password attribute and after a SASL security

Harrison Expires April 2004 [Page 41]

Internet-Draft LDAP Authentication Methods 7 October 2003

layer is negotiated by removing the term
"user" in referring to ensure that they are using the best available
security mechanism supported mutually directory entry specified by the client and server. A
note at DN in
the end bind request.

G.11. Meaning of LDAP Association

The original RFC 2830 uses the paragraph indicates that this is term "LDAP association" in describing
a SHOULD
since there are environments where the connection between an LDAP client might get a list and server regardless of
supported SASL mechanisms from a different trusted source.

I wonder if the intent
state of this could TLS on that connection. This term needs to be restated more plainly using
one of these two approaches (I've paraphrased for the sake of
brevity):

Approach 1: Clients SHOULD check the supportedSASLMechanisms
list both before and after SASL negotiation defined or clients SHOULD
use a different trusted source to determine available supported
SASL mechanisms.

Approach 2: Clients MUST check the supportedSASLMechanisms list
both before and after SASL negotiation UNLESS they use a
different trusted source to determine available supported SASL
mechanisms.
possibly changed.

Status: resolved. WG input at IETF 51 was Bob Morgan indicated that Approach 1 the term
"LDAP association" was
probably best. I ended up keeping intended to distinguish the basic structure similar LDAP-level
connection from the TLS-level connection. This still needs to be
clarified somewhere in the
original draft. Added "LDAP association" to meet this intent.

G.9.

Section 6.3.1 states: "DSAs that map the DN sent a
glossary in section 1.

G.12. Is DIGEST-MD5 mandatory for all implementations?

Reading 2829bis I think DIGEST-MD5 is mandatory ONLY IF your server
supports password based authentication...but the bind request following makes it
sound mandatory to a directory entry provide BOTH password authentication AND DIGEST-

Harrison Expires June 2004 [Page 43]

Internet-Draft LDAP Authentication Methods 5 December 2003

MD5:

"6.2. Digest authentication

LDAP implementations MUST support authentication with a userPassword attribute will... compare
[each value password
using the DIGEST-MD5 SASL mechanism for password protection, as
defined in section 6.1."

The thing is for acl it would be nice (though not critical) to be
able to default the named user's entry]... with required authentication level for a subject to a
single "fairly secure" mechanism--if there is no such mandatory
authentication scheme then you cannot do that. (Source: Rob Byrne)

Status: resolved. -00 version of the presented
password." This implies draft added a sentence at the
beginning of section 8.2 stating that LDAP server implementations
must support this applies only to user entries with
userPassword attributes. What about other types method.

G.13. Ordering of entries that
might allow passwords and might store in authentication levels requested

Again on the password information subject of authentication level, is it possible to
define an ordering on authentication levels which defines their
relative "strengths" ? This would be useful in
other attributes? Do we want acl as you could say
things like"a given aci grants access to make a given subject at this
authentication level AND ABOVE". David Chadwick raised this text more general?

Status: resolved before
in -03 draft by generalizing section 8.3.1 to not
refer to any specific password attribute and by removing the term
"user" in referring context of denying access to the directory entry specified by the DN a subject at a given
authentication level, in
the bind request.

G.10 userPassword and simple bind

We need which case he wanted to be sure that we don't require userPassword express "deny
access to be this subject at this authentication level AND TO ALL
IDENTITIES AUTHENTICATED BELOW THAT LEVEL". (Source: Rob Byrne)

Status: out of scope. This is outside the only
attribute used for authenticating via simple bind. (See 2251 sec 4.2 scope of this document and authmeth 6.3.1. Work with Jim Sermersheim on resolution
will not be addressed.

G.14. Document vulnerabilities of various mechanisms

While I'm here...in 2829, I think it would be good to this.
On publication state something like: "This is have some
comments or explicit reference to a place where the specific
implementation security
properties of what we discussed in our general reorg
conversation on the list." (Source: Kurt Zeilenga)

Status: resolved in -03 draft by generalizing section 8.3.1 to not
refer particular mandatory authentication schemes are
outlined. When I say "security properties" I mean stuff like "This
scheme is vulnerable to any specific password attribute such and by removing such attacks, is only safe if the term
"user" in referring to
key size is > 50, this hash is widely considered the directory entry specified by best, etc...".
I think an LDAP implementor is likely to be interested in that
information, without having to wade through the DN in security RFCs.
(Source: Rob Byrne)

Status: out of scope. This is outside the bind request.

G.11. Meaning scope of LDAP Association this document and
will not be addressed.

G.15. Include a Start TLS state transition table

The pictoral representation it is nominally based on is here (URL
possibly folded):

http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-
1999-12-14.html

Harrison Expires April June 2004 [Page 42] 44]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

The original RFC 2830 uses the term "LDAP association"

(Source: Jeff Hodges)

Status: Resolved.

Table provided in describing -03. Review of content for accuracy in -04.
Additional review is needed, plus comments from WG members indicate
that additional description of each state's meaning would be
helpful.

Did a connection between an LDAP client and server regardless significant revision of the state of TLS transition table in -09. Changes
were based on suggestions from WG and greatly simplified overall
table.

G.16. Empty sasl credentials question

I spent some more time looking microscopically at ldap-auth-methods
and ldap-ext-tls drafts. The drafts say that connection. This term needs to be defined the credential must
have the form dn:xxx or
possibly changed. u:xxx or be absent, and although they don't
say what to do in the case of an empty octet string I would say that
we could send protocolError (claim it is a bad PDU).

There is still the question of what to do if the credential is 'dn:'
(or 'u:') followed by the empty string. (Source: ariel@columbia.edu
via Jeff Hodges)

Status: resolved. Kurt Zeilenga indicated during ldapbis WG
discussion at IETF 51 Bob Morgan indicated 52 that SASL AuthzID credentials empty and absent
are equivalent in the term
"LDAP association" was intended to distinguish the LDAP-level
connection from the TLS-level connection. latest SASL ID. This still needs to be
clarified somewhere in resolves the draft. Added "LDAP association" issue.

G.17. Hostname check from MUST to a
glossary in section 1.

G.12. Is DIGEST-MD5 mandatory for all implementations?

Reading 2829bis SHOULD?

I think DIGEST-MD5 is mandatory ONLY IF your server
supports password based authentication...but am uneasy about the following makes it
sound mandatory to provide BOTH password authentication AND DIGEST-
MD5:

"6.2. Digest authentication

LDAP implementations MUST support authentication hostname check. My experience from PKI with
HTTP probably is a password contributing factor; we have people using the DIGEST-MD5 SASL mechanism for password protection, as
defined in section 6.1."

The thing is for acl it would be nice (though not critical) to be
able
short hostname to default the required authentication level for a subject get to a
single "fairly secure" mechanism--if there is no such mandatory
authentication scheme then you cannot do that. (Source: Rob Byrne)

Status: resolved. -00 version of server which naturally has the draft added a sentence at FQDN in
the
beginning of section 8.2 stating that LDAP server implementations
must support this method.

G.13. Ordering certificate, no end of authentication levels requested

Again problems. I have a certificate on my
laptop which has the subject of authentication level, FQDN for the casse when the system is it possible to
define an ordering on authentication levels which defines their
relative "strengths" ? This would be useful in acl as you could say
things like"a given aci grants access to our
Columbia network with a given subject at this
authentication level AND ABOVE". David Chadwick raised this before fixed IP; when I dial in however, I have
some horrible dialup name, and using the context of denying access to a subject at local https server becomes
annoying. Issuing a given
authentication level, certificate in which case he wanted to express "deny
access to this subject at the name 'localhost' is not a
solution! Wildcard match does not solve this authentication level AND TO ALL
IDENTITIES AUTHENTICATED BELOW THAT LEVEL". (Source: Rob Byrne)

Status: out problem. For these
reasons I am inclined to argue for 'SHOULD' instead of scope. This is outside
'MUST' in paragraph...

Also, The hostname check against the scope name in the certificate is a
very weak means of this document and
will preventing man-in-the-middle attacks; the proper
solution is not be addressed.

G.14. Document vulnerabilities of various mechanisms

While I'm here...in 2829, I think it would be good to have some
comments here yet (SecureDNS or explicit reference to some equivalent). Faking out
DNS is not so hard, and we see this sort of thing in the press on a place
pretty regular basis, where site A hijacks the security
properties of the particular mandatory authentication schemes are

Harrison Expires April 2004 [Page 43]

Internet-Draft LDAP Authentication Methods 7 October 2003

outlined. When I say "security properties" I mean stuff like "This
scheme is vulnerable to such DNS server for site B
and such attacks, is only safe if gets all their requests. Some mention of this should be made in
the
key size is > 50, draft. (Source: ariel@columbia.edu via Jeff Hodges)

Status: resolved. Based on discussion at IETF 52 ldapbis WG meeting,
this hash text will stand as it is. The check is widely considered a MUST, but the best, etc...".
I think an behavior

Harrison Expires June 2004 [Page 45]

Internet-Draft LDAP implementor Authentication Methods 5 December 2003

afterward is likely a SHOULD. This gives server implementations the room to be interested
maneuver as needed.

G.18. Must SASL DN exist in that
information, without having to wade through the security RFCs.
(Source: Rob Byrne)

Status: out of scope. This is outside directory?

If the scope 'dn:' form of this document and
will not be addressed.

G.15. Include a StartTLS state transition table

The pictoral representation it sasl creds is nominally based on used, is here (URL
possibly folded):

http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-
1999-12-14.html

(Source: Jeff Hodges)

Status: In Process. Table provided in -03. Review it the intention of content for
accuracy in -04. Additional review is needed, plus comments from WG
members indicate the
draft(ers) that additional description of each state's meaning
would be helpful.

G.16. Empty sasl credentials question

I spent some more time looking microscopically at ldap-auth-methods this DN must exist in the directory and ldap-ext-tls drafts. The drafts say that the credential must client
will have the form dn:xxx or u:xxx privileges associated with that entry, or be absent, and although they don't
say what can the
server map the sasl DN to do perhaps some other DN in the case of directory,
in an empty octet string I would say implementation-dependent fashion?

We already know that
we could send protocolError (claim it is a bad PDU).

There is still the question of what to do if *no* sasl credentials are presented, the credential is 'dn:'
(or 'u:') followed by DN
or altname in the client certificate may be mapped to a DN in an
implementation-dependent fashion, or indeed to something not in the empty string.
directory at all. (Right?) (Source: ariel@columbia.edu via Jeff
Hodges)

Status: resolved. Kurt Zeilenga indicated during ldapbis WG
discussion at IETF 52 (11/12/02)Based on my research I propose that SASL AuthzID credentials empty and absent
are equivalent the
DN MUST exist in the latest SASL ID. This resolves directory when the issue.

G.17. Hostname check from MUST to SHOULD? DN form of sasl creds is
used. I am uneasy about have made this proposal to the hostname check. My experience ldapbis mailing list.

(11/21/02) Feedback from PKI with
HTTP probably is a contributing factor; we have people using mailing list has proposed removing this
paragraph entirely because (1) explicit assertion of authorization
identity should only be done when proxying (2) mapping of the
short hostname
asserted authorization identity is implementation specific and
policy driven [SASL] section 4.2, and (3) keeping this paragraph is
not required for interoperability.

G.19. DN used in conjunction with SASL mechanism

We need to get specify whether the DN field in Bind operation can/cannot
be used when SASL mechanism is specified. (source: RL Bob)

Status: resolved. (-03) Based on ldapbis WG discussion at IETF52 two
sentences were added to section 4.3 indicating that clients SHOULD
NOT send a server which naturally has DN value when binding with the FQDN sasl choice and servers
SHALL ignore any value received in
the certificate, no end this circumstance. During edits
for -04 version of problems. I have a certificate on my
laptop which draft it was noted that [Protocol] section 4.2
conflicts with this draft. The editor of [Protocol] has been
notified of the FQDN for the casse when the system discrepancy, and they have been handled.

G.20. Bind states

Differences between unauthenticated and anonymous. There are four
states you can get into. One is on our
Columbia network with a fixed IP; when I dial completely undefined (this is now
explicitly called out in however, I have
some horrible dialup [Protocol]). This text needs to be moved
from [Protocol] to this draft. (source: Jim Sermersheim)

Status: Resolved. There are four states: (1) no name, no password
(anon); (2) name, no password (anon); (3) no name, password
(invalid); (4) name, password (simple bind). States 1, 2, and using the local https server becomes
annoying. Issuing a certificate 4 are
called out in the name 'localhost' [AuthMeth]. State 3 is not a
solution! Wildcard match does not solve called out in [Protocol]; this problem. For these
reasons I am inclined to argue for 'SHOULD' instead
seems appropriate based on review of
'MUST' in paragraph... alternatives.

Harrison Expires April June 2004 [Page 44] 46]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

Also, The hostname check against the

G.21. Misuse of unauthenticated access

Add a security consideration that operational experience shows that
clients can misuse unauthenticated access (simple bind with name in the certificate is but
no password). Servers SHOULD by default reject authentication
requests that have a
very weak means DN with an empty password with an error of preventing man-in-the-middle attacks; the proper
solution is not here yet (SecureDNS or some equivalent). Faking out
DNS is not so hard,
invalidCredentials. (Source: Kurt Zeilenga and Chris Newman (Sun))

Status: Resolved. Added to security considerations in -03.

G.22. Need to move Start TLS protocol information to [Protocol]

Status: Resolved. Removed Sections 5.1, 5.2, and we see this sort of thing in the press on a
pretty regular basis, where site A hijacks the DNS server 5.4 for site B -04 and gets all their requests. Some mention of this should be
they are [Protocol] -11.

G.23. Split Normative and Non-normative references into separate
sections.

Status: Resolved. Changes made in
the draft. (Source: ariel@columbia.edu via Jeff Hodges)

Status: resolved. Based on discussion at IETF 52 ldapbis WG meeting,
this text will stand as it is. The check -04

G.24. What is a MUST, but the behavior
afterward is authentication state if a SHOULD. Bind operation is
abandoned?

Status: Resolved.

(3/24/03) This gives server implementations the room to
maneuver as needed.

G.18. Must SASL DN exist following text appears in the directory?

If the 'dn:' form of sasl creds is used, is it the intention section 4.2.1 of the
draft(ers) that this DN must exist in the directory and the client
will have the privileges associated with that entry, or can the
server map the sasl DN [Protocol]
revision -13 to perhaps some other DN in the directory,
in an implementation-dependent fashion?

We already know that cover what happens if *no* sasl credentials are presented, the DN a bind operation is abandoned:

A failed or altname in abandoned Bind Operation has the client certificate may be mapped to a DN effect of leaving the
connection in an
implementation-dependent fashion, or indeed to something not in the
directory anonymous state. To arrive at all. (Right?) (Source: ariel@columbia.edu via Jeff
Hodges)

Status: resolved. (11/12/02)Based on my research I propose that a known
authentication state after abandoning a bind operation, clients may
unbind, rebind, or make use of the
DN MUST exist BindResponse.

(6/28/03): The state table in the directory when the DN form section 6 of sasl creds is
used. I have made this proposal to the ldapbis mailing list.

(11/21/02) Feedback from mailing list [AuthMeth] has proposed removing been
updated to reflect this
paragraph entirely because (1) explicit assertion of authorization
identity should only be done when proxying (2) mapping wording.

G.25. Difference between checking server hostname and server's
canonical DNS name in Server Identity Check?

Section 4.1.6: I now understand the intent of the
asserted authorization identity check (prevent
man-in-the-middle attacks). But what is implementation specific and
policy driven [SASL] section 4.2, the subtle difference
between the "server hostname" and (3) keeping the "server's canonical DNS name"?
(Source: Tim Hahn)

Status: Resolved.

(11/12/02) Sent suggested wording change to this paragraph is
not required for interoperability.

G.19. DN used in conjunction with SASL mechanism

We need to specify whether the DN field in Bind operation can/cannot
be used when SASL mechanism is specified. (source: RL Bob)

Status: resolved. (-03) Based on
ldapbis WG discussion at IETF52 two
sentences were added mail list and also asked for opinion as to section 4.3 indicating that clients SHOULD
NOT send a DN value when binding with whether we should
discuss the sasl choice distinction between server DNS hostname and servers
SHALL ignore any value received server
canonical DNS hostname in this circumstance. During edits
for -04 version of draft it was noted that [Protocol] section 4.2
conflicts with this draft. The editor of [Protocol] has been
notified [AuthMeth].

(11/21/02): RL Bob Morgan will provide wording that allows
derivations of the discrepancy, and they have been handled.

G.20. Bind states name that are provided securely.

Harrison Expires April June 2004 [Page 45] 47]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

Differences between unauthenticated and anonymous. There are four
states you can get into. One is completely undefined (this

(6/28/03): posted to the WG list asking Bob or any other WG member
who is now
explicitly called out in [Protocol]). This knowledgeable about the issues involved to help me with
wording or other information I can use to make this change and close
the work item.

(10/08/03): Based on WG list feedback, I've updated this text needs to
read what I judge to be moved the WG consensus, "The client MUST use the
server provided by the user (or other trusted entity) as the value
to compare against the server name as expressed in the server's
certificate. A hostname derived from [Protocol] the user input is to this draft. (source: Jim Sermersheim) be
considered provided by the user only if derived in a secure fashion
(e.g., DNSSEC)."

G.26. Server Identity Check using servers located via SRV records

Section 4.1.6: What should be done if the server was found using SRV
records based on the "locate" draft/RFC? (Source: Tim Hahn).

Status: Resolved. There are four states: (1) no name, no password
(anon); (2) name, no password (anon); (3) no name, password
(invalid); (4) name, password (simple bind). States 1, 2, and 4 are
called Section 5 of draft-ietf-ldapext-locate-08
specifically calls out how the server identity should be performed
if the server is located using the method defined in [AuthMeth]. State 3 that draft.
This is called out in [Protocol]; the right location for this
seems appropriate based information, and the coverage
appears to be adequate.

G.27 Inconsistency in effect of TLS closure on review LDAP association.

Section 4.4.1 of alternatives.

G.21. Misuse authmeth -03 (section 4.1 of unauthenticated access

Add a security consideration that operational experience shows RFC2830) states that
clients can misuse unauthenticated access (simple bind
TLS closure alert will leave the LDAP association intact. Contrast
this with name but
no password). Servers SHOULD by default reject authentication
requests Section 4.5.2 (section 5.2 of RFC2830) that have a DN with an empty password with an error says that the
closure of
invalidCredentials. (Source: Kurt Zeilenga and Chris Newman (Sun))

Status: Resolved. Added to security considerations in -03.

G.22. Need the TLS connection MUST cause the LDAP association to
move StartTLS protocol information to [Protocol] an anonymous authentication.

Status: Resolved. Removed Sections 5.1, 5.2, and 5.4 for -04 and
they are (11/12/02) This is actually a [Protocol] issue
because these sections have now been moved to [Protocol] -11.

G.23. Split Normative and Non-normative references into separate
sections.

Status: Resolved. Changes made in -04

G.24. What is I have
proposed the authentication state if a Bind operation is
abandoned?

Status: Resolved.

(3/24/03) This following text appears in section 4.2.1 for Section 4.4.1 of [Protocol]
revision -13 [AuthMeth] -03
(section 4.13.3.1 of [Protocol]) to cover what happens if a bind operation is abandoned:

A failed resolve this apparent
discrepancy:

"Either the client or abandoned Bind Operation has server MAY terminate the TLS connection on an
LDAP association by sending a TLS closure alert. The LDAP
connection remains open for further communication after TLS closure
occurs although the effect authentication state of leaving the LDAP connection is
affected (see [AuthMeth] section 4.2.2).

(11/21/02): resolution to this is expected in an anonymous state. To arrive at a known
authentication state after abandoning [Protocol] -12

(06/28/03): [Protocol]-15 clarifies that a bind operation, clients may
unbind, rebind, or make use of TLS closure alert
terminates the BindResponse.

(6/28/03): TLS connection while leaving the LDAP connection
intact. The authentication state table in section 6 of [AuthMeth] has been
updated to reflect this wording.

G.25. Difference between checking server hostname and server's
canonical DNS name in Server Identity Check?

Section 4.1.6: I now understand the intent of the check (prevent
man-in-the-middle attacks). But what is the subtle difference
between specifies the "server hostname" and
effect on the "server's canonical DNS name"?
(Source: Tim Hahn) LDAP association.

G.28 Ordering of external sources of authorization identities

Harrison Expires April June 2004 [Page 46] 48]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

Status: Resolved.

(11/12/02) Sent suggested wording change to this paragraph to the
ldapbis mail list and also asked for opinion as to whether we should
discuss the distinction between server DNS hostname and server
canonical DNS hostname in [AuthMeth].

(11/21/02): RL Bob Morgan will provide wording

Section 4.3.2 implies that allows
derivations external sources of the name that authorization
identities other than TLS are provided securely.

(6/28/03): posted to permitted. What is the WG list asking Bob or any other WG member
who behavior when
two external sources of authentication credentials are available
(e.g. TLS and IPsec are both present (is this possible?)) and a SASL
EXTERNAL Bind operation is knowledgeable about performed?

Status: resolved. 11/20/02: Resolved by Section 4.2 of [SASL] which
states that the issues involved decision to help me with
wording allow or other information I can use to make this change and close disallow the work item.

(10/08/03): Based asserted identity
is based on WG list feedback, I've updated this text to
read what I judge an implementation defined policy.

G.29 Rewrite of Section 9, TLS Ciphersuites

This section contains anachronistic references and needs to be
updated/rewritten in a way that provides useful guidance for future
readers in a way that will transcend the WG consensus, "The client MUST use the
server provided by the user (or other trusted entity) as passage of time.

Status: Resolved. (6/28/03): Rewrote the value section to compare against cover the server name as expressed
general issues and considerations involved in the server's
certificate. A hostname derived from the user input is selecting TLS
ciphersuites.

G.30 Update to Appendix A, Example Deployment Scenarios

This section needs to be
considered provided by the user only if derived updated to indicate which security
mechanisms and/or combinations of security mechanisms described
elsewhere in a secure fashion
(e.g., DNSSEC)."

G.26. Server Identity Check using servers located via SRV records

Section 4.1.6: What should be done if the server was found using SRV
records based on document can provide the "locate" draft/RFC? (Source: Tim Hahn).

Status: Resolved. Section 5 types of draft-ietf-ldapext-locate-08
specifically calls out how the server identity should be performed
if the protections
suggested in this appendix.

G.31 Use of PLAIN SASL Mechanism

At least one LDAP server is located using implementer has found the method defined SASL "PLAIN"
mechanism useful in authenticating to legacy systems that draft.
This is the right location for this information, and the coverage do not
represent authentication identities as DNs. Section 3.3.1 appears to be adequate.

G.27 Inconsistency in effect of TLS closure on LDAP association.

Section 4.4.1 of authmeth -03 (section 4.1
implicitly disallow the use of RFC2830) states that
TLS closure alert will leave the LDAP association intact. Contrast
this SASL "PLAIN" mechanism with Section 4.5.2 (section 5.2 of RFC2830) that says that LDAP.
Should we allow the
closure use of the TLS connection this mechanism? I.e. is this "SASL"
"PLAIN" MUST cause the LDAP association to
move to an anonymous authentication.

Status: Resolved. (11/12/02) This NOT be used with LDAP, or is actually a [Protocol] issue
because it simply that LDAP
doesn't define bindings for these sections have now been moved to [Protocol] -11. I have
proposed mechanism. If SASL "PLAIN" is
allowed, the following text for Section 4.4.1 adjustments will be needed to section 3.3.1:
(a) change section heading, (b) remove reference to "PLAIN" in the
section, (c) ensure wording of [AuthMeth] -03
(section 4.13.3.1 last sentence regarding non-DN
AuthZIDs is consistent with rest of [Protocol]) the section.

Status: Resolved.

(6/28/03): email to resolve this apparent
discrepancy:

"Either WG list stating issue and asking if we should
remove the client or server MAY terminate reference to SASL "PLAIN".

For -07 draft I've generalized the TLS connection SASL profile in section 3.3 to
allow any SASL mechanism.

G.32 Clarification on an
LDAP association by sending a TLS closure alert. The LDAP
connection remains open for further communication after TLS closure use of SASL mechanisms

Section 3.3.1: BTW, what _are_ the "ANONYMOUS" and "PLAIN" SASL
mechanisms? They are not defined in RFC2222. If you refer to other

Harrison Expires April June 2004 [Page 47] 49]

Internet-Draft LDAP Authentication Methods 7 October 5 December 2003

occurs although the authentication state

SASL mechanisms than those in rfc2222, Maybe you should only list
which mechanisms _are_used, instead of which ones are _not. (Source:
Hallvard Furuseth)

I (Kurt Zeilenga) note[s] as well that the LDAP connection is
affected (see [AuthMeth] ANONYMOUS/PLAIN section 4.2.2).

(11/21/02): resolution to this is expected
(4.2) should
be deleted. ANONYMOUS and PLAIN, like in [Protocol] -12

(06/28/03): [Protocol]-15 clarifies that a TLS closure alert
terminates the TLS connection while leaving the LDAP connection
intact. The authentication state table other mechanism,
can be used in [AuthMeth] specifies the
effect on the LDAP association.

G.28 Ordering of external sources of authorization identities

Section 4.3.2 implies if a) supported and b) enabled. I note
that external sources of authorization
identities other than TLS they each offer capabilities not found in their simple
bind equivalents (and hence are permitted. What used in some deployments).
For example, PLAIN (over TLS) is the behavior quite useful when
two external sources of interacting
with legacy authentication credentials are available
(e.g. TLS and IPsec are both present (is this possible?)) and a SASL
EXTERNAL Bind operation is performed? subsystems. (Source: Kurt Zeilenga)

Status: resolved. 11/20/02: Resolved by Section 4.2 of [SASL] which
states that Resolved.

For -07 draft I've generalized the decision SASL profile in section 3.3 to
allow or disallow the asserted identity
is any SASL mechanism.

G.33 Clarification on use of password protection based on AuthZID form

Section 3.3.1: "If an implementation defined policy.

G.29 Rewrite authorization identity of Section 9, TLS Ciphersuites

This section contains anachronistic references and needs to be
updated/rewritten in a way form different
from a DN is requested by the client, a mechanism that provides useful guidance for future
readers protects the
password in a way transit SHOULD be used." What has that will transcend to do with DNs?
A mechanism that protects the passage of time. password in transit should be used in
any case, shouldn't it?

Status: Resolved. (6/28/03): Rewrote the section to cover the

In -08 draft this text was removed. There is already a general issues and considerations involved
security consideration that covers this issue.

G.34 Clarification on use of matching rules in Server Identity Check

The text in selecting TLS
ciphersuites.

G.30 Update to Appendix A, Example Deployment Scenarios

This section needs 4.1.6 isn't explicit on whether all rules apply
to both CN and dNSName values. The text should be updated clear as to indicate which security
rules apply to which values.... in particular, the wildcard
rules. (Source: Kurt Zeilenga)

G.35 Requested Additions to Security Considerations

Requested to mention hostile servers which the user might have been
fooled to into contacting. Which mechanisms and/or combinations that are standardized by
the LDAP standard do/do not disclose the user's password to the
server? (Or to servers doing man-in-the-middle attack? Or is that a
stupid question?)

Requested to mention denial of security mechanisms described
elsewhere in service attacks.

Requested list of methods that need/don't need the document can provide server to know
the types user's plaintext password. (I say 'know' instead of protections
suggested 'store'

Harrison Expires June 2004 [Page 50]

Internet-Draft LDAP Authentication Methods 5 December 2003

because it could still store the password encrypted, but in this appendix.

G.31 Use a way
which it knows how to decrypt.)

(Source: Hallvard Furuseth)

G.36 Add reference to definition of PLAIN SASL Mechanism

At least one LDAP server implementer has found DIGEST-MD5

Need a reference to the definition of DIGEST-MD5 SASL "PLAIN" mechanism useful in authenticating
section 7.2 (Source: Hallvard Furuseth)

Status: Resolved. A reference to legacy systems that do not
represent authentication identities as DNs. Section 3.3.1 appears to
implicitly disallow the use of the DIGEST-MD5 SASL "PLAIN" mechanism mechanism,
[DigestAuth], is included in the -07 revision.

G.37 Clarification on procedure for certificate-based authentication

8.1. Certificate-based authentication with LDAP.
Should we allow TLS states: "Following
the use successful completion of this mechanism? I.e. is this "SASL"
"PLAIN" MUST NOT be used with LDAP, or is it simply that TLS negotiation, the client will send
an LDAP
doesn't define bindings for these mechanism. If bind request with the SASL "PLAIN" is
allowed, "EXTERNAL" mechanism." Is this
immediately following, or just some time later? Should the following adjustments wording,
"the client will be needed to section 3.3.1:
(a) change section heading, (b) remove reference to "PLAIN" in the
section, (c) ensure wording of last sentence regarding non-DN
AuthZIDs is consistent with rest send..." actually read, "the client MUST send..."?

G.38 Effect of Start TLS on authentication state

Should the section.

Harrison Expires April 2004 [Page 48]

Internet-Draft LDAP Authentication Methods 7 October 2003

Status: Resolved.

(6/28/03): email server drop all knowledge of connection, i.e. return to WG list stating issue
anonymous state, if it gets a Start TLS request on a connection that
has successfully bound using the simple method?

G.39 Be sure that there is a consideration in [SCHEMA] that discusses
multiple password values in userPassword

Allowing multiple values obviously does raise a number of security
considerations and asking if we should
remove these need to be discussed in the reference document.

Certainly applications which intend to SASL "PLAIN".

For -07 draft I've generalized replace the SASL profile in section 3.3 userPassword with
new value(s) should use modify/replaceValues (or
modify/deleteAttribute+addAttribute). Additionally, server
implementations should be encouraged to
allow any SASL mechanism.

G.32 Clarification provide administrative
controls which, if enabled, restrict userPassword to one value.

G.40. Clarify need to verify mapping between authentication identity
and resulting authorization identity on use implicit assertion of SASL mechanisms

Section 3.3.1: BTW, what _are_ AuthZID.

4.2.2.3. Error Conditions

"For either form of assertion, the "ANONYMOUS" and "PLAIN" SASL
mechanisms? They are not defined server MUST verify that the
client's authentication identity as supplied in RFC2222. If you refer its TLS credentials
is permitted to be mapped to other
SASL mechanisms than those in rfc2222, Maybe you should only list
which mechanisms _are_used, instead of which ones are _not. (Source:
Hallvard Furuseth)

I (Kurt Zeilenga) note[s] as well that the ANONYMOUS/PLAIN section
(4.2) should asserted authorization identity."

This makes sense for the explicit assertion case, but seems to be deleted. ANONYMOUS and PLAIN, like in other mechanism,
ambiguous for the implicit case.
IMHO, the mapping can be used in done as two steps:
a). deriving LDAP if a) supported and b) enabled. I note
that they each offer capabilities not found in their simple
bind equivalents (and hence are used in some deployments).
For example, PLAIN (over TLS) is quite useful when interacting
with legacy authentication subsystems. (Source: Kurt Zeilenga)

Status: Resolved.

For -07 draft I've generalized identity from TLS credentials; If t
this steps fails, EXTERNAL mechanism returns failure.

Harrison Expires June 2004 [Page 51]

Internet-Draft LDAP Authentication Methods 5 December 2003

b). verify that the SASL profile in section 3.3 to
allow any SASL mechanism.

G.33 Clarification on use of password protection based on AuthZID form

Section 3.3.1: "If an authorization identity of a form different
from a DN is requested by allowed for the client, a mechanism that protects
derived authentication identity. This is always "noop" for the
password in transit SHOULD be used." What has that to do with DNs?
A mechanism
implicit case.
I am not sure that protects the password in transit should be used in
any case, shouldn't it?

G.34 Clarification on use of matching rules in Server Identity Check

The text is saying this.
(Source: Alexey Melnikov email 8/1/2003 5:30:43 PM)

Status: Resolved in section 4.1.6 isn't explicit on whether all rules apply
to both CN -07. After reading the comments and dNSName values. The the text of
the draft, I believe that this should be clear as clarified. The local policy
used to which
rules apply map the AuthNID to which values.... the AuthZID in particular, the wildcard
rules. (Source: Kurt Zeilenga)

G.35 Requested Additions implicit case is
sufficient and that no additional verification is useful or needed.
This text has been moved to Security Considerations

Requested apply only to mention hostile servers which the user might have been
fooled to into contacting. Which mechanisms that are standardized by

Harrison Expires April 2004 [Page 49]

Internet-Draft LDAP Authentication Methods 7 October 2003 explicit assertion
case.

G.41. Section 7.2 contains unnecessary and misleading detail.

" I am not sure why this section is required in the document.
DIGEST-MD5 is defined in a separate document and there should be
nothing magical about its usage in LDAP. If DIGEST-MD5 description
creates confusion for LDAP standard do/do not disclose the user's password to implementors, let's fix the
server? (Or DIGEST-MD5
document! Also, this section tries to servers doing man-in-the-middle attack? Or redefine DIGEST-MD5 behavior,
which is that a
stupid question?)

Requested to mention denial of service attacks.

Requested list of methods that need/don't need explicitly prohibited by the server to know SASL specification."
(Source: Alexey Melnikov: email 8/1/2003 5:30:43 PM)

Status: Resolved.

After reading the user's plaintext password. (I say 'know' instead comments and the text of 'store'
because it could still store the password encrypted, but draft plus the
related text in a way
which it knows how to decrypt.)

(Source: Hallvard Furuseth)

G.36 Add reference draft-ietf-sasl-rfc2831bis-02.txt plus
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
02.txt, I am inclined to definition of DIGEST-MD5

Need a reference agree with Alexey. In -07 I rewrote section
3.3 (SASL mechanisms) to match the definition of DIGEST-MD5 SASL mechanism profiling requirements
rfc2831bis. I then dramatically reduced the material in section 7.2 (Source: Hallvard Furuseth)

Status: Resolved. A reference
to a bare minimum and let the SASL profile stand on its own.

G.42. Does change for G.41 cause interoperability issue?

There is one issue with the way the authmeth draft is currently
written that changes the SASL DIGEST-MD5 behavior on the way the
server responds with the subsequent authentication information .
This has been documented in this fashion since RFC 2829 (section
6.1) was originally published and may cause an interoperability
issue at this point if it changed to follow the DIGEST-MD5 SASL mechanism,
[DigestAuth], is included spec (as
it was in the -07 revision.

G.37 Clarification on procedure for certificate-based authentication

8.1. Certificate-based authentication with TLS states: "Following
the successful completion of TLS negotiation, the client will send
an LDAP bind request with the SASL "EXTERNAL" mechanism." Is AuthMeth). Take this
immediately following, or just some time later? Should issue to the wording,
"the client will send..." actually read, "the client MUST send..."?

G.38 Effect of StartTLS list.

Status: Resolved

(10/08/03) This item was discussed on authentication state

Should the server drop all knowledge of connection, i.e. return WG list between 5/2/03 and
5/9/03. Consensus apppears to
anonymous state, if it gets a StartTLS request on a connection that
has successfully bound using support the simple method?

G.39 Be sure notion that there is a consideration RFC 2829 was
in [SCHEMA] error and that discusses
multiple password values in userPassword

Allowing multiple values obviously does raise a number the semantics of security
considerations RFC 2831 are correct and these need to should
be discussed reflected in authmeth. This is already the document.

Certainly applications which intend to replace case as of the userPassword with
new value(s) should use modify/replaceValues (or
modify/deleteAttribute+addAttribute). Additionally, server
implementations should be encouraged to -07
draft.

G.43. DIGEST-MD5 Realms recommendations for LDAP

Harrison Expires June 2004 [Page 52]

Internet-Draft LDAP Authentication Methods 5 December 2003

From http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
02.txt: A protocol profile SHOULD provide administrative
controls which, if enabled, restrict userPassword to one value.

G.40. Clarify need a guidance how realms are
to verify mapping between authentication identity be constructed and resulting authorization identity on implicit assertion of AuthZID.

4.2.2.3. Error Conditions

"For either form of assertion, used in the server MUST verify protocol and MAY further restrict
its syntax and protocol-specific semantics."

I don't believe that any such guidance exists within the

Harrison Expires April 2004 [Page 50]

Internet-Draft LDAP Authentication Methods 7 October 2003

client's authentication identity as supplied in its TLS credentials
is permitted to be mapped TS.
The most likely place for this to reside is in the asserted authorization identity."

This makes sense for authmeth draft.

Related email from Alexey Melnikov (8/4/2003 1:08:40 PM):

"The problem I have with the explicit assertion case, but seems to document is that it references realm
without explaining what it is (or at least some examples of valid
values). For LDAP, some recommendations should be
ambiguous for given. For
example:
1). Use a hardcoded string as the implicit case.
IMHO, realm (one of the mapping implementations
I worked on was doing that)
2). Use hostname (realm==host) or domain/cluster name (realm
includes multiple hosts).
3). Use a node in DIT above user entry, for example for "cn=Barbara
Jensen, ou=Accounting, o=Ace Industry, c=US"
and "cn=John Doe, ou=Accounting, o=Ace Industry, c=US" realm can be done as two steps:
a). deriving LDAP authentication identity from TLS credentials; If t
this steps fails, EXTERNAL mechanism returns failure.
b). verify that the authorization identity is allowed
"ou=Accounting, o=Ace Industry, c=US"
(or "o=Ace Industry, c=US"); for the
derived authentication identity. This is always "noop" "cn=Gern Jensen, ou=Product
Testing,o=Ace Industry, c=US" realm can be "ou=Product Testing,
o=Ace Industry, c=US".

Of course other choices are possible.

Alexey

To summarize: I'd like authmeth to define a realm name for the
implicit case.
I am not sure use with
Digest-MD5 that the text corresponds to LDAP DNs known to this server.
Authzid is saying this.
(Source: Alexey Melnikov email 8/1/2003 5:30:43 PM) okay, but perhaps could be better put into context.

John McMeeking (5/12/2003)

Status: Resolved in -07. After reading the comments and the text of
the draft, I believe that Resolved.

draft-ietf-sasl-rfc2222bis-03.txt no longer requires this should be clarified. The local policy
used to map the AuthNID to the AuthZID
information in a SASL protocol. In addition, the implicit case is
sufficient and that no additional verification is useful or needed.
This text has been moved ldapbis WG chairs
have ruled this work out of scope. Individuals are welcome to apply only make
submissions to provide guidance on the explicit assertion
case.

G.41. Section 7.2 contains unnecessary use of realm and misleading detail.

" I am not sure why this section is required realm values
in the document.
DIGEST-MD5 is defined LDAP.

G.44. Use of DNs in a separate document usernames and there should be
nothing magical about its usage realms in LDAP. If DIGEST-MD5 description
creates confusion for LDAP implementors, let's fix

In reading the DIGEST-MD5
document! Also, this section tries to redefine DIGEST-MD5 behavior,
which is explicitly prohibited by discussion on the SASL specification."
(Source: Alexey Melnikov: email 8/1/2003 5:30:43 PM)

Status: Resolved.

After reading mailing list, I reach the comments following
conclusions:

DIGEST-MD5 username and the text realm are simple strings. The syntax of
these strings allows strings that look like DNs in form, however,
DIGEST-MD5 treats them a simple strings for comparision purposes.
For example, the draft plus the
related text DNs cn=roger, o=US and cn=roger,o=us are equivalent

Harrison Expires June 2004 [Page 53]

Internet-Draft LDAP Authentication Methods 5 December 2003

when being compared semantically as DNs, however, these would be
considered two different username values in draft-ietf-sasl-rfc2831bis-02.txt plus
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
02.txt, I am inclined DIGEST-MD5 because
simple octet-wise semantics (rather than DN semantics) are used to agree with Alexey.
compare username values in DIGEST-MD5. Ditto for realm values.

Status: Resolved.

In -07 revision I rewrote section
3.3 (SASL mechanisms) added notes to match the profiling requirements
rfc2831bis. I then dramatically reduced the material implementors expressing this issue
in section 7.2 7.2.

G.45: Open Issue: Is Simple+TLS mandatory to a bare minimum implement?

Going forward, it would be much better to clarify that simple
+TLS is to be used for DN/password credentials and let the SASL profile stand on its own.

G.42. Does change DIGEST-MD5
(or PLAIN+TLS) be used for G.41 cause interoperability issue?

There is one issue with the way the authmeth draft is currently
written that changes username/password credentials. (Kurt
Zeilenga, 5/12/2003)

I don't believe you can mandate simple/TLS! At the SASL DIGEST-MD5 behavior time RFC 2829 was
debated, a large number on the WG wanted this. They did not get
their way because of the
server responds with complexity of the subsequent authentication information . solution. It was argued
that a password-based method would be better. I think they believed
it would still be DN/password, though. (Ron Ramsay, 5/12/2003)

This has been documented in this fashion since RFC 2829 (section
6.1) was originally published and may cause officially opened as an interoperability issue at this point if it changed to follow the DIGEST-MD5 spec (as
it was in -07 by WG co-chair Kurt Zeilenga
on 5/12/03. Little direct discussion has occurred since, however
there has been significant discussion on the use of AuthMeth). Take this issue to DN values as the list.
username for DIGEST-MD5.

Status: Resolved

Harrison Expires April 2004 [Page 51]

Internet-Draft LDAP Authentication Methods 7 October 2003

(10/08/03) This item was discussed Resolved.

Based on the WG list between 5/2/03 and
5/9/03. Consensus apppears to support the notion that RFC 2829 was
in error and that the semantics discussion, Kurt Zeilenga has gaged a lack of RFC 2831 are correct and WG
consensus that Simple+TLS should be reflected in authmeth. This is already the case as of the -07
draft.

G.43. DIGEST-MD5 Realms recommendations for LDAP

From http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
02.txt: A protocol profile SHOULD provide a guidance how realms are mandatory to be constructed and used in the protocol and MAY implement. No
further restrict
its syntax and protocol-specific semantics."

I don't believe that any such guidance exists within the LDAP TS.
The most likely place for this to reside discussion is in the authmeth draft.

Related email from Alexey Melnikov (8/4/2003 1:08:40 PM):

"The problem I have with necessary.

Intellectual Property Rights

The IETF takes no position regarding the document is that it references realm
without explaining what it is (or at least some examples validity or scope of valid
values). For LDAP, some recommendations should any
intellectual property or other rights that might be given. For
example:
1). Use a hardcoded string as claimed to
pertain to the realm (one implementation or use of the implementations
I worked on was doing that)
2). Use hostname (realm==host) technology described in
this document or domain/cluster name (realm
includes multiple hosts).
3). Use a node the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in DIT above user entry, for example for "cn=Barbara
Jensen, ou=Accounting, o=Ace Industry, c=US" standards-track and "cn=John Doe, ou=Accounting, o=Ace Industry, c=US" realm
standards-related documentation can be
"ou=Accounting, o=Ace Industry, c=US"
(or "o=Ace Industry, c=US"); found in BCP-11. Copies of
claims of rights made available for "cn=Gern Jensen, ou=Product
Testing,o=Ace Industry, c=US" realm can publication and any assurances
of licenses to be "ou=Product Testing,
o=Ace Industry, c=US".

Of course other choices are possible.

Alexey

To summarize: I'd like authmeth made available, or the result of an attempt made
to define obtain a realm name general license or permission for the use with
Digest-MD5 that corresponds to LDAP DNs known to of such
proprietary rights by implementors or users of this server.
Authzid is okay, but perhaps could specification
can be better put into context.

John McMeeking (5/12/2003)

G.44. Use of DNs in usernames and realms in DIGEST-MD5

In reading the discussion on the mailing list, I reach obtained from the following
conclusions:

DIGEST-MD5 username and realm are simple strings. IETF Secretariat.

The syntax of
these strings allows strings IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that look like DNs in form, however,
DIGEST-MD5 treats them a simple strings for comparision purposes.
For example, the DNs cn=roger, o=US and cn=roger,o=us are equivalent may be required to practice

Harrison Expires April June 2004 [Page 52]

Internet-Draft LDAP Authentication Methods 7 October 2003

when being compared semantically as DNs, however, these would be
considered two different username values in DIGEST-MD5 because
simple octet-wise semantics (rather than DN semantics) are used to
compare username values in DIGEST-MD5. Ditto for realm values.

Status: Resolved.

In -07 revision I added notes to implementors expressing 54]

Internet-Draft LDAP Authentication Methods 5 December 2003

this issue
in section 7.2.

G.45: Open Issue: Is Simple+TLS mandatory standard. Please address the information to implement?

Going forward, the IETF Executive
Director.

Full Copyright

This document and translations of it would may be much better copied and furnished to clarify
others, and derivative works that simple
+TLS is to comment on or otherwise explain it
or assist in its implementation may be used for DN/password credentials prepared, copied, published
and DIGEST-MD5
(or PLAIN+TLS) be used for username/password credentials. (Kurt
Zeilenga, 5/12/2003)

I don't believe you can mandate simple/TLS! At distributed, in whole or in part, without restriction of any
kind, provided that the time RFC 2829 was
debated, a large number above copyright notice and this paragraph
are included on the WG wanted this. They did all such copies and derivative works. However, this
document itself may not get
their way because of the complexity of the solution. It was argued
that a password-based method would be better. I think they believed
it would still be DN/password, though. (Ron Ramsay, 5/12/2003)

This was officially opened modified in any way, such as an issue by WG co-chair Kurt Zeilenga
on 5/12/03. Little direct discussion has occurred since, however
there has been significant discussion on removing
the use of DN values copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the
username purpose of
developing Internet standards in which case the procedures for DIGEST-MD5.
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

Harrison Expires April June 2004 [Page 53] 55]

----