Re: SSH revised

[Sam Mason]

On Fri, Mar 24, 2006 at 03:53:11AM +0100, Marcus Brinkmann wrote:
> The malicious user catching your passphrase would immediately use it
> to start a man-in-the-middle attack.

That's probably more difficult as they would have to guess the correct
username.  But this isn't my main concern, you resolved it further down
anyway.  I seem to keep forgetting all the tools that a real capability
system provides to do things securely.

Your discussion about ways to confirm the entered usernames was
interesting and I hope some of your ideas will be included in login
programs -- when they get written, but that seems a while away yet!

> Here is something you can do to avoid leaking the passphrase even if
> you enter it: the system could run the user's authentication code in a
> confined environment.  In this case, no information can be passed from
> the authentication code to the user's session, so giving this piece of
> code a sensitive password would not cause any problems.  This
> mechanism would require a couple of additional steps, and make it more
> difficult (but not impossible) to support things like one time
> passwords.

I keep forgetting that you can do this confined execution thing.  Here's
an idea that I've just spent a while thinking about.

Each user would register an agent with the system that performs the
authentication checks (this could be done though the syslog idea you
came up with previously).  This process would be isolated from all
but a specific set of surrogate processes that would perform more
complicated checks (interacting with kerberos servers, keeping track
of one-time-passwords).  At authentication time this agent would be
given a capability to the login device (terminal/SSH byte stream) and
would be expected to interact with it and return if the authentication
was successful or not.  When authentication has passed successfully,
the terminal would be passed to the user's session init code.  The
surrogate processes could have the option of attaching tokens to the
login device that identify their state.

> However, to really make this work you would also have to
> indicate to the user when the authentication phase is over (because
> that is when it is no longer necessarily safe to enter a secret), and
> you could still not be sure if you are actually logged into the right
> session (the malicious user's auth daemon could just grant you access).

This would be specific to each login device, and could be done by the
controlling login process.

> The problem of leaking the password already exists in totally
> different scenarios as well.  For example, I sometimes happen to enter
> my IRC password into the wrong emacs buffer, much to the amusements of
> my friends.  And I always wonder if the sysadmin of a remote machine
> does not log my failed attempts at remembering the right password, to
> fish for valid passwords on different machines I have accounts on.

I don't think we're going to solve that one just yet though :)

> > I'm aware that it also places limits on authentication mechanisms, but
> > I'm having trouble reconciling these arguments.
> 
> I like the concept that sitting at a terminal (and entering a user
> name) is necessary and sufficient proof for the human to be able to
> assign the terminal to any user in the system.

yes, this would be nice.  but can only be done in situations where no
sensitive information is stored or you know that physical access to the
machine is controlled somehow.

I would like to have my computer at home running like this for example.
But I would also like to have data/programs on it that are only
available when more proof of identity has been given.

> Let me give you another example: I could set up, as a user, my account
> in a way that allows anybody at "terminal 3" to see my finger
> information, just by entering my username at the login prompt, even if
> they don't have an account.  That's a flexibility that you can't do if
> the system requires full authentication before assigning the terminal.

sounds cool, but you're saying that you want to give your login agent
at least readonly access to your account?  if so then what if there
are bugs in it that an attacker manages to exploit.  keeping the login
procedure constrained should give you much more confidence in it.

> > Strange, I don't think I got Niels email.  
> 
> The list was CC'ed, but it didn't went through (yet?).

still haven't got it :(

> > are you suggesting that this "logical device" is only to be used in the
> > context of SSH connections? or would it make sense to try and generalise
> > this a bit?  i.e. the other end of the connection wants to set up a new
> > PTY, a new incoming/outgoing port, wants access to your file system!
> 
> I don't know how the interface of the logical device would/should look
> like.  I suppose that the logical device would sort of represent the
> encrypted low level transport layer to the client side.
> 
> The user would have to implement all the higher level protocol stuff
> of SSH themselves.  Ie, PTY set up, new ports, etc.

OK, that's what I was interested in

> > That's all starting to sound a bit frightening and I guess we just want
> > a way of passing the unencrypted packets to user space and back. . .
> > Humm, I think the SSH server has just become fully trusted!  or can you
> > use the containment bits of coyotos to verify that it is only going to
> > be sending your data encrypted to the correct socket?
> 
> The system part of the SSH server is of course system code, just like
> any other terminal hardware driver.

that seems obvious in retrospect!  I was mainly concerned that a bug in
the SSH server wouldn't allow one user's session to observe (or worse,
interact in) another users session.  But I think this sort of thing
should be easy to guarantee.


  Sam