RE: RFC 2251 anonymous vs unauthenticated

[Bruce Greenblatt <Bgreenblatt@rsa.com>]

John,

LDAP does not prohibit the association of an identity with a connection when
no authentication is required.  It just doesn't let you do this with the
simple bind mechanism defined in RFC 2251 (and RFC 1777 for that matter).
If you have this requirement, then the simplest thing to do is to define a
SASL mechanism (as defined in RFC 2222) that takes only a distinguished
name, email address, or whatever.  This mechanism would end up being
virtually identical to the "anonymous" SASL mechanism that is defined in RFC
2245.  Don't forget to register your new SASL mechanism with IANA.

Bruce

> -----Original Message-----
> From:	John Aurich [SMTP:JAURICH@novell.com]
> Sent:	Friday, May 01, 1998 2:58 PM
> To:	ietf-ldapext@netscape.com
> Cc:	BTHORNE@novell.com; CCASTLETON@novell.com; DMAHLUM@novell.com;
> DWILBUR@novell.com; FLWO@novell.com; JAURICH@novell.com;
> MMEREDIT@novell.com; RCAMPBEL@novell.com; RHARRISON@novell.com;
> RWEISER@novell.com
> Subject:	RFC 2251 anonymous vs unauthenticated
> 
> We at Novell, along with other concerned organizations,
> suggest that there is an important difference between
> associating an identity with a connection (binding), and
> proving that the client is the identity that it claimed to
> be (authenticating).
> 
> We also suggest that there is desirable value in allowing
> Administrators to configure multiple DNs which do not require
> authentication, but do provide various environment or network
> access characteristics which are different from anonymous.
> 
> This philosophy prompted the following discussion regarding
> Bind Requests using the simple bind mechanism.  The current
> intent of RFC 2251 is to force all passwordless simple Bind
> Requests to be treated as the anonymous bind request.  I have
> been asked to obtain additional input from the greater LDAP
> community.
> 
> ============================================================
> 
> Thanks for clarifying the original intent of the simple bind
> request, Tim.  I still do not understand what the expected
> benefit is from this intention.  It could actually cause more
> problems than it may solve.
> 
> It appears that many common network protocols and
> authentication utilities (TELNET, FTP, rlogin/rsh, NetWare
> NCPs, NT Logon, UNIX and NetWare Login to name a few)
> differentiate between the two operations contained in the
> Bind Request message.
> 
> They permit the absence of authentication information, and do
> not attempt to reinterpret these bind requests nor force them
> to succeed.  They allow and rely on Administrators to set up
> the desired authentication configuration.  This philosophy is
> straight forward and easy to use, for both the developer and
> the user.
> 
> The unique behavior imposed by the current LDAP protocol
> should be understood by all LDAP consumers.  For instance,
> Administrators may be free to set up their DIT with certain
> DNs that do not require passwords, but everyone using the
> LDAP protocol to bind in this DIT needs to be aware that:
> 
>     1. LDAP can never bind to those DNs using the simple bind
>     mechanism.  Although this mechanism would seem a rather
>     natural choice for binding to DNs without passwords, it
>     is the only mechanism that expressly forbids it.  And
>     according to section 4.2.2, the simple bind mechanism
>     MUST be chosen if no authentication is to be performed.
> 
>     2. LDAP might happen to bind to those DNs using other
>     methods or mechanisms, such as "when authentication has
>     been performed at a lower layer, or when using SASL
>     credentials with a mechanism that includes the LDAPDN in
>     the credentials", section 4.2.  This appears to be at
>     odds with section 4.2.2.  Are all methods preceding an
>     LDAP bind supposed to have a special case for null
>     passwords?
> 
>     3. Applications which require user input for bind should
>     determine what the user actually meant when a DN and a
>     zero length password were entered (or vice versa) and act
>     accordingly.  Was it a simple mistake?  Will the
>     underlying bind mechanism ignore half of the input?  Does
>     the user care if they are bound as anonymous instead?
> 
> Customers and developers may become frustrated with the
> inconsistent behavior and imposed limitations of their LDAP
> application, and consider it "broken" until they are
> indoctrinated with the LDAP Bind Request protocol and
> either accept or somehow work around this behavior.
> 
> On the other hand, all of these inconsistences would vanish
> if the protocol simply returned a result code based on the
> validation of the information provided in the Bind Request
> against the configuration established by the Administrator.
> Users could still access anonymous information if the bind
> failed, so I find that nothing is really gained by forcing
> an anonymous bind.
> 
> The authentication status of a connection may be set to
> various levels of authenticity based on the trust of the
> authentication method, but lack of authentication information
> should not automatically prohibit the bind of a specific DN.
> 
> John
> 
> 
> Tim Howes replied:
> 
> > The intention was this: As far as operations subsequent to
> > the bind are concerned (e.g., for access control purposes),
> > there is no difference between a simple bind with a zero-
> > length DN and zero-length password, the absence of any
> > bind at all, and a simple bind with some non-zero-length
> > DN and a zero-length password. The authentication status
> > of the connection should be treated the same after any of
> > these events.
> 
> > So as an implementor, if you get a simple bind with a
> > zero-length password, you may safely ignore the DN,
> > you may log the DN, or do something else with it. The
> > DN is not relevant to the authentication decision.
> 
> > One consequence of this is that it is not possible to
> > assign a zero-length password to an entry and subsequently
> > authenticate as that entry using a simple bind with a
> > zero-length password.
> 
> > Any client that is confused by this behavior (i.e., binds
> > with a zero-length password and expects to be authenticated)
> > does not conform to the standard.
> 
> > I would be happy to include some clarifying language
> > in the next revision of the documents, if this is confusing
> > to people. This is the first I've heard about this problem,
> > though. If you've got clarifying language, please feel free
> > to send it to Mark, who is the editor of 2251.      -- Tim
> 
> 
> 
> John Aurich originally wrote:
> 
> > Connectathon affiliates, authors, and noted others,
> >
> > Forward:
> > Following is a (lengthy) discussion attempting to answer
> > the basic question:
> >
> > Should all Bind Requests that include some value in the
> > name field, but omit additional information in the
> > authentication field, be viewed as unauthenticated and
> > therefore, automatically treated as anonymous Bind
> > Requests?
> >
> > This question seemed easy enough to answer through RFC
> > 2251, but after writing the detailed discussion below, I
> > find that although I have rather strong feelings in one
> > direction, I could make a good case either way from the
> > wording in the RFC.  In fact, I would have to make more
> > modifications to the RFC to support my position than to
> > support the other, even though I think my position is the
> > same as the original intent of the authors.  That is why I
> > have included them in the distribution of this discussion.
> >
> > I am requesting that a single view come out of all of this,
> > and the RFC eventually updated with more direct language
> > to reflect the final decision.  This will allow us to all
> > get going in the same cadence, prevent others from later
> > misinterpreting the RFC and also prevent the introduction
> > of conflicting products in the marketplace.
> >
> > Discuss:
> > While running the Basic LDAPv3 Interoperability Test Suite
> > (BLITS), we have come across six test cases which contain
> > simple errors themselves, but are easily diagnosed and
> > remedied.  These anomalies have been reported back to
> > Ludovic Poitou at Sun for consideration.  But one test case
> > in particular highlights a situation which seems to require
> > additional philosophical discussion.
> >
> > 3.3.1.4.2 Bind With Missing Password
> > Purpose    Test authenticated unprotected simple Bind
> >         with missing password.
> > Reference  RFC 2251 4.1.10, 4.2, 4.2.2
> > Procedure  Test authenticated unprotected simple Bind as
> >         'cn=Paul Cezanne, ou=Search, o=IMC, c=US' with a
> >          null password.
> > Expect     success (0)  The test is successful if the
> >         connection attempt is accepted, but established as
> >         an anonymous bind.  Search requests should now be
> >         accepted and processed by the server.
> >
> > This test has raised various points of view regarding Bind
> > Requests with a zero length password.  Some find that the
> > wording in RFC 2251 suggests that any passwordless Bind
> > Request is an unauthenticated bind and therefore, should
> > be treated as an anonymous bind.  If this is true, then in
> > the above test case, the server should ignore the DN in the
> > name field, bind the client as anonymous, return success,
> > and the test case stands.
> >
> > But I do not think this was the original intention of the
> > unauthenticated bind.  This interpretation seems too narrow
> > and limiting for many reasons, a few of which I'll quickly
> > highlight.
> >
> > If the server must initially fail the Bind Request 
> > internally because the DN object requires password
> > authentication, but quietly defaults the failed bind to
> > anonymous and returns success, then the client will
> > ignorantly assume that the original DN Bind Request
> > succeeded.  This bait and switch behavior at the onset of
> > a session can cause all kinds of client confusion and
> > frustration at various times later on, such as when the
> > specific DN and anonymous have different access rights to
> > the DIT.  The result to the user is that although the bind
> > succeeded, sometimes the client appears to "work"
> > correctly, and other times it is "broken" and fails to
> > access the directory, even though the Administrator granted
> > the DN explicit access.
> >
> > I have used enough login GUIs to know that when I am in a
> > hurry, or before I've had my morning <insert jumpstart
> > beverage of choice>, I can become Captain Fumblefingers and
> > inadvertently press ENTER instead of TAB to change fields
> > in the GUI.  I am comforted to know that when I accidently
> > do not supply a password, the server will fail the login
> > attempt and the application will require me to try again.
> >
> > In addition, I suggest that Administrators may choose to
> > set up different workspace environments and/or grant
> > different DIT access controls to various DNs, while not
> > requiring the clients claiming to be those DNs to prove
> > their identity.  In other words, if the directory
> > information in point does not need to be protected by
> > password authentication, then for convenience, various DNs
> > could be granted access to different kinds or locations of
> > this unprotected public information in the DIT.  If all
> > unauthenticated clients were treated as anonymous, this
> > simple and straight forward method could not be used to
> > provide this functionality.
> >
> > The main question seems to be:
> >
> > Q1. Is a Bind Request with a name but without
> >     authentication information the same as an anonymous
> >     Bind Request?
> >
> > The answer to Q1 may also spark additional questions:
> >
> > Q2. Can an Administrator set up an LDAPDN to not require a
> >     password?
> >
> > Q3. Is a valid anonymous Bind Request represented by:
> >     A. only a zero length name and a zero length password?
> >     B. a zero length name and ignore any password?
> >     C. a zero length password and ignore any name?
> >     D. some combination of the above?
> >
> > Q4. Is a valid unauthenticated Bind Request represented by:
> >     A. only a valid name with a zero length password? (bind
> >         as DN or anonymous?)
> >     B. an invalid name with a zero length password?
> >        (bind as anonymous?)
> >     C. a zero length password and ignore any name?
> >        (bind as anonymous?)
> >     D. some combination of the above?
> >
> > Q5. When may a server fail an anonymous Bind Request?
> >
> > Q6. When may a server fail an unauthenticated Bind Request?
> >
> > I searched RFCs for clarification on anonymous and
> > unauthenticated binds.  Both RFC 2251 and its predecessor,
> > RFC 1777, only mention the word 'anonymous' 3 times each.
> > None of those sections provide a definitive explanation of
> > the relationship between unauthenticated binds and
> > anonymous binds.  Not finding a direct answer, I have
> > pieced together what I feel is the intent of the anonymous
> > verses unauthenticated Bind Request philosophy.  I have
> > included pertinent excerpts of RFC 2251 below in square
> > brackets, and provided my position after the closing
> > bracket of each section.
> >
> > Surprisingly enough, I could (but generally don't) make a
> > case to support the other camp, albeit less flexible and
> > more confusing in actual implementation, in each one of
> > these sections.  But off we go.
> > [
> >     IESG Note
> >         This document describes a directory access protocol
> >         that provides both read and update access.  Update
> >         access requires secure authentication, but this
> >         document does not mandate implementation of any
> >         satisfactory authentication mechanisms.
> > ]
> > Update access requires secure authentication, but Bind
> > Requests could be initiated for read only access or other
> > kinds of sessions for which the Administrator deems
> > unnecessary to require secure authentication.
> >
> > [
> >     Section 4.2. Bind Operation
> >         The function of the Bind Operation is to allow
> >         authentication information to be exchanged between
> >         the client and server.
> >     <abridged>
> >       - name: The name of the directory object that the
> >         client wishes to bind as.  This field may take on
> >         a null value (a zero length string) for the
> >         purposes of anonymous binds, when authentication
> >         has been performed at a lower layer, or when using
> >         SASL credentials with a mechanism that includes the
> >         LDAPDN in the credentials.
> >
> >       - authentication: information used to authenticate
> >         the name, if any, provided in the Bind Request.
> >
> >         Upon receipt of a Bind Request, a protocol server
> >         will authenticate the requesting client, if
> >         necessary.  The server will then return a Bind
> >         Response to the client indicating the status of the
> >         authentication.
> > ]
> > The Bind Operation allows for the exchange of
> > authentication information.  The client might attempt to
> > bind as any existing directory object name or invalid name
> > or anonymously.  Anonymous Bind Requests are represented by
> > a zero length name string value.
> >
> > The word anonymous means nameless.  It is a very fitting
> > term for a simple mechanism Bind Request that does not
> > supply a DN in the name field.  Any other value in the name
> > field could not be anonymous by definition.  The
> > authentication field allows the client to prove to the
> > server that he is who he claims to be.  Authentication
> > field information is neither mandated nor required by the
> > protocol.  A server may find it unnecessary to authenticate
> > the requesting client, based on the Administrator's
> > configuration of the DN object.
> >
> > [
> >     4.2.1. Sequencing of the Bind Request
> >     <abridged>
> >         Unlike LDAP v2, the client need not send a Bind
> >         Request in the first PDU of the connection.  The
> >         client may request any operations and the server
> >         MUST treat these as unauthenticated.  If the server
> >         requires that the client bind before browsing or
> >         modifying the directory, the MAY reject a request
> >         other than binding, unbinding or an extended
> >         request with the "operationsError" result.
> >     <abridged>
> >         Clients MAY send multiple Bind Requests on a
> >         connection to change their credentials.  A
> >         subsequent bind process has the effect of
> >         abandoning all operations outstanding on the
> >         connection.  (This simplifies server
> >         implementation.)  Authentication from earlier binds
> >         are subsequently ignored, and so if the bind fails,
> >         the connection will be treated as anonymous.  If a
> >         SASL transfer encryption or integrity mechanism has
> >         been negotiated, and that mechanism does not
> >         support the changing of credentials from one
> >         identity to another, then the client MUST instead
> >         establish a new connection.
> > ]
> > A client which has not sent a Bind Request MUST be treated
> > as an unauthenticated client.  The server MAY, under
> > certain conditions, reject operation requests from
> > unauthenticated clients.  Clients which fail subsequent
> > Bind Requests will be treated as anonymous connections.
> >
> > All of this is simply the direct result of LDAPv3
> > specifically allowing clients which have not completed a
> > successful bind with the server, to always be allowed
> > service using the access controls granted to anonymous.
> >
> > The term 'unauthenticated' is a little troubling here,
> > especially since the Bind Request includes the optional
> > authentication field.  What do you call a client which
> > claimed to be a certain DN in a Bind Request, but was not
> > required to prove it with some sort of authentication
> > information?  Is that client authenticated?  Certainly the
> > server has an identity that it associates with the client.
> > This might be loosely referred to as an authenticated
> > client because the client is known by a DN.  Yet the client
> > is not authenticated in the strict interpretation.
> >
> > Proponents of "passwordless binds equal anonymous binds"
> > would argue that this shows the authors original intent to
> > equate the two.  Why else would the authors substitute
> > 'unauthenticated' for 'anonymous' so freely?
> >
> > I believe 'unauthenticated' here represents what the first
> > sentence stated - a client that has yet to successfully
> > complete a bind - not how the bind should be completed.
> > It was simply a poor choice of words to use here, and
> > should be replaced with 'anonymous' to keep the two
> > concepts completely separate.
> >
> > [
> >     4.2.2. Authentication and Other Security Services
> >     <abridged>
> >         If no authentication is to be performed, then the
> >         simple authentication option MUST be chosen, and
> >         the password be of zero length.  (This is often
> >         done by LDAPv2 clients.)  Typically the DN is also
> >         of zero length.
> > ]
> > LDAPv2 clients often attempt to bind without
> > authentication.  In this scenario, the name field is
> > typically null, which represents an anonymous Bind Request.
> > LDAPv2 servers were not allowed to service clients until
> > they had successfully completed a Bind Request, as opposed
> > to LDAPv3 servers which do not require the client to bind
> > before being serviced anonymously.  This does not rule out
> > the 'non-typical' condition where the DN is not null, but
> > no authentication is to be performed.  These clients may
> > attempt to bind as a certain DN, but not be required by the
> > server to provide proof that they are who they claim to be.
> > All unauthenticated Bind Requests MUST be performed using
> > the simple authentication option, and the password MUST be
> > of zero length.  An anonymous bind is just one
> > instantiation of an unauthenticated bind, the others having
> > specific DN names associated with them.
> >
> > [
> >     4.2.3. Bind Response
> >     <abridged>
> >         If the bind was successful, the resultCode will be
> >         success, otherwise it will be one of:
> >         <abridged>
> >         - inappropriateAuthentication: the server requires
> >           the client which had attempted to bind
> >           anonymously or without supplying credentials to
> >           provide some form of credentials,
> >
> >         - invalidCredentials: the wrong password was
> >           supplied or the SASL credentials could not be
> >           processed,
> > ]
> > The server may reject a passwordless simple Bind Request
> > if the directory object referenced in the name field
> > requires authentication information from the client.  This
> > failure could never be sent if all passwordless Bind
> > Requests were converted to anonymous binds.  This is the
> > result code that should be sent in the above test case
> > 3.3.1.4.2.
> >
> > Again I am troubled with the anonymous reference here.
> > Apparently, this is also the code to return if anonymous
> > binds are disabled on the server.  Otherwise, I am confused
> > by the idea of refusing an anonymous Bind Request because
> > the server requires some form of credentials.  Is your
> > server still LDAPv3 if you do not allow anonymous binds?
> >
> > I propose the following answers to the questions way back
> > up at the top of this growing saga.  Actually, for your
> > viewing pleasure, I will duplicate them again.
> >
> > Q1. Is a Bind Request with a name but without
> >     authentication information the same as an anonymous
> >     Bind Request?
> > A1. No, they are completely different kinds of requests
> >     and must be treated as such.
> >
> > Q2. Can an Administrator set up an LDAPDN to not require a
> >     password?
> > A2. Yes.
> >
> > Q3. Is a valid anonymous Bind Request represented by:
> >     A. only a zero length name and password?
> >     B. a zero length name and ignore any password?
> >     C. a zero length password and ignore any name?
> >     D. some combination of the above?
> > A3.
> >     A. Yes.
> >     B. Probably not because something must have gone awry
> >        and the client should be notified.  Besides, when
> >        would clients think that anonymous binds require
> >        authentication? Anonymous, by LDAPv3 definition,
> >        cannot require authentication or else we are right
> >        back to LDAPv2 where a bind would be required before
> >        other operations could be serviced.
> >     C. No, this is now in Q4's domain.
> >     D. No.
> >
> > Q4. Is a valid unauthenticated Bind Request represented by:
> >     A. only a valid name with a zero length password?
> >     B. an invalid name with a zero length password?
> >     C. a zero length password and ignore any name?
> >     D. some combination of the above?
> > A4.
> >     A. Yes, if the DN object does not require
> >        authentication information.
> >     B. No, this must be failed all the way back to the
> >        client.
> >     C. No, the name is used to determine if authentication
> >        is required or not.
> >     D. No.
> >
> > Q5. When may a server fail an anonymous Bind Request?
> > A5. When anonymous binds have been disabled on the server,
> >     or Q3.B, or for other Bind Response conditions like
> >     protocolError and unavailable.
> >
> > Q6. When may a server fail an unauthenticated Bind Request?
> > A6. When the DN requires authentication, or Q4.B, or the
> >     other Bind Response conditions.
> >
> > On a side note, there are only 10 valid bind responses
> > according to the Bind Response section: success (0),
> > operationsError (1), protocolError (2),
> > authMethodNotSupported (7), strongAuthRequired (8),
> > referral (10), saslBindInProgress (14),
> > inappropriateAuthentication (18), invalidCredentials (49)
> > and unavailable (52).
> >
> > BLITS test 3.3.1.4.3 Bind With Invalid DN Syntax expects
> > result code invalidDNSyntax (34).  Are we to limit responses
> > to only those explicitly listed in the Bind Response
> > section?  What result code should be returned if a client
> > attempts to bind with a non-existent DN or with invalid DN
> > syntax?  LDAPv3 also defines specific result codes for
> > these, yet they are not included in this section.  Are all
> > of these failures (ambiguously) covered by
> > inappropriateAuthentication (18)?
> >
> > John Aurich
> > Software Engineer
> > Novell Directory Services; LDAP