Re: authmeth-15 notes

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

Roger Harrison writes:
>>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 09/22/05 4:26 pm >>>
>>> 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 $,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.

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

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.

>>> 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?  (...)
>
> (...) 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.

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

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