Subject: Fwd: Re: result code for a deleted identity on a connection

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 28 Jul 2003 23:55:23 -0600

Regarding #2: Are you proposing that we add specific instructions for
this scenario? I'm not sure that we can find two interoperable
implementations that would adhere to any new recommendation. Aside from
that (because that alone shouldn't interfere with us solving a serious
security implication), is this a serious security implication? 
 
The general scenario is that a bind succeeded, and later, the identity
(or its credentials) become invalid (perhaps the identity is represented
as a DN and that object is deleted, or perhaps a ticket expired, or a
cert expired, or any number of other incidents may have happened to the
identity or its credentials such that if that bind were to be re-issued
again, it would fail--yet the connection (on which the bind succeeded)
is still open, and then some subsequent request is made. Is this
accurate, or are you only trying to address the specific issue of a
simple bind, followed by a deletion of the bind DN?
 
If the specific problem is being addressed, we also need to consider
what happens when:
- the password is changed
- the DN is moved or renamed
- the DN is not local and authentication was chained
- other policy has caused the "account" to be "locked"
- etc.
 
If the general problem is being addressed, then there are a number of
other considerations to be made.
 
In either case, it seems to be opening a level of complexity never
before described in the TS, and prescribing implementation behavior
beyond a level in which implementors can handle. I note that there are
similar analogies that are unspecified. For example, is a server forced
to calculate authorization for each operation, or can it cache certain
types of authZ data when the client performs a bind? If the server is
allowed to cache, then changes to authZ data (ACIs) may go unnoticed,
thus creating a security breach. To date, this level of detail has been
left to implementations. 
 
If we don't allow option e below, then we are saying that we will
mandate behavior--that we will force servers to know when an identity
(or possibly any of the other items above) has changed. Are we willing
to begin mandating this level of behavior?
 
Jim

>>> "Vithalprasad Gaitonde" <[email-masked]> 7/28/03 6:48:23
AM >>>
Jim,
Two items:
1. Does the case need a representation in the state transition diagram
that Roger has been working on in his authmethd draft. (This question
should probably go to Roger).
2. You mention "e) not even be aware that a change has happened and
proceed as if the
identity still exists." Leaving this behaviour as option to the
server, could have some serious security implications. When I read
this
and see the IESG note regrading security implications in 2251
especially
with respect to update operations, I wonder if progressing the draft
would have problems because of these security implications.

Prasad

>>> "Jim Sermersheim" < [email-masked] > 7/23/2003 10:02:02 PM >>>
Prasad,

Currently Protocol says:
(in Notice of Disconnection)
- strongAuthRequired: The server has detected that an establish
security association between the client and server has unexpectedly
failed or been compromised, or that the server now requires the client
to authenticate using a strong(er) mechanism.

(in A.2)
strongAuthRequired (8)
Except when returned in a Notice of Disconnect (see section 4.4.1),
this indicates that the server requires the client to authentication
using a strong(er) mechanism.

Do you think more needs to be added/changed (aside from the two
typos)?
There is nothing that restricts which operation responses
strongAuthRequired is returned in.

I prefer not to mention specific scenarios (like the one mentioned
below), because I don't want to restrict other errors from being
returned. 
If the scenario below happens, a server should be free to:
a) revert the authN/authZ state to anonymous and allow operations to
succeed or fail (with insufficientAccessRights) as they normally
would.
b) revert the auth state to unknown and fail all non-authN requests
c) send a notice of disconnect
d) do a or b and also send some unsolicited notification which
notifies
that the connection state has changed
e) not even be aware that a change has happened and proceed as if the
identity still exists.
f) others that I haven't thought of.

Jim

>>> "Vithalprasad Gaitonde" < [email-masked] > 7/23/03
2:27:47
AM >>>
Roger/Jim,
Sometime back we discussed this on the list.
Probably we should make the necessary edits for this in AuthMeth
(clarification of server behaviour when the bind identity of an
established connection is deleted) and Protocol ( edit of when
strongAuthRequired can be sent).

-Prasad

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 29 Jul 2003 09:17:40 +0200

My personal view on this thread is that issues of authentication
and access control are a local matter and we should limit any
additional text here to the Security Considerations section(s).

At 07:55 AM 7/29/2003, Jim Sermersheim wrote:
>Regarding #2: Are you proposing that we add specific instructions for this scenario? I'm not sure that we can find two interoperable implementations that would adhere to any new recommendation. Aside from that (because that alone shouldn't interfere with us solving a serious security implication), is this a serious security implication? 
> 
>The general scenario is that a bind succeeded, and later, the identity (or its credentials) become invalid (perhaps the identity is represented as a DN and that object is deleted, or perhaps a ticket expired, or a cert expired, or any number of other incidents may have happened to the identity or its credentials such that if that bind were to be re-issued again, it would fail--yet the connection (on which the bind succeeded) is still open, and then some subsequent request is made. Is this accurate, or are you only trying to address the specific issue of a simple bind, followed by a deletion of the bind DN?
> 
>If the specific problem is being addressed, we also need to consider what happens when:
>If the general problem is being addressed, then there are a number of other considerations to be made.
> 
>In either case, it seems to be opening a level of complexity never before described in the TS, and prescribing implementation behavior beyond a level in which implementors can handle. I note that there are similar analogies that are unspecified. For example, is a server forced to calculate authorization for each operation, or can it cache certain types of authZ data when the client performs a bind? If the server is allowed to cache, then changes to authZ data (ACIs) may go unnoticed, thus creating a security breach. To date, this level of detail has been left to implementations. 
> 
>If we don't allow option e below, then we are saying that we will mandate behavior--that we will force servers to know when an identity (or possibly any of the other items above) has changed. Are we willing to begin mandating this level of behavior?
> 
>Jim
>
>
>>>> "Vithalprasad Gaitonde" <[email-masked]> 7/28/03 6:48:23 AM >>>
>Jim,
>Two items:
>server, could have some serious security implications. When I read this
>and see the IESG note regrading security implications in 2251 especially
>>>> "Jim Sermersheim" < <mailto:[email-masked]>[email-masked] > 7/23/2003 10:02:02 PM >>>
>Prasad,
>
>Currently Protocol says:
>(in Notice of Disconne! ction)
>succeed or fail (with insuff! icientAccessRights) as they normally
>would.
>b) revert th! e auth s tate to unknown and fail all non-authN requests
>>>> "Vithalprasad Gaitonde" < <mailto:[email-masked]>[email-masked] > 7/23/03 2:27:47
>AM >>>
>Roger/Jim,

---

From: Michael Ströder <[email-masked]>
Date: Tue, 29 Jul 2003 10:06:35 +0200

> additional text here to the Security Considerations section(s).

+1

Ciao, Michael.