[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
authmeth review notes [long]
Here are my notes from my in-progress review. I hope
to wrap up my review on the airplane, but thought I'd
share this with you all now (to stir up discussion before
our session). Later....
Kurt
>INTERNET-DRAFT Editor: R. Harrison
>draft-ietf-ldapbis-authmeth-10.txt Novell, Inc.
>Obsoletes: 2829, 2830 10 February 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 Revision 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.
>
>Copyright Notice
>
> Copyright (C) The Internet Society (2003). All Rights Reserved.
Update year.
>
>Abstract
>
> This document describes authentication methods and connection level
> security mechanisms of the Lightweight Directory Access Protocol
> (LDAP).
>
> This document also details establishment of TLS (Transport Layer
> Security) using the Start TLS operation.
s/also//
> This document also details the simple Bind authentication method
s/also//
> 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.
> 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.
s/describes/discusses/
>Table of Contents
>
> 1. Introduction................................................3
> 1.1. Relationship to Other Documents...........................5
> 2. Conventions Used in this Document...........................5
> 2.1. Glossary of Terms.........................................5
> 2.2. Security Terms and Concepts...............................5
> 2.3. Keywords..................................................6
> 3. Start TLS Operation.........................................6
> 3.1. Sequencing of the Start TLS Operation ....................6
> 3.1.1. Start TLS Request.......................................6
> 3.1.2. Start TLS Response......................................7
> 3.1.3. TLS Version Negotiation.................................7
> 3.1.4. Discovery of Resultant Security Level...................7
> 3.1.5. Server Identity Check...................................7
> 3.1.6. Refresh of Server Capabilities Information..............8
> 3.2. Effects of TLS on a Client's Authorization Identity.......8
> 3.2.1. TLS Connection Establishment Effects....................9
> 3.2.2. Client Assertion of Authorization Identity..............9
> 3.2.3. TLS Connection Closure Effects..........................9
> 4. Bind Operation..............................................9
> 4.1. Simple Authentication.....................................9
> 4.2. SASL Authentication.......................................9
> 5. Anonymous LDAP Association on Unbound Connections......... 10
> 6. Anonymous Authentication ................................. 10
> 7. Simple Authentication..................................... 10
> 8. SASL Authentication Profile............................... 11
> 8.1. SASL Service Name for LDAP.............................. 11
> 8.2. SASL Authentication Initiation and Protocol Exchange.... 11
> 8.3. Octet Where Negotiated Security Mechanisms Take Effect.. 12
> 8.4. Determination of Supported SASL Mechanisms.............. 12
> 8.5. Rules for Using SASL Security Layers.................... 13
> 9. SASL EXTERNAL Mechanism................................... 13
> 9.1. Implicit Assertion...................................... 13
> 9.2. Explicit Assertion...................................... 14
> 9.3. SASL Authorization Identity............................. 14
> 9.4 Authorization Identity Syntax............................ 14
> 10. SASL DIGEST-MD5 Mechanism................................ 15
> 11. General Requirements for Password-based Authentication .. 15
> 12. Invalidated Associations................................. 16
> 13. TLS Ciphersuites......................................... 16
> 13.1. TLS Ciphersuites Recommendations....................... 17
> 14. Security Considerations ................................. 18
> 14.1. Start TLS Security Considerations...................... 18
> 15. IANA Considerations...................................... 19
> Acknowledgements............................................. 19
> Normative References......................................... 19
> Informative References....................................... 21
> Author's Address............................................. 21
> Appendix A. LDAP Association State Transition Tables......... 21
> A.1. LDAP Association States................................. 21
> A.2. Actions that Affect LDAP Association State.............. 22
> A.3. Decisions Used in Making LDAP Association State Changes. 22
> A.4. LDAP Association State Transition Table................. 22
> Appendix B. Example Deployment Scenarios..................... 23
> Appendix C. Authentication and Authorization Concepts........ 24
> C.1. Access Control Policy................................... 24
> C.2. Access Control Factors ................................. 24
> C.3. Authentication, Credentials, Identity .................. 25
> C.4. Authorization Identity ................................. 25
> Appendix D. RFC 2829 Change History ......................... 25
> Appendix E. RFC 2830 Change History ......................... 29
> Appendix F. RFC 2251 Change History ......................... 30
> Appendix G. Change History to Combined Document.............. 30
> Appendix H. Issues to be Resolved............................ 41
>
>
>1. Introduction
>
> The Lightweight Directory Access Protocol (LDAP) [Protocol] is a
> powerful access protocol for directories.
s/[Protocol]/[Roadmap]/
Suggest
s/access protocol for directories/protocol for accessing 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 directory data by monitoring others'
> access,
>
> (3) Unauthorized access to reusable client authentication
> information by monitoring others' access,
>
> (4) Unauthorized modification of directory data,
>
> (5) Unauthorized modification of configuration information,
>
> (6) Denial of Service: Use of resources (commonly in excess) in a
> manner intended to deny service to others. and
s/. and/,/
>
> (7) Spoofing: Tricking a user or 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. Tricking a user or client into sending privileged
> information to a hostile entity that appears to be the directory
> server but is not. Tricking a directory server into believing
> that information came from a particular client when in fact it
> came from a hostile entity.
s/./, and/
> (8) Hijacking of prototocol sessions.
s/prototocol/protocol/
> 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, e.g. IP
> spoofing.
Add (8) to the latter list.
> LDAP offers the following security mechanisms:
>
> (1) Authentication by means of the Bind operation. The Bind
> operation provides a simple method which supports anonymous,
> unauthenticated, and authenticated with password mechanisms, and
> the Secure Authentication and Security Layer (SASL) method which
> supports a wide variety of authentication mechanisms and which
> may be extended to support additional methods of authentication.
s/./,/
s/and which...// (no need to discuss extensibility here)
> (2) Client authorization by means of access control based on the
> requestor's authenticated identity,
Given that LDAP doesn't offer an authorization (access control)
model, this seems dubious (even with the note below). However, I
don't have a suggestion (at the moment) on how to better address
this.
> (3) Data integrity protection by means of TLS or SASL mechanisms
> with security layers that provide data integrity services,
s/protection/service/ (use RFC2828 term)
> (4) Data confidentiality protection against snooping by means of the
> TLS protocol or SASL mechanisms that provide data
> confidentiality services,
s/protection/service/ (use RFC2828 term)
s/against snooping// (implicit in term, hence redundant)
> (5) Server resource usage limitation by means of administrative
> service limits configured on the server, and
s/service//
Note: the term "administrative limits" comes from X.511 and is
specifically associated with the adminLimitExceeded result code.
Insertion of the word "service" confuses this association.
> (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
s/any/an/ or s/any implemention/implementations/
> 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 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.
s/see/use/
s/take the form of an LDAP distinguished name/
s/are represented as distinguished names [X.501][Models] in string
form [LDAPDN]/.
> This means that this data must be updated outside the
> protocol or only updated in sessions well protected against
> snooping.
s/snooping/eavesdropping/ (use RFC2828 term)
> It is also desirable to allow authentication methods to
> carry identities not represented as LDAP DNs that are familiar to
> the user or that are used in other systems.
suggest:
It is also desirable to allow authentication methods to
carry identities (other than DNs) that are familiar to the
user 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 B 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 obsoletes RFC 2829.
>
> 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
Suggest you make this Section 1.2.
>2.1. Glossary of Terms
and this 1.2.1.
> 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 [TLS] 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
and this 1.2.2.
>
>
>Harrison Expires July 2004 [Page 5]
>
>Internet-Draft LDAP Authentication Methods 5 December 2003
>
> In general, security terms in this document are used consistently
> with the definitions provided in [Glossary]. In addition, several
> terms and concepts relating to security, authentication, and
> authorization are presented in Appendix C 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 C before reading the remainder of this document.
>2.3. Keywords
and this 1.2.3.
>
> 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 [Keyword].
I would like to add a new section (or possible placed subsequent
to the technical specification of these features) which gathers the
high level implementation requirements. Gathering the statements
are requirement level for each feature (as oppose to detailing how
that feature, if implemented, is to be implemented).
2. Implementation Requirements
LDAP implementations which support any authentication mechanism
(other than anonymous mechanism of the simple Bind method) MUST
support the DIGEST-MD5 [RFC2831bis] mechanism of the SASL Bind
method (as detailed in Section X). That is, excepting those
implementations which only support anonymous connections, all
implementations MUST support DIGEST-MD5. DIGEST-MD5 is reasonably
strong authentication mechanism which provides (mandatory-to-implement)
data security (data integrity and data confidentity) services.
LDAP implementations SHOULD support the simple DN/password mechanism
of the simple Bind method (as detailed in Section X). Implementations
which support this mechanism MUST be capable of protecting it by
establishment (as discussed in Section 3) of TLS.
LDAP server implementations MUST support the anonymous mechanism of
the simple Bind method.
Implementations MAY support additional authentication mechanisms of
the simple and SASL bind methods, and/or mechanisms of other bind
methods. Some of these mechanisms are discussed below.
>3. Start TLS Operation
>
> The Start Transport Layer Security (Start TLS) operation defined in
> section 4.13 of [Protocol] provides the ability to establish [TLS]
> on an LDAP connection.
>
>3.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
> 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 connection are described in detail in
> section 3.2.
>
>3.1.1. Start TLS Request
>
> A 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 outstanding LDAP operations on the connection.
s/LDAP operations/responses for previously issued operations/
This makes, I think, it clear that clients are to wait. Hence,
the following paragraph can be replaced with:
As described in [Protocol, Section 4.13.2.2], a (detected)
violation of any of these requirements results in return of
the operationsError resultCode.
> 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 if the server has sufficient time
> 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.
(Even with all of the qualifications, the above wording sounds
like it condoning not waiting for outstanding responses.)
> There is no requirement that the client have or have not already
> performed a Bind operation (section 4) before sending a Start TLS
> operation request.
s/no/no general/ (there may be requirements in specific cases)
> If the client did not establish a TLS connection before sending some
> other request, and the server requires the client to establish a TLS
> connection before performing that request, the server MUST reject
> that request by sending a resultCode of confidentialityRequired or
> strongAuthRequired.
The following paragraph seems misplaced as it relates to events
which take place after success completion of the operation. Suggest
you insert a subsection "Client Certificate" after 3.1.3. (This
section could meantion that the client certificate may be used
in support of the EXTERNAL mechanism.)
> 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 TLS negotiation if the client did
> not present a certificate which could be validated.
There are too many conditionals in the above sentence.
could it end with "not present an suitable certificate"?
>3.1.2. 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 resultCode values (documented in [Protocol] section 4.13.2.2)
> if it is unwilling or unable to do so.
s/other resultCode values/a resultCode other than success/
> 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.
>
>3.1.3. TLS Version Negotiation
>
> Negotiating the version of TLS to be used is a part of the TLS
> Handshake Protocol [TLS]. Please refer to that document for details.
>
>3.1.4. Discovery of Resultant Security Level
>
> After a TLS connection is established on an LDAP connection, both
> parties 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 3.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.
>
>3.1.5. Server Identity Check
>
> 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
> 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.
>
>3.1.6. Refresh of Server Capabilities Information
>
> Upon TLS session establishment, the client SHOULD discard or refresh
> all information about the server 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
> EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
> after a TLS negotiation has been performed).
>
>3.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 connection.
> 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 C.
>
>3.2.1. TLS Connection Establishment Effects
>
> The decision to keep or invalidate the established authentication
> and authorization identities in place after TLS closure is a matter
> of local server policy.
>
>3.2.2. Client Assertion of Authorization Identity
>
> After successfully establishing a TLS session, a client may request
> that its credentials exchanged during the TLS establishment be
> utilized to authenticate the LDAP association and thus determine the
> client's authorization status. The client accomplishes this via an
> LDAP Bind request specifying a SASL mechanism of EXTERNAL [SASL]
> (section 9). LDAP server implementations SHOULD support this
> authentication method.
>
>3.2.3. TLS Connection Closure Effects
>
> The decision to keep or invalidate the established authentication
> and authorization identities in place after TLS closure is a matter
> of local server policy.
I think we should insert here a section about LDAP associations,
including what the default association is, how new associations
are established, and how associations are invalidated. If done
well, sections 4, 5, 12 could be merged into this new section.
>4. 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.
>
> Upon receipt of a Bind request, the LDAP association is moved to an
> anonymous state and only upon successful completion of the
> authentication exchange (and the Bind operation) is the association
> moved to an authenticated state.
>
>4.1. Simple Authentication
>
> The simple authentication choice of the Bind Operation provides
> minimal facilities for establishing an anonymous association
> (section 6) or for establishing an LDAP association based upon
> credentials consisting of a name (in the form of an LDAP
> distinguished name [LDAPDN]) and a password (section 7).
>
>4.2. SASL Authentication
>
> The sasl authentication choice of the Bind Operation provides
> facilities for authenticating via SASL mechanisms (sections 8-10).
>
>5. Anonymous LDAP Association on Unbound Connections
>
> Prior to the successful completion of a Bind operation and during
> any subsequent authentication exchange, the session has an anonymous
> 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.
>
>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.
I hope this is not typical. I think this paragraph should simply
be deleted.
> An LDAP client may explicitly establish an anonymous association by
> sending a Bind Request with the simple authentication choice
> containing a value--construed as the password--of zero length. A
> bind request where both the name and password are of zero length is
> said to be an anonymous bind. A bind request where the name, a DN,
> is of non-zero length, and the password is of zero length is said to
> be an unauthenticated bind. Both variations produce an anonymous
> association.
>
> Unauthenticated binds can have significant security issues (see
> section 14). Servers SHOULD by default reject unauthenticated bind
> requests with a resultCode of invalidCredentials, and clients may
> need to actively detect situations where they would make an
> unauthenticated bind request.
>
> 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.
>
> LDAP implementations MUST support anonymous authentication.
>
>7. Simple Authentication
>
> An LDAP client may establish an LDAP association by sending a Bind
> Request with a name value consisting of an LDAP distinguished name
> [LDAPDN] and specifying the simple authentication choice with a
> password value.
s/an LDAP distinguished name/a distinguished name in LDAP string
form [LDAPDN]/
s/password value/password value, an OCTET STRING.
> DSAs that map the DN sent in the bind request to a directory entry
> with an associated set of one or more passwords will compare the
> presented password to the set of passwords associated with that
> entry.
s/DSAs/Servers/
s/more passwords/more passwords, each an OCTET STRING,/
s/compare/compare octet wise/
> If the presented password matches any member of that set,
> then the server will respond with a success resultCode, otherwise
> the server will respond with an invalidCredentials resultCode.
This wording doesn't account for other possible failures. Instead,
I suggest:
The presented password is considered valid if it
matches any member of this set.
If the DN is not valid, or the password is not valid for
the DN, or the server otherwise considers the credentials
to be invalid, the server is to return the invalidCredentials
result code. The server is only to return success result
code when the credentials are valid and the server is willing
to provide service to the entity these credentials identify.
> The simple authentication choice is not suitable for authentication
> in environments where there is no network or transport layer
> confidentiality. LDAP implementations SHOULD support authentication
> with the "simple" authentication choice when the connection is
> protected against eavesdropping using TLS, as defined in section 4.
> LDAP implementations SHOULD NOT support authentication with the
> "simple" authentication choice unless the data on the connection is
> protected using TLS or other data confidentiality and data integrity
> protection.
>
>8. SASL Authentication Profile
>
> LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
> includes native anonymous and plaintext authentication methods, the
> ANONYMOUS [ANONYMOUS] and 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.
>
>8.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.
>
>8.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 5.1).
>
> In general, a SASL authentication protocol exchange consists of a
> series of server challenges and client responses, the contents of
> 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
> 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.
>
>8.3. Octet Where Negotiated Security Mechanisms Take Effect
>
> SASL security layers take effect following the transmission by the
> server and reception by the client of the final successful
> 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).
>
>8.4. Determination of Supported SASL Mechanisms
>
> Clients may determine the SASL mechanisms a server supports by
> reading the 'supportedSASLMechanisms ' attribute from the root DSE
> (DSA-Specific Entry) ([Models] section 5.1). The values of this
> attribute, if any, list the mechanisms the server supports in the
> current LDAP session state.
>
> LDAP servers SHOULD allow an anonymously-bound client to retrieve
> the supportedSASLMechanisms attribute of the root DSE.
>
>8.5. Rules for Using SASL Security Layers
>
> If a SASL security layer is negotiated, the client SHOULD discard
> information about the server it obtained prior to the initiation of
> the SASL negotiation and not obtained through secure mechanisms.
>
> 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.
>
>9. SASL EXTERNAL Mechanism
I think this section needs a major rewrite. I'll offer
replacement text in a bit.
>
> A client can use the EXTERNAL SASL [SASL] mechanism to request the
> LDAP server to make use of security credentials exchanged by a lower
> security layer (such as by TLS authentication or IP-level security
> [SecArch]).
"lower level security layer" is too restrictive. RFC 2222 actually
says
The server uses information, external to SASL, to determine
whether the client is authorized to authenticate as the
authorization identity.
This section needs to reworded using terms consisent with RFC 2222
section 7.4. Also, introduction of "implicit assertion" and
"explicit assertion" terminology seems unnecessary (and certainly
isn't specific to this mechanism). General handling of authorization
identities needs to be discussed in section 8. This section needs
only to provide an LDAP profile of the EXTERNAL mechanism, and
possibly an example or two.
> If the client's authentication credentials have not been established
> at a lower security layer, the SASL EXTERNAL bind MUST fail with a
> resultCode of inappropriateAuthentication.
It may be difficult for some LDAP implementations, such as those
which use protocol-neutral SASL implementations, to map a
mechanism-specific failure to a protocol-specific code. For
ease of implementation, we should avoid mandating mechanism-specific
failure handling. This MUST should minimally be replaced with a
SHOULD, if not removed outright... (or replaced with mechanism
neutral text placed elsewhere).
> 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). In such a situation, the
> state of any established security layer is unaffected.
This seems to just be restating was is true for all Bind
failures. I see little point in repeating it.
>
> A client may either implicitly request that its LDAP authorization
> identity be derived from a lower layer or it may explicitly provide
> an 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 latter as an explicit assertion.
>
>9.1. Implicit Assertion
>
> An implicit authorization identity assertion is performed by
> invoking a Bind request of the SASL form using the EXTERNAL
> mechanism name that does 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
> 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 implementation specific.
>
>9.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 includes the credentials octet string. This
> string MUST be constructed as documented in section 3.4.1.
>
> The server MUST verify 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.
>
>9.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.
I think we need cover mechanism indepenent handling of authzids
in section 8 and only detail in section 9 how authzids are
transferred (or not) when using EXTERNAL.
>9.4 Authorization Identity Syntax
This section needs to be in section 8 as the LDAP's SASL profile
must include the specification the authorization identity form.
>
> 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:"
These are not equivalent to the RFC 2829 ABNF! Instead:
DNCOLON = ( %x44 / %x64 ) ( %4E / %x6E ) %x3A ; "dn:"
UCOLON = ( %x55 / %x75 ) %x3A ; "u:"
> ; distinguished-name-based authz id.
> dnAuthzId = DNCOLON distinguishedName
>
> ; unspecified authorization id, UTF-8 encoded.
> uAuthzId = UCOLON userid
> userid = *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 clients to assert authorization
> identities in the form of a distinguished name to be matched in
> accordance with the distinguishedNameMatch 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.
I also suggest a slight rewriting:
As the decision to allow or disallow the client to assume
the requested authorization identity is a matter of local
policy (see section 4.2 of [SASL]), there is no requirement
that the asserted DN be that of an entry in the directory.
> The uAuthzId choice allows for compatibility with 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] before being
> compared octet-wise. The format of userid is defined as only a
> sequence 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.
s/the local-part of//
This offers an example which, unlike the others, obviously
includes punctuation characters.
> A uAuthzId SHOULD NOT be assumed to be globally unique.
>
>10. SASL DIGEST-MD5 Mechanism
>
> 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.
>
> Support for subsequent authentication ([DIGEST-MD5] section 2.2) is
> OPTIONAL in clients and servers.
>
> Implementers 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 mechanism utilizes
> realm and username values ([DIGEST-MD5] section 2.1) which are
> syntactically simple strings and semantically simple realm and
> username values. These values are not LDAP DNs, and there is no
> requirement that they be 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 two DNs <cn=Bob,dc=example,dc=com> (upper case "B") and
> <cn=bob,dc=example,dc=com> (lower case "b") are equivalent when
> being compared semantically as LDAP DNs because the cn attribute is
> defined to be case insensitive, however the two values are not
> equivalent if they represent username values in DIGEST-MD5 because
> [SASLPrep] semantics are used by DIGEST-MD5.
>
>11. General Requirements for Password-based Authentication
>
> 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 authentication [SASL]
> mechanisms that do not transmit passwords in the clear or 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 at the
> time of authentication or password modification, requires:
>
> 1) A Start TLS encryption layer has been successfully negotiated.
>
> OR
>
> 2) Some other confidentiality mechanism that protects the password
> value from snooping has been provided.
>
> OR
>
> 3) The server returns a resultCode of confidentialityRequired for
> the operation (i.e. simple bind with password value, SASL bind
> transmitting a password value in the clear, add or modify
> including a userPassword value, etc.), even if the password
> value is correct.
>
>12. Invalidated Associations
>
> The server may, at any time, invalidate the association, e.g. if the
> established security association between the client and server has
> unexpectedly failed or been compromised. The association remains
> invalidated until the next successful bind request. While the
> association is invalidated, the server may reject any operation
> request other than Bind, Unbind, and Start TLS by responding with a
> resultCode of strongAuthRequired to indicate that the client needs
> to bind to reestablish its authentication state before performing
> the requested operation.
>
>13. TLS Ciphersuites
This section should be incorporated in section 3 (as the last
subsection).
> A client or server that supports TLS MUST support
> TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. Servers SHOULD NOT support
> weaker ciphersuites unless other data integrity and
> confidentiality protection (such as a SASL security layer) is
> in place
This is unnecessarily intended.
> 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.
>
>13.1. TLS Ciphersuites Recommendations
This section needs to be updated.
> 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.
>
> 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
> 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
>
>
>14. Security Considerations
I'd like to see this section split into a couple of additional
subsections.
14.1 General considerations
14.2 Start TLS considerations
14.3 Simple Bind considerations
14.4 SASL Bind considerations
And then flush these sections out.
> 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 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 bind (see section 5.1). For example, a
> client program might make a decision to grant access to non-
> directory information on the basis of completing a successful bind
> operation. Some LDAP server implementations will return a success
> response to an unauthenticated bind thus leaving the client with the
> impression that the server has successfully authenticated the
> identity represented by the user name, when in effect, an anonymous
> LDAP association has been created. Clients that use the results from
> a simple bind operation to make authorization decisions should
> actively detect unauthenticated bind requests (via the empty
> password 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 established connection
> integrity and privacy services (e.g via Start TLS, IPSec or a
> suitable SASL mechanism) is subject to man-in-the-middle attacks to
> view and modify information in transit.
>
>14.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
> connection--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 supported 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 data 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.
>
> 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].
>
>15. IANA Considerations
>
> The following IANA considerations apply to this document:
>
> Please update the GSSAPI service name registry to point to [Roadmap]
> and this document.
>
> [To be completed]
>
>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.
>
> 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
>
> [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
> Syntax Specifications: ABNF", RFC 2234, November 1997.
>
> [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.
>
> [Keyword] Bradner, S., "Key Words for use in RFCs to Indicate
> Requirement Levels", BCP 14, RFC 2119, March 1997.
>
> [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String
> Representation of Distinguished Names", draft-ietf-
> ldapbis-dn-xx.txt, a work in progress.
>
> [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.
>
> [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 3629, STD 63, November 2003.
>
> [Unicode] 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 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.
>
> [Glossary] Shirey, R., "Internet Security Glossary", RFC 2828, May
> 2000.
>
> [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-
> sasl-plain-xx.txt, a work in progress.
>
> [SecArch] 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
> USA
> +1 801 861 2642
> roger_harrison@novell.com
>
>Appendix A. LDAP Association State Transition Tables
>
> This section provides a state transition table to represent a state
> diagram for the various authentication and TLS states through which
> an LDAP association may pass during the course of its existence and
> the actions that cause these changes in state.
>
> This section is based entirely on information found in this document
> and other documents that are part of the LDAP Technical
> Specification [Roadmap]. As such, it is strictly informational in
> nature.
>
>A.1. LDAP Association States
>
> The following table lists the valid LDAP association states and
> provides a description of each state. The ID for each state is used
> in the state transition table in section A.4.
>
> ID State Description
> -- --------------------------------------------------------------
> S1 Anonymous
> no Authentication ID is associated with the 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
>
>A.2. Actions that Affect LDAP Association State
>
> The following table lists the actions that can affect the
> authentication and authorization state of an LDAP association. The
> ID for each action is used in the state transition table in section
> A.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 current
> authentication ID maps to authorization ID = Y.
> A6 Client Binds SASL EXTERNAL with explicit assertion of
> authorization ID = Z (section 3.3.6.2)]
> A7 Client abandons a bind operation, and server processes the
> abandon
> A8 Client abandons a bind operation, and server does not process
> the abandon
> A9 Client Start TLS request fails
> A10 Client Start TLS request succeeds
> A11 Client or Server: graceful TLS closure ([Protocol] section
> 4.13.3.1.)
>
>A.3. Decisions Used in Making LDAP Association State Changes
>
> Certain changes in the authentication and authorization state of an
> LDAP association are only allowed if the server can affirmatively
> answer a question. These questions are applied as part of the
> criteria for allowing or disallowing a state transition in the state
> transition table in section A.4.
>
> ID Decision Question
> -- --------------------------------------------------------------
> D1 Are lower-layer credentials available?
> D2 Can lower-layer credentials for Auth ID "K" be mapped to
> asserted AuthZID "L"?
>
>A.4. LDAP Association State Transition Table
>
> The LDAP Association table below lists the valid authentication and
> authorization states for an LDAP association and the actions that
> could affect them. For any given row in the table, the Current State
> column gives the state of an LDAP association, the Action column
> gives an action that could affect the state of an LDAP assocation,
> and the Next State column gives the resulting state of an LDAP
> association after the 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
> 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
>
>Appendix B. Example Deployment Scenarios
>
> The following scenarios are typical for LDAP directories on the
> Internet, and have different security requirements. (In the
> following discussion, "sensitive data" refers to information whose
> disclosure, alteration, destruction, or loss would adversely affect
> the interests or business of its owner or user. Also note that there
> may be 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 TCP connection hijacking or IP spoofing is not
> a problem. Anonymous authentication, described in section 7, is
> suitable for this type 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 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 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 C. Authentication and Authorization Concepts
>
> This appendix defines basic terms, concepts, and interrelationships
> regarding authentication, authorization, credentials, and identity.
> These concepts are used in describing how various security
> approaches are utilized in client authentication and authorization.
>
>C.1. Access Control Policy
>
> An access control policy is a set of rules defining the protection
> of resources, generally in terms of the capabilities of persons or
> other entities accessing those resources. Security objects and
> mechanisms, such as those described here, enable the expression of
> access control policies and their enforcement.
>
>C.2. Access Control Factors
>
> A 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 server uses these factors to determine whether and
> how to process the request. These are called 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 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.
>
>C.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 identity
> they assert. An authentication identity is the name presented in a
> credential.
>
> There are many forms of authentication credentials -- the 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 form of authentication identities used
> with it.
>
>C.4. Authorization Identity
>
> An authorization identity is 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 an association is often exactly
> the same as the authentication identity presented by the client, but
> it may be different. SASL allows clients to specify an authorization
> identity distinct from the authentication identity asserted by the
> client's credentials. This permits agents such as proxy servers to
> authenticate using their own credentials, yet request the access
> privileges of the identity for which they are proxying [SASL]. Also,
> the form of authentication identity supplied by a service like TLS
> may not correspond to the authorization identities used to express a
> server's access control policy, requiring a server-specific mapping
> 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 D. RFC 2829 Change History
Insert here a summary of substantive changes (in total) since RFC
2829.
Then either add:
[[Note to RFC Editor: the remaining portion of this appendix
should be deleted prior to publication.]]
or remove the following text and subsections.
> This appendix lists the changes made to the text of RFC 2829 in
> preparing this document.
>
[trimmed]
>
>Appendix E. RFC 2830 Change History
Insert here a summary of substantive changes (in total) since RFC
2830.
Then either add:
[[Note to RFC Editor: the remaining portion of this appendix
should be deleted prior to publication.]]
or remove the following text and subsections.
> This appendix lists the changes made to the text of RFC 2830 in
> preparing this document.
[trimmed]
>Appendix F. RFC 2251 Change History
Insert here a summary of substantive changes (in total) since RFC
2251.
Then either add:
[[Note to RFC Editor: the remaining portion of this appendix
should be deleted prior to publication.]]
or remove the following text and subsections.
>Appendix G. Change History to Combined Document
Either add:
[[Note to RFC Editor: this appendix should be deleted prior
to publication.]]
or remove it.
[trimmed]
>
>Appendix H. Issues to be Resolved
>
Either add:
[[Note to RFC Editor: this appendix should be deleted prior
to publication.]]
or remove it.
> This appendix lists open questions and issues that need to be
> resolved before work on this document is deemed complete.
[trimmed]