|
Responses are inline below.
> > > This document discusses various authentication and authorization > > states through which a connection to an LDAP server may pass and the > > actions that trigger these state changes. > > Now that the state tables are gone, this particular info is only > available by reading the whole document, looking for state changes. > (Aha ‑ finally I understand what the tables were good for:‑)
Are you thinking that we should put them back into the document? I'm fine with doing so if there seems to be consensus that doing so would be useful.
> > Anyway, maybe Section 4.something should mention that Bind is the > operation which can change authorization state, and in addition TLS > operations can invalidate the association. >
The first paragraph of section 4 already states that the Bind operation is used to allow the client and server to exchange information that changes the authorization state.
> > 1. Introduction > > > Basic threats to an LDAP directory service include: > > (...) > > (5) Unauthorized modification of configuration information, > > (...) > > Threats (1), (4), (5) and (6) are due to hostile clients. > > How is modification of config info a hostile client? Sounds like a > break‑in on the user's account or the root account of the user's > machine. Unless you refer to client configuration info which the client > reads from LDAP, but if so that should be clarified.
I agree with your train of thought on this. At least some directory server implementations store much of their configuration as directory entries which have the potential for being altered due to hostile clients. The way threat (5) is written and discussed implies that this is the only way that configuration can/will be stored, which is clearly not reasonable. How about I remove threat (5) from the hostile client list and say something like this:
"Threat (5) is due to any agent that can obtain update access to configuration information stored at the client or server."
> > > LDAP offers the following security mechanisms: > > > (2) Mechanisms to support vendor‑specific access control facilities > > (LDAP does not offer a standard access control facility) > > > (3) Data integrity service by means of security layers in TLS or > > SASL mechanisms, > > I think s/TLS/TLS (Transport Layer Security)/. It has been expanded in > the abstract, but not elsewhere. SASL has been expanded before.
Yes.
> > > At the moment, imposition of access controls is done by means > > outside the scope of LDAP. > > Isn't that sentence a duplicate of (2) above?
Yes. I struck the entire paragraph.
> > At the end of section 1, s/Appendix C/Appendix A/.
Thanks!
> > > 3.1.2. StartTLS Response > > > > The server will return a resultCode other than success (as > > documented in [Protocol] section 4.13.2.2) if it is unwilling or > > unable to negotiate TLS. In this case the LDAP session is left > > without a TLS layer. > > This only says what happens at non‑success, not at success. > [Protocol] is rather sparse about it too.
Jim Sermersheim and I both agree. We recommend a change in [Protocol] I'll bring this to the list as a separate item to make it easier to track.
> > > 3.1.4. Discovery of Resultant Security Level > > > If the client or server decides that the security level is not high > > enough for it to continue, it SHOULD gracefully remove the TLS > > connection immediately after the TLS negotiation has completed (see > > [Protocol] section 4.13.3.1 and section 3.2.3 below). The client > > may then either close the transport connection, attempt to StartTLS > > again, send an unbind request, or send any other LDAP request. > > The server too can close the connection. I don't remember what's the > use of such a detailed list of what the client can do, but maybe it > should be reflected with a list of what the server can do. >
In reviewing [Protocol] section 4.13.3.1, I believe that this is adequately covered there. I have deleted the last sentence of this paragraph.
> > 4.3. Invalidated Authorization State > > > > The server may invalidate the existing authorization state at any > > time, e.g. if an established security layer between the client and > > server has unexpectedly failed or been compromised. A resultCode of > > strongerAuthRequired may indicate that such a condition exists. In > > practice, the strongerAuthRequired resultCode means that the client > > needs to bind to (re)establish a suitably strong authorization state > > before the server will attempt to perform the requested operation. > > In order to permit clients to establish such an authorization state, > > servers should not respond to Bind, Unbind, and StartTLS requests > > with the stongerAuthRequired resultCode. > > When was this decided? Copied from my message > <http://www.openldap.org/lists/ietf-ldapbis/200503/msg00006.html>, > > The last I remember, we gave up on having invalidated associations > return a result to a rejected request: thread 'Result code for > invalidated associations', 2004. The whole mess about them doing so > just got too ugly. Instead, if a request is rejected because the > association is invalidated, just send Notice of Disconnection and > terminate the session. I don't remember which result code we ended > up with; I think that issue came up in several threads. > > I'm sure it turned out ot be reasons why no result code was suitable for > responses to normal requests during invalidated associations, but I'm > not going to dig that up now. Of course these reasons may have been > wrong...
I reviewed the email thread you mention both before publishing authmeth-15 and again today. I see a lot of discussion regarding possibilities for dealing with this, but I don't see any clear conclusion that the proper behavior is to send a Notice of Disconnection. I'm going to duplicate post this section of the response for further input from the WG. > > ‑‑ > Hallvard >
Roger |