|
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" <gvithalprasad@novell.com> 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" < jimse@novell.com > 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 th! e auth s tate 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" < gvithalprasad@novell.com > 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 |