by mail.netbsd.org with SMTP; 18 Oct 2000 13:58:03 -0000
	by noc.untraceable.net (8.11.1/8.11.1/bonk!) id e9IDvu929811;
	Wed, 18 Oct 2000 09:57:56 -0400 (EDT)
Date: Wed, 18 Oct 2000 09:57:56 -0400
From: Andrew Brown <atatat@atatdot.net>
To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
Cc: Atsushi Onoe <onoe@sm.sony.co.jp>, cjs@cynic.net,
   hubert.feyrer@informatik.fh-regensburg.de, tech-security@netbsd.org
Subject: Re: setuid ssh
Message-ID: <20001018095755.A29756@noc.untraceable.net>
Reply-To: Andrew Brown <atatat@atatdot.net>
References: <atatat@atatdot.net> <20001018135146.300E22A2A@orchard.arlington.ma.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001018135146.300E22A2A@orchard.arlington.ma.us>; from sommerfeld@orchard.arlington.ma.us on Wed, Oct 18, 2000 at 09:51:40AM -0400
Return-Receipt-To: receipts@daemon.org

>> ssh-agent should be changed anyway.  what it *should* do is store the
>> decrypted key for a period of time and then expunge it (ala kerberos's
>> tgt, or sudo), requiring the user to reauthenticate periodically.
>> once i look more closely at it, i'll have more colorful ideas, i'm
>> sure.
>
>yes.  IMHO it should generate a new keypair and use the user's
>long-term key to sign a short-term "certificate" saying that the
>temporary keypair is equivalent to the long-term key for some (short)
>lifetime.

but the problem of how to get the public half of the short term key
pair into my authorized_keys file on remote machines still presents
itself...

...unless it used the long term private half to sign the short term
public half that the agent was storing.  then all you'd be doing would
be providing a passphrase for signing to take place: ssh-agent would
never need to know about the long term key.

...of course, a new form of rsa authentication would have to be added:
SSH_AUTH_RSA_RSA with the long term public piece, the signature on the
short term public half that the long term public half can be used to
verify, and the short term public half.  the challenge from the server
to the client would then be the same, as would the client's response.

hmm...does that sounds reasonable?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."