Invalidated Authorization State (WAS: authmeth-15 notes)

"Roger Harrison" <[email protected]> Mon, 26 Sep 2005 13:12:07 -0600
Newsgroups gmane.ietf.ldapbis
Message-ID <[email protected]>
>>> Hallvard B Furuseth <[email protected]> 09/22/05 4:26 pm >>>
              
> > 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... 

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. 

> ‑‑       
> Hallvard 

Roger