Re: authmeth-15 notes

Roger Harrison writes: 

>>>>> Hallvard B Furuseth <[email protected]> 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