Re: agent draft (was Re: Secure Shell: Milestone Update.)

[nisse%lysator.liu.se@localhost (Niels Möller)]

Simon Tatham <anakin%pobox.com@localhost> writes:

> Bill Sommerfeld  <sommerfeld%sun.com@localhost> wrote:
> >  3) if the agent is the only trusted one and the remote system is not
> > trusted to see the cleartext private key, the key could be stored
> > remotely in encrypted form and decrypted
> > by the agent (using a passphrase or other means).  (very different use
> > model.)
> 
> The PuTTY team has had quite a lot of requests for a use model like
> this, because it provides other desirable features such as the
> ability to store all your keys encrypted until they're first needed
> and ask for their passphrases as required.

This leads to an interesting twist of password authentication.

Setup: User creates a keypair, and encrypts the private half using a
passphrase. (This naturally has to be done on a trusted machine). User
transfers public key and encrypted private key to one or more servers.

Login: Client asks server for encrypted private key. User types in
passphrase to decrypt it. Key is used to sign the session id, just
like for plain publickey authentication.

At a first look, the security properties seem quite similar to plain
password authentication, but with the important difference that the
server never, not even temporarily, has access to the clear text
passphrase, and that it should be reasonable safe to use the same
passphrase with several mutually untrusting servers.

I think I've read a few papers on session setup, where the scenario is
that the user sits at a (trusted) terminal, but has no keys,
certificates, hostkeys or any other personal information stored
locally. However, the user knows a secret passphrase. The objective is
to make use of this passphrase to download private keys, certificates
etc from the server in a secure way, with as little trust as possible
put on the server.

But for login, I think it would be even better with something in the
srp/speke class of password authentication. Important objectives are:
Use passphrase also to authenticate the server (so we can bootstrap
without hostkeys). And don't transmit anything on the wire that allows
an eavesdropper or MITM to mount a dictionary attack. It's REALLY a
shame almost everything in that area seem to be patented.

(I think
http://www.watersprings.org/pub/id/draft-perlman-strong-pass-00.txt
was written in an attempt to get around patents, but there are broad
patents in the area that might cover even this fairly unique
construction).

Regards,
/Niels