2 Network Working Group M. Wahl
3 INTERNET-DRAFT Innosoft International, Inc.
10 Expires in six months from June 21, 1999
13 Authentication Methods for LDAP
14 <draft-ietf-ldapext-authmeth-04.txt>
16 1. Status of this Memo
18 This document is an Internet-Draft. Internet-Drafts are working
19 documents of the Internet Engineering Task Force (IETF), its
20 areas, and its working groups. Note that other groups may also
21 distribute working documents as Internet-Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six
24 months and may be updated, replaced, or obsoleted by other
25 documents at any time. It is inappropriate to use Internet-Drafts
26 as reference material or to cite them other than as "work in
29 To view the entire list of current Internet-Drafts, please check
30 the "1id-abstracts.txt" listing contained in the Internet-Drafts
31 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
32 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
33 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
38 This document specifies particular combinations of security
39 mechanisms which are required and recommended in LDAP [1]
44 LDAP version 3 is a powerful access protocol for directories.
46 It offers means of searching, fetching and manipulating directory
47 content, and ways to access a rich set of security functions.
49 In order to function for the best of the Internet, it is vital
50 that these security functions be interoperable; therefore there
51 has to be a minimum subset of security functions that is common to
52 all implementations that claim LDAPv3 conformance.
56 Wahl, Alvestrand, Hodges, Morgan Page 1
58 INTERNET-DRAFT Authentication Methods for LDAP June 1999
60 Basic threats to an LDAP directory service include:
62 (1) Unauthorized access to data via data-fetching operations,
64 (2) Unauthorized access to reusable client authentication
65 information by monitoring others' access,
67 (3) Unauthorized access to data by monitoring others' access,
69 (4) Unauthorized modification of data,
71 (5) Unauthorized modification of configuration,
73 (6) Unauthorized or excessive use of resources (denial of
76 (7) Spoofing of directory: Tricking a client into believing
77 that information came from the directory when in fact it
78 did not, either by modifying data in transit or misdirecting
79 the client's connection.
81 Threats (1), (4), (5) and (6) are due to hostile clients. Threats
82 (2), (3) and (7) are due to hostile agents on the path between client
83 and server, or posing as a server.
85 The LDAP protocol suite can be protected with the following
88 (1) Client authentication by means of the SASL [2] mechanism set,
89 possibly backed by the TLS credentials exchange mechanism,
91 (2) Client authorization by means of access control based on
92 the requestor's authenticated identity,
94 (3) Data integrity protection by means of the TLS protocol or
95 data-integrity SASL mechanisms,
97 (4) Protection against snooping by means of the TLS protocol
98 or data-encrypting SASL mechanisms,
100 (5) Resource limitation by means of administrative limits on
101 service controls, and
103 (6) Server authentication by means of the TLS protocol or SASL
106 At the moment, imposition of access controls is done by means
107 outside the scope of the LDAP protocol.
109 In this document, the term "user" represents any application which
110 is an LDAP client using the directory to retrieve or store information.
112 Wahl, Alvestrand, Hodges, Morgan Page 2
114 INTERNET-DRAFT Authentication Methods for LDAP June 1999
116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
118 this document are to be interpreted as described in RFC 2119 [3].
120 4. Example deployment scenarios
122 The following scenarios are typical for LDAP directories on the
123 Internet, and have different security requirements. (In the
124 following, "sensitive" means data that will cause real damage to
125 the owner if revealed; there may be data that is protected but
126 not sensitive). This is not intended to be a comprehensive list,
127 other scenarios are possible, especially on physically protected
130 (1) A read-only directory, containing no sensitive data,
131 accessible to "anyone", and TCP connection hijacking
132 or IP spoofing is not a problem. This directory requires
133 no security functions except administrative service limits.
135 (2) A read-only directory containing no sensitive data; read
136 access is granted based on identity. TCP connection
137 hijacking is not currently a problem. This scenario requires
138 a secure authentication function.
140 (3) A read-only directory containing no sensitive data; and
141 the client needs to ensure that the directory data is
142 authenticated by the server and not modified while being
143 returned from the server.
145 (4) A read-write directory, containing no sensitive data; read
146 access is available to "anyone", update access to properly
147 authorized persons. TCP connection hijacking is not
148 currently a problem. This scenario requires a secure
149 authentication function.
151 (5) A directory containing sensitive data. This scenario
152 requires session confidentiality protection AND secure
155 5. Authentication and Authorization: Definitions and Concepts
157 This section defines basic terms, concepts, and interrelationships
158 regarding authentication, authorization, credentials, and identity.
159 These concepts are used in describing how various security
160 approaches are utilized in client authentication and authorization.
168 Wahl, Alvestrand, Hodges, Morgan Page 3
170 INTERNET-DRAFT Authentication Methods for LDAP June 1999
172 5.1. Access Control Policy
174 An access control policy is a set of rules defining the protection
175 of resources, generally in terms of the capabilities of persons or
176 other entities accessing those resources. A common expression of an
177 access control policy is an access control list. Security objects
178 and mechanisms, such as those described here, enable the expression of
179 access control policies and their enforcement. Access control
180 policies are typically expressed in terms of access control attributes
183 5.2. Access Control Factors
185 A request, when it is being processed by a server, may be associated
186 with a wide variety of security-related factors (section 4.2 of [1]).
187 The server uses these factors to determine whether and how to process
188 the request. These are called access control factors (ACFs). They
189 might include source IP address, encryption strength, the type of
190 operation being requested, time of day, etc. Some factors may be
191 specific to the request itself, others may be associated with the
192 connection via which the request is transmitted, others (e.g. time of
193 day) may be "environmental".
195 Access control policies are expressed in terms of access control
196 factors. E.g., a request having ACFs i,j,k can perform operation Y
197 on resource Z. The set of ACFs that a server makes available for such
198 expressions is implementation-specific.
200 5.3. Authentication, Credentials, Identity
202 Authentication credentials are the evidence supplied by one party to
203 another, asserting the identity of the supplying party (e.g. a user)
204 who is attempting to establish an association with the other party
205 (typically a server). Authentication is the process of generating,
206 transmitting, and verifying these credentials and thus the identity
207 they assert. An authentication identity is the name presented in a
210 There are many forms of authentication credentials -- the form used
211 depends upon the particular authentication mechanism negotiated by the
212 parties. For example: X.509 certificates, Kerberos tickets, simple
213 identity and password pairs. Note that an authentication mechanism may
214 constrain the form of authentication identities used with it.
216 5.4. Authorization Identity
218 An authorization identity is one kind of access control factor. It is
219 the name of the user or other entity that requests that operations be
220 performed. Access control policies are often expressed in terms of
221 authorization identities; e.g., entity X can perform operation Y on
224 Wahl, Alvestrand, Hodges, Morgan Page 4
226 INTERNET-DRAFT Authentication Methods for LDAP June 1999
228 The authorization identity bound to an association is often exactly the
229 same as the authentication identity presented by the client, but it may
230 be different. SASL allows clients to specify an authorization identity
231 distinct from the authentication identity asserted by the client's
232 credentials. This permits agents such as proxy servers to authenticate
233 using their own credentials, yet request the access privileges of the
234 identity for which they are proxying [2]. Also, the form of
235 authentication identity supplied by a service like TLS may not
236 correspond to the authorization identities used to express a server's
237 access control policy, requiring a server-specific mapping to be done.
238 The method by which a server composes and validates an authorization
239 identity from the authentication credentials supplied by a client is
240 implementation-specific.
242 6. Required security mechanisms
244 It is clear that allowing any implementation, faced with the above
245 requirements, to pick and choose among the possible alternatives
246 is not a strategy that is likely to lead to interoperability. In
247 the absence of mandates, clients will be written that do not
248 support any security function supported by the server, or worse,
249 support only mechanisms like cleartext passwords that provide
250 clearly inadequate security.
252 Active intermediary attacks are the most difficult for an attacker
253 to perform, and for an implementation to protect against. Methods
254 that protect only against hostile client and passive eavesdropping
255 attacks are useful in situations where the cost of protection
256 against active intermediary attacks is not justified based on the
257 perceived risk of active intermediary attacks.
259 Given the presence of the Directory, there is a strong desire to
260 see mechanisms where identities take the form of a Distinguished
261 Name and authentication data can be stored in the directory; this
262 means that either this data is useless for faking authentication
263 (like the Unix "/etc/passwd" file format used to be), or its
264 content is never passed across the wire unprotected - that is,
265 it's either updated outside the protocol or it is only updated in
266 sessions well protected against snooping. It is also desirable
267 to allow authentication methods to carry authorization identities
268 based on existing forms of user identities for backwards compatibility
269 with non-LDAP-based authentication services.
271 Therefore, the following implementation conformance requirements
274 (1) For a read-only, public directory, anonymous authentication,
275 described in section 7, can be used.
280 Wahl, Alvestrand, Hodges, Morgan Page 5
282 INTERNET-DRAFT Authentication Methods for LDAP June 1999
284 (2) Implementations providing password-based authenticated access
285 MUST support authentication using Digest, as described in
286 section 8.1. This provides client authentication with
287 protection against passive eavesdropping attacks, but does
288 not provide protection against active intermediary attacks.
290 (3) For a directory needing session protection and
291 authentication, the Start TLS extended operation, and either
292 the simple authentication choice or the SASL EXTERNAL
293 mechanism, are to be used together. Implementations SHOULD
294 support authentication with a password as described in
295 section 8.2, and SHOULD support authentication with a
296 certificate as described in section 9.1. Together, these
297 can provide integrity and disclosure protection of
298 transmitted data, and authentication of client and server,
299 including protection against active intermediary attacks.
301 If TLS is negotated, the client MUST discard all information about
302 the server fetched prior to the TLS negotiation. In particular, the
303 value of supportedSASLMechanisms MAY be different after TLS has been
304 negotiated (specifically, the EXTERNAL mechanism or the proposed
305 PLAIN mechanism are likely to only be listed after a TLS negotiation
308 If a SASL security layer is negotiated, the client MUST discard all
309 information about the server fetched prior to SASL. In particular, if
310 the client is configured to support multiple SASL mechanisms, it SHOULD
311 fetch supportedSASLMechanisms both before and after the SASL security
312 layer is negotiated and verify that the value has not changed after the
313 SASL security layer was negotiated. This detects active attacks which
314 remove supported SASL mechanisms from the supportedSASLMechanisms list.
316 7. Anonymous authentication
318 Directory operations which modify entries or access protected
319 attributes or entries generally require client authentication.
320 Clients which do not intend to perform any of these operations
321 typically use anonymous authentication.
323 LDAP implementations MUST support anonymous authentication, as
324 defined in section 7.1.
326 LDAP implementations MAY support anonymous authentication with TLS,
327 as defined in section 7.2.
329 While there MAY be access control restrictions to prevent access to
330 directory entries, an LDAP server SHOULD allow an anonymously-bound
331 client to retrieve the supportedSASLMechanisms attribute of the root
336 Wahl, Alvestrand, Hodges, Morgan Page 6
338 INTERNET-DRAFT Authentication Methods for LDAP June 1999
340 An LDAP server MAY use other information about the client provided
341 by the lower layers or external means to grant or deny access even
342 to anonymously authenticated clients.
344 7.1. Anonymous authentication procedure
346 An LDAP client which has not successfully completed a bind operation
347 on a connection is anonymously authenticated.
349 An LDAP client MAY also specify anonymous authentication in a bind
350 request by using a zero-length OCTET STRING with the simple
351 authentication choice.
353 7.2. Anonymous authentication and TLS
355 An LDAP client MAY use the Start TLS operation [5] to negotiate the
356 use of TLS security [6]. If the client has not bound beforehand,
357 then until the client uses the EXTERNAL SASL mechanism to negotiate
358 the recognition of the client's certificate, the client is
359 anonymously authenticated.
361 Recommendations on TLS ciphersuites are given in section 12.
363 An LDAP server which requests that clients provide their certificate
364 during TLS negotiation MAY use a local security policy to determine
365 whether to successfully complete TLS negotiation if the client did not
366 present a certificate which could be validated.
368 8. Password-based authentication
370 LDAP implementations MUST support authentication with a password using
371 the DIGEST-MD5 mechanism for password protection, as defined in section
374 LDAP implementations SHOULD support authentication with the "simple"
375 password choice when the connection is protected against eavesdropping
376 using TLS, as defined in section 8.2.
378 8.1. Digest authentication
380 An LDAP client MAY determine whether the server supports this
381 mechanism by performing a search request on the root DSE, requesting
382 the supportedSASLMechanisms attribute, and checking whether the
383 string "DIGEST-MD5" is present as a value of this attribute.
385 In the first stage of authentication, when the client is performing
386 an "initial authentication" as defined in section 2.1 of [4], the
387 client sends a bind request in which the version number is 3, the
388 authentication choice is sasl, the sasl mechanism name is "DIGEST-MD5",
389 and the credentials are absent. The client then waits for a response
390 from the server to this request.
392 Wahl, Alvestrand, Hodges, Morgan Page 7
394 INTERNET-DRAFT Authentication Methods for LDAP June 1999
396 The server will respond with a bind response in which the resultCode
397 is saslBindInProgress, and the serverSaslCreds field is present. The
398 contents of this field is a string defined by "digest-challenge" in
399 section 2.1.1 of [4]. The server SHOULD include a realm indication and
400 MUST indicate support for UTF-8.
402 The client will send a bind request with a distinct mesage id, in which
403 the version number is 3, the authentication choice is sasl, the sasl
404 mechanism name is "DIGEST-MD5", and the credentials contain the string
405 defined by "digest-response" in section 2.1.2 of [4]. The serv-type
408 The server will respond with a bind response in which the resultCode
409 is either success, or an error indication. If the authentication is
410 successful and the server does not support subsequent authentication,
411 then the credentials field is absent. If the authentication is
412 successful and the server supports subsequent authentication, then
413 the crendentials field contains the string defined by "response-auth"
414 in section 2.1.3 of [4]. Support for subsequent authentication is
415 OPTIONAL in clients and servers.
417 8.2. "simple" authentication choice under TLS encryption
419 A user who has a directory entry containing a userPassword attribute
420 MAY authenticate to the directory by performing a simple password
421 bind sequence following the negotiation of a TLS ciphersuite
422 providing connection confidentiality [6].
424 The client will use the Start TLS operation [5] to negotiate the
425 use of TLS security [6] on the connection to the LDAP server. The
426 client need not have bound to the directory beforehand.
428 For this authentication procedure to be successful, the client and
429 server MUST negotiate a ciphersuite which contains a bulk encryption
430 algorithm of appropriate strength. Recommendations on cipher
431 suites are given in section 12.
433 Following the successful completion of TLS negotiation, the client
434 MUST send an LDAP bind request with the version number of 3, the
435 name field containing the name of the user's entry, and the "simple"
436 authentication choice, containing a password.
438 The server will, for each value of the userPassword attribute in
439 the named user's entry, compare these for case-sensitive equality
440 with the client's presented password. If there is a match, then the
441 server will respond with resultCode success, otherwise the server will
442 respond with resultCode invalidCredentials.
448 Wahl, Alvestrand, Hodges, Morgan Page 8
450 INTERNET-DRAFT Authentication Methods for LDAP June 1999
452 8.3. Other authentication choices with TLS
454 It is also possible to perform a SASL authentication exchange of
455 passwords following the negotiation of TLS. In this case the
456 client and server need not negotiate a ciphersuite which provides
457 confidentiality if the only service required is data integrity.
459 9. Certificate-based authentication
461 LDAP implementations SHOULD support authentication via a client
462 certificate in TLS, as defined in section 9.1.
464 9.1. Certificate-based authentication with TLS
466 A user who has a public/private key pair in which the public key has
467 been signed by a Certification Authority may use this key pair to
468 authenticate to the directory server if the user's certificate is
469 requested by the server. The user's certificate subject field
470 SHOULD be the name of the user's directory entry, and the
471 Certification Authority must be sufficiently trusted by the
472 directory server to have issued the certificate in order that the
473 server can process the certificate. The means by which servers
474 validate certificate paths is outside the scope of this document.
476 A server MAY support mappings for certificates in which the subject
477 field name is different from the name of the user's directory entry.
478 A server which supports mappings of names MUST be capable of being
479 configured to support certificates for which no mapping is required.
481 The client will use the Start TLS operation [5] to negotiate the
482 use of TLS security [6] on the connection to the LDAP server. The
483 client need not have bound to the directory beforehand.
485 In the TLS negotiation, the server MUST request a certificate. The
486 client will provide its certificate to the server, and MUST perform
487 a private key-based encryption, proving it has it private key
488 associated with the certificate.
490 As deployments will require protection of sensitive data in transit,
491 the client and server MUST negotiate a ciphersuite which contains a
492 bulk encryption algorithm of appropriate strength. Recommendations
493 of cipher suites are given in section 12.
495 The server MUST verify that the client's certificate is valid.
496 The server will normally check that the certificate is issued by a
497 known CA, and that none of the certificates on the client's
498 certificate chain are invalid or revoked. There are several
499 procedures by which the server can perform these checks.
501 Following the successful completion of TLS negotiation, the client
502 will send an LDAP bind request with the SASL "EXTERNAL" mechanism.
504 Wahl, Alvestrand, Hodges, Morgan Page 9
506 INTERNET-DRAFT Authentication Methods for LDAP June 1999
510 The LDAP "simple" authentication choice is not suitable for
511 authentication on the Internet where there is no network or transport
512 layer confidentiality.
514 As LDAP includes a native anonymous and plaintext authentication
515 methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used
516 with LDAP. If an authorization identity of a form different from
517 a DN is requested by the client, a mechanism that protects the
518 password in transit SHOULD be used.
520 The following SASL-based mechanisms are not considered in this
521 document: KERBEROS_V4, GSSAPI and SKEY.
523 The "EXTERNAL" SASL mechanism can be used to request the LDAP server
524 make use of security credentials exchanged by a lower layer. If a
525 TLS session has not been established between the client and server
526 prior to making the SASL EXTERNAL Bind request and there is no other
527 external source of authentication credentials (e.g. IP-level
528 security [8]), or if, during the process of establishing the
529 TLS session, the server did not request the client's authentication
530 credentials, the SASL EXTERNAL bind MUST fail with a result code of
531 inappropriateAuthentication. Any authentication identity and
532 authorization identity, as well as TLS connection, which were in
533 effect prior to making the Bind request, MUST remain in force.
535 11. Authorization Identity
537 The authorization identity is carried as part of the SASL credentials
538 field in the LDAP Bind request and response.
540 When the "EXTERNAL" mechanism is being negotiated, if the
541 credentials field is present, it contains an authorization identity
542 of the authzId form described below.
544 Other mechanisms define the location of the authorization
545 identity in the credentials field.
547 The authorization identity is a string in the UTF-8 character set,
548 corresponding to the following ABNF [7]:
550 ; Specific predefined authorization (authz) id schemes are
551 ; defined below -- new schemes may be defined in the future.
553 authzId = dnAuthzId / uAuthzId
555 ; distinguished-name-based authz id.
557 dn = utf8string ; with syntax defined in RFC 2253
560 Wahl, Alvestrand, Hodges, Morgan Page 10
562 INTERNET-DRAFT Authentication Methods for LDAP June 1999
564 ; unspecified userid, UTF-8 encoded.
565 uAuthzId = "u:" userid
566 userid = utf8string ; syntax unspecified
568 A utf8string is defined to be the UTF-8 encoding of one or more
569 ISO 10646 characters.
571 All servers which support the storage of authentication credentials,
572 such as passwords or certificates, in the directory MUST support the
575 The uAuthzId choice allows for compatibility with client applications
576 which wish to authenticate to a local directory but do not know their
577 own Distinguished Name or have a directory entry. The format of the
578 string is defined as only a sequence of UTF-8 encoded ISO 10646
579 characters, and further interpretation is subject to prior agreement
580 between the client and server.
582 For example, the userid could identify a user of a specific directory
583 service, or be a login name or the local-part of an RFC 822 email
584 address. In general a uAuthzId MUST NOT be assumed to be globally
587 Additional authorization identity schemes MAY be defined in future
588 versions of this document.
592 The following ciphersuites defined in [6] MUST NOT be used for
593 confidentiality protection of passwords or data:
595 TLS_NULL_WITH_NULL_NULL
596 TLS_RSA_WITH_NULL_MD5
597 TLS_RSA_WITH_NULL_SHA
599 The following ciphersuites defined in [6] can be cracked easily
600 (less than a week of CPU time on a standard CPU in 1997). The
601 client and server SHOULD carefully consider the value of the
602 password or data being protected before using these ciphersuites:
604 TLS_RSA_EXPORT_WITH_RC4_40_MD5
605 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
606 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
607 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
608 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
609 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
610 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
611 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
612 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
616 Wahl, Alvestrand, Hodges, Morgan Page 11
618 INTERNET-DRAFT Authentication Methods for LDAP June 1999
620 The following ciphersuites are vulnerable to man-in-the-middle
621 attacks, and SHOULD NOT be used to protect passwords or sensitive
622 data, unless the network configuration is such that the danger of
623 a man-in-the-middle attack is tolerable:
625 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
626 TLS_DH_anon_WITH_RC4_128_MD5
627 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
628 TLS_DH_anon_WITH_DES_CBC_SHA
629 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
631 A client or server that supports TLS MUST support at least
632 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
634 13. SASL service name for LDAP
636 For use with SASL [2], a protocol must specify a service name to be
637 used with various SASL mechanisms, such as GSSAPI. For LDAP, the
638 service name is "ldap", which has been registered with the IANA
639 as a GSSAPI service name.
641 14. Security Considerations
643 Security issues are discussed throughout this memo; the
644 (unsurprising) conclusion is that mandatory security is important,
645 and that session encryption is required when snooping is a
648 Servers are encouraged to prevent modifications by anonymous
649 users. Servers may also wish to minimize denial of service attacks
650 by timing out idle connections, and returning the unwillingToPerform
651 result code rather than performing computationally expensive
652 operations requested by unauthorized clients.
654 A connection on which the client has not performed the Start TLS
655 operation or negotiated a suitable SASL mechanism for connection
656 integrity and encryption services is subject to man-in-the-middle
657 attacks to view and modify information in transit.
659 Additional security considerations relating to the EXTERNAL
660 EXTERNAL mechanism to negotiate TLS can be found in [2], [5]
665 This document is a product of the LDAPEXT Working Group of the
666 IETF. The contributions of its members is greatly appreciated.
672 Wahl, Alvestrand, Hodges, Morgan Page 12
674 INTERNET-DRAFT Authentication Methods for LDAP June 1999
678 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
679 Protocol (v3)", Dec. 1997, RFC 2251.
681 [2] J. Myers, "Simple Authentication and Security Layer (SASL)",
684 [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement
687 [4] P. Leach, C. Newman, "Using Digest Authentication as a SASL
688 Mechanism", INTERNET DRAFT <draft-leach-digest-sasl-00.txt>.
690 [5] J. Hodges, RL Morgan, M. Wahl, "LDAPv3 Extension for Transport
691 Layer Security", Oct. 1998, INTERNET DRAFT
692 <draft-ietf-ldapext-ldapv3-tls-03.txt>.
694 [6] T. Diers, C. Allen, "The TLS Protocol Version 1.0", Jan. 1999,
697 [7] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
698 Specifications: ABNF", RFC 2234.
700 [8] S. Kent, R. Atkinson, "Security Architecture for the Internet
701 Protocol", Nov. 1998, RFC 2401.
706 Innosoft International, Inc.
707 8911 Capital of Texas Hwy, Suite 4140
710 Phone: +1 512 231 1600
711 EMail: Mark.Wahl@innosoft.com
713 Harald Tveit Alvestrand
714 EMail: Harald.Alvestrand@maxware.no
717 Computing & Communication Services
721 Stanford, CA 94305-4122
723 Phone: +1-650-723-2452
724 EMail: Jeff.Hodges@Stanford.edu
728 Wahl, Alvestrand, Hodges, Morgan Page 13
730 INTERNET-DRAFT Authentication Methods for LDAP June 1999
733 Computing & Communication Services
737 Stanford, CA 94305-4122
739 Phone: +1-650-723-9711
740 EMail: Bob.Morgan@Stanford.edu
742 Full Copyright Statement
744 Copyright (C) The Internet Society (1998). All Rights Reserved.
746 This document and translations of it may be copied and furnished to
747 others, and derivative works that comment on or otherwise explain it
748 or assist in its implementation may be prepared, copied, published
749 and distributed, in whole or in part, without restriction of any
750 kind, provided that the above copyright notice and this paragraph are
751 included on all such copies and derivative works. However, this
752 document itself may not be modified in any way, such as by removing
753 the copyright notice or references to the Internet Society or other
754 Internet organizations, except as needed for the purpose of
755 developing Internet standards in which case the procedures for
756 copyrights defined in the Internet Standards process must be
757 followed, or as required to translate it into languages other than
760 The limited permissions granted above are perpetual and will not be
761 revoked by the Internet Society or its successors or assigns.
763 This document and the information contained herein is provided on an
764 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
765 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
766 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
767 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
768 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
783 Wahl, Alvestrand, Hodges, Morgan Page 14