comments on draft-ietf-ldapext-authmeth-01.txt

[Jeff.Hodges@stanford.edu]

Overall comments..

1. I think this document is needed. Tho, is it an explicit "Applicability 
Statement (AS)" per rfc2026? It perhaps should explicitly say so, if is 
actually intended as such.

2. some of my comments refer to the concept of "authorization identities" 
(aka "authz ids"). Refer to sections 6.X of draft-ietf-ldapext-ldapv3-tls-00.tx
t for a discussion of them.

3. The terms "user" and "users" are utilized pervasively in this doc in 
regards to entities making LDAP requests. To me, it is strongly assuming that 
LDAP requestors will typically be humans --
moreover, humans who have directory entries corresponding to them. I think 
that LDAP's wide applicability and allowance for autonomous instances negate 
those assumptions. 

For example, a network management station might be utilizing LDAP to query 
data-collection agents -- which are acting as LDAP servers. This is the sort 
of scenario envisioned by the MS-Cisco Directory Enabled Networks (DEN) 
initiative. These LDAP servers, nee agents, may only maintain info about 
device objects, not about users or whatever other entities are acting as 
requesters. Expecting that this server would be able to act as an LDAP client 
to look up info about the requesting entity in yet another directory instance 
seems unreasonable. (see http://www.stanford.edu/~hodges/doc/AuthzIDsNotRestric
tedToDNs.txt for a related discussion)

At a minimum, I think we should change the term "user(s)" in the document to 
"requesting entity(ies)" or something similar.

4. I think the various deployment scenarios in section 4 are artificially 
distinct.


Thanks,

Jeff


> Network Working Group                                            M. Wahl
> INTERNET-DRAFT                                       Critical Angle Inc.
>                                                            H. Alvestrand
>                                                               MaXware AS
> Expires in six months from                              January 28, 1998
> 
> 
>                       Authentication Methods for LDAP
>                    <draft-ietf-ldapext-authmeth-01.txt>
> 
> 1. Status of this Memo
> 
>    This document is an Internet-Draft.  Internet-Drafts are working docu-
>    ments of the Internet Engineering Task Force (IETF), its areas, and its
>    working groups.  Note that other groups may also distribute working
>    documents as Internet-Drafts.
>  
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference material
>    or to cite them other than as ``work in progress.''
>  
>    To learn the current status of any Internet-Draft, please check the
>    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
>    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
>    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
>    ftp.isi.edu (US West Coast).
> 
> 2. Abstract
> 
>    This document specifies particular combinations of SASL [2] mechanisms
>    and extensions which are required and recommended in LDAP [1] 
>    implementations.

The abstract could be more descriptive. Probably should mention & reference 
TLS as well as SASL.

Is this doc an explicit "Applicability Statement (AS)" per rfc2026? It perhaps 
should explicitly say so, if is actually intended as such. 


>    The key words ''MUST'', ''MUST NOT'', ''REQUIRED'', ''SHALL'', ''SHALL NOT'', 
>    ''SHOULD'', ''SHOULD NOT'', ''RECOMMENDED'',  ''MAY'', and ''OPTIONAL'' in 
>    this document are to be interpreted as described in RFC 2119 [3].

This should be it's own little section so it doesn't get included with the 
abstract in references & compilations.


> 
> 3. Introduction
> 
>     LDAP version 3 is a powerful access protocol for directories.
> 
>     It offers means of searching, fetching and manipulating directory
>     content, and ways to access a rich set of security functions.
> 
>     In order to function for the best of the Internet,..


Perhaps need to more explicitly define this doc's "domain of applicability" 
per rfc2026. 


>     ..it is vital
>     that these security functions be interoperable; therefore there
>     has to be a minimum subset of security functions that is common to
>     all implementations that claim LDAPv3 conformance.
> 
> 
> 
> 
> 
> 
> Wahl et al.          Authentication Methods for LDAP           [Page 1]
> 
> INTERNET-DRAFT     draft-ietf-ldapext-authmeth-01.txt      January 1998
> 
>     2.  Threats to an LDAP directory

Need to left-shift section 2.


> 
>     The basic threats to the LDAP service are:
                           ^^^^^^^^^^^^^^^^^^^^

I think it'd be better to use "an LDAP-based directory service are".

> 
>      (1)   Unauthorized access to data via data-fetching operations,
> 
>      (2)   Unauthorized access to data by monitoring others' access,
> 
>      (3)   Unauthorized modification of data,
> 
>      (4)   Unauthorized modification of configuration,
> 
>      (5)   Unauthorized use of resources (denial of service), and
> 
>      (6)   Spoofing of directory: Tricking a client into believing
>            that information came from the directory when in fact it
>            did not.
> 
>     The LDAP protocol suite can be protected with the following
>     security mechanisms:
> 
>      (1)   Client authentication by means of the SASL mechanism set,
>            possibly backed by the TLS credentials exchange mechanism,
> 
>      (2)   Client authorization by means of access control based on
>            the authenticated identity,
                ^
        requesting entity's



> 
>      (3)   Snoop protection by means of the TLS protocol,
                                                          ^
                                                  or SASL mechanisms



> 
>      (4)   Resource limitation by means of administrative limits on
>            service controls, and
> 
>      (5)   Server authentication by means of the TLS protocol.
> 
>     At the moment, imposition of access controls is done by means
>     outside the scope of the LDAP protocol.  
> 
> 4.  Deployment scenarios
> 
>     The following scenarios make sense for LDAP, and have vastly
>     different security requirements. (In the following, "sensitive"
>     means data that will cause real damage to the owner if revealed;
>     there may be data that is protected but not sensitive)
> 
>      (1)   A read-only directory, containing no sensitive data,
>            accessible to "anyone". This directory requires no security
>            functions except the service limits.
> 
> 
> 
> 
> 
> Wahl et al.          Authentication Methods for LDAP           [Page 2]
> 
> INTERNET-DRAFT     draft-ietf-ldapext-authmeth-01.txt      January 1998
> 
>      (2)   A read-only directory containing no sensitive data; read
>            access is granted based on identity.  This scenario requires 
                                        ^^^^^^^^
                                it might also be based on other things --
				ip addr, source domain, etc. See discussion
				of "authorization factors" in
				draft-ietf-ldapext-ldapv3-tls-00.txt




>            a secure authentication function.  TCP connection hijacking 
>            is not currently a problem.
             ^^^^^^^^^^^^^^^^^^^^^^^^^^

Why? An appendix explaining why w/appropriate refs is appropriate. In any 
case, I'm not sure I believe this claim.

Maybe I don't understand this correctly, but couldn't an attacker utilize 
connection hijacking to masquerade as the directory server and thus feed bogus 
data back to an unsuspecting client?

If so, its hard to quantify how that bogus data might affect the consumer -- 
disclosure of the data in its original form on the legitimate server may be 
harmless to the serving entity, but who knows in what manner the consumer is 
relying on it and thus the level of damage potentially induced by bogus data.

Is this the nature of situation you're imagining in this scenario (i.e. active 
masquerade of either client or server by an attacker)? If not, then I'm not 
sure what you're getting at.


> 
>      (3)   A read-write directory, containing no sensitive data; read
>            access is available to "anyone", update access to properly
>            authorized persons.  This scenario requires a secure 
>            authentication function.  TCP connection hijacking is not
>            currently a problem.


Overall, this "deployment scenarios" taxonomy is artificially separating cases 
that will be more blurred together in practice. Specifically, the case of..

  Read-write directory w/ sensitive & non-sensitive data. Access to classes of 
  data based upon authz id of requesting entity. Effectively "read access of 
  some data to some requesting entities, write access to some data to some 
  requesting entities". 

This will be a common occurance in practice, based on our experience. 


> 
>      (4)   A directory containing sensitive data.  This scenario
>            session confidentiality protection AND secure authentication.
            ^
         requires?



> 
>     This document does not describe the requirements for use of LDAP
>     in physically protected networks; this is concerned with LDAP used
>     on the Internet.
> 
> 5.  Choice of mandatory security mechanisms

Perhaps rename section to..

      "Required security mechanisms"

> 
>     It is clear that allowing any implementation, faced with the above
>     requirements, to pick and choose among the possible alternatives
>     is not a strategy that is likely to lead to interoperability. In
>     the absence of mandates, clients will be written that do not
>     support any security function supported by the server, or worse,
>     support only mechanisms like cleartext passwords that provide
>     clearly inadequate security.
> 
>     Given the presence of the Directory, there is a strong desire to
>     see mechanisms where identities take the form of a Distinguished
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     Name and authentication data can be stored in the directory; this
      ^^^^^

This can't and shouldn't be the only approach. See our discussion of 
authorization (authz) ids...

  http://www.stanford.edu/~hodges/doc/AuthzIDsNotRestrictedToDNs.txt



>     means that either this data is useless for faking authentication
>     (like the Unix "/etc/passwd" file format used to be), or its
>     content is never passed across the wire unprotected - that is,
>     it's either updated outside the protocol or it is only updated in
>     sessions well protected against snooping.
> 
>     At the moment, only implementations using public key cryptography
>     satisfy the requirement that it be useless for faking
>     authentication.

What about Kerberos? I believe it meets the above broad definition. And what 
is the precise definition of "faking authentication"? Should supply an 
applicable reference.


> 
>     Therefore, the following mandates are in place:

I'm not sure "mandates" is the appropriate word. What audience is this doc 
trying to address? Implementors? Then perhaps these are "implementation 
conformance requirements".

> 
>      (1)   For a read-only, public directory, anonymous authentication, 
>            described in section 6, can be used.

enhancement, given comments on scenarios above..

      (1)   For read-only, public portions of a directory, anonymous 
            authentication, described in section 6, can be used.



> 
>      (2)   Implementations MUST support password-based authentication 
>            using CRAM-MD5, as described in section 7.1.
> 
> 
> 
> 
> Wahl et al.          Authentication Methods for LDAP           [Page 3]
> 
> INTERNET-DRAFT     draft-ietf-ldapext-authmeth-01.txt      January 1998
> 
>      (3)   For a directory needing session protection and
>            authentication, Start TLS with the SASL EXTERNAL mechanism
>            is to be used.  ...

perhaps this should be restated like..

      (3)   Implementations MUST support the Start TLS extended operation
            as well as the SASL EXTERNAL mechanism, in order to meet the       
            requirements for session protection and authentication. ...

>		...	Implementations SHOULD support authentication
>            with a password as described in section 7.2, and SHOULD
>            support authentication with a certificate as described in 
>            section 8.1.
> 
> 6. Anonymous authentication
> 
>    Anonymous authentication is suitable for users who do not intend to
                                              ^^^^^

Need to better define this, as discussed above. Perhaps should be "requesting 
entities" -- won't always be humans, & won't always already have directory 
entry in the target directory or the local/general dir svc contexts it may 
participate in.



>    modify directory entries and do not require access to protected 
>    attributes or entries.
> 
>    LDAP implementations MUST support anonymous authentication, as 
>    defined in section 6.1.
> 
>    While there MAY be access control restrictions to prevent access to 
>    directory entries, an LDAP server MUST allow an anonymously-bound 
>    client to retrieve the supportedSASLMechanisms attribute of the root 
>    DSE.
> 
> 6.1. Anonymous authentication procedure
> 
>    An LDAP client which has not successfully completed a bind operation 
>    on a connection is anonymously authenticated.
> 
>    An LDAP client MAY also specify anonymous authentication in a bind 
>    request by using a zero-length OCTET STRING with the simple
>    authentication choice.
> 
> 6.2. Anonymous authentication and TLS
> 
>    An LDAP client MAY use the Start TLS operation [5] to negotiate the
>    use of TLS security [6].  If the client has not bound beforehand and
>    does not present a certificate during TLS negotiation, then the 
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    client is anonymously authenticated.

Not necessarily. First, the server must explicitly request a client cert -- 
whether to do this or not is a matter of local server-side policy. Also, the 
requesting entity (i.e. client) can remain anonymous (if it was prior to 
issuing StartTLS request) even if the server does req a client cert -- this is 
a matter of both local policy on the server and whether the client explicitly 
requests mapping of its cert-borne auth id to its ldap authz id via subsequent 
issuing of a SASL EXTERNAL-flavored Bind request. And even then, whether that 
is accepted or not is a matter of local (i.e. server-side) policy.


> 
> 7. Password-based authentication
> 
>    LDAP implementations MUST support authentication with a password using
>    the CRAM-MD5 mechanism for password protection, as defined in section 
>    7.1.  
> 
>    LDAP implementations SHOULD support authentication with the "simple"
>    password choice when the connection is protected against eavesdropping
>    using TLS, as defined in section 7.2.
> 
> 
> 
> 
> 
> 
> Wahl et al.          Authentication Methods for LDAP           [Page 4]
> 
> INTERNET-DRAFT     draft-ietf-ldapext-authmeth-01.txt      January 1998
> 
> 7.1. CRAM-MD5 authentication
> 
>    A user who has a directory entry containing a userPassword attribute
       ^^^^
    "requesting entity"


>    may authenticate to the directory by performing a protected password
>    bind sequence based on the CRAM-MD5 mechanism [4].
> 
>    An LDAP client may determine whether the server supports this 
>    mechanism by performing a search request on the root DSE, requesting
>    the supportedSASLMechanisms attribute, and checking whether the 
>    string "CRAM-MD5" is present as a value of this attribute.
> 
>    In the first stage of authentication, the client sends a bind 
>    request in which the version number is 3, the name field is the name 
>    of the user's entry, the authentication choice is sasl, the sasl 
>    mechanism name is "CRAM-MD5", and the credentials are absent.  The
>    client then waits for a response from the server to this request.
> 
>    The server shall generate a challenge and return a bind response in
>    which the resultCode is saslBindInProgress, and the serverSaslCreds
>    field is present.  The contents of the serverSaslCreds string is 
>    the challenge, which is not base64 encoded.  An example challenge is
>    "<1896.697170952@postoffice.reston.mci.net>".  Note that in this 
>    stage of the mechanism, the server need not access the user's entry.
>    The server will save the challenge internally, associated with the
>    connection, until the next stage of the bind operation is completed.
>    The challenge string will not reused, however.
>    
>    Upon receipt of the challenge, the client will generate the response
>    digest value, which is a string of 32 hexadecimal digits.  An 
>    example digest derived from the above challenge and the password 
>    "tanstaaftanstaaf" is "b913a602c7eda7a495b4e6e7334d3890". The client
>    will send a bind request, with a different message id, in which the
>    version number is 3, the name field is the name of the user's entry,
>    the authentication choice is sasl, the sasl mechanism name is 
>    "CRAM-MD5", and the credentials field contains a concatenation of 
>    the name of the user's entry, a space character (ASCII 32), and the 
>    digest string.  The client then will waits for another response from 
                                              ^
>    the server.
> 
>    The server will then, for each value of the userPassword attribute 
>    in the named user's entry, generate the digest value itself, and 
>    compare the result with the client's presented digest.  If there is 
>    a match, then the server will respond with resultCode success, 
>    otherwise the server will respond with resultCode invalidCredentials.
>    The serverSaslCreds field will be absent.
> 
> 
> 
> 
> 
> 
> 
> Wahl et al.          Authentication Methods for LDAP           [Page 5]
> 
> INTERNET-DRAFT     draft-ietf-ldapext-authmeth-01.txt      January 1998
> 
>    If the client does not complete the SASL negotiation, the server 
>    MUST delete the challenge from memory, as challenge strings MUST
>    never be used twice.  ....

Shouldn't the server be explicitly required to delete the challenge from 
memory upon successful completion?



>            .... A client MUST NOT send more than one bind 
>    request containing response digest values in which the same challenge
>    string was used.  If a client wishes to change authentication, it
>    MUST start from the beginning and request a new challenge.
> 
> 7.2. "simple" authentication choice under encryption
> 
>    A user who has a directory entry containing a userPassword attribute
>    can authenticate to the directory by performing a simple password
     ^^^
  Should this perhaps be "MAY"?



>    bind sequence following the negotiation of a TLS ciphersuite 
>    providing connection confidentiality [6].
> 
>    The client will use the Start TLS operation [5] to negotiate the 
>    use of TLS security [6] on the connection to the LDAP server.  The
>    client need not have bound to the directory beforehand.
> 
>    For this authentication procedure to be successful, the client and 
>    server MUST negotiate a ciphersuite which contains a cipher 
>    algorithm.  The following are NOT permitted:
> 
>          TLS_NULL_WITH_NULL_NULL
>          TLS_RSA_WITH_NULL_MD5
>          TLS_RSA_WITH_NULL_SHA
> 
>    The RECOMMENDED ciphersuite is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
> 
>    Following the successful completion of TLS negotiation, the client
>    MUST send an LDAP bind request with the version number of 3, the 
>    name field containing the name of the user's entry, and the "simple" 
>    authentication choice, containing a password.
> 
>    The server will, for each value of the userPassword attribute in 
>    the named user's entry, compare these for case-sensitive equality 
>    with the client's presented password.  If there is a match, then the 
>    server will respond with resultCode success, otherwise the server will
>    respond with resultCode invalidCredentials.
> 
> 8. Certificate-based authentication
> 
>    LDAP implementations SHOULD support authentication via a client 
>    certificate in TLS, as defined in section 8.1.  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Wahl et al.          Authentication Methods for LDAP           [Page 6]
> 
> INTERNET-DRAFT     draft-ietf-ldapext-authmeth-01.txt      January 1998
> 
> 8.1. Certificate-based authentication with TLS
> 
>    A user who has a public/private key pair in which the public key has
>    been signed by a Certification Authority may use this key pair to
                                              ^^^^^^^^^^^^^^^^^^^^^^^^
>    authenticate to the directory server. ...
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This implies client choice, but in TLS, it is the server which decides whether 
to explicitly request a client cert or not. See [6] section 7.4.4



>				.......  The user's certificate 
                                             ^^^^^^^^^^^^^^^^^^
>    subject field SHOULD be the name of the user's directory entry, and
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                    MAY?


See discussion of authz identity mapping above. 


>    the Certification Authority must be sufficiently trusted by the 
                                 ^^^^
                                SHOULD?
>    directory server to have issued the certificate.

TLS itself doesn't make any provisions for "certificate status validation" 
(CSV). That is left up to whatever PKI tls is being utilized within. PKIX et 
al would seem to be the appropriate doc set to reference here.

[ Note that PKIX (i.e. draft-ietf-pkix-ipki-part1-06.txt et al) isn't yet an 
RFC, so that may hold up this draft, as well as TLS protocol draft and 
StartTLS draft (by reference). ]



> 
>    The client will use the Start TLS operation [5] to negotiate the 
>    use of TLS security [6] on the connection to the LDAP server.  The
>    client need not have bound to the directory beforehand.
> 
>    In the TLS negotiation, the server MUST request a certificate. ...

Correct. Perhaps needs some elucidation here because whether the server reqs 
the client cert or not is (or SHOULD be in impls) a matter of local 
server-side policy. In this case, in order to accomplish this section's goals, 
it is a MUST. Also note that the client can't simply supply one gratis.


>								... The
>    client will provide its certificate to the server, and MUST perform 
>    a private key-based encryption, proving it has it private key 
>    associated with the certificate.  
> 
>    As deployments will require protection of sensitive data in transit,
>    the client and server MUST negotiate a ciphersuite which contains a 
>    cipher algorithm.  The following are NOT permitted:
> 
>          TLS_NULL_WITH_NULL_NULL
>          TLS_RSA_WITH_NULL_MD5
>          TLS_RSA_WITH_NULL_SHA
> 
>    The RECOMMENDED ciphersuite is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
> 
>    The server MUST verify that the client's certificate is valid, 
>    issued by a known CA, and that none of the certificates on the 
>    client's certificate chain are invalid or revoked.

How? Need to supply references. Only present candidate is PKIX et al, it 
seems. TLS itself explicitly doesn't specify this (see [6] appendix D.3.).

The last paragraph above is an explicit requirement for CSV functionality, 
which is being discussed in the PKIX group, but nothing (to my knowledge) is 
really specified except for CRLs (certificate revocation lists). More scalable 
(in terms of lower latencies, less client groveling thru mounds of data, and 
overall transaction density) are being actively discussed.

> 
>    Following the successful completion of TLS negotiation, the client
>    MUST send an LDAP bind request with the SASL "EXTERNAL" mechanism.  
     ^^^^

But [5] explicitly says it is a MAY. Need to elucidate why here we're 
requiring it to be a MUST.



>    The format of this bind request and the server's behavior is defined 
>    in section 6.2 of [5].
> 
>    If the server receives a bind request with the EXTERNAL SASL
>    mechanism name and TLS has not been negotiated, it SHOULD return a
>    resultCode of invalidCredentials.
> 
> 9. Limited Use

Limited use of what? Is this the "limited use" term in the formal sense 
outlined in rfc2026? should supply reference if so.

> 
>    The LDAP "simple" authentication choice is not suitable for 
>    authentication on the Internet where there is no network or transport 
>    layer confidentiality.
> 
>    As LDAP includes a native anonymous and plaintext authentication 
>    methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used 
>    with LDAP.
> 
> 
> Wahl et al.          Authentication Methods for LDAP           [Page 7]
> 
> INTERNET-DRAFT     draft-ietf-ldapext-authmeth-01.txt      January 1998
> 


>    The following SASL-based mechanisms are not considered in this 
>    document: KERBEROS_V4, GSSAPI and SKEY.

Why? privacy and integrity services are also offered by some of these 
approaches. What about Microsoft's move towards kerberos? It's going to be 
being widely used, and for directories too.

Simply overlooking the relevance of these approaches isn't reasonable when 
there are significant sites which already have these technologies (kerberos in 
particular) actively deployed.

These approaches need to be discussed in this doc. 

> 
> 10. Security Considerations
> 
>    Security issues are discussed throughout this memo; the
>    (unsurprising) conclusion is that mandatory security is important,
>    and that session encryption is required when snooping is a
>    problem.
> 
>    Servers are encouraged to prevent DIT modifications by anonymous 
>    users. Servers may also wish to minimize denial of service attacks 
>    by timing out idle connections, and returning the unwillingToPerform
>    result code rather than performing computationally expensive 
>    operations requested by unauthorized clients.
> 
>    A connection on which the client has not performed the Start TLS 
>    operation or negotiated a suitable SASL mechanism for connection 
>    integrity and encryption services is subject to man-in-the-middle 
>    attacks to view and modify information in transit.
> 
>    Additional security considerations relating to the CRAM-MD5 
>    mechanism can be found in [4], and security considerations relating
>    to the EXTERNAL mechanism to negotiate TLS can be found in [2], [5]
>    and [6].  
> 
> 11. Acknowledgements
> 
>    This document is a product of the LDAPEXT Working Group of the 
>    IETF.  The contributions of its members is greatly appreciated.
> 
> 12. Bibliography
> 
>    [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 
>        Protocol (v3)", Dec. 1997, RFC 2251.
> 
>    [2] J. Myers, "Simple Authentication and Security Layer (SASL)", 
>        Oct. 1997, RFC 2222.
> 
>    [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement
>        Levels", RFC 2119.
> 
>    [4] J. Klensin, R. Catoe, P. Krumviede, "IMAP/POP AUTHorize
>        Extension for Simple Challenge/Response", Sep. 1997, RFC 2195.
> 
>    [5] J. Hodges, RL Morgan, M. Wahl, "LDAPv3 Extension for Transport
>        Layer Security", Aug. 1997, INTERNET DRAFT
>        <draft-ietf-asid-ldapv3-tls-02.txt>.
	  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

please update to point to draft-ietf-ldapext-ldapv3-tls-00.txt


> 
>    [6] T. Diers, C. Allen, "The TLS Protocol Version 1.0", Oct. 1997,
>        INTERNET DRAFT <draft-ietf-tls-protocol-04.txt>.
> 
> Wahl et al.          Authentication Methods for LDAP           [Page 8]
> 
> INTERNET-DRAFT     draft-ietf-ldapext-authmeth-01.txt      January 1998
> 
> 13. Authors Address
> 
>     Mark Wahl
>     Critical Angle Inc.
>     4815 West Braker Lane #502-385
>     Austin, TX 78759 USA
> 
>     EMail:  M.Wahl@critical-angle.com
> 
> 
>     Harald Tveit Alvestrand
>     Harald.Alvestrand@maxware.no
> 
> Full Copyright Statement
> 
>    Copyright (C) The Internet Society (1998).  All Rights Reserved.
> 
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph are
>    included on all such copies and derivative works.  However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
> 
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assigns.
> 
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Wahl et al.          Authentication Methods for LDAP           [Page 9]
> 
> 
>