|
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.
I've completely reworked this section for -16. I think this should meet your request now.
> >>> 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.
I believe this is also now covered in the rewrite of the Authorization State -16. If not, please suggest some words at a specific location.
>>>> 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.
In the end, we decided to keep protocol issues in [Protocol]. Section 4.14.3 of [Protocol] covers removal of TLS layers. The last paragraph explicitly allows either protocol peer to terminate the LDAP session after sending or receiving a TLS closure alert, so I believe this issue is resolved. > >‑‑ >Hallvard >
Thanks,
Roger |