by mail.netbsd.org with SMTP; 18 Oct 2000 17:27:03 -0000
	by warning.follo.net (8.9.3/8.9.3) id TAA31013;
	Wed, 18 Oct 2000 19:25:56 +0200 (CEST)
Date: Wed, 18 Oct 2000 19:25:55 +0200
From: Eivind Eklund <eivind@FreeBSD.org>
To: Andrew Brown <atatat@atatdot.net>
Cc: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>,
        Atsushi Onoe <onoe@sm.sony.co.jp>, cjs@cynic.net,
        tech-security@netbsd.org
Subject: Re: setuid ssh
Message-ID: <20001018192555.A26814@warning.follo.net>
References: <atatat@atatdot.net> <20001018142031.6072B2A2A@orchard.arlington.ma.us> <20001018102640.A293@noc.untraceable.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <20001018102640.A293@noc.untraceable.net>; from atatat@atatdot.net on Wed, Oct 18, 2000 at 10:26:40AM -0400

On Wed, Oct 18, 2000 at 10:26:40AM -0400, Andrew Brown wrote:
> but to digress further, what would be better, imho, would be if
> something "similar" to rhosts existed, but allowed me to specify an
> rsa key (for rsa authenticaion) along with the host, and perhaps even
> whether or not a remote command is required/refused/optional.  i had a
> case where some people should be allowed to remote execute things, but
> certainly not to log in.  that one was fun.

You can do that in authorized_keys.

Back to authentication changes:  You (plural) do not seem to be defining
what properties you want from a new authentication system in SSH before
starting to informally define one.  I'll try to describe the issues that I
see, so anybody that define a new protocol at least have a set of basics:
1. You do not want compromise of a host with an ssh-agent to allow perpertual
   access (that's the point of the certificate use.)

2. You want the SSH agent to know as much as possible about who is requesting
   authentication.  This includes knowing the entire path along which the
   authentication travels.

3. You do not want to leak information about how many or which keys are
   available in authorized_keys (beyond the one used to authenticate if
   authentication works.)

4. You do not want to leak information about how many or which keys are
   present in the authentication agent.

5. You may not want to leak information about which hosts are 'further out'
   (closer to the ssh-agent) to the hosts in the chain.  (Not sure about
   this.)

6. It'd be nice to establish a pair of cryptographic keys between any pair of
   links in the chain when you are doing this, in order to be able to 'jump'
   hops that are not required.   This may be of more theoretic than
   practical interest, though, 

This is a thorny issue.   I've not yet found a solution that covers all of
this; 3 and 4 seems to be mutually exclusive.

Eivind.