]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc2829.txt
Sync with HEAD
[openldap] / doc / rfc / rfc2829.txt
1
2
3
4
5
6
7 Network Working Group                                            M. Wahl
8 Request for Comments: 2829                        Sun Microsystems, Inc.
9 Category: Standards Track                                  H. Alvestrand
10                                                              EDB Maxware
11                                                                J. Hodges
12                                                              Oblix, Inc.
13                                                                R. Morgan
14                                                 University of Washington
15                                                                 May 2000
16
17
18                     Authentication Methods for LDAP
19
20 Status of this Memo
21
22    This document specifies an Internet standards track protocol for the
23    Internet community, and requests discussion and suggestions for
24    improvements.  Please refer to the current edition of the "Internet
25    Official Protocol Standards" (STD 1) for the standardization state
26    and status of this protocol.  Distribution of this memo is unlimited.
27
28 Copyright Notice
29
30    Copyright (C) The Internet Society (2000).  All Rights Reserved.
31
32 Abstract
33
34    This document specifies particular combinations of security
35    mechanisms which are required and recommended in LDAP [1]
36    implementations.
37
38 1. Introduction
39
40    LDAP version 3 is a powerful access protocol for directories.
41
42    It offers means of searching, fetching and manipulating directory
43    content, and ways to access a rich set of security functions.
44
45    In order to function for the best of the Internet, it is vital that
46    these security functions be interoperable; therefore there has to be
47    a minimum subset of security functions that is common to all
48    implementations that claim LDAPv3 conformance.
49
50    Basic threats to an LDAP directory service include:
51
52       (1)   Unauthorized access to data via data-fetching operations,
53
54
55
56
57
58 Wahl, et al.                Standards Track                     [Page 1]
59 \f
60 RFC 2829            Authentication Methods for LDAP             May 2000
61
62
63       (2)   Unauthorized access to reusable client authentication
64             information by monitoring others' access,
65
66       (3)   Unauthorized access to data by monitoring others' access,
67
68       (4)   Unauthorized modification of data,
69
70       (5)   Unauthorized modification of configuration,
71
72       (6)   Unauthorized or excessive use of resources (denial of
73             service), and
74
75       (7)   Spoofing of directory: Tricking a client into believing that
76             information came from the directory when in fact it did not,
77             either by modifying data in transit or misdirecting the
78             client's connection.
79
80    Threats (1), (4), (5) and (6) are due to hostile clients.  Threats
81    (2), (3) and (7) are due to hostile agents on the path between client
82    and server, or posing as a server.
83
84    The LDAP protocol suite can be protected with the following security
85    mechanisms:
86
87       (1)   Client authentication by means of the SASL [2] mechanism
88             set, possibly backed by the TLS credentials exchange
89             mechanism,
90
91       (2)   Client authorization by means of access control based on the
92             requestor's authenticated identity,
93
94       (3)   Data integrity protection by means of the TLS protocol or
95             data-integrity SASL mechanisms,
96
97       (4)   Protection against snooping by means of the TLS protocol or
98             data-encrypting SASL mechanisms,
99
100       (5)   Resource limitation by means of administrative limits on
101             service controls, and
102
103       (6)   Server authentication by means of the TLS protocol or SASL
104             mechanism.
105
106    At the moment, imposition of access controls is done by means outside
107    the scope of the LDAP protocol.
108
109    In this document, the term "user" represents any application which is
110    an LDAP client using the directory to retrieve or store information.
111
112
113
114 Wahl, et al.                Standards Track                     [Page 2]
115 \f
116 RFC 2829            Authentication Methods for LDAP             May 2000
117
118
119    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
120    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
121    document are to be interpreted as described in RFC 2119 [3].
122
123 2.  Example deployment scenarios
124
125    The following scenarios are typical for LDAP directories on the
126    Internet, and have different security requirements. (In the
127    following, "sensitive" means data that will cause real damage to the
128    owner if revealed; there may be data that is protected but not
129    sensitive).  This is not intended to be a comprehensive list, other
130    scenarios are possible, especially on physically protected networks.
131
132       (1)   A read-only directory, containing no sensitive data,
133             accessible to "anyone", and TCP connection hijacking or IP
134             spoofing is not a problem.  This directory requires no
135             security functions except administrative service limits.
136
137       (2)   A read-only directory containing no sensitive data; read
138             access is granted based on identity.  TCP connection
139             hijacking is not currently a problem. This scenario requires
140             a secure authentication function.
141
142       (3)   A read-only directory containing no sensitive data; and the
143             client needs to ensure that the directory data is
144             authenticated by the server and not modified while being
145             returned from the server.
146
147       (4)   A read-write directory, containing no sensitive data; read
148             access is available to "anyone", update access to properly
149             authorized persons.  TCP connection hijacking is not
150             currently a problem.  This scenario requires a secure
151             authentication function.
152
153       (5)   A directory containing sensitive data.  This scenario
154             requires session confidentiality protection AND secure
155             authentication.
156
157 3.  Authentication and Authorization:  Definitions and Concepts
158
159    This section defines basic terms, concepts, and interrelationships
160    regarding authentication, authorization, credentials, and identity.
161    These concepts are used in describing how various security approaches
162    are utilized in client authentication and authorization.
163
164
165
166
167
168
169
170 Wahl, et al.                Standards Track                     [Page 3]
171 \f
172 RFC 2829            Authentication Methods for LDAP             May 2000
173
174
175 3.1.  Access Control Policy
176
177    An access control policy is a set of rules defining the protection of
178    resources, generally in terms of the capabilities of persons or other
179    entities accessing those resources.  A common expression of an access
180    control policy is an access control list.  Security objects and
181    mechanisms, such as those described here, enable the expression of
182    access control policies and their enforcement.  Access control
183    policies are typically expressed in terms of access control
184    attributes as described below.
185
186 3.2.  Access Control Factors
187
188    A request, when it is being processed by a server, may be associated
189    with a wide variety of security-related factors (section 4.2 of [1]).
190    The server uses these factors to determine whether and how to process
191    the request.  These are called access control factors (ACFs).  They
192    might include source IP address, encryption strength, the type of
193    operation being requested, time of day, etc.  Some factors may be
194    specific to the request itself, others may be associated with the
195    connection via which the request is transmitted, others (e.g. time of
196    day) may be "environmental".
197
198    Access control policies are expressed in terms of access control
199    factors.  E.g., a request having ACFs i,j,k can perform operation Y
200    on resource Z. The set of ACFs that a server makes available for such
201    expressions is implementation-specific.
202
203 3.3.  Authentication, Credentials, Identity
204
205    Authentication credentials are the evidence supplied by one party to
206    another, asserting the identity of the supplying party (e.g. a user)
207    who is attempting to establish an association with the other party
208    (typically a server).  Authentication is the process of generating,
209    transmitting, and verifying these credentials and thus the identity
210    they assert.  An authentication identity is the name presented in a
211    credential.
212
213    There are many forms of authentication credentials -- the form used
214    depends upon the particular authentication mechanism negotiated by
215    the parties.  For example: X.509 certificates, Kerberos tickets,
216    simple identity and password pairs.  Note that an authentication
217    mechanism may constrain the form of authentication identities used
218    with it.
219
220
221
222
223
224
225
226 Wahl, et al.                Standards Track                     [Page 4]
227 \f
228 RFC 2829            Authentication Methods for LDAP             May 2000
229
230
231 3.4.  Authorization Identity
232
233    An authorization identity is one kind of access control factor.  It
234    is the name of the user or other entity that requests that operations
235    be performed.  Access control policies are often expressed in terms
236    of authorization identities; e.g., entity X can perform operation Y
237    on resource Z.
238
239    The authorization identity bound to an association is often exactly
240    the same as the authentication identity presented by the client, but
241    it may be different.  SASL allows clients to specify an authorization
242    identity distinct from the authentication identity asserted by the
243    client's credentials.  This permits agents such as proxy servers to
244    authenticate using their own credentials, yet request the access
245    privileges of the identity for which they are proxying [2].  Also,
246    the form of authentication identity supplied by a service like TLS
247    may not correspond to the authorization identities used to express a
248    server's access control  policy, requiring a server-specific mapping
249    to be done.  The method by which a server composes and validates an
250    authorization identity from the authentication credentials supplied
251    by a client is implementation-specific.
252
253 4. Required security mechanisms
254
255    It is clear that allowing any implementation, faced with the above
256    requirements, to pick and choose among the possible alternatives is
257    not a strategy that is likely to lead to interoperability. In the
258    absence of mandates, clients will be written that do not support any
259    security function supported by the server, or worse, support only
260    mechanisms like cleartext passwords that provide clearly inadequate
261    security.
262
263    Active intermediary attacks are the most difficult for an attacker to
264    perform, and for an implementation to protect against.  Methods that
265    protect only against hostile client and passive eavesdropping attacks
266    are useful in situations where the cost of protection against active
267    intermediary attacks is not justified based on the perceived risk of
268    active intermediary attacks.
269
270    Given the presence of the Directory, there is a strong desire to see
271    mechanisms where identities take the form of a Distinguished Name and
272    authentication data can be stored in the directory; this means that
273    either this data is useless for faking authentication (like the Unix
274    "/etc/passwd" file format used to be), or its content is never passed
275    across the wire unprotected - that is, it's either updated outside
276    the protocol or it is only updated in sessions well protected against
277    snooping.  It is also desirable to allow authentication methods to
278
279
280
281
282 Wahl, et al.                Standards Track                     [Page 5]
283 \f
284 RFC 2829            Authentication Methods for LDAP             May 2000
285
286
287    carry authorization identities based on existing forms of user
288    identities for backwards compatibility with non-LDAP-based
289    authentication services.
290
291    Therefore, the following implementation conformance requirements are
292    in place:
293
294       (1)   For a read-only, public directory, anonymous authentication,
295             described in section 5, can be used.
296
297       (2)   Implementations providing password-based authenticated
298             access MUST support authentication using the DIGEST-MD5 SASL
299             mechanism [4], as described in section 6.1.  This provides
300             client authentication with protection against passive
301             eavesdropping attacks, but does not provide protection
302             against active intermediary attacks.
303
304       (3)   For a directory needing session protection and
305             authentication, the Start TLS extended operation [5], and
306             either the simple authentication choice or the SASL EXTERNAL
307             mechanism, are to be used together.  Implementations SHOULD
308             support authentication with a password as described in
309             section 6.2, and SHOULD support authentication with a
310             certificate as described in section 7.1.  Together, these
311             can provide integrity and disclosure protection of
312             transmitted data, and authentication of client and server,
313             including protection against active intermediary attacks.
314
315    If TLS is negotiated, the client MUST discard all information about
316    the server fetched prior to the TLS negotiation.  In particular, the
317    value of supportedSASLMechanisms MAY be different after TLS has been
318    negotiated (specifically, the EXTERNAL mechanism or the proposed
319    PLAIN mechanism are likely to only be listed after a TLS negotiation
320    has been performed).
321
322    If a SASL security layer is negotiated, the client MUST discard all
323    information about the server fetched prior to SASL.  In particular,
324    if the client is configured to support multiple SASL mechanisms, it
325    SHOULD fetch supportedSASLMechanisms both before and after the SASL
326    security layer is negotiated and verify that the value has not
327    changed after the SASL security layer was negotiated.  This detects
328    active attacks which remove supported SASL mechanisms from the
329    supportedSASLMechanisms list, and allows the client to ensure that it
330    is using the best mechanism supported by both client and server
331    (additionally, this is a SHOULD to allow for environments where the
332    supported SASL mechanisms list is provided to the client through a
333    different trusted source, e.g. as part of a digitally signed object).
334
335
336
337
338 Wahl, et al.                Standards Track                     [Page 6]
339 \f
340 RFC 2829            Authentication Methods for LDAP             May 2000
341
342
343 5. Anonymous authentication
344
345    Directory operations which modify entries or access protected
346    attributes or entries generally require client authentication.
347    Clients which do not intend to perform any of these operations
348    typically use anonymous authentication.
349
350    LDAP implementations MUST support anonymous authentication, as
351    defined in section 5.1.
352
353    LDAP implementations MAY support anonymous authentication with TLS,
354    as defined in section 5.2.
355
356    While there MAY be access control restrictions to prevent access to
357    directory entries, an LDAP server SHOULD allow an anonymously-bound
358    client to retrieve the supportedSASLMechanisms attribute of the root
359    DSE.
360
361    An LDAP server MAY use other information about the client provided by
362    the lower layers or external means to grant or deny access even to
363    anonymously authenticated clients.
364
365 5.1. Anonymous authentication procedure
366
367    An LDAP client which has not successfully completed a bind operation
368    on a connection is anonymously authenticated.
369
370    An LDAP client MAY also specify anonymous authentication in a bind
371    request by using a zero-length OCTET STRING with the simple
372    authentication choice.
373
374 5.2. Anonymous authentication and TLS
375
376    An LDAP client MAY use the Start TLS operation [5] to negotiate the
377    use of TLS security [6].  If the client has not bound beforehand,
378    then until the client uses the EXTERNAL SASL mechanism to negotiate
379    the recognition of the client's certificate, the client is
380    anonymously authenticated.
381
382    Recommendations on TLS ciphersuites are given in section 10.
383
384    An LDAP server which requests that clients provide their certificate
385    during TLS negotiation MAY use a local security policy to determine
386    whether to successfully complete TLS negotiation if the client did
387    not present a certificate which could be validated.
388
389
390
391
392
393
394 Wahl, et al.                Standards Track                     [Page 7]
395 \f
396 RFC 2829            Authentication Methods for LDAP             May 2000
397
398
399 6. Password-based authentication
400
401    LDAP implementations MUST support authentication with a password
402    using the DIGEST-MD5 SASL mechanism for password protection, as
403    defined in section 6.1.
404
405    LDAP implementations SHOULD support authentication with the "simple"
406    password choice when the connection is protected against
407    eavesdropping using TLS, as defined in section 6.2.
408
409 6.1. Digest authentication
410
411    An LDAP client MAY determine whether the server supports this
412    mechanism by performing a search request on the root DSE, requesting
413    the supportedSASLMechanisms attribute, and checking whether the
414    string "DIGEST-MD5" is present as a value of this attribute.
415
416    In the first stage of authentication, when the client is performing
417    an "initial authentication" as defined in section 2.1 of [4], the
418    client sends a bind request in which the version number is 3, the
419    authentication choice is sasl, the sasl mechanism name is "DIGEST-
420    MD5", and the credentials are absent.  The client then waits for a
421    response from the server to this request.
422
423    The server will respond with a bind response in which the resultCode
424    is saslBindInProgress, and the serverSaslCreds field is present.  The
425    contents of this field is a string defined by "digest-challenge" in
426    section 2.1.1 of [4].  The server SHOULD include a realm indication
427    and MUST indicate support for UTF-8.
428
429    The client will send a bind request with a distinct message id, in
430    which the version number is 3, the authentication choice is sasl, the
431    sasl mechanism name is "DIGEST-MD5", and the credentials contain the
432    string defined by "digest-response" in section 2.1.2 of [4].  The
433    serv-type is "ldap".
434
435    The server will respond with a bind response in which the resultCode
436    is either success, or an error indication.  If the authentication is
437    successful and the server does not support subsequent authentication,
438    then the credentials field is absent.  If the authentication is
439    successful and the server supports subsequent authentication, then
440    the credentials field contains the string defined by "response-auth"
441    in section 2.1.3 of [4].   Support for subsequent authentication is
442    OPTIONAL in clients and servers.
443
444
445
446
447
448
449
450 Wahl, et al.                Standards Track                     [Page 8]
451 \f
452 RFC 2829            Authentication Methods for LDAP             May 2000
453
454
455 6.2. "simple" authentication choice under TLS encryption
456
457    A user who has a directory entry containing a userPassword attribute
458    MAY authenticate to the directory by performing a simple password
459    bind sequence following the negotiation of a TLS ciphersuite
460    providing connection confidentiality [6].
461
462    The client will use the Start TLS operation [5] to negotiate the use
463    of TLS security [6] on the connection to the LDAP server.  The client
464    need not have bound to the directory beforehand.
465
466    For this authentication procedure to be successful, the client and
467    server MUST negotiate a ciphersuite which contains a bulk encryption
468    algorithm of appropriate strength.  Recommendations on cipher suites
469    are given in section 10.
470
471    Following the successful completion of TLS negotiation, the client
472    MUST send an LDAP bind request with the version number of 3, the name
473    field containing the name of the user's entry, and the "simple"
474    authentication choice, containing a password.
475
476    The server will, for each value of the userPassword attribute in the
477    named user's entry, compare these for case-sensitive equality with
478    the client's presented password.  If there is a match, then the
479    server will respond with resultCode success, otherwise the server
480    will respond with resultCode invalidCredentials.
481
482 6.3. Other authentication choices with TLS
483
484    It is also possible, following the negotiation of TLS, to perform a
485    SASL authentication which does not involve the exchange of plaintext
486    reusable passwords.  In this case the client and server need not
487    negotiate a ciphersuite which provides confidentiality if the only
488    service required is data integrity.
489
490 7. Certificate-based authentication
491
492    LDAP implementations SHOULD support authentication via a client
493    certificate in TLS, as defined in section 7.1.
494
495 7.1. Certificate-based authentication with TLS
496
497    A user who has a public/private key pair in which the public key has
498    been signed by a Certification Authority may use this key pair to
499    authenticate to the directory server if the user's certificate is
500    requested by the server.  The user's certificate subject field SHOULD
501    be the name of the user's directory entry, and the Certification
502    Authority must be sufficiently trusted by the directory server to
503
504
505
506 Wahl, et al.                Standards Track                     [Page 9]
507 \f
508 RFC 2829            Authentication Methods for LDAP             May 2000
509
510
511    have issued the certificate in order that the server can process the
512    certificate.  The means by which servers validate certificate paths
513    is outside the scope of this document.
514
515    A server MAY support mappings for certificates in which the subject
516    field name is different from the name of the user's directory entry.
517    A server which supports mappings of names MUST be capable of being
518    configured to support certificates for which no mapping is required.
519
520    The client will use the Start TLS operation [5] to negotiate the use
521    of TLS security [6] on the connection to the LDAP server.  The client
522    need not have bound to the directory beforehand.
523
524    In the TLS negotiation, the server MUST request a certificate.  The
525    client will provide its certificate to the server, and MUST perform a
526    private key-based encryption, proving it has the private key
527    associated with the certificate.
528
529    As deployments will require protection of sensitive data in transit,
530    the client and server MUST negotiate a ciphersuite which contains a
531    bulk encryption algorithm of appropriate strength.  Recommendations
532    of cipher suites are given in section 10.
533
534    The server MUST verify that the client's certificate is valid. The
535    server will normally check that the certificate is issued by a known
536    CA, and that none of the certificates on the client's certificate
537    chain are invalid or revoked.  There are several procedures by which
538    the server can perform these checks.
539
540    Following the successful completion of TLS negotiation, the client
541    will send an LDAP bind request with the SASL "EXTERNAL" mechanism.
542
543 8. Other mechanisms
544
545    The LDAP "simple" authentication choice is not suitable for
546    authentication on the Internet where there is no network or transport
547    layer confidentiality.
548
549    As LDAP includes native anonymous and plaintext authentication
550    methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used
551    with LDAP.  If an authorization identity of a form different from a
552    DN is requested by the client, a mechanism that protects the password
553    in transit SHOULD be used.
554
555    The following SASL-based mechanisms are not considered in this
556    document: KERBEROS_V4, GSSAPI and SKEY.
557
558
559
560
561
562 Wahl, et al.                Standards Track                    [Page 10]
563 \f
564 RFC 2829            Authentication Methods for LDAP             May 2000
565
566
567    The "EXTERNAL" SASL mechanism can be used to request the LDAP server
568    make use of security credentials exchanged by a lower layer. If a TLS
569    session has not been established between the client and server prior
570    to making the SASL EXTERNAL Bind request and there is no other
571    external source of authentication credentials (e.g.  IP-level
572    security [8]), or if, during the process of establishing the TLS
573    session, the server did not request the client's authentication
574    credentials, the SASL EXTERNAL bind MUST fail with a result code of
575    inappropriateAuthentication.  Any client authentication and
576    authorization state of the LDAP association is lost, so the LDAP
577    association is in an anonymous state after the failure.
578
579 9. Authorization Identity
580
581    The authorization identity is carried as part of the SASL credentials
582    field in the LDAP Bind request and response.
583
584    When the "EXTERNAL" mechanism is being negotiated, if the credentials
585    field is present, it contains an authorization identity of the
586    authzId form described below.
587
588    Other mechanisms define the location of the authorization identity in
589    the credentials field.
590
591    The authorization identity is a string in the UTF-8 character set,
592    corresponding to the following ABNF [7]:
593
594    ; Specific predefined authorization (authz) id schemes are
595    ; defined below -- new schemes may be defined in the future.
596
597    authzId    = dnAuthzId / uAuthzId
598
599    ; distinguished-name-based authz id.
600    dnAuthzId  = "dn:" dn
601    dn         = utf8string    ; with syntax defined in RFC 2253
602
603    ; unspecified userid, UTF-8 encoded.
604    uAuthzId   = "u:" userid
605    userid     = utf8string    ; syntax unspecified
606
607    A utf8string is defined to be the UTF-8 encoding of one or more ISO
608    10646 characters.
609
610    All servers which support the storage of authentication credentials,
611    such as passwords or certificates, in the directory MUST support the
612    dnAuthzId choice.
613
614
615
616
617
618 Wahl, et al.                Standards Track                    [Page 11]
619 \f
620 RFC 2829            Authentication Methods for LDAP             May 2000
621
622
623    The uAuthzId choice allows for compatibility with client applications
624    which wish to authenticate to a local directory but do not know their
625    own Distinguished Name or have a directory entry.  The format of the
626    string is defined as only a sequence of UTF-8 encoded ISO 10646
627    characters, and further interpretation is subject to prior agreement
628    between the client and server.
629
630    For example, the userid could identify a user of a specific directory
631    service, or be a login name or the local-part of an RFC 822 email
632    address. In general a uAuthzId MUST NOT be assumed to be globally
633    unique.
634
635    Additional authorization identity schemes MAY be defined in future
636    versions of this document.
637
638 10. TLS Ciphersuites
639
640    The following ciphersuites defined in [6] MUST NOT be used for
641    confidentiality protection of passwords or data:
642
643          TLS_NULL_WITH_NULL_NULL
644          TLS_RSA_WITH_NULL_MD5
645          TLS_RSA_WITH_NULL_SHA
646
647    The following ciphersuites defined in [6] can be cracked easily (less
648    than a week of CPU time on a standard CPU in 1997).  The client and
649    server SHOULD carefully consider the value of the password or data
650    being protected before using these ciphersuites:
651
652          TLS_RSA_EXPORT_WITH_RC4_40_MD5
653          TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
654          TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
655          TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
656          TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
657          TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
658          TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
659          TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
660          TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
661
662    The following ciphersuites are vulnerable to man-in-the-middle
663    attacks, and SHOULD NOT be used to protect passwords or sensitive
664    data, unless the network configuration is such that the danger of a
665    man-in-the-middle attack is tolerable:
666
667
668
669
670
671
672
673
674 Wahl, et al.                Standards Track                    [Page 12]
675 \f
676 RFC 2829            Authentication Methods for LDAP             May 2000
677
678
679          TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
680          TLS_DH_anon_WITH_RC4_128_MD5
681          TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
682          TLS_DH_anon_WITH_DES_CBC_SHA
683          TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
684
685    A client or server that supports TLS MUST support at least
686    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
687
688 11. SASL service name for LDAP
689
690    For use with SASL [2], a protocol must specify a service name to be
691    used with various SASL mechanisms, such as GSSAPI.  For LDAP, the
692    service name is "ldap", which has been registered with the IANA as a
693    GSSAPI service name.
694
695 12. Security Considerations
696
697    Security issues are discussed throughout this memo; the
698    (unsurprising) conclusion is that mandatory security is important,
699    and that session encryption is required when snooping is a problem.
700
701    Servers are encouraged to prevent modifications by anonymous users.
702    Servers may also wish to minimize denial of service attacks by timing
703    out idle connections, and returning the unwillingToPerform result
704    code rather than performing computationally expensive operations
705    requested by unauthorized clients.
706
707    A connection on which the client has not performed the Start TLS
708    operation or negotiated a suitable SASL mechanism for connection
709    integrity and encryption services is subject to man-in-the-middle
710    attacks to view and modify information in transit.
711
712    Additional security considerations relating to the EXTERNAL mechanism
713    to negotiate TLS can be found in [2], [5] and [6].
714
715 13. Acknowledgements
716
717    This document is a product of the LDAPEXT Working Group of the IETF.
718    The contributions of its members is greatly appreciated.
719
720
721
722
723
724
725
726
727
728
729
730 Wahl, et al.                Standards Track                    [Page 13]
731 \f
732 RFC 2829            Authentication Methods for LDAP             May 2000
733
734
735 14. Bibliography
736
737    [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
738        Protocol (v3)", RFC 2251, December 1997.
739
740    [2] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC
741        2222, October 1997.
742
743    [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
744        Levels", BCP 14, RFC 2119, March 1997.
745
746    [4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
747        Mechanism", RFC 2831, May 2000.
748
749    [5] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access
750        Protocol (v3): Extension for Transport Layer Security", RFC 2830,
751        May 2000.
752
753    [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
754        2246, January 1999.
755
756    [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
757        Specifications: ABNF", RFC 2234, November 1997.
758
759    [8] Kent, S. and R. Atkinson, "Security Architecture for the Internet
760        Protocol", RFC 2401, November 1998.
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786 Wahl, et al.                Standards Track                    [Page 14]
787 \f
788 RFC 2829            Authentication Methods for LDAP             May 2000
789
790
791 15. Authors' Addresses
792
793    Mark Wahl
794    Sun Microsystems, Inc.
795    8911 Capital of Texas Hwy #4140
796    Austin TX 78759
797    USA
798
799    EMail: M.Wahl@innosoft.com
800
801
802    Harald Tveit Alvestrand
803    EDB Maxware
804    Pirsenteret
805    N-7462 Trondheim, Norway
806
807    Phone: +47 73 54 57 97
808    EMail: Harald@Alvestrand.no
809
810
811    Jeff Hodges
812    Oblix, Inc.
813    18922 Forge Drive
814    Cupertino, CA 95014
815    USA
816
817    Phone: +1-408-861-6656
818    EMail: JHodges@oblix.com
819
820
821    RL "Bob" Morgan
822    Computing and Communications
823    University of Washington
824    Seattle, WA 98105
825    USA
826
827    Phone: +1-206-221-3307
828    EMail: rlmorgan@washington.edu
829
830
831
832
833
834
835
836
837
838
839
840
841
842 Wahl, et al.                Standards Track                    [Page 15]
843 \f
844 RFC 2829            Authentication Methods for LDAP             May 2000
845
846
847 16.  Full Copyright Statement
848
849    Copyright (C) The Internet Society (2000).  All Rights Reserved.
850
851    This document and translations of it may be copied and furnished to
852    others, and derivative works that comment on or otherwise explain it
853    or assist in its implementation may be prepared, copied, published
854    and distributed, in whole or in part, without restriction of any
855    kind, provided that the above copyright notice and this paragraph are
856    included on all such copies and derivative works.  However, this
857    document itself may not be modified in any way, such as by removing
858    the copyright notice or references to the Internet Society or other
859    Internet organizations, except as needed for the purpose of
860    developing Internet standards in which case the procedures for
861    copyrights defined in the Internet Standards process must be
862    followed, or as required to translate it into languages other than
863    English.
864
865    The limited permissions granted above are perpetual and will not be
866    revoked by the Internet Society or its successors or assigns.
867
868    This document and the information contained herein is provided on an
869    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
870    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
871    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
872    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
873    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
874
875 Acknowledgement
876
877    Funding for the RFC Editor function is currently provided by the
878    Internet Society.
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898 Wahl, et al.                Standards Track                    [Page 16]
899 \f