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

From: "Vithalprasad Gaitonde" <[email-masked]>
Date: Wed, 23 Jul 2003 02:27:47 -0600

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

Subject: Re: result code for a deleted identity on a connection
From: "Kurt D. Zeilenga" <[email-masked]>
To: "Vithalprasad Gaitonde" <[email-masked]>
Cc: <[email-masked]>, "Vijay KN" <[email-masked]>, "Savitha R" <[email-masked]>
Date: Fri, 09 May 2003 17:21:55 -0700

At 10:55 PM 5/4/2003, Vithalprasad Gaitonde wrote:
>"But I'm thinking RFC 2251, 4.4.1 should be clarified as well:
>        - 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."
>But what does strong(er) imply in the case which we are talking
>about...

In this case, it's the former part of the description which applies.
That is, the code indicates that a security association has failed.

>does that mean the client has to go over TLS or use some SASL
>bind and not use a clear text simple bind ?

It means either a security association has failed or the
better mechanisms are needed.

>.at least that was the
>conventional meaning of strongauthrequired.
>
>Prasad
>
>
>>>> "Kurt D. Zeilenga" <[email-masked]> 5/3/2003 4:08:01 AM >>>
>At 01:59 PM 5/2/2003, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>>> We should probably have a result code like invalidIdentity which
>is
>>>> sent back with a notice of disconnection (section 4.4.1 protocol
>draft)
>>>> followed by a closing of the connection by the server.
>>> 
>>> RFC 2251, 4.4.1:
>>>>   - strongAuthRequired: The server has detected that an
>established
>>>>     underlying security association protecting communication
>between
>>>>     the client and server has unexpectedly failed or been
>compromised.
>>> 
>>> I think it would be reasonable to return this in this case as well.
>>
>>Why ask for _strong_ auth, and not just auth?
>
>First, we've clarified the result code, in general, to mean:
>>        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.
>
>But I'm thinking RFC 2251, 4.4.1 should be clarified as well:
>        - 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.
>
>That is, generalized the result code here as well.  I also
>think other codes should be allowed in the Notice.  I think
>it reasonable for implementations to return a variety of
>other codes including busy, other, adminLimitExceeded,
>unwillingToPerform, and confidentialityRequired.
>
>Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 23 Jul 2003 10:32:02 -0600

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,

-Prasad

---

From: "Vithalprasad Gaitonde" <[email-masked]>
Date: Mon, 28 Jul 2003 06:48:23 -0600

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 A.2)
strongAuthRequired (8)
 
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.
 
succeed or fail (with insufficientAccessRights) as they normally
would.
d) do a or b and also send some unsolicited notification which
notifies
 
Jim

AM >>>
Roger/Jim,

-Prasad

---

From: John McMeeking <[email-masked]>
Date: Tue, 29 Jul 2003 07:15:14 -0500

I also favor leaving this to the Security Considerations section.

I was trying to remember how operating systems I have worked on handle
this.  Unfortunately, the number of times I have been in a position to even
try the experiment is close to zero.  But I suspect this is handled in
different ways.  I know that at least one operating system does not allow
deleting a user while there are jobs running under that user; the
administrator must first boot the user off the system (probably disabling
the account first).  And I think this discussion was in the context of
AuthMeth which addresses authentication methods where the server may not be
(probably isn't) the authentication authority.  For a server to be aware of
events like deletion of an account in a Kerberos realm or revocation of
certificates (outside of the authentication process) is asking a lot.

John  McMeeking

                      Michael Ströder                                                                                                     
                      <[email-masked]        To:       "Kurt D. Zeilenga" <[email-masked]>                                        
                      m>                          cc:       Jim Sermersheim <[email-masked]>, [email-masked]                 
                      Sent by:                    Subject:  Re: Fwd: Re: result code for a deleted identity on a connection               
                      owner-ietf-ldapbis@O                                                                                                
                      penLDAP.org                                                                                                         

                      07/29/2003 03:06 AM                                                                                                 

Kurt D. Zeilenga wrote:
> 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).

+1

Ciao, Michael.