by mail.netbsd.org with SMTP; 18 Oct 2000 14:10:36 -0000
	id 1EB702A2A; Wed, 18 Oct 2000 10:10:36 -0400 (EDT)
	by orchard.arlington.ma.us (Postfix) with ESMTP
	id E6AF81FCD; Wed, 18 Oct 2000 10:10:35 -0400 (EDT)
To: Andrew Brown <atatat@atatdot.net>
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 
In-Reply-To: Message from Andrew Brown <atatat@atatdot.net> 
   of "Wed, 18 Oct 2000 09:57:56 EDT." <20001018095755.A29756@noc.untraceable.net> 
Reply-To: sommerfeld@orchard.arlington.ma.us
Date: Wed, 18 Oct 2000 10:10:30 -0400
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
Message-Id: <20001018141036.1EB702A2A@orchard.arlington.ma.us>

> ...unless it used the long term private half to sign the short term
> public half that the agent was storing.  

That's what I said:

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

so, moving on:

> ssh-agent would never need to know about the long term key.

correct; the signing could happen in ssh-add.

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

you want to sign more than just the short-term key; you also need to
sign a mini-certificate including a validity period so that the end
server can enforce expiration of the short-term key.

					- Bill