Re: Invalidated Authorization State (WAS: authmeth-15 notes)

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.

   


At 12:12 PM 9/26/2005, Roger Harrison wrote:

>>>> Hallvard B Furuseth <h.b.furuseth@xxxxxxxxxxx> 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