2 INTERNET-DRAFT Editor: R. Harrison
3 draft-ietf-ldapbis-authmeth-09.txt Novell, Inc.
4 Obsoletes: 2251, 2829, 2830 5 December 2003
5 Intended Category: Draft Standard
8 LDAP: Authentication Methods
10 Connection Level Security Mechanisms
14 This document is an Internet-Draft and is in full conformance with
15 all provisions of Section 10 of RFC2026.
17 This document is intended to be, after appropriate review and
18 revision, submitted to the RFC Editor as a Standard Track document.
19 Distribution of this memo is unlimited. Technical discussion of
20 this document will take place on the IETF LDAP Extension Working
21 Group mailing list <ietf-ldapbis@OpenLDAP.org>. Please send
22 editorial comments directly to the author
23 <roger_harrison@novell.com>.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF), its areas, and its working groups. Note that
27 other groups may also distribute working documents as Internet-
28 Drafts. Internet-Drafts are draft documents valid for a maximum of
29 six months and may be updated, replaced, or obsoleted by other
30 documents at any time. It is inappropriate to use Internet-Drafts
31 as reference material or to cite them other than as "work in
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-
36 Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html.
41 Copyright (C) The Internet Society (2003). All Rights Reserved.
45 This document describes authentication methods and connection level
46 security mechanisms of the Lightweight Directory Access Protocol
49 This document details the simple Bind authentication method
50 including anonymous, unauthenticated, and plain-text password
51 methods and the SASL (Simple Authentication and Security Layer) Bind
52 authentication method including the use of DIGEST-MD5 and EXTERNAL
56 Harrison Expires June 2004 [Page 1]
58 Internet-Draft LDAP Authentication Methods 5 December 2003
60 This document also details establishment of TLS (Transport Layer
61 Security) using the Start TLS operation.
63 This document describes various authentication and authorization
64 states through which a connection to an LDAP server may pass and the
65 actions that trigger these state changes.
69 The Lightweight Directory Access Protocol (LDAP) [Protocol] is a
70 powerful access protocol for directories. It offers means of
71 searching, retrieving and manipulating directory content, and ways
72 to access a rich set of security functions.
74 It is vital that these security functions be interoperable among all
75 LDAP clients and servers on the Internet; therefore there has to be
76 a minimum subset of security functions that is common to all
77 implementations that claim LDAP conformance.
79 Basic threats to an LDAP directory service include:
81 (1) Unauthorized access to directory data via data-retrieval
84 (2) Unauthorized access to reusable client authentication
85 information by monitoring others' access,
87 (3) Unauthorized access to directory data by monitoring others'
90 (4) Unauthorized modification of directory data,
92 (5) Unauthorized modification of configuration information,
94 (6) Unauthorized or excessive use of resources (denial of service),
97 (7) Spoofing of directory: Tricking a client into believing that
98 information came from the directory when in fact it did not,
99 either by modifying data in transit or misdirecting the client's
100 connection. Also, tricking a client into sending privileged
101 information to a hostile entity that appears to be the directory
104 Threats (1), (4), (5) and (6) are due to hostile clients. Threats
105 (2), (3) and (7) are due to hostile agents on the path between
106 client and server or hostile agents posing as a server.
108 LDAP can be protected with the following security mechanisms:
110 (1) Client authentication by means of the Secure Authentication and
111 Security Layer (SASL) [SASL] mechanism set, possibly backed by
112 the Transport Layer Security (TLS) [TLS] credentials exchange
115 Harrison Expires June 2004 [Page 2]
117 Internet-Draft LDAP Authentication Methods 5 December 2003
120 (2) Client authorization by means of access control based on the
121 requestor's authenticated identity,
123 (3) Data integrity protection by means of TLS or SASL mechanisms
124 with security layers that provide data integrity services,
126 (4) Data confidentiality protection against snooping by means of the
127 TLS protocol or SASL mechanisms that provide data
128 confidentiality services,
130 (5) Server resource usage limitation by means of administrative
131 service limits configured on the server, and
133 (6) Server authentication by means of the TLS protocol or SASL
136 At the moment, imposition of access controls is done by means
137 outside the scope of LDAP.
139 It seems clear that allowing any implementation, faced with the
140 above requirements, to simply pick and choose among the possible
141 alternatives is not a strategy that is likely to lead to
142 interoperability. In the absence of mandates, clients will be
143 written that do not support any security function supported by the
144 server, or worse, they will support only mechanisms like the LDAP
145 simple bind using clear text passwords that provide inadequate
146 security for most circumstances.
148 Given the presence of the Directory, there is a strong desire to see
149 mechanisms where identities take the form of an LDAP distinguished
150 name [LDAPDN] and authentication data can be stored in the
151 directory. This means that this data must be updated outside the
152 protocol or only updated in sessions well protected against
153 snooping. It is also desirable to allow authentication methods to
154 carry identities not represented as LDAP DNs that are familiar to
155 the user or that are used in other systems.
157 The set of security mechanisms provided in LDAP and described in
158 this document is intended to meet the security needs for a wide
159 range of deployment scenarios and still provide a high degree of
160 interoperability among various LDAP implementations and
161 deployments. Appendix A contains example deployment scenarios that
162 list the mechanisms that might be used to achieve a reasonable
163 level of security in various circumstances.
165 1.1. Relationship to Other Documents
167 This document is an integral part of the LDAP Technical
168 Specification [Roadmap].
170 This document obsoletes RFC 2829.
174 Harrison Expires June 2004 [Page 3]
176 Internet-Draft LDAP Authentication Methods 5 December 2003
178 Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
179 remainder of RFC 2830 is obsoleted by this document.
181 2. Conventions Used in this Document
183 2.1. Glossary of Terms
185 The following terms are used in this document. To aid the reader,
186 these terms are defined here.
188 - "user" represents any human or application entity which is
189 accessing the directory using a directory client. A directory
190 client (or client) is also known as a directory user agent
193 - "connection" and "LDAP connection" both refer to the underlying
194 transport protocol connection between two protocol peers.
196 - "TLS connection" refers to a TLS-protected LDAP connection.
198 - "association" and "LDAP association" both refer to the
199 association of the LDAP connection and its current
200 authentication and authorization state.
202 2.2. Security Terms and Concepts
204 In general, security terms in this document are used consistently
205 with the definitions provided in [RFC2828]. In addition, several
206 terms and concepts relating to security, authentication, and
207 authorization are presented in Appendix B of this document. While
208 the formal definition of these terms and concepts is outside the
209 scope of this document, an understanding of them is prerequisite to
210 understanding much of the material in this document. Readers who are
211 unfamiliar with security-related concepts are encouraged to review
212 Appendix B before reading the remainder of this document.
216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
218 document are to be interpreted as described in RFC 2119 [RFC2119].
222 The Bind operation defined in section 4.2 of [Protocol] allows
223 authentication information to be exchanged between the client and
224 server to establish a new LDAP association. The new LDAP association
225 is established upon successful completion of the authentication
228 3.1. Implied Anonymous Bind on LDAP Association
230 Prior to the successful completion of a Bind operation and during
231 any subsequent authentication exchange, the session has an anonymous
233 Harrison Expires June 2004 [Page 4]
235 Internet-Draft LDAP Authentication Methods 5 December 2003
237 LDAP association. Among other things this implies that the client
238 need not send a Bind Request in the first PDU of the connection. The
239 client may send any operation request prior to binding, and the
240 server MUST treat it as if it had been performed after an anonymous
241 bind operation. This authentication state on an LDAP association is
242 sometimes referred to as an implied anonymous bind.
244 3.2. Simple Authentication
246 The simple authentication choice provides minimal facilities for
247 establishing an anonymous association or for establishing an LDAP
248 association based upon credentials consisting of a name (in the form
249 of an [LDAPDN] and a password.
251 The simple authentication choice provides two different methods
252 for establishing an anonymous association: anonymous bind and
253 unauthenticated bind (see section 5.1).
255 The simple authentication choice provides one method for
256 establishing a non-anonymous association: simple password bind.
258 3.3. SASL Authentication Profile
260 LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
261 includes native anonymous and plaintext authentication methods, the
262 ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN] SASL mechanisms are
263 typically not used with LDAP.
265 Each protocol that utilizes SASL services is required to supply
266 certain information profiling the way they are exposed through the
267 protocol ([SASL] section 5). This section explains how each of these
268 profiling requirements are met by LDAP.
270 3.3.1. SASL Service Name for LDAP
272 The SASL service name for LDAP is "ldap", which has been registered
273 with the IANA as a GSSAPI service name.
275 3.3.2. SASL authentication initiation and protocol exchange
277 SASL authentication is initiated via an LDAP bind request
278 ([Protocol] section 4.2) with the following parameters:
281 - The AuthenticationChoice is sasl.
282 - The mechanism element of the SaslCredentials sequence contains
283 the value of the desired SASL mechanism.
284 - The optional credentials field of the SaslCredentials sequence
285 may be used to provide an initial client response for
286 mechanisms that are defined to have the client send data first
287 (see [SASL] sections 5 and 5.1).
289 In general, a SASL authentication protocol exchange consists of a
290 series of server challenges and client responses, the contents of
292 Harrison Expires June 2004 [Page 5]
294 Internet-Draft LDAP Authentication Methods 5 December 2003
296 which are specific to and defined by the SASL mechanism. Thus for
297 some SASL authentication mechanisms, it may be necessary for the
298 client to respond to one or more server challenges by invoking the
299 BindRequest multiple times. A challenge is indicated by the server
300 sending a BindResponse with the resultCode set to
301 saslBindInProgress. This indicates that the server requires the
302 client to send a new bind request, with the same sasl mechanism to
303 continue the authentication process.
305 To the encapsulating protocol, these challenges and responses are
306 opaque binary tokens of arbitrary length. LDAP servers use the
307 serverSaslCreds field, an OCTET STRING, in a bind response message
308 to transmit each challenge. LDAP clients use the credentials field,
309 an OCTET STRING, in the SaslCredentials sequence of a bind request
310 message to transmit each response. Note that unlike some Internet
311 protocols where SASL is used, LDAP is not text-based, thus no Base64
312 transformations are performed on these challenge and response
315 Clients sending a bind request with the sasl choice selected SHOULD
316 NOT send a value in the name field. Servers receiving a bind request
317 with the sasl choice selected SHALL ignore any value in the name
320 A client may abort a SASL bind negotiation by sending a BindRequest
321 with a different value in the mechanism field of SaslCredentials, or
322 an AuthenticationChoice other than sasl.
324 If the client sends a BindRequest with the sasl mechanism field as
325 an empty string, the server MUST return a BindResponse with
326 authMethodNotSupported as the resultCode. This will allow clients to
327 abort a negotiation if it wishes to try again with the same SASL
330 The server indicates completion of the SASL challenge-response
331 exchange by responding with a bind response in which the resultCode
332 is either success, or an error indication.
334 The serverSaslCreds field in the bind response can be used to
335 include an optional challenge with a success notification for
336 mechanisms which are defined to have the server send additional data
337 along with the indication of successful completion.
339 3.3.3. Octet where negotiated security mechanisms take effect
341 When negotiated, SASL security layers take effect following the
342 transmission by the server and reception by the client of the final
343 BindResponse in the exchange.
345 Once a SASL security layer providing integrity or confidentiality
346 services takes effect, the layer remains in effect until a new layer
347 is installed (i.e. at the first octet following the final
348 BindResponse of the bind operation that caused the new layer to take
351 Harrison Expires June 2004 [Page 6]
353 Internet-Draft LDAP Authentication Methods 5 December 2003
356 3.3.4. Determination of supported SASL mechanisms
358 An LDAP client may determine the SASL mechanisms a server supports
359 by performing a search request on the root DSE, requesting the
360 supportedSASLMechanisms attribute. The values of this attribute, if
361 any, list the mechanisms the server supports.
363 3.3.5. Rules for using SASL security layers
365 If a SASL security layer is negotiated, the client SHOULD discard
366 information about the server it obtained prior to the initiation of
367 the SASL negotiation and not obtained through secure mechanisms.
369 If a lower level security layer (such as TLS) is negotiated, any
370 SASL security services SHALL be layered on top of such security
371 layers regardless of the order of their negotiation. In all other
372 respects, SASL security services and other security layers act
373 independently, e.g. if both TLS and SASL security service are in
374 effect removing the SASL security service does not affect the
375 continuing service of TLS and vice versa.
377 Because SASL mechanisms provide critical security functions, clients
378 and servers should allow the user to specify what mechanisms are
379 acceptable and allow only those mechanisms to be used.
381 3.3.6. Use of EXTERNAL SASL Mechanism
383 A client can use the EXTERNAL SASL [SASL] mechanism to request the
384 LDAP server to make use of security credentials exchanged by a lower
385 security layer (such as by TLS authentication or IP-level security
388 If the client's authentication credentials have not been established
389 at a lower security layer, the SASL EXTERNAL bind MUST fail with a
390 resultCode of inappropriateAuthentication. Any client
391 authentication and authorization state of the LDAP association is
392 lost, so the LDAP association is in an anonymous state after the
393 failure (see [Protocol] section 4.2.1). In such a situation, the
394 state of any established security layer is unaffected.
396 A client may either implicitly request that its LDAP authorization
397 identity be derived from a lower layer or it may explicitly provide
398 an authorization identity and assert that it be used in combination
399 with its authenticated TLS credentials. The former is known as an
400 implicit assertion, and the latter as an explicit assertion.
402 3.3.6.1. Implicit Assertion
404 An implicit authorization identity assertion is performed by
405 invoking a Bind request of the SASL form using the EXTERNAL
406 mechanism name that SHALL NOT include the optional credentials octet
407 string (found within the SaslCredentials sequence in the Bind
408 Request). The server will derive the client's authorization identity
410 Harrison Expires June 2004 [Page 7]
412 Internet-Draft LDAP Authentication Methods 5 December 2003
414 from the authentication identity supplied by the security layer
415 (e.g., a public key certificate used during TLS establishment)
416 according to local policy. The underlying mechanics of how this is
417 accomplished are implementation specific.
419 3.3.6.2. Explicit Assertion
421 An explicit authorization identity assertion is performed by
422 invoking a Bind request of the SASL form using the EXTERNAL
423 mechanism name that SHALL include the credentials octet string. This
424 string MUST be constructed as documented in section 3.4.1.
426 The server MUST that the client's authentication identity as
427 supplied in its TLS credentials is permitted to be mapped to the
428 asserted authorization identity. The server MUST reject the Bind
429 operation with an invalidCredentials resultCode in the Bind response
430 if the client is not so authorized.
432 3.3.6.3. SASL Authorization Identity
434 When the EXTERNAL SASL mechanism is being negotiated, if the
435 SaslCredentials credentials field is present, it contains an
436 authorization identity. Other mechanisms define the location of the
437 authorization identity in the credentials field. In either case, the
438 authorization identity is represented in the authzId form described
441 3.3.6.4 Authorization Identity Syntax
443 The authorization identity is a string of [UTF-8] encoded [Unicode]
444 characters corresponding to the following [ABNF] grammar:
446 authzId = dnAuthzId / uAuthzId
448 DNCOLON = %x64 %x6e %x3a ; "dn:"
449 UCOLON = %x75 %x3a ; "u:"
451 ; distinguished-name-based authz id.
452 dnAuthzId = DNCOLON distinguishedName
454 ; unspecified authorization id, UTF-8 encoded.
455 uAuthzId = UCOLON userid
456 userid = *UTF8 ; syntax unspecified
458 where the <distinguishedName> production is defined in section 3 of
459 [LDAPDN] and <UTF8> production is defined in section 1.3 of
462 In order to support additional specific authorization identity
463 forms, future updates to this specification may add new choices
464 supporting other forms may be added to the authzId production.
466 The dnAuthzId choice allows clients to assert authorization
467 identities in the form of a distinguished name to be matched in
469 Harrison Expires June 2004 [Page 8]
471 Internet-Draft LDAP Authentication Methods 5 December 2003
473 accordance with the distinguishedName matching rule [Syntaxes]. The
474 decision to allow or disallow an authentication identity to have
475 access to the requested authorization identity is a matter of local
476 policy ([SASL] section 4.2). For this reason there is no requirement
477 that the asserted dn be that of an entry in directory.
479 The uAuthzId choice allows for compatibility with clients that wish
480 to assert an authorization identity to a local directory but do not
481 have that identity in distinguished name form. The value contained
482 within a uAuthzId MUST be prepared using [SASLPrep] before being
483 compared octet-wise. The format of utf8string is defined as only a
484 sequence of [UTF-8] encoded [Unicode] characters, and further
485 interpretation is subject to prior agreement between the client and
488 For example, the userid could identify a user of a specific
489 directory service or be a login name or the local-part of an RFC 822
490 email address. A uAuthzId SHOULD NOT be assumed to be globally
493 4. Start TLS Operation
495 The Start Transport Layer Security (Start TLS) operation defined in
496 section 4.13 of [Protocol] provides the ability to establish [TLS]
497 on an LDAP association.
499 4.1. Sequencing of the Start TLS Operation
501 This section describes the overall procedures clients and servers
502 must follow for TLS establishment. These procedures take into
503 consideration various aspects of the overall security of the LDAP
504 association including discovery of resultant security level and
505 assertion of the client's authorization identity.
507 Note that the precise effects, on a client's authorization identity,
508 of establishing TLS on an LDAP association are described in detail
511 4.1.1. Start TLS Request
513 The client MAY send the Start TLS extended request at any time after
514 establishing an LDAP connection, except:
516 - when TLS is currently established on the connection,
517 - when a multi-stage SASL negotiation is in progress on the
519 - when there are one or more outstanding LDAP operations on the
522 The result of violating any of these requirements is a resultCode of
523 operationsError, as described in [Protocol] section 4.13.2.2. Client
524 implementers should note that it is possible to receive a resultCode
525 of success for a Start TLS operation that is sent on a connection
526 with outstanding LDAP operations and the server has sufficient time
528 Harrison Expires June 2004 [Page 9]
530 Internet-Draft LDAP Authentication Methods 5 December 2003
532 to process them prior to its receiving the Start TLS request.
533 Implementors of clients should ensure that they do not inadvertently
534 depend upon this race condition.
536 In particular, there is no requirement that the client have or have
537 not already performed a Bind operation before sending a Start TLS
538 operation request. The client may have already performed a Bind
539 operation when it sends a Start TLS request, or the client might
542 If the client did not establish a TLS connection before sending any
543 other requests, and the server requires the client to establish a
544 TLS connection before performing a particular request, the server
545 MUST reject that request by sending a resultCode of
546 confidentialityRequired or strongAuthRequired.
548 4.1.2. Start TLS Response
550 The server will return an extended response with the resultCode of
551 success if it is willing and able to negotiate TLS. It will return
552 other resultCode values (documented in [Protocol] section 4.13.2.2)
553 if it is unwilling or unable to do so.
555 In the successful case, the client (which has ceased to transfer
556 LDAP requests on the connection) MUST either begin a TLS negotiation
557 or close the connection. The client will send PDUs in the TLS Record
558 Protocol directly over the underlying transport connection to the
559 server to initiate [TLS] negotiation.
561 4.1.3. TLS Version Negotiation
563 Negotiating the version of TLS or SSL to be used is a part of the
564 [TLS] Handshake Protocol. Please refer to that document for details.
566 4.1.4. Discovery of Resultant Security Level
568 After a TLS connection is established on an LDAP association, both
569 parties must individually decide whether or not to continue based on
570 the security level achieved. Ascertaining the TLS connection's
571 security level is implementation dependent and accomplished by
572 communicating with one's respective local TLS implementation.
574 If the client or server decides that the level of authentication or
575 security is not high enough for it to continue, it SHOULD gracefully
576 close the TLS connection immediately after the TLS negotiation has
577 completed (see [Protocol] section 4.13.3.1 and section 4.2.3 below).
578 If the client decides to continue, it may gracefully close the TLS
579 connection and attempt to Start TLS again, it may send an unbind
580 request, or it may send any other LDAP request.
582 4.1.5. Server Identity Check
587 Harrison Expires June 2004 [Page 10]
589 Internet-Draft LDAP Authentication Methods 5 December 2003
591 The client MUST check its understanding of the server's hostname
592 against the server's identity as presented in the server's
593 Certificate message in order to prevent man-in-the-middle attacks.
595 Matching is performed according to these rules:
597 - The client MUST use the server provided by the user (or other
598 trusted entity) as the value to compare against the server name
599 as expressed in the server's certificate. A hostname derived
600 from the user input is to be considered provided by the user
601 only if derived in a secure fashion (e.g., DNSSEC).
603 - If a subjectAltName extension of type dNSName is present in the
604 certificate, it SHOULD be used as the source of the server's
607 - Matching is case-insensitive.
609 - The "*" wildcard character is allowed. If present, it applies
610 only to the left-most name component.
612 For example, *.bar.com would match a.bar.com and b.bar.com, but
613 it would not match a.x.bar.com nor would it match bar.com. If
614 more than one identity of a given type is present in the
615 certificate (e.g. more than one dNSName name), a match in any
616 one of the set is considered acceptable.
618 If the hostname does not match the dNSName-based identity in the
619 certificate per the above check, user-oriented clients SHOULD either
620 notify the user (clients may give the user the opportunity to
621 continue with the connection in any case) or terminate the
622 connection and indicate that the server's identity is suspect.
623 Automated clients SHOULD close the connection, returning and/or
624 logging an error indicating that the server's identity is suspect.
626 Beyond the server identity checks described in this section, clients
627 SHOULD be prepared to do further checking to ensure that the server
628 is authorized to provide the service it is observed to provide. The
629 client may need to make use of local policy information in making
632 4.1.6. Refresh of Server Capabilities Information
634 Upon TLS session establishment, the client SHOULD discard or refresh
635 all information about the server it obtained prior to the initiation
636 of the TLS negotiation and not obtained through secure mechanisms.
637 This protects against active-intermediary attacks that may have
638 altered any server capabilities information retrieved prior to TLS
641 The server may advertise different capabilities after TLS
642 establishment. In particular, the value of supportedSASLMechanisms
643 may be different after TLS has been negotiated (specifically, the
646 Harrison Expires June 2004 [Page 11]
648 Internet-Draft LDAP Authentication Methods 5 December 2003
650 EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
651 after a TLS negotiation has been performed).
653 4.2. Effects of TLS on a Client's Authorization Identity
655 This section describes the effects on a client's authorization
656 identity brought about by establishing TLS on an LDAP association.
657 The default effects are described first, and next the facilities for
658 client assertion of authorization identity are discussed including
659 error conditions. Finally, the effects of closing the TLS connection
662 Authorization identities and related concepts are described in
665 4.2.1. TLS Connection Establishment Effects
667 The decision to keep or invalidate the established authentication
668 and authorization identities in place after TLS is negotiated is a
669 matter of local server policy. If a server chooses to invalidate
670 established authentication and authorization identities after TLS is
671 negotiated, it MUST reply to subsequent valid operation requests
672 until the next TLS closure or successful bind request with a
673 resultCode of strongAuthRequired to indicate that the client needs
674 to bind to reestablish its authentication. If the client attempts to
675 bind using a method the server is unwilling to support, it responds
676 to the with a resultCode of authMethodNotSupported (per [Protocol])
677 to indicate that a different authentication method should be used.
679 4.2.2. Client Assertion of Authorization Identity
681 After successfully establishing a TLS session, a client may request
682 that its credentials exchanged during the TLS establishment be
683 utilized to determine the client's authorization status. The client
684 accomplishes this via an LDAP Bind request specifying a SASL
685 mechanism of EXTERNAL [SASL]. See section 3.3.6 for additional
688 4.2.3. TLS Connection Closure Effects
690 The decision to keep or invalidate the established authentication
691 and authorization identities in place after TLS closure is a matter
692 of local server policy. If a server chooses to invalidate
693 established authentication and authorization identities after TLS is
694 negotiated, it MUST reply to subsequent valid operation requests
695 until the next TLS closure or successful bind request with a
696 resultCode of strongAuthRequired to indicate that the client needs
697 to bind to reestablish its authentication. If the client attempts to
698 bind using a method the server is unwilling to support, it responds
699 to the with a resultCode of authMethodNotSupported (per [Protocol])
700 to indicate that a different authentication method should be used.
702 5. Anonymous Authentication
705 Harrison Expires June 2004 [Page 12]
707 Internet-Draft LDAP Authentication Methods 5 December 2003
709 Directory operations that modify entries or access protected
710 attributes or entries generally require client authentication.
711 Clients that do not intend to perform any of these operations
712 typically use anonymous authentication.
714 LDAP implementations MUST support anonymous authentication, as
715 defined in section 5.1.
717 LDAP implementations MAY support anonymous authentication with TLS,
718 as defined in section 5.2.
720 While there may be access control restrictions to prevent access to
721 directory entries, an LDAP server SHOULD allow an anonymously-bound
722 client to retrieve the supportedSASLMechanisms attribute of the root
725 An LDAP server may use other information about the client provided
726 by the lower layers or external means to grant or deny access even
727 to anonymously authenticated clients.
729 5.1. Anonymous Authentication Procedure
731 Prior to successfully completing a Bind operation, the LDAP
732 association is anonymous. See section 3.1.
734 An LDAP client may also explicitly establish an anonymous
735 association by sending a Bind Request with the simple authentication
736 option and a password of zero length. A bind request where both the
737 name and password are of zero length is said to be an anonymous
738 bind. A bind request where the name, a DN, is of non-zero length,
739 and the password is of zero length is said to be an unauthenticated
740 bind. Both variations produce an anonymous association.
742 Unauthenticated binds can have significant security issues (see
743 section 10). Servers SHOULD by default reject unauthenticated bind
744 requests with a resultCode of invalidCredentials, and clients may
745 need to actively detect situations where they would make an
746 unauthenticated bind request.
748 5.2. Anonymous Authentication and TLS
750 An LDAP client may use the Start TLS operation (section 5) to
751 negotiate the use of [TLS] security. If the client has not bound
752 beforehand, then until the client uses the EXTERNAL SASL mechanism
753 to negotiate the recognition of the client's certificate, the client
754 is anonymously authenticated.
756 Recommendations on TLS ciphersuites are given in section 9.
758 An LDAP server which requests that clients provide their certificate
759 during TLS negotiation MAY use a local security policy to determine
760 whether to successfully complete TLS negotiation if the client did
761 not present a certificate which could be validated.
764 Harrison Expires June 2004 [Page 13]
766 Internet-Draft LDAP Authentication Methods 5 December 2003
768 6. Password-based Authentication
770 This section discusses various options for performing password-based
771 authentication to LDAP compliant servers and the environments
772 suitable for their use.
774 The transmission of passwords in the clear--typically for
775 authentication or modification--poses a significant security risk.
776 This risk can be avoided by using SASL bind [SASL] mechanisms that
777 do not transmit passwords in the clear and by negotiating transport
778 or session layer confidentiality services before transmitting
781 To mitigate the security risks associated with the use of passwords,
782 a server implementation MUST implement a configuration that at the
783 time of authentication or password modification, requires:
785 1) A Start TLS encryption layer has been successfully negotiated.
789 2) Some other confidentiality mechanism that protects the password
790 value from snooping has been provided.
794 3) The server returns a resultCode of confidentialityRequired for
795 the operation (i.e. simple bind with password value, SASL bind
796 transmitting a password value in the clear, add or modify
797 including a userPassword value, etc.), even if the password
800 6.1. Simple Authentication
802 The LDAP "simple" authentication choice is not suitable for
803 authentication in environments where there is no network or
804 transport layer confidentiality. LDAP implementations SHOULD support
805 authentication with the "simple" authentication choice when the
806 connection is protected against eavesdropping using TLS, as defined
807 in section 4. LDAP implementations SHOULD NOT support authentication
808 with the "simple" authentication choice unless the data on the
809 connection is protected using TLS or other data confidentiality and
810 data integrity protection.
812 6.2. Digest Authentication
814 LDAP servers that implement any authentication method or mechanism
815 (other than simple anonymous bind) MUST implement the SASL
816 DIGEST-MD5 mechanism [DIGEST-MD5]. This provides client
817 authentication with protection against passive eavesdropping
818 attacks, but does not provide protection against active intermediary
819 attacks. DIGEST-MD5 also provides data integrity and data
820 confidentiality capabilities.
823 Harrison Expires June 2004 [Page 14]
825 Internet-Draft LDAP Authentication Methods 5 December 2003
828 Support for subsequent authentication is OPTIONAL in clients and
831 Implementors must take care to ensure that they maintain the
832 semantics of the DIGEST-MD5 specification even when handling data
833 that has different semantics in the LDAP protocol.
834 For example, the SASL DIGEST-MD5 authentication mechanism utilizes
835 realm and username values ([DigestAuth section 2.1) which are
836 syntactically simple strings and semsantically simple realm and
837 username values. These values are not LDAP DNs, and there is no
838 requirement that they be represented or treated as such. Username
839 and realm values that look like LDAP DNs in form, e.g. <cn=bob,
840 dc=example,dc=com>, are syntactically allowed, however DIGEST-MD5
841 treats them as simple strings for comparison purposes. To illustrate
842 further, the two DNs <cn=Bob,dc=example,dc=com> (upper case "B") and
843 <cn=bob,dc=example,dc=com> (lower case "b") are equivalent when
844 being compared semantically as LDAP DNs because the cn attribute is
845 defined to be case insensitive, however the two values are not
846 equivalent if they represent username values in DIGEST-MD5 because
847 [SASLPrep] semantics are used by DIGEST-MD5.
849 6.3. simple authentication choice under TLS encryption
851 Following the negotiation of an appropriate TLS ciphersuite
852 providing connection confidentiality, a client MAY authenticate to a
853 directory that supports the simple authentication choice by
854 performing a simple bind operation
856 Simple authentication with TLS encryption protection is performed as
859 1. The client will use the Start TLS operation [Protocol] to
860 negotiate the use of TLS security [TLS] on the connection to
861 the LDAP server. The client need not have bound to the
862 directory beforehand.
864 For the subsequent authentication procedure to be performed
865 securely, the client and server MUST negotiate a ciphersuite
866 which contains a bulk encryption algorithm of appropriate
867 strength. Recommendations on cipher suites are given in
870 2. Following the successful completion of TLS negotiation, the
871 client MUST send an LDAP bind request with the version number
872 of 3, the name field containing a DN, and the simple
873 authentication choice, containing a password.
875 6.3.1. simple Authentication Choice
877 DSAs that map the DN sent in the bind request to a directory entry
878 with an associated set of one or more passwords will compare the
879 presented password to the set of passwords associated with that
880 entry. If the presented password matches any member of that set,
882 Harrison Expires June 2004 [Page 15]
884 Internet-Draft LDAP Authentication Methods 5 December 2003
886 then the server will respond with a success resultCode, otherwise
887 the server will respond with an invalidCredentials resultCode.
889 6.4. Other authentication choices with TLS
891 It is also possible, following the negotiation of TLS, to perform a
892 SASL authentication that does not involve the exchange of plaintext
893 reusable passwords. In this case the client and server need not
894 negotiate a ciphersuite that provides confidentiality if the only
895 service required is data integrity.
897 7. Certificate-based authentication
899 LDAP server implementations SHOULD support authentication via a
900 client certificate in TLS, as defined in section 7.1.
902 7.1. Certificate-based authentication with TLS
904 A user who has a public/private key pair in which the public key has
905 been signed by a Certification Authority may use this key pair to
906 authenticate to the directory server if the user's certificate is
907 requested by the server. The user's certificate subject field SHOULD
908 be the name of the user's directory entry, and the Certification
909 Authority that issued the user's certificate must be sufficiently
910 trusted by the directory server in order for the server to process
911 the certificate. The means by which servers validate certificate
912 paths is outside the scope of this document.
914 A server MAY support mappings for certificates in which the subject
915 field name is different from the name of the user's directory entry.
916 A server which supports mappings of names MUST be capable of being
917 configured to support certificates for which no mapping is required.
919 The client will use the Start TLS operation [Protocol] to negotiate
920 the use of TLS security [TLS] on the connection to the LDAP server.
921 The client need not have bound to the directory beforehand.
923 In the TLS negotiation, the server MUST request a certificate. The
924 client will provide its certificate to the server, and the server
925 MUST perform a private key-based encryption, proving it has the
926 private key associated with the certificate.
928 In deployments that require protection of sensitive data in transit,
929 the client and server MUST negotiate a ciphersuite that contains a
930 bulk encryption algorithm of appropriate strength. Recommendations
931 of cipher suites are given in section 9.
933 The server MUST verify that the client's certificate is valid. The
934 server will normally check that the certificate is issued by a known
935 certification authority (CA), and that none of the certificates on
936 the client's certificate chain are invalid or revoked. There are
937 several procedures by which the server can perform these checks.
941 Harrison Expires June 2004 [Page 16]
943 Internet-Draft LDAP Authentication Methods 5 December 2003
945 Following the successful completion of TLS negotiation, the client
946 will send an LDAP bind request with the SASL EXTERNAL mechanism.
948 8. LDAP Association State Transition Tables
950 To comprehensively diagram the various authentication and TLS states
951 through hich an LDAP association may pass, this section provides a
952 state transition table to represent a state diagram for the various
953 states through which an LDAP association may pass during the course
954 of its existence and the actions that cause these changes in state.
956 8.1. LDAP Association States
958 The following table lists the valid LDAP association states and
959 provides a description of each state. The ID for each state is used
960 in the state transition table in section 8.4.
963 -- --------------------------------------------------------------
965 no Authentication ID is associated with the LDAP connection
966 no Authorization ID is in force
968 Authentication ID = I
970 S3 Authenticated SASL EXTERNAL, implicit authorization ID
971 Authentication ID = J
973 S4 Authenticated SASL EXTERNAL, explicit authorization ID
974 Authentication ID = J
977 8.2. Actions that Affect LDAP Association State
979 The following table lists the actions that can affect the
980 authentication and authorization state of an LDAP association. The
981 ID for each action is used in the state transition table in section
985 -- --------------------------------------------------------------
986 A1 Client bind request fails
987 A2 Client successfully performs anonymous simple bind
988 A3 Client successfully performs unauthenticated simple bind
989 A4 Client successfully performs simple bind with name and
990 password OR SASL bind with any mechanism except EXTERNAL using
991 an authentication ID = I that maps to authorization ID X
992 A5 Client Binds SASL EXTERNAL with implicit assertion of
993 authorization ID (section 3.3.6.1)]. The current
994 authentication ID maps to authorization ID = Y.
995 A6 Client Binds SASL EXTERNAL with explicit assertion of
996 authorization ID = Z (section 3.3.6.2)]
999 Harrison Expires June 2004 [Page 17]
1001 Internet-Draft LDAP Authentication Methods 5 December 2003
1003 A7 Client abandons a bind operation, and server processes the
1005 A8 Client abandons a bind operation, and server does not process
1007 A9 Client Start TLS request fails
1008 A10 Client Start TLS request succeeds
1009 A11 Client or Server: graceful TLS closure ([Protocol] section
1012 8.3. Decisions Used in Making LDAP Association State Changes
1014 Certain changes in the authentication and authorization state of an
1015 LDAP association are only allowed if the server can affirmatively
1016 answer a question. These questions are applied as part of the
1017 criteria for allowing or disallowing a state transition in the state
1018 transition table in section 8.4.
1020 ID Decision Question
1021 -- --------------------------------------------------------------
1022 D1 Are lower-layer credentials available?
1023 D2 Can lower-layer credentials for Auth ID "K" be mapped asserted
1026 8.4. LDAP Association State Transition Table
1028 The LDAP Association table below lists the valid authentication and
1029 authorization states for an LDAP association and the actions that
1030 could affect them. For any given row in the table, the Current State
1031 column gives the state of an LDAP association, the Action column
1032 gives an action that could affect the state of an LDAP assocation,
1033 and the Next State column gives the resulting state of an LDAP
1034 association after the action occurs.
1036 S1, the initial state for the state machine described in this table,
1037 is the authentication state when an LDAP connection is initially
1041 State Action State Comment
1042 ------- ------- ----- ---------------------------------------
1043 Any A1 S1 [Protocol] section 4.2.1
1046 Any A4 S2 Sections 6.1, 6.2
1047 Any A5, S1 Failed bind, section 3.3.6
1051 Any A6, S1 failed bind, section 3.3.6
1053 Any A6, S1 failed bind, section 3.3.6.2
1057 Harrison Expires June 2004 [Page 18]
1059 Internet-Draft LDAP Authentication Methods 5 December 2003
1064 Any A7 S1 [Protocol] section 4.2.1. Clients
1065 cannot detect this state.
1066 Any A8 no [Protocol] section 4.2.1. Clients
1067 change cannot detect this state.
1068 Any A9 no [Protocol] section 4.13.2.2
1070 Any A10 no Section 4.2.1
1072 Any A11 S1 Section 4.2.3
1076 A client or server that supports TLS MUST support
1077 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and MAY support other ciphersuites
1078 offering equivalent or better protection.
1080 Several issues should be considered when selecting TLS ciphersuites
1081 that are appropriate for use in a given circumstance. These issues
1082 include the following:
1084 - The ciphersuite's ability to provide adequate confidentiality
1085 protection for passwords and other data sent over the LDAP
1086 connection. Client and server implementers should recognize that
1087 some TLS ciphersuites provide no confidentiality protection
1088 while other ciphersuites that do provide confidentiality
1089 protection may be vulnerable to being cracked using brute force
1090 methods, especially in light of ever-increasing CPU speeds that
1091 reduce the time needed to successfully mount such attacks.
1093 Client and server implementers SHOULD carefully consider the
1094 value of the password or data being protected versus the level
1095 of confidentially protection provided by the ciphersuite to
1096 ensure that the level of protection afforded by the ciphersuite
1099 - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
1100 middle attacks. Ciphersuites vulnerable to man-in-the-middle
1101 attacks SHOULD NOT be used to protect passwords or sensitive
1102 data, unless the network configuration is such that the danger
1103 of a man-in-the-middle attack is tolerable.
1105 9.1. TLS Ciphersuites Recommendations
1107 As of the writing of this document, the following recommendations
1108 regarding TLS ciphersuites are applicable. Because circumstances are
1109 constantly changing, this list must not be considered exhaustive,
1110 but is hoped that it will serve as a useful starting point for
1115 Harrison Expires June 2004 [Page 19]
1117 Internet-Draft LDAP Authentication Methods 5 December 2003
1119 The following ciphersuites defined in [TLS] MUST NOT be used for
1120 confidentiality protection of passwords or data:
1122 TLS_NULL_WITH_NULL_NULL
1123 TLS_RSA_WITH_NULL_MD5
1124 TLS_RSA_WITH_NULL_SHA
1126 The following ciphersuites defined in [TLS] can be cracked easily
1127 (less than a day of CPU time on a standard CPU in 2000) and are NOT
1128 RECOMMENDED for use in confidentiality protection of passwords or
1131 TLS_RSA_EXPORT_WITH_RC4_40_MD5
1132 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
1133 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
1134 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
1135 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
1136 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
1137 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
1138 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
1139 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
1141 The following ciphersuites are vulnerable to man-in-the-middle
1144 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
1145 TLS_DH_anon_WITH_RC4_128_MD5
1146 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
1147 TLS_DH_anon_WITH_DES_CBC_SHA
1148 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
1152 10. Security Considerations
1154 Security issues are discussed throughout this memo; the
1155 (unsurprising) conclusion is that mandatory security is important
1156 and that session confidentiality protection is required when
1157 snooping is a problem.
1159 Servers are encouraged to prevent modifications by anonymous users.
1161 Servers can minimize denial of service attacks by timing out idle
1162 connections, and returning the unwillingToPerform resultCode rather
1163 than performing computationally expensive operations requested by
1164 unauthorized clients.
1166 The use of cleartext passwords and other unprotected authentication
1167 credentials is strongly discouraged over open networks when the
1168 underlying transport service cannot guarantee confidentiality.
1170 Operational experience shows that clients can (and frequently do)
1171 misuse unauthenticated bind (see section 5.1). For example, a
1172 client program might make a decision to grant access to non-
1174 Harrison Expires June 2004 [Page 20]
1176 Internet-Draft LDAP Authentication Methods 5 December 2003
1178 directory information on the basis of completing a successful bind
1179 operation. Some LDAP server implementations will return a success
1180 response to an unauthenticated bind thus leaving the client with the
1181 impression that the server has successfully authenticated the
1182 identity represented by the user name, when in effect, an anonymous
1183 LDAP association has been created. Clients that use the results from
1184 a simple bind operation to make authorization decisions should
1185 actively detect unauthenticated bind requests (via the empty
1186 password value) and react appropriately.
1188 Access control SHOULD always be applied when reading sensitive
1189 information or updating directory information.
1191 A connection on which the client has not performed the Start TLS
1192 operation or negotiated a suitable SASL mechanism for connection
1193 integrity and encryption services is subject to man-in-the-middle
1194 attacks to view and modify information in transit.
1196 10.1. Start TLS Security Considerations
1198 The goals of using the TLS protocol with LDAP are to ensure
1199 connection confidentiality and integrity, and to optionally provide
1200 for authentication. [TLS] expressly provides these capabilities.
1202 All security gained via use of the Start TLS operation is gained by
1203 the use of TLS itself. The Start TLS operation, on its own, does not
1204 provide any additional security.
1206 Once established, TLS only provides for and ensures confidentiality
1207 and integrity of the operations and data in transit over the LDAP
1208 association--and only if the implementations on the client and
1209 server support and negotiate it. The use of TLS does not provide or
1210 ensure for confidentiality and/or non-repudiation of the data housed
1211 by an LDAP-based directory server. Nor does it secure the data from
1212 inspection by the server administrators.
1214 The level of security provided though the use of TLS depends
1215 directly on both the quality of the TLS implementation used and the
1216 style of usage of that implementation. Additionally, an active-
1217 intermediary attacker can remove the Start TLS extended operation
1218 from the supportedExtension attribute of the root DSE. Therefore,
1219 both parties SHOULD independently ascertain and consent to the
1220 security level achieved once TLS is established and before beginning
1221 use of the TLS connection. For example, the security level of the
1222 TLS connection might have been negotiated down to plaintext.
1224 Clients SHOULD either warn the user when the security level achieved
1225 does not provide confidentiality and/or integrity protection, or be
1226 configurable to refuse to proceed without an acceptable level of
1229 Client and server implementors SHOULD take measures to ensure proper
1230 protection of credentials and other confidential data where such
1231 measures are not otherwise provided by the TLS implementation.
1233 Harrison Expires June 2004 [Page 21]
1235 Internet-Draft LDAP Authentication Methods 5 December 2003
1238 Server implementors SHOULD allow for server administrators to elect
1239 whether and when connection confidentiality and/or integrity is
1240 required, as well as elect whether and when client authentication
1241 via TLS is required.
1243 Additional security considerations relating to the EXTERNAL
1244 mechanism to negotiate TLS can be found in [SASL] and [TLS].
1246 11. IANA Considerations
1248 The following IANA considerations apply to this document:
1250 Please update the GSSAPI service name registry to point to [Roadmap]
1257 This document combines information originally contained in RFC 2829
1258 and RFC 2830. The editor acknowledges the work of Harald Tveit
1259 Alvestrand, Jeff Hodges, Tim Howes, Steve Kille, RL "Bob" Morgan ,
1260 and Mark Wahl, each of whom authored one or more of these documents.
1262 This document is based upon input of the IETF LDAP Revision working
1263 group. The contributions and suggestions made by its members in
1264 shaping the contents and technical accuracy of this document is
1265 greatly appreciated.
1267 Normative References
1269 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
1270 Requirement Levels", BCP 14, RFC 2119, March 1997.
1272 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1273 Specifications: ABNF", RFC 2234, November 1997.
1275 [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest
1276 Authentication as a SASL Mechanism", draft-ietf-sasl-rfc2831bis-
1277 xx.txt, a work in progress.
1279 [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String Representation of
1280 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in
1283 [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory Information
1284 Models", draft-ietf-ldapbis-models-xx.txt, a work in progress.
1286 [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
1287 ldapbis-protocol-xx.txt, a work in progress.
1289 [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
1290 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
1292 Harrison Expires June 2004 [Page 22]
1294 Internet-Draft LDAP Authentication Methods 5 December 2003
1297 [SASL] Melnikov, A. (editor), "Simple Authentication and Security
1298 Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in
1301 [SASLPrep] Zeilenga, K., "Stringprep profile for user names and
1302 passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
1305 [StringPrep] Hoffman P. and M. Blanchet, "Preparation of
1306 Internationalized Strings ('stringprep')", draft-hoffman-
1307 rfc3454bis-xx.txt, a work in progress.
1309 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
1310 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
1312 [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
1313 draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
1315 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
1316 RFC 3629, STD 63, November 2003.
1318 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
1319 3.2.0" is defined by "The Unicode Standard, Version 3.0"
1320 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as
1321 amended by the "Unicode Standard Annex #27: Unicode 3.1"
1322 (http://www.unicode.org/reports/tr27/) and by the öUnicode
1323 Standard Annex #28: Unicode 3.2"
1324 (http://www.unicode.org/reports/tr28/).
1326 Informative References
1328 [ANONYMOUS] Zeilenga, K.,"Anonymous SASL Mechanism", draft-zeilenga-
1329 sasl-anon-xx.txt, a work in progress.
1331 [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-sasl-
1332 plain-xx.txt, a work in progress.
1334 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
1337 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
1338 Internet Protocol", RFC 2401, November 1998.
1345 1800 S. Novell Place
1348 roger_harrison@novell.com
1351 Harrison Expires June 2004 [Page 23]
1353 Internet-Draft LDAP Authentication Methods 5 December 2003
1355 Appendix A. Example Deployment Scenarios
1357 The following scenarios are typical for LDAP directories on the
1358 Internet, and have different security requirements. (In the
1359 following discussion, "sensitive data" refers to information whose
1360 disclosure, alteration, destruction, or loss would adversely affect
1361 the interests or business of its owner or user. Also note that there
1362 may be data that is protected but not sensitive.) This is not
1363 intended to be a comprehensive list; other scenarios are possible,
1364 especially on physically protected networks.
1366 (1) A read-only directory, containing no sensitive data, accessible
1367 to "anyone", and TCP connection hijacking or IP spoofing is not
1368 a problem. Anonymous authentication, described in section 7, is
1369 suitable for this type of deployment, and requires no additional
1370 security functions except administrative service limits.
1372 (2) A read-only directory containing no sensitive data; read access
1373 is granted based on identity. TCP connection hijacking is not
1374 currently a problem. This scenario requires data confidentiality
1375 for sensitive authentication information AND data integrity for
1376 all authentication information.
1378 (3) A read-only directory containing no sensitive data; and the
1379 client needs to ensure the identity of the directory server and
1380 that the directory data is not modified while being returned
1381 from the server. A data origin authentication service AND data
1382 integrity service are required.
1384 (4) A read-write directory, containing no sensitive data; read
1385 access is available to "anyone", update access to properly
1386 authorized persons. TCP connection hijacking is not currently a
1387 problem. This scenario requires data confidentiality for
1388 sensitive authentication information AND data integrity for all
1389 authentication information.
1391 (5) A directory containing sensitive data. This scenario requires
1392 data confidentiality protection AND secure authentication.
1394 Appendix B. Authentication and Authorization: Definitions and Concepts
1396 This appendix defines basic terms, concepts, and interrelationships
1397 regarding authentication, authorization, credentials, and identity.
1398 These concepts are used in describing how various security
1399 approaches are utilized in client authentication and authorization.
1401 B.1. Access Control Policy
1403 An access control policy is a set of rules defining the protection
1404 of resources, generally in terms of the capabilities of persons or
1405 other entities accessing those resources. A common expression of an
1406 access control policy is an access control list. Security objects
1407 and mechanisms, such as those described here, enable the expression
1408 of access control policies and their enforcement. Access control
1410 Harrison Expires June 2004 [Page 24]
1412 Internet-Draft LDAP Authentication Methods 5 December 2003
1414 policies are typically expressed in terms of access control factors
1417 B.2. Access Control Factors
1419 A request, when it is being processed by a server, may be associated
1420 with a wide variety of security-related factors (section 4.2 of
1421 [Protocol]). The server uses these factors to determine whether and
1422 how to process the request. These are called access control factors
1423 (ACFs). They might include source IP address, encryption strength,
1424 the type of operation being requested, time of day, etc. Some
1425 factors may be specific to the request itself, others may be
1426 associated with the connection via which the request is transmitted,
1427 others (e.g. time of day) may be "environmental".
1429 Access control policies are expressed in terms of access control
1430 factors. E.g., a request having ACFs i,j,k can perform operation Y
1431 on resource Z. The set of ACFs that a server makes available for
1432 such expressions is implementation-specific.
1434 B.3. Authentication, Credentials, Identity
1436 Authentication credentials are the evidence supplied by one party to
1437 another, asserting the identity of the supplying party (e.g. a user)
1438 who is attempting to establish an association with the other party
1439 (typically a server). Authentication is the process of generating,
1440 transmitting, and verifying these credentials and thus the identity
1441 they assert. An authentication identity is the name presented in a
1444 There are many forms of authentication credentials -- the form used
1445 depends upon the particular authentication mechanism negotiated by
1446 the parties. For example: X.509 certificates, Kerberos tickets,
1447 simple identity and password pairs. Note that an authentication
1448 mechanism may constrain the form of authentication identities used
1451 B.4. Authorization Identity
1453 An authorization identity is one kind of access control factor. It
1454 is the name of the user or other entity that requests that
1455 operations be performed. Access control policies are often expressed
1456 in terms of authorization identities; e.g., entity X can perform
1457 operation Y on resource Z.
1459 The authorization identity bound to an association is often exactly
1460 the same as the authentication identity presented by the client, but
1461 it may be different. SASL allows clients to specify an authorization
1462 identity distinct from the authentication identity asserted by the
1463 client's credentials. This permits agents such as proxy servers to
1464 authenticate using their own credentials, yet request the access
1465 privileges of the identity for which they are proxying [SASL]. Also,
1466 the form of authentication identity supplied by a service like TLS
1467 may not correspond to the authorization identities used to express a
1469 Harrison Expires June 2004 [Page 25]
1471 Internet-Draft LDAP Authentication Methods 5 December 2003
1473 server's access control policy, requiring a server-specific mapping
1474 to be done. The method by which a server composes and validates an
1475 authorization identity from the authentication credentials supplied
1476 by a client is implementation-specific.
1478 Appendix C. RFC 2829 Change History
1480 This appendix lists the changes made to the text of RFC 2829 in
1481 preparing this document.
1483 C.0. General Editorial Changes
1486 - Changed other instances of the term LDAP to LDAP where v3 of the
1487 protocol is implied. Also made all references to LDAP use the
1490 - Miscellaneous grammatical changes to improve readability.
1492 - Made capitalization in section headings consistent.
1496 - Changed title to reflect inclusion of material from RFC 2830 and
1499 C.1. Changes to Section 1
1503 - Moved conventions used in document to a separate section.
1505 C.2. Changes to Section 2
1509 - Moved section to an appendix.
1511 C.3. Changes to Section 3
1515 - Moved section to an appendix.
1517 C.4 Changes to Section 4
1521 - Changed "Distinguished Name" to "LDAP distinguished name".
1523 C.5. Changes to Section 5
1528 Harrison Expires June 2004 [Page 26]
1530 Internet-Draft LDAP Authentication Methods 5 December 2003
1532 - Added the following sentence: "Servers SHOULD NOT allow clients
1533 with anonymous authentication to modify directory entries or
1534 access sensitive information in directory entries."
1536 C.5.1. Changes to Section 5.1
1540 - Replaced the text describing the procedure for performing an
1541 anonymous bind (protocol) with a reference to section 4.2 of RFC
1542 2251 (the protocol spec).
1546 - Brought text describing procedure for performing an anonymous
1547 bind from section 4.2 of RFC 2251 bis. This text will be
1548 removed from the draft standard version of that document.
1550 C.6. Changes to Section 6.
1554 Reorganized text in section 6.1 as follows:
1556 1. Added a new section (6.1) titled "Simple Authentication" and
1557 moved one of two introductory paragraphs for section 6 into
1558 section 6.1. Added sentences to the paragraph indicating:
1560 a. simple authentication is not suitable for environments where
1561 confidentiality is not available.
1563 b. LDAP implementations SHOULD NOT support simple
1564 authentication unless confidentiality and data integrity
1565 mechanisms are in force.
1567 2. Moved first paragraph of section 6 (beginning with "LDAP
1568 implementations MUST support authentication with a password...")
1569 to section on Digest Authentication (Now section 6.2).
1571 C.6.1. Changes to Section 6.1.
1573 Version -00 Renamed section to 6.2
1575 - Added sentence from original section 6 indicating that the
1576 DIGEST-MD5 SASL mechanism is required for all conforming LDAP
1579 C.6.2. Changes to Section 6.2
1583 - Renamed section to 6.3
1587 Harrison Expires June 2004 [Page 27]
1589 Internet-Draft LDAP Authentication Methods 5 December 2003
1591 - Reworded first paragraph to remove reference to user and the
1592 userPassword password attribute Made the first paragraph more
1593 general by simply saying that if a directory supports simple
1594 authentication that the simple bind operation MAY performed
1595 following negotiation of a TLS ciphersuite that supports
1598 - Replaced "the name of the user's entry" with "a DN" since not
1599 all bind operations are performed on behalf of a "user."
1601 - Added Section 6.3.1 heading just prior to paragraph 5.
1603 - Paragraph 5: replaced "The server" with "DSAs that map the DN
1604 sent in the bind request to a directory entry with a
1605 userPassword attribute."
1607 C.6.3. Changes to section 6.3.
1611 - Renamed to section 6.4.
1613 C.7. Changes to section 7.
1617 C.7.1. Changes to section 7.1.
1621 - Clarified the entity issuing a certificate by moving the phrase
1622 "to have issued the certificate" immediately after
1623 "Certification Authority."
1625 C.8. Changes to section 8.
1629 - Removed the first paragraph because simple authentication is
1630 covered explicitly in section 6.
1632 - Added section 8.1. heading just prior to second paragraph.
1634 - Added section 8.2. heading just prior to third paragraph.
1636 - Added section 8.3. heading just prior to fourth paragraph.
1640 - Moved entire section 8 of RFC 2829 into section 3.4 (Using SASL
1641 for Other Security Services) to bring material on SASL
1642 mechanisms together into one location.
1644 C.9. Changes to section 9.
1646 Harrison Expires June 2004 [Page 28]
1648 Internet-Draft LDAP Authentication Methods 5 December 2003
1653 - Paragraph 2: changed "EXTERNAL mechanism" to "EXTERNAL SASL
1656 - Added section 9.1. heading.
1658 - Modified a comment in the ABNF from "unspecified userid" to
1659 "unspecified authz id".
1661 - Deleted sentence, "A utf8string is defined to be the UTF-8
1662 encoding of one or more ISO 10646 characters," because it is
1665 - Added section 9.1.1. heading.
1667 - Added section 9.1.2. heading.
1671 - Moved entire section 9 to become section 3.5 so that it would be
1672 with other SASL material.
1674 C.10. Changes to Section 10.
1678 - Updated reference to cracking from a week of CPU time in 1997 to
1679 be a day of CPU time in 2000.
1681 - Added text: "These ciphersuites are NOT RECOMMENDED for use...
1682 and server implementers SHOULD" to sentence just prior the
1683 second list of ciphersuites.
1685 - Added text: "and MAY support other ciphersuites offering
1686 equivalent or better protection," to the last paragraph of the
1689 C.11. Changes to Section 11.
1693 - Moved to section 3.6 to be with other SASL material.
1695 C.12. Changes to Section 12.
1699 - Inserted new section 12 that specifies when SASL protections
1700 begin following SASL negotiation, etc. The original section 12
1701 is renumbered to become section 13.
1705 Harrison Expires June 2004 [Page 29]
1707 Internet-Draft LDAP Authentication Methods 5 December 2003
1710 - Moved to section 3.7 to be with other SASL material.
1712 C.13. Changes to Section 13 (original section 12).
1716 Appendix D. RFC 2830 Change History
1718 This appendix lists the changes made to the text of RFC 2830 in
1719 preparing this document.
1721 D.0. General Editorial Changes
1723 - Material showing the PDUs for the Start TLS response was broken
1724 out into a new section.
1726 - The wording of the definition of the Start TLS request and Start
1727 TLS response was changed to make them parallel. NO changes were
1728 made to the ASN.1 definition or the associated values of the
1731 - A separate section heading for graceful TLS closure was added
1732 for parallelism with section on abrupt TLS closure.
1734 Appendix E. RFC 2251 Change History
1736 This appendix lists the changes made to the text of RFC 2251 in
1737 preparing this document.
1739 E.0. General Editorial Changes
1741 - All material from section 4.2 of RFC 2251 was moved into this
1744 - A new section was created for the Bind Request
1746 - Section 4.2.1 of RFC 2251 (Sequencing Bind Request) was moved
1747 after the section on the Bind Response for parallelism with the
1748 presentation of the Start TLS operations. The section was also
1749 subdivided to explicitly call out the various effects being
1750 described within it.
1752 - All SASL profile information from RFC 2829 was brought within
1753 the discussion of the Bind operation (primarily sections 4.4 -
1756 Appendix F. Change History to Combined Document
1758 F.1. Changes for draft-ldap-bis-authmeth-02
1764 Harrison Expires June 2004 [Page 30]
1766 Internet-Draft LDAP Authentication Methods 5 December 2003
1768 - Added references to other LDAP standard documents, to sections
1769 within the document, and fixed broken references.
1771 - General editorial changes--punctuation, spelling, formatting,
1776 - Added glossary of terms and added sub-section headings
1780 - Clarified security mechanisms 3, 4, & 5 and brought language in
1781 line with IETF security glossary.
1785 - Brought language in requirement (3) in line with security
1788 - Clarified that information fetched prior to initiation of TLS
1789 negotiation must be discarded
1791 -Clarified that information fetched prior to initiation of SASL
1792 negotiation must be discarded
1794 - Rewrote paragraph on SASL negotiation requirements to clarify
1799 - Added stipulation that sasl choice allows for any SASL mechanism
1800 not prohibited by this document. (Resolved conflict between this
1801 statement and one that prohibited use of ANONYMOUS and PLAIN
1806 - Added a.x.bar.com to wildcard matching example on hostname
1811 - Added LDAP Association State Transition Tables to show the
1812 various states through which an LDAP association may pass along
1813 with the actions and decisions required to traverse from state
1818 - Brought security terminology in line with IETF security glossary
1819 throughout the appendix.
1821 F.2. Changes for draft-ldap-bis-authmeth-03
1823 Harrison Expires June 2004 [Page 31]
1825 Internet-Draft LDAP Authentication Methods 5 December 2003
1830 - Added introductory notes and changed title of document and
1831 references to conform to WG chair suggestions for the overall
1832 technical specification.
1834 - Several issues--G.13, G.14, G.16, G.17--were resolved without
1835 requiring changes to the document.
1839 - Removed reference to /etc/passwd file and associated text.
1843 - Removed sections 4.1, 4.2 and parts of section 4.3. This
1844 information was being duplicated in the protocol specification
1845 and will now reside there permanently.
1848 - changed words, "not recommended" to "strongly discouraged"
1852 - Based on ldapbis WG discussion at IETF52 two sentences were
1853 added indicating that clients SHOULD NOT send a DN value when
1854 binding with the sasl choice and servers SHALL ignore any value
1855 received in this circumstance.
1860 - Generalized the language of this section to not refer to any
1861 specific password attribute or to refer to the directory entry
1866 - Added security consideration regarding misuse of unauthenticated
1869 - Added security consideration requiring access control to be
1870 applied only to authenticated users and recommending it be
1871 applied when reading sensitive information or updating directory
1875 F.3. Changes for draft-ldap-bis-authmeth-04
1879 - Changed references to use [RFCnnnn] format wherever possible.
1880 (References to works in progress still use [name] format.)
1882 Harrison Expires June 2004 [Page 32]
1884 Internet-Draft LDAP Authentication Methods 5 December 2003
1886 - Various edits to correct typos and bring field names, etc. in
1887 line with specification in [Protocol] draft.
1889 - Several issues--G.13, G.14, G.16, G.17--were resolved without
1890 requiring changes to the document.
1894 - Changed ABNF grammar to use productions that are like those in
1899 - Removed sections 5.1, 5.2, and 5.4 that will be added to
1900 [Protocol]. Renumbered sections to accommodate this change.
1905 - Reviewed LDAP Association State table for completeness and
1906 accuracy. Renumbered actions A3, A4, and A5 to be A5, A3, and A4
1907 respectively. Re-ordered several lines in the table to ensure
1908 that actions are in ascending order (makes analyzing the table
1909 much more logical). Added action A2 to several states where it
1910 was missing and valid. Added actions A7 and A8 placeholders to
1911 states S1, S2, S4 and S5 pending resolution of issue G.28.
1915 - Modified security consideration (originally added in -03)
1916 requiring access control to be applied only to authenticated
1917 users. This seems nonsensical because anonymous users may have
1918 access control applied to limit permissible actions.
1922 - Verified all normative references and moved informative
1923 references to a new section 14.
1925 F.4. Changes for draft-ldap-bis-authmeth-05
1929 - General editory changes to fix punctuation, spelling, line
1931 - Verified and updated intra- and inter-document references
1933 - Document-wide review for proper usage of RFC 2119 keywords with
1934 several changes to correct improper usage.
1937 - Updated to match current contents of documents. This was needed
1938 due to movement of material on Bind and Start TLS operations to
1939 [Protocol] in this revision.
1941 Harrison Expires June 2004 [Page 33]
1943 Internet-Draft LDAP Authentication Methods 5 December 2003
1948 - Renamed section to "Rationale for LDAP Security Mechanisms" and
1949 removed text that did not support this theme. Part of the
1950 motivation for this change was to remove the implication of the
1951 previous section title, "Required Security Mechanisms", and
1952 other text found in the section that everything in the section
1955 - Information from several removed paragraphs that describe
1956 deployment scenarios will be added Appendix A in the next
1957 revision of the draft.
1960 - Paragraph beginning, " If TLS is negotiated, the client MUST
1961 discard all information..." was moved to section 5.1.7 and
1962 integrated with related material there.
1964 - Paragraph beginning, "If a SASL security layer is negotiated..."
1965 was moved to section 4.2
1969 - Changed wording of first paragraph to clarify meaning.
1972 - Added paragraph from section 3 of -04 beginning, "If a SASL
1973 security layer is negotiated..."
1976 - Renamed to "Other SASL Mechanisms" and completely rewrote the
1977 section (one sentence) to generalize the treatment of SASL
1978 mechanisms not explicitly mentioned in this document.
1982 - Added paragraph beginning, "The dnAuthzID choice allows client
1983 applications..." to clarify whether DN form authorization
1984 identities have to also have a corresponding directory entry.
1985 This change was based on editor's perception of WG consensus.
1987 - Made minor clarifying edits in the paragraph beginning, "The
1988 uAuthzID choice allows for compatibility..."
1992 - Made minor clarifying edits in the last paragraph of the
2000 Harrison Expires June 2004 [Page 34]
2002 Internet-Draft LDAP Authentication Methods 5 December 2003
2004 - Wording from section 3 paragraph beginning " If TLS is
2005 negotiated, the client MUST discard all information..." was
2006 moved to this section and integrated with existing text.
2010 - Changed usage of "TLS connection" to "TLS session" throughout.
2012 - Removed empty section 5.2.1 and renumbered sections it had
2013 previously contained.
2017 - Added introductory paragraph at beginning of section.
2021 - Changed term "data privacy" to "data confidentiality" to be
2022 consistent with usage in rest of document.
2026 - Changed first paragraph to require implementations that
2027 implement *password-based* authentication to implement and
2028 support DIGEST-MD5 SASL authentication.
2032 - First paragraph: changed "session encryption" to "session
2033 confidentiality protection" to be consistent with usage in rest
2038 - Began changes to incorporate information on deployment scenarios
2039 removed from section 3.
2041 F.5. Changes for draft-ldap-bis-authmeth-06
2046 - Combined Section 2 (Introduction) and Section 3 (Motivation) and
2047 moved Introduction to section 1. All following sections numbers
2048 were decremented by one as result.
2050 - Edits to fix typos, I-D nits, etc.
2052 - Opened several new issues in Appendix G based on feedback from
2053 WG. Some of these have been resolved. Others require further
2059 Harrison Expires June 2004 [Page 35]
2061 Internet-Draft LDAP Authentication Methods 5 December 2003
2063 - Added additional example of spoofing under threat (7).
2067 - Changed definition of "LDAP association" and added terms,
2068 "connection" and "TLS connection" to bring usage in line with
2073 - Clarified sentence stating that the client MUST NOT use derived
2078 - Began edits to LDAP Association state table to clarify meaning
2079 of various states and actions.
2081 - Added action A9 to cover abandoned bind operation and added
2082 appropriate transitions to the state transition table to
2087 - Replaced first paragraph to clarify that the "DIGEST-MD5" SASL
2088 mechanism is required to implement.
2092 - Rewrote the section to make the advice more applicable over the
2093 long term, i.e. more "timeless." The intent of content in the
2094 original section was preserved.
2098 - Added a clarifying example to the consideration regarding misuse
2099 of unauthenticated access.
2101 F.6. Changes for draft-ldap-bis-authmeth-07
2106 - Updated external and internal references to accommodate changes
2109 - Opened several new issues in Appendix G based on feedback from
2110 WG. Some of these have been resolved. Others require further
2115 - Rewrote much of section 3.3 to meet the SASL profile
2116 requirements of draft-ietf-sasl-rfc2222bis-xx.txt section 5.
2118 Harrison Expires June 2004 [Page 36]
2120 Internet-Draft LDAP Authentication Methods 5 December 2003
2123 - Changed treatement of SASL ANONYMOUS and PLAIN mechanisms to
2124 bring in line with WG consensus.
2128 - Note to implementers in section 4.1.1 based on operational
2131 - Clarification on client continuing by performing a Start TLS
2132 with TLS already established in section 4.1.4.
2134 - Moved verification of mapping of client's authentication ID to
2135 asserted authorization ID to apply only to explicit assertion.
2136 The local policy in place for implicit assertion is adequate.
2140 - Removed most of section 7.2 as the information is now covered
2141 adequately via the new SASL profile in section 3.3. Added note
2142 to implementors regarding the treatment of username and realm
2143 values in DIGEST-MD5.
2145 - Section 7.3. Minor clarifications in wording.
2147 - Section 7.3.1. Clarification that a match of the presented value
2148 to any member of the set of stored passwords constitutes a
2149 successful authentication.
2151 F.6. Changes for draft-ldap-bis-authmeth-08
2156 - Changed usage from LDAPv3 to LDAP for usage consistency across
2157 LDAP technical specification.
2159 - Fixed a number of usage nits for consistency and to bring doc in
2160 conformance with publication guidelines.
2164 - Significant cleanup and rewording of abstract based on WG
2169 - New definition of user.
2173 - Added 1.5 sentences at end of introductory paragraph indicating
2174 the effect of the Bind op on the LDAP association.
2177 Harrison Expires June 2004 [Page 37]
2179 Internet-Draft LDAP Authentication Methods 5 December 2003
2183 - Retitled section and clarified wording
2187 - Clarified that simple authentication choice provides three types
2188 of authentication: anonymous, unauthenticated, and simple
2193 - New wording clarifying when negotiated security mechanisms take
2198 - Changed requirement to discard information about server fetched
2199 prior to SASL negotiation from MUST to SHOULD to allow for
2200 information obtained through secure mechanisms.
2204 - Simplified wording of first paragraph based on suggestion from
2209 - Minor clarifications in wording.
2213 - Minor clarifications in wording in first sentence.
2214 - Explicitly called out that the DN value in the dnAuthzID form is
2215 to be matched using DN matching rules.
2216 - Called out that the uAuthzID MUST be prepared using SASLprep
2217 rules before being compared.
2218 - Clarified requirement on assuming global uniqueness by changing
2219 a "generally... MUST" wording to "SHOULD".
2223 - Simplified wording describing conditions when Start TLS cannot
2225 - Simplified wording in note to implementers regarding race
2226 condition with outstanding LDAP operations on connection.
2230 - Removed section and moved relevant text to section 4.2.2.
2234 - Renumbered to 4.1.5.
2236 Harrison Expires June 2004 [Page 38]
2238 Internet-Draft LDAP Authentication Methods 5 December 2003
2240 - Updated server identity check rules for server's name based on
2245 - Renumbered to 4.1.6
2246 - Changed requirement to discard information about server fetched
2247 prior to TLS negotion from MUST to SHOULD to allow for
2248 information obtained through secure mechanisms.
2252 - Clarified wording.
2253 - Added definition of anonymous and unauthenticated binds.
2257 - Added security consideration (moved from elsewhere) discouraging
2258 use of cleartext passwords on unprotected communication
2263 - Added an IANA consideration to update GSSAPI service name
2264 registry to point to [Roadmap] and [Authmeth]
2266 F.7. Changes for draft-ldap-bis-authmeth-09
2271 - Updated section references within document
2272 - Changed reference tags to match other docs in LDAP TS
2273 - Used non-quoted names for all SAL mechanisms
2277 - Inspected keyword usage and removed several improper usages.
2279 - Removed sentence saying DIGEST-MD5 is LDAP's mandatory-to-
2280 implement mechanism. This is covered elsewhere in document.
2282 - Moved section 5, authentication state table, of -08 draft to
2283 section 8 of -09 and completely rewrote it.
2287 - Reworded sentence beginning, "It is also desireable to allow
2288 authentication methods to carry identities based on existingù
2289 non-LDAP DNùforms..."
2290 - Clarified relationship of this document to other documents in
2295 Harrison Expires June 2004 [Page 39]
2297 Internet-Draft LDAP Authentication Methods 5 December 2003
2300 - Removed paragraph beginning,"If the client is configured to
2301 support multiple SASL mechanisms..." because the actions
2302 specified in the paragraph do not provide the protections
2303 indicated. Added a new paragraph indicating that clients and
2304 server should allow specification of acceptable mechanisms and
2305 only allow those mechanisms to be used.
2307 - Clarified independent behavior when TLS and SASL security layers
2308 are both in force (e.g. one being removed doesn't affect the
2313 - Moved most of section 4.2.2, Client Assertion of Authorization
2314 Identity, to sections 3.3.6, 3.3.6.1, and 3.3.6.2.
2318 - Moved some normative comments into text body.
2322 - Non success resultCode values are valid if server is *unwilling*
2323 or unable to negotiate TLS.
2327 - Rewrote entire section based on WG feedback.
2331 - Moved most of this section to 3.3.6 for better document flow.
2335 - Rewrote entire section based on WG feedback.
2339 - Moved imperative language regarding unauthenticated access from
2340 security considerations to here.
2344 - Added several paragraphs regarding the risks of transmitting
2345 passwords in the clear and requiring server implementations to
2346 provide a specific configuration that reduces these risks.
2350 - Added sentence describing protections provided by DIGEST-MD5
2352 - Changed DNs in exmple to be dc=example,dc=com.
2354 Harrison Expires June 2004 [Page 40]
2356 Internet-Draft LDAP Authentication Methods 5 December 2003
2361 - Updated consideration on use of cleartext passwords to include
2362 other unprotected authentication credentials
2363 - Substantial rework of consideration on misuse of unauthenticated
2366 Appendix G. Issues to be Resolved
2368 This appendix lists open questions and issues that need to be
2369 resolved before work on this document is deemed complete.
2373 Section 1 lists 6 security mechanisms that can be used by LDAP
2374 servers. I'm not sure what mechanism 5, "Resource limitation by
2375 means of administrative limits on service controls" means.
2377 Status: resolved. Changed wording to "administrative service limits"
2382 Section 2 paragraph 1 defines the term, "sensitive." Do we want to
2383 bring this term and other security-related terms in alignment with
2384 usage with the IETF security glossary (RFC 2828)?
2386 Status: resolved. WG input at IETF 51 was that we should do this, so
2387 the appropriate changes have been made.
2391 Section 2, deployment scenario 2: What is meant by the term "secure
2392 authentication function?"
2394 Status: resolved. Based on the idea that a "secure authentication
2395 function" could be provided by TLS, I changed the wording to require
2396 data confidentiality for sensitive authentication information and
2397 data integrity for all authentication information.
2401 Section 3, deployment scenario 3: What is meant by the phrase,
2402 "directory data is authenticated by the server?"
2404 Status: resolved. I interpreted this to mean the ability to ensure
2405 the identity of the directory server and the integrity of the data
2406 sent from that server to the client, and explictly stated such.
2413 Harrison Expires June 2004 [Page 41]
2415 Internet-Draft LDAP Authentication Methods 5 December 2003
2417 Section 4 paragraph 3: What is meant by the phrase, "this means that
2418 either this data is useless for faking authentication (like the Unix
2419 "/etc/passwd" file format used to be)?"
2421 Status: resolved. Discussion at IETF 52 along with discussions with
2422 the original authors of this material have convinced us that this
2423 reference is simply too arcane to be left in place. In -03 the text
2424 has been modified to focus on the need to either update password
2425 information in a protected fashion outside of the protocol or to
2426 update it in session well protected against snooping, and the
2427 reference to /etc/passwd has been removed.
2431 Section 4 paragraph 7 begins: "For a directory needing session
2432 protection..." Is this referring to data confidentiality or data
2435 Status: resolved. Changed wording to say, "For a directory needing
2436 data security (both data integrity and data confidentiality)..."
2440 Section 4 paragraph 8 indicates that "information about the server
2441 fetched prior to the TLS negotiation" must be discarded. Do we want
2442 to explicitly state that this applies to information fetched prior
2443 to the *completion* of the TLS negotiation or is this going too far?
2445 Status: resolved. Based on comments in the IETF 51 LDAPBIS WG
2446 meeting, this has been changed to explicitly state, "fetched prior
2447 to the initiation of the TLS negotiation..."
2451 Section 4 paragraph 9 indicates that clients SHOULD check the
2452 supportedSASLMechanisms list both before and after a SASL security
2453 layer is negotiated to ensure that they are using the best available
2454 security mechanism supported mutually by the client and server. A
2455 note at the end of the paragraph indicates that this is a SHOULD
2456 since there are environments where the client might get a list of
2457 supported SASL mechanisms from a different trusted source.
2459 I wonder if the intent of this could be restated more plainly using
2460 one of these two approaches (I've paraphrased for the sake of
2463 Approach 1: Clients SHOULD check the supportedSASLMechanisms
2464 list both before and after SASL negotiation or clients SHOULD
2465 use a different trusted source to determine available supported
2468 Approach 2: Clients MUST check the supportedSASLMechanisms list
2469 both before and after SASL negotiation UNLESS they use a
2472 Harrison Expires June 2004 [Page 42]
2474 Internet-Draft LDAP Authentication Methods 5 December 2003
2476 different trusted source to determine available supported SASL
2479 Status: resolved. WG input at IETF 51 was that Approach 1 was
2480 probably best. I ended up keeping the basic structure similar to the
2481 original to meet this intent.
2485 Section 6.3.1 states: "DSAs that map the DN sent in the bind request
2486 to a directory entry with a userPassword attribute will... compare
2487 [each value in the named user's entry]... with the presented
2488 password." This implies that this applies only to user entries with
2489 userPassword attributes. What about other types of entries that
2490 might allow passwords and might store in the password information in
2491 other attributes? Do we want to make this text more general?
2493 Status: resolved in -03 draft by generalizing section 8.3.1 to not
2494 refer to any specific password attribute and by removing the term
2495 "user" in referring to the directory entry specified by the DN in
2498 G.10 userPassword and simple bind
2500 We need to be sure that we don't require userPassword to be the only
2501 attribute used for authenticating via simple bind. (See 2251 sec 4.2
2502 and authmeth 6.3.1. Work with Jim Sermersheim on resolution to this.
2503 On publication state something like: "This is the specific
2504 implementation of what we discussed in our general reorg
2505 conversation on the list." (Source: Kurt Zeilenga)
2507 Status: resolved in -03 draft by generalizing section 8.3.1 to not
2508 refer to any specific password attribute and by removing the term
2509 "user" in referring to the directory entry specified by the DN in
2512 G.11. Meaning of LDAP Association
2514 The original RFC 2830 uses the term "LDAP association" in describing
2515 a connection between an LDAP client and server regardless of the
2516 state of TLS on that connection. This term needs to be defined or
2519 Status: resolved. at IETF 51 Bob Morgan indicated that the term
2520 "LDAP association" was intended to distinguish the LDAP-level
2521 connection from the TLS-level connection. This still needs to be
2522 clarified somewhere in the draft. Added "LDAP association" to a
2523 glossary in section 1.
2525 G.12. Is DIGEST-MD5 mandatory for all implementations?
2527 Reading 2829bis I think DIGEST-MD5 is mandatory ONLY IF your server
2528 supports password based authentication...but the following makes it
2529 sound mandatory to provide BOTH password authentication AND DIGEST-
2531 Harrison Expires June 2004 [Page 43]
2533 Internet-Draft LDAP Authentication Methods 5 December 2003
2537 "6.2. Digest authentication
2539 LDAP implementations MUST support authentication with a password
2540 using the DIGEST-MD5 SASL mechanism for password protection, as
2541 defined in section 6.1."
2543 The thing is for acl it would be nice (though not critical) to be
2544 able to default the required authentication level for a subject to a
2545 single "fairly secure" mechanism--if there is no such mandatory
2546 authentication scheme then you cannot do that. (Source: Rob Byrne)
2548 Status: resolved. -00 version of the draft added a sentence at the
2549 beginning of section 8.2 stating that LDAP server implementations
2550 must support this method.
2552 G.13. Ordering of authentication levels requested
2554 Again on the subject of authentication level, is it possible to
2555 define an ordering on authentication levels which defines their
2556 relative "strengths" ? This would be useful in acl as you could say
2557 things like"a given aci grants access to a given subject at this
2558 authentication level AND ABOVE". David Chadwick raised this before
2559 in the context of denying access to a subject at a given
2560 authentication level, in which case he wanted to express "deny
2561 access to this subject at this authentication level AND TO ALL
2562 IDENTITIES AUTHENTICATED BELOW THAT LEVEL". (Source: Rob Byrne)
2564 Status: out of scope. This is outside the scope of this document and
2565 will not be addressed.
2567 G.14. Document vulnerabilities of various mechanisms
2569 While I'm here...in 2829, I think it would be good to have some
2570 comments or explicit reference to a place where the security
2571 properties of the particular mandatory authentication schemes are
2572 outlined. When I say "security properties" I mean stuff like "This
2573 scheme is vulnerable to such and such attacks, is only safe if the
2574 key size is > 50, this hash is widely considered the best, etc...".
2575 I think an LDAP implementor is likely to be interested in that
2576 information, without having to wade through the security RFCs.
2579 Status: out of scope. This is outside the scope of this document and
2580 will not be addressed.
2582 G.15. Include a Start TLS state transition table
2584 The pictoral representation it is nominally based on is here (URL
2587 http://www.stanford.edu/~hodges/doc/LDAPAssociationStateDiagram-
2590 Harrison Expires June 2004 [Page 44]
2592 Internet-Draft LDAP Authentication Methods 5 December 2003
2595 (Source: Jeff Hodges)
2599 Table provided in -03. Review of content for accuracy in -04.
2600 Additional review is needed, plus comments from WG members indicate
2601 that additional description of each state's meaning would be
2604 Did a significant revision of state transition table in -09. Changes
2605 were based on suggestions from WG and greatly simplified overall
2608 G.16. Empty sasl credentials question
2610 I spent some more time looking microscopically at ldap-auth-methods
2611 and ldap-ext-tls drafts. The drafts say that the credential must
2612 have the form dn:xxx or u:xxx or be absent, and although they don't
2613 say what to do in the case of an empty octet string I would say that
2614 we could send protocolError (claim it is a bad PDU).
2616 There is still the question of what to do if the credential is 'dn:'
2617 (or 'u:') followed by the empty string. (Source: ariel@columbia.edu
2620 Status: resolved. Kurt Zeilenga indicated during ldapbis WG
2621 discussion at IETF 52 that SASL AuthzID credentials empty and absent
2622 are equivalent in the latest SASL ID. This resolves the issue.
2624 G.17. Hostname check from MUST to SHOULD?
2626 I am uneasy about the hostname check. My experience from PKI with
2627 HTTP probably is a contributing factor; we have people using the
2628 short hostname to get to a server which naturally has the FQDN in
2629 the certificate, no end of problems. I have a certificate on my
2630 laptop which has the FQDN for the casse when the system is on our
2631 Columbia network with a fixed IP; when I dial in however, I have
2632 some horrible dialup name, and using the local https server becomes
2633 annoying. Issuing a certificate in the name 'localhost' is not a
2634 solution! Wildcard match does not solve this problem. For these
2635 reasons I am inclined to argue for 'SHOULD' instead of
2636 'MUST' in paragraph...
2638 Also, The hostname check against the name in the certificate is a
2639 very weak means of preventing man-in-the-middle attacks; the proper
2640 solution is not here yet (SecureDNS or some equivalent). Faking out
2641 DNS is not so hard, and we see this sort of thing in the press on a
2642 pretty regular basis, where site A hijacks the DNS server for site B
2643 and gets all their requests. Some mention of this should be made in
2644 the draft. (Source: ariel@columbia.edu via Jeff Hodges)
2646 Status: resolved. Based on discussion at IETF 52 ldapbis WG meeting,
2647 this text will stand as it is. The check is a MUST, but the behavior
2649 Harrison Expires June 2004 [Page 45]
2651 Internet-Draft LDAP Authentication Methods 5 December 2003
2653 afterward is a SHOULD. This gives server implementations the room to
2656 G.18. Must SASL DN exist in the directory?
2658 If the 'dn:' form of sasl creds is used, is it the intention of the
2659 draft(ers) that this DN must exist in the directory and the client
2660 will have the privileges associated with that entry, or can the
2661 server map the sasl DN to perhaps some other DN in the directory,
2662 in an implementation-dependent fashion?
2664 We already know that if *no* sasl credentials are presented, the DN
2665 or altname in the client certificate may be mapped to a DN in an
2666 implementation-dependent fashion, or indeed to something not in the
2667 directory at all. (Right?) (Source: ariel@columbia.edu via Jeff
2670 Status: resolved. (11/12/02)Based on my research I propose that the
2671 DN MUST exist in the directory when the DN form of sasl creds is
2672 used. I have made this proposal to the ldapbis mailing list.
2674 (11/21/02) Feedback from mailing list has proposed removing this
2675 paragraph entirely because (1) explicit assertion of authorization
2676 identity should only be done when proxying (2) mapping of the
2677 asserted authorization identity is implementation specific and
2678 policy driven [SASL] section 4.2, and (3) keeping this paragraph is
2679 not required for interoperability.
2681 G.19. DN used in conjunction with SASL mechanism
2683 We need to specify whether the DN field in Bind operation can/cannot
2684 be used when SASL mechanism is specified. (source: RL Bob)
2686 Status: resolved. (-03) Based on ldapbis WG discussion at IETF52 two
2687 sentences were added to section 4.3 indicating that clients SHOULD
2688 NOT send a DN value when binding with the sasl choice and servers
2689 SHALL ignore any value received in this circumstance. During edits
2690 for -04 version of draft it was noted that [Protocol] section 4.2
2691 conflicts with this draft. The editor of [Protocol] has been
2692 notified of the discrepancy, and they have been handled.
2696 Differences between unauthenticated and anonymous. There are four
2697 states you can get into. One is completely undefined (this is now
2698 explicitly called out in [Protocol]). This text needs to be moved
2699 from [Protocol] to this draft. (source: Jim Sermersheim)
2701 Status: Resolved. There are four states: (1) no name, no password
2702 (anon); (2) name, no password (anon); (3) no name, password
2703 (invalid); (4) name, password (simple bind). States 1, 2, and 4 are
2704 called out in [AuthMeth]. State 3 is called out in [Protocol]; this
2705 seems appropriate based on review of alternatives.
2708 Harrison Expires June 2004 [Page 46]
2710 Internet-Draft LDAP Authentication Methods 5 December 2003
2712 G.21. Misuse of unauthenticated access
2714 Add a security consideration that operational experience shows that
2715 clients can misuse unauthenticated access (simple bind with name but
2716 no password). Servers SHOULD by default reject authentication
2717 requests that have a DN with an empty password with an error of
2718 invalidCredentials. (Source: Kurt Zeilenga and Chris Newman (Sun))
2720 Status: Resolved. Added to security considerations in -03.
2722 G.22. Need to move Start TLS protocol information to [Protocol]
2724 Status: Resolved. Removed Sections 5.1, 5.2, and 5.4 for -04 and
2725 they are [Protocol] -11.
2727 G.23. Split Normative and Non-normative references into separate
2730 Status: Resolved. Changes made in -04
2732 G.24. What is the authentication state if a Bind operation is
2737 (3/24/03) This following text appears in section 4.2.1 of [Protocol]
2738 revision -13 to cover what happens if a bind operation is abandoned:
2740 A failed or abandoned Bind Operation has the effect of leaving the
2741 connection in an anonymous state. To arrive at a known
2742 authentication state after abandoning a bind operation, clients may
2743 unbind, rebind, or make use of the BindResponse.
2745 (6/28/03): The state table in section 6 of [AuthMeth] has been
2746 updated to reflect this wording.
2748 G.25. Difference between checking server hostname and server's
2749 canonical DNS name in Server Identity Check?
2751 Section 4.1.6: I now understand the intent of the check (prevent
2752 man-in-the-middle attacks). But what is the subtle difference
2753 between the "server hostname" and the "server's canonical DNS name"?
2758 (11/12/02) Sent suggested wording change to this paragraph to the
2759 ldapbis mail list and also asked for opinion as to whether we should
2760 discuss the distinction between server DNS hostname and server
2761 canonical DNS hostname in [AuthMeth].
2763 (11/21/02): RL Bob Morgan will provide wording that allows
2764 derivations of the name that are provided securely.
2767 Harrison Expires June 2004 [Page 47]
2769 Internet-Draft LDAP Authentication Methods 5 December 2003
2771 (6/28/03): posted to the WG list asking Bob or any other WG member
2772 who is knowledgeable about the issues involved to help me with
2773 wording or other information I can use to make this change and close
2776 (10/08/03): Based on WG list feedback, I've updated this text to
2777 read what I judge to be the WG consensus, "The client MUST use the
2778 server provided by the user (or other trusted entity) as the value
2779 to compare against the server name as expressed in the server's
2780 certificate. A hostname derived from the user input is to be
2781 considered provided by the user only if derived in a secure fashion
2785 G.26. Server Identity Check using servers located via SRV records
2787 Section 4.1.6: What should be done if the server was found using SRV
2788 records based on the "locate" draft/RFC? (Source: Tim Hahn).
2790 Status: Resolved. Section 5 of draft-ietf-ldapext-locate-08
2791 specifically calls out how the server identity should be performed
2792 if the server is located using the method defined in that draft.
2793 This is the right location for this information, and the coverage
2794 appears to be adequate.
2796 G.27 Inconsistency in effect of TLS closure on LDAP association.
2798 Section 4.4.1 of authmeth -03 (section 4.1 of RFC2830) states that
2799 TLS closure alert will leave the LDAP association intact. Contrast
2800 this with Section 4.5.2 (section 5.2 of RFC2830) that says that the
2801 closure of the TLS connection MUST cause the LDAP association to
2802 move to an anonymous authentication.
2804 Status: Resolved. (11/12/02) This is actually a [Protocol] issue
2805 because these sections have now been moved to [Protocol] -11. I have
2806 proposed the following text for Section 4.4.1 of [AuthMeth] -03
2807 (section 4.13.3.1 of [Protocol]) to resolve this apparent
2810 "Either the client or server MAY terminate the TLS connection on an
2811 LDAP association by sending a TLS closure alert. The LDAP
2812 connection remains open for further communication after TLS closure
2813 occurs although the authentication state of the LDAP connection is
2814 affected (see [AuthMeth] section 4.2.2).
2816 (11/21/02): resolution to this is expected in [Protocol] -12
2818 (06/28/03): [Protocol]-15 clarifies that a TLS closure alert
2819 terminates the TLS connection while leaving the LDAP connection
2820 intact. The authentication state table in [AuthMeth] specifies the
2821 effect on the LDAP association.
2823 G.28 Ordering of external sources of authorization identities
2826 Harrison Expires June 2004 [Page 48]
2828 Internet-Draft LDAP Authentication Methods 5 December 2003
2830 Section 4.3.2 implies that external sources of authorization
2831 identities other than TLS are permitted. What is the behavior when
2832 two external sources of authentication credentials are available
2833 (e.g. TLS and IPsec are both present (is this possible?)) and a SASL
2834 EXTERNAL Bind operation is performed?
2836 Status: resolved. 11/20/02: Resolved by Section 4.2 of [SASL] which
2837 states that the decision to allow or disallow the asserted identity
2838 is based on an implementation defined policy.
2840 G.29 Rewrite of Section 9, TLS Ciphersuites
2842 This section contains anachronistic references and needs to be
2843 updated/rewritten in a way that provides useful guidance for future
2844 readers in a way that will transcend the passage of time.
2846 Status: Resolved. (6/28/03): Rewrote the section to cover the
2847 general issues and considerations involved in selecting TLS
2850 G.30 Update to Appendix A, Example Deployment Scenarios
2852 This section needs to be updated to indicate which security
2853 mechanisms and/or combinations of security mechanisms described
2854 elsewhere in the document can provide the types of protections
2855 suggested in this appendix.
2857 G.31 Use of PLAIN SASL Mechanism
2859 At least one LDAP server implementer has found the SASL "PLAIN"
2860 mechanism useful in authenticating to legacy systems that do not
2861 represent authentication identities as DNs. Section 3.3.1 appears to
2862 implicitly disallow the use of the SASL "PLAIN" mechanism with LDAP.
2863 Should we allow the use of this mechanism? I.e. is this "SASL"
2864 "PLAIN" MUST NOT be used with LDAP, or is it simply that LDAP
2865 doesn't define bindings for these mechanism. If SASL "PLAIN" is
2866 allowed, the following adjustments will be needed to section 3.3.1:
2867 (a) change section heading, (b) remove reference to "PLAIN" in the
2868 section, (c) ensure wording of last sentence regarding non-DN
2869 AuthZIDs is consistent with rest of the section.
2873 (6/28/03): email to WG list stating issue and asking if we should
2874 remove the reference to SASL "PLAIN".
2876 For -07 draft I've generalized the SASL profile in section 3.3 to
2877 allow any SASL mechanism.
2880 G.32 Clarification on use of SASL mechanisms
2882 Section 3.3.1: BTW, what _are_ the "ANONYMOUS" and "PLAIN" SASL
2883 mechanisms? They are not defined in RFC2222. If you refer to other
2885 Harrison Expires June 2004 [Page 49]
2887 Internet-Draft LDAP Authentication Methods 5 December 2003
2889 SASL mechanisms than those in rfc2222, Maybe you should only list
2890 which mechanisms _are_used, instead of which ones are _not. (Source:
2893 I (Kurt Zeilenga) note[s] as well that the ANONYMOUS/PLAIN section
2895 be deleted. ANONYMOUS and PLAIN, like in other mechanism,
2896 can be used in LDAP if a) supported and b) enabled. I note
2897 that they each offer capabilities not found in their simple
2898 bind equivalents (and hence are used in some deployments).
2899 For example, PLAIN (over TLS) is quite useful when interacting
2900 with legacy authentication subsystems. (Source: Kurt Zeilenga)
2904 For -07 draft I've generalized the SASL profile in section 3.3 to
2905 allow any SASL mechanism.
2909 G.33 Clarification on use of password protection based on AuthZID form
2911 Section 3.3.1: "If an authorization identity of a form different
2912 from a DN is requested by the client, a mechanism that protects the
2913 password in transit SHOULD be used." What has that to do with DNs?
2914 A mechanism that protects the password in transit should be used in
2915 any case, shouldn't it?
2919 In -08 draft this text was removed. There is already a general
2920 security consideration that covers this issue.
2923 G.34 Clarification on use of matching rules in Server Identity Check
2925 The text in section 4.1.6 isn't explicit on whether all rules apply
2926 to both CN and dNSName values. The text should be clear as to which
2927 rules apply to which values.... in particular, the wildcard
2928 rules. (Source: Kurt Zeilenga)
2931 G.35 Requested Additions to Security Considerations
2933 Requested to mention hostile servers which the user might have been
2934 fooled to into contacting. Which mechanisms that are standardized by
2935 the LDAP standard do/do not disclose the user's password to the
2936 server? (Or to servers doing man-in-the-middle attack? Or is that a
2939 Requested to mention denial of service attacks.
2941 Requested list of methods that need/don't need the server to know
2942 the user's plaintext password. (I say 'know' instead of 'store'
2944 Harrison Expires June 2004 [Page 50]
2946 Internet-Draft LDAP Authentication Methods 5 December 2003
2948 because it could still store the password encrypted, but in a way
2949 which it knows how to decrypt.)
2951 (Source: Hallvard Furuseth)
2953 G.36 Add reference to definition of DIGEST-MD5
2955 Need a reference to the definition of DIGEST-MD5 SASL mechanism in
2956 section 7.2 (Source: Hallvard Furuseth)
2958 Status: Resolved. A reference to to the DIGEST-MD5 SASL mechanism,
2959 [DigestAuth], is included in the -07 revision.
2961 G.37 Clarification on procedure for certificate-based authentication
2964 8.1. Certificate-based authentication with TLS states: "Following
2965 the successful completion of TLS negotiation, the client will send
2966 an LDAP bind request with the SASL "EXTERNAL" mechanism." Is this
2967 immediately following, or just some time later? Should the wording,
2968 "the client will send..." actually read, "the client MUST send..."?
2970 G.38 Effect of Start TLS on authentication state
2972 Should the server drop all knowledge of connection, i.e. return to
2973 anonymous state, if it gets a Start TLS request on a connection that
2974 has successfully bound using the simple method?
2976 G.39 Be sure that there is a consideration in [SCHEMA] that discusses
2977 multiple password values in userPassword
2979 Allowing multiple values obviously does raise a number of security
2980 considerations and these need to be discussed in the document.
2982 Certainly applications which intend to replace the userPassword with
2983 new value(s) should use modify/replaceValues (or
2984 modify/deleteAttribute+addAttribute). Additionally, server
2985 implementations should be encouraged to provide administrative
2986 controls which, if enabled, restrict userPassword to one value.
2988 G.40. Clarify need to verify mapping between authentication identity
2989 and resulting authorization identity on implicit assertion of AuthZID.
2991 4.2.2.3. Error Conditions
2993 "For either form of assertion, the server MUST verify that the
2994 client's authentication identity as supplied in its TLS credentials
2995 is permitted to be mapped to the asserted authorization identity."
2997 This makes sense for the explicit assertion case, but seems to be
2998 ambiguous for the implicit case.
2999 IMHO, the mapping can be done as two steps:
3000 a). deriving LDAP authentication identity from TLS credentials; If t
3001 this steps fails, EXTERNAL mechanism returns failure.
3003 Harrison Expires June 2004 [Page 51]
3005 Internet-Draft LDAP Authentication Methods 5 December 2003
3007 b). verify that the authorization identity is allowed for the
3008 derived authentication identity. This is always "noop" for the
3010 I am not sure that the text is saying this.
3011 (Source: Alexey Melnikov email 8/1/2003 5:30:43 PM)
3013 Status: Resolved in -07. After reading the comments and the text of
3014 the draft, I believe that this should be clarified. The local policy
3015 used to map the AuthNID to the AuthZID in the implicit case is
3016 sufficient and that no additional verification is useful or needed.
3017 This text has been moved to apply only to the explicit assertion
3020 G.41. Section 7.2 contains unnecessary and misleading detail.
3022 " I am not sure why this section is required in the document.
3023 DIGEST-MD5 is defined in a separate document and there should be
3024 nothing magical about its usage in LDAP. If DIGEST-MD5 description
3025 creates confusion for LDAP implementors, let's fix the DIGEST-MD5
3026 document! Also, this section tries to redefine DIGEST-MD5 behavior,
3027 which is explicitly prohibited by the SASL specification."
3028 (Source: Alexey Melnikov: email 8/1/2003 5:30:43 PM)
3032 After reading the comments and the text of the draft plus the
3033 related text in draft-ietf-sasl-rfc2831bis-02.txt plus
3034 http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
3035 02.txt, I am inclined to agree with Alexey. In -07 I rewrote section
3036 3.3 (SASL mechanisms) to match the profiling requirements
3037 rfc2831bis. I then dramatically reduced the material in section 7.2
3038 to a bare minimum and let the SASL profile stand on its own.
3040 G.42. Does change for G.41 cause interoperability issue?
3042 There is one issue with the way the authmeth draft is currently
3043 written that changes the SASL DIGEST-MD5 behavior on the way the
3044 server responds with the subsequent authentication information .
3045 This has been documented in this fashion since RFC 2829 (section
3046 6.1) was originally published and may cause an interoperability
3047 issue at this point if it changed to follow the DIGEST-MD5 spec (as
3048 it was in -07 of AuthMeth). Take this issue to the list.
3052 (10/08/03) This item was discussed on the WG list between 5/2/03 and
3053 5/9/03. Consensus apppears to support the notion that RFC 2829 was
3054 in error and that the semantics of RFC 2831 are correct and should
3055 be reflected in authmeth. This is already the case as of the -07
3058 G.43. DIGEST-MD5 Realms recommendations for LDAP
3062 Harrison Expires June 2004 [Page 52]
3064 Internet-Draft LDAP Authentication Methods 5 December 2003
3066 From http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-
3067 02.txt: A protocol profile SHOULD provide a guidance how realms are
3068 to be constructed and used in the protocol and MAY further restrict
3069 its syntax and protocol-specific semantics."
3071 I don't believe that any such guidance exists within the LDAP TS.
3072 The most likely place for this to reside is in the authmeth draft.
3074 Related email from Alexey Melnikov (8/4/2003 1:08:40 PM):
3076 "The problem I have with the document is that it references realm
3077 without explaining what it is (or at least some examples of valid
3078 values). For LDAP, some recommendations should be given. For
3080 1). Use a hardcoded string as the realm (one of the implementations
3081 I worked on was doing that)
3082 2). Use hostname (realm==host) or domain/cluster name (realm
3083 includes multiple hosts).
3084 3). Use a node in DIT above user entry, for example for "cn=Barbara
3085 Jensen, ou=Accounting, o=Ace Industry, c=US"
3086 and "cn=John Doe, ou=Accounting, o=Ace Industry, c=US" realm can be
3087 "ou=Accounting, o=Ace Industry, c=US"
3088 (or "o=Ace Industry, c=US"); for "cn=Gern Jensen, ou=Product
3089 Testing,o=Ace Industry, c=US" realm can be "ou=Product Testing,
3090 o=Ace Industry, c=US".
3092 Of course other choices are possible.
3096 To summarize: I'd like authmeth to define a realm name for use with
3097 Digest-MD5 that corresponds to LDAP DNs known to this server.
3098 Authzid is okay, but perhaps could be better put into context.
3101 John McMeeking (5/12/2003)
3105 draft-ietf-sasl-rfc2222bis-03.txt no longer requires this
3106 information in a SASL protocol. In addition, the ldapbis WG chairs
3107 have ruled this work out of scope. Individuals are welcome to make
3108 submissions to provide guidance on the use of realm and realm values
3111 G.44. Use of DNs in usernames and realms in DIGEST-MD5
3113 In reading the discussion on the mailing list, I reach the following
3116 DIGEST-MD5 username and realm are simple strings. The syntax of
3117 these strings allows strings that look like DNs in form, however,
3118 DIGEST-MD5 treats them a simple strings for comparision purposes.
3119 For example, the DNs cn=roger, o=US and cn=roger,o=us are equivalent
3121 Harrison Expires June 2004 [Page 53]
3123 Internet-Draft LDAP Authentication Methods 5 December 2003
3125 when being compared semantically as DNs, however, these would be
3126 considered two different username values in DIGEST-MD5 because
3127 simple octet-wise semantics (rather than DN semantics) are used to
3128 compare username values in DIGEST-MD5. Ditto for realm values.
3132 In -07 revision I added notes to implementors expressing this issue
3135 G.45: Open Issue: Is Simple+TLS mandatory to implement?
3137 Going forward, it would be much better to clarify that simple
3138 +TLS is to be used for DN/password credentials and DIGEST-MD5
3139 (or PLAIN+TLS) be used for username/password credentials. (Kurt
3140 Zeilenga, 5/12/2003)
3142 I don't believe you can mandate simple/TLS! At the time RFC 2829 was
3143 debated, a large number on the WG wanted this. They did not get
3144 their way because of the complexity of the solution. It was argued
3145 that a password-based method would be better. I think they believed
3146 it would still be DN/password, though. (Ron Ramsay, 5/12/2003)
3148 This was officially opened as an issue by WG co-chair Kurt Zeilenga
3149 on 5/12/03. Little direct discussion has occurred since, however
3150 there has been significant discussion on the use of DN values as the
3151 username for DIGEST-MD5.
3155 Based on WG list discussion, Kurt Zeilenga has gaged a lack of WG
3156 consensus that Simple+TLS should be mandatory to implement. No
3157 further discussion is necessary.
3160 Intellectual Property Rights
3162 The IETF takes no position regarding the validity or scope of any
3163 intellectual property or other rights that might be claimed to
3164 pertain to the implementation or use of the technology described in
3165 this document or the extent to which any license under such rights
3166 might or might not be available; neither does it represent that it
3167 has made any effort to identify any such rights. Information on the
3168 IETF's procedures with respect to rights in standards-track and
3169 standards-related documentation can be found in BCP-11. Copies of
3170 claims of rights made available for publication and any assurances
3171 of licenses to be made available, or the result of an attempt made
3172 to obtain a general license or permission for the use of such
3173 proprietary rights by implementors or users of this specification
3174 can be obtained from the IETF Secretariat.
3176 The IETF invites any interested party to bring to its attention any
3177 copyrights, patents or patent applications, or other proprietary
3178 rights which may cover technology that may be required to practice
3180 Harrison Expires June 2004 [Page 54]
3182 Internet-Draft LDAP Authentication Methods 5 December 2003
3184 this standard. Please address the information to the IETF Executive
3189 Copyright (C) The Internet Society (2003). All Rights Reserved.
3191 This document and translations of it may be copied and furnished to
3192 others, and derivative works that comment on or otherwise explain it
3193 or assist in its implementation may be prepared, copied, published
3194 and distributed, in whole or in part, without restriction of any
3195 kind, provided that the above copyright notice and this paragraph
3196 are included on all such copies and derivative works. However, this
3197 document itself may not be modified in any way, such as by removing
3198 the copyright notice or references to the Internet Society or other
3199 Internet organizations, except as needed for the purpose of
3200 developing Internet standards in which case the procedures for
3201 copyrights defined in the Internet Standards process must be
3202 followed, or as required to translate it into languages other than
3239 Harrison Expires June 2004 [Page 55]