Subject: Re: 10.4 IDENTIFY Command II

From: [email-masked]
Date: Wed, 4 Dec 2002 16:10:24 -0500

Doug wrote on 11/18/2002 12:26:47 PM:
> >  Kinda illogical to me. 
> >  If the command succeeded then I should be allowed in. 
> 
> Where does the draft say that if it succeeds that you are not allowed 
in?

Go reread BEEP where it talks about this apparent paradox.  See Section 
3.1.1 Profile Identification and Initialization.  Its not 100% a 1-to-1 
mappable example to CAP but its a scenario where it can occur.  In any 
case the main topic here is the way CAP deals with failures, etc.

> If you determined that a hacker was attacking your system, would
> you first inform them:
> 
>    > 1: Network failure
>    > 2: CS crash/shutdown
>    > 3: "Im a bad boy"
>    > 4: "Im not allowed to be the CFO of the company"
>    > 5: "Sorry C&S Team AA, you are still not allowed to assume Bruces 
identity"
>    > ...

Hmm, Im impressed that you alone have developed the means to make software 
clairvoyant and have imbued it with the ability to tell a hacker from a 
legitimate user who is retrying something they think should/will work.  I 
look forward to reading the patent application for that.

The "dealing with a hacker" case is just one scenario.  The responses you 
gave for 2, 4 and 5 are VERY useful for informing legitimate users of 
failures for assorted reasons (the CUA and CS disagree on authorization, 
credentials, etc).  If the CS thinks its got a hacker then 3 is probably 
the best answer to send back.

You are arguing FOR my points here, not against them.  Sounds like violent 
agreement again...

> Or would you just block them? I block them and let them wonder why they
> failed. 

"Security thru obscurity" went out in the early 90's around here... 
Perhaps its still alive elsewhere in the world though.

>          I would not inform them of the specifics. And we are talking
> about a 'security violation' and NOT a failed login attempt.

No matter the case.  In your scenario the hacker logged in just fine and 
is now attempting to get to areas they are not permitted.  In other 
scenarios its AAs trying to do the same thing but they are prohibited for 
some reason (ie: Credential discrepancies, etc).

My point is that there are many valid cases where providing information IS 
desirable but we have no way to do it.  If your implementation decides 
that a persistent AA is a hacker then its free to send back a (3) response 
and drop them entirely.  You can even have the CS lock that UPN out (or 
the IP out or both or...).  I dont think we should design CAP with the 
mind set that all CUAs that try to do thinks that fail are hackers; thats 
just a negative mindset that impedes usability designs in the protocol.

> > So just how would you craft your awesome CUA so that it can 
distinguish 
> > between the cases listed above??  I dont see anything in the CAP draft 

> > that would allow it so you must have some pretty good mojo to do it 
w/o 
> > protocol support...
> 
> If a CUA attempts to hack my system - I would not care about the error
> messages it displayed.

Again w/the clairvoyance references... 

You still dont address dealing w/the CUA before you get to this 
determination (unless you consider 1 failure a hack attack and punt them 
right off!).  For these cases how does the CUA know that the failure is 
due to insufficient credentials, the CS beginning shutdown, etc. if its 
not sent by the CS??

> > You are assuming that the CS did some diagnostic logging at a minimum. 

> >  That BEEP-like recomendation should be added to the draft since its 
not 
> > there now.
> 
> Where does it say that the CS may not perform logging as specified
> and recommended in BEEP?

CAP logging is not the same as BEEP logging.  BEEP logging should be for 
stuff like bad BEEP packets, etc.  CAP logging would be for failures like 
we are arguing now.  The inability to change the identity is NOT a BEEP 
level issue; its a CAP one.  Im recommending that CAP include some text 
ala BEEPs for cases like this since there is _none_ now.

> > Im NOT trying to nail down what criteria a CS uses to determine if the 

> > IDENTIFY command is an actual violation or not; Im just trying to nail 

> > down the behaviour so that its a bit more robust and allows for 
> > providing of diagnostic information when/if the implementation desires 

> > to send it.
> 
> I will never tell a hacker or malicious software why attempts failed.

So just send back a (3) "Bad boy" response and punt them.  Until they get 
to that point though you should be sending back some more useful response 
codes so that legit CUAs can take the right course of action besides 
complaining to the boss "That stupid program wont let me and I cant tell 
why!".

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...