authmeth-15 notes

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

> Abstract

>   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:-)

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.

> 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.

>   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.

>   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?

At the end of section 1, s/Appendix C/Appendix A/.

> 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.

> 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.

> 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...

-- 
Hallvard