Subject: authmeth-15 notes

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 23 Sep 2005 00:26:09 +0200

> 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

---

From: "Roger Harrison" <[email-masked]>
Date: Mon, 26 Sep 2005 13:03:24 -0600

Responses are inline below. 

>>> Hallvard B Furuseth <[email-masked]> 09/22/05 4:26 pm >>>
> > Abstract 
> 
> (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. 

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

> break‑in on the user's account or the root account of the user's 

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. 

> >   (2) Mechanisms to support vendor‑specific access control facilities 

Yes. 

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

> This only says what happens at non‑success, not at success. 

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. 

> use of such a def 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. 
  
> not going to dig that up now.  Of course these reasons may have been 

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

Roger

---

From: "Roger Harrison" <[email-masked]>
Date: Mon, 26 Sep 2005 13:08:52 -0600

> [Protocol] is rather sparse about it too. 

Based on Hallvard's query above, Jim Sermersheim and I recommend a change to paragraph 2 of [Protocol] section 14.4.2 to explicitly state that a success resultCode indicates that the protocol peers should begin TLS negotiation. I'll leave it to Jim to craft the wording. 

Thanks, 

Roger

---

From: "Roger Harrison" <[email-masked]>
Date: Mon, 26 Sep 2005 13:12:07 -0600

> not going to dig that up now.  Of course these reasons may have been 

I reviewed the email thread Hallvard mentions above 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 would appreciate help from WG members as to whether I am not simply not seeing the conclusions on this or if we still have an open issue here. 

Roger

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 Sep 2005 16:46:16 -0700

I am generally opposed to the inclusion of Section 4.3
and the uses of the word "invalidate" as it applies
to "state".  State comprises multiple factors... and
events (in TLS, LDAP, elsewhere) can alter these factors.

A client always has some authorization state at the server.
If the current state prevents the server from processing
the operation, the server returns the non-successful result
code best describing the nature of the problem WITH THIS REQUEST.
That is, result codes are generally not indicative of
problems in the session, certainly not indicative
of the outcome of future requests.

In particular, just be strongerAuthRequired was returned
for a particular request does not imply that repeating
the same request will again result in strongerAuthRequired.
The factor(s) within the authorization state that
previously lead to the strongerAuthRequired return
could have changed... or the policy could have been
changed.

For starters, 3.2 needs work:

Change heading to:  TLS Effects on Authorization Factors

Replace:
   The decision to keep or invalidate the established authorization    
   state (section 4.3) after TLS layer installation or removal is a  
   matter of local server policy.
with:

    The existence of TLS protective services, particulars
    of that services, as well as service events (e.g., establishment,
    closure, change ciphersuite), are often factors in making
    authorization and other decisions are a local matter.
    For instance, establishment or closure of TLS may result
    in the state being moved to an anonymous (or anonymous
    equivalent) state (see section 4) as it applies to this
    request.

Rationale: A server is free after establishment of TLS
to require re-authentication for some set of operations
and not for others. For instance, the server could allow
read operations under the previously established
authorization identity but require re-authentication
before write operations will be processed.

Section 4:  Replace the whole section (including subsections)
with:

    Every LDAP session has an associated authorization state.
    This state comprises of numerous factors such as what
    (if any) authorization identity has been established and
    how, what security services are in place, etc..   Some factors
    may be determined and/or effected by protocol events
    (e.g., Bind, StartTLS, TLS closure), some factors may be
    determined by external events (e.g., time of day,
    server load).

    While is often convenient to view authorization state
    in simplistic terms (as we often do in this technical
    specifications) such as "an anonymous state", it is
    noted that authorization systems in LDAP implementations
    commonly involve many factors which relate in complex
    manners.   Authorization in LDAP are a local matter.

    One of the key factors in making authorization decisions
    is authorization identity.  Upon establishment of the
    LDAP session, the session has an anonymous authorization
    state.  The Bind operation is used to establish an
    authorization identity.   The Bind operation may also be
    used to move the LDAP session to an anonymous authorization
    state.

    Upon receipt of the Bind request, the server immediately
    moves the session to an anonymous authorization
    state.  If the request was to move the session to an
    anonymous state and successful, the state remains anonymous.
    If the request was to establish a new authorization identity
    and successful, upon return success the state is moved to
    an authenticated state.  Otherwise, the session remains in
    an anonymous state.

    It is noted that other events, in LDAP or external, may
    result in the authorization state being moved to an anonymous
    one.  For instance, establishment, change, or closure of security
    services may result in a move to an anonymous state, or
    the user's credential information (e.g., certificate)
    may have expired.  The former is an example of an event
    internal to the protocol.  The second is an example of
    an external event.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 27 Sep 2005 01:52:09 +0200

Roger Harrison writes:
>> (Aha $,1rq(B finally I understand what the tables were good for:$,1rq(B)
>
> 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.

No, just a single sentence somewhere under Authorization State.

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

Yes.  What it doesn't say is that no other operation (in the core
standard) does that, except for invalidating associations.
So I need to change assoc state" has a quick answer in the document,
but "when can assoc state get changed?" requires a scan of the whole
document.

>> How is modification of config info a hostile client?  (...)
>
> (...) 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.

Fine.

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

You seem to be reading an old [Protocol] draft.  Protocol-31 does not
mention graceful TLS closure at all.  Protocol-31 StartTLS is section
4.14, not 4.13.

If I remember correctly, it was decided some time ago to move several
protocol-like issues involving TLS from [protocol] to [authmeth].
Don't remember why.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 Sep 2005 21:35:33 -0700

At 03:26 PM 9/22/2005, Hallvard B Furuseth wrote:
>  invalidated associations', 2004.

Well, I think we did reach consensus that result codes
describe why the requested operation could be successfully
completed.  They do not generally describe the authorization
state or other session level details.  LDAP does not offer
a general mechanism for communicating authorization state
changes at the server.

>  The whole mess about them doing so

I think part of the problem is that we're trying to oversimply
authorization state, something which is inherently complex
given multiple factors and sophisticated policy controls.

If the authorization state is such that the server doesn't
want to continue, then certainly sending a notice of disconnect
and disconnecting would be appropriate.  However, there
are cases where authorization state allows the server to
continue.  Maybe for the requested operation the server
requires new authentication and hence returns
strongerAuthRequired.  Or maybe the server just performs the
operation but at reduced authorization level (for instance,
processing a search operation as if submitted anonymously
instead under the previously established authorization
identity).  That is, some authenticated authorization states
may allow no more (maybe even less) access than some anonymous
states.

Kurt