Subject: WG Chair comments on draft-ietf-secsh-agent-01.txt

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 15 Jul 2003 18:25:52 -0400

Two comments:

 1) "split" references (there's only one and it's normative)

 2) security considerations section doesn't mention the case where you
    do an ssh-add into a forwarded agent connection.  While this
    exchange is protected via encryption, it does involve casually
    moving a long-term public keypair over the net to a remote system,
    which should raise a few eyebrows..

It is not clear to me what we should do about this.  Either we should:

a) suggest that implementations detect and warn about this case,

or 

b) redesign the protocol so that SSH_AGENT_PRIVATE_KEY_OP requests
 flow towards the node with the key rather than having all keys and
 requests flow to the "root" agent.

Any comments from the rest of the WG?

						- Bill

---

From: Darren J Moffat <[email-masked]>
Date: Tue, 15 Jul 2003 15:34:44 -0700 (PDT)

>  requests flow to the "root" agent.

Or maybe both, if it can be migrated do so and the implementation SHOULD warn.

In fact if the key is actually in an HSM it may not be possible to
migrate the actual key to the "root" agent anyway so we might actually want
to forward the request to the "owning" agent in some cases.  However I could
be convinced the practical aspects of having access to an HSM (like a
smartcard) on the remote machine are such that this maybe unlikely and thus
we don't need to complicate the protocol.

-- 
Darren J Moffat

---

From: Simon Tatham <[email-masked]>
Date: Wed, 16 Jul 2003 09:47:50 +0100

>     which should raise a few eyebrows..

Hmm. I tend to see it the other way round. In the designed usage
model, the real agent is running on your _local_ system, which is
usually the only one you trust with your private keys. If you do an
ssh-add from a remote system, the potential problem is not the
transfer of the key to your trusted local machine: it's the fact
that the remote system somewhere on the Internet which you're
transferring the key _from_ had access to both the key file and the
passphrase. Or, if you're concerned about attacks on the network
connection between them, then the damage is probably already done
once you've typed the passphrase through your SSH connection.

I'm tempted to suggest that if you _must_ store your private key
remotely, then the only sensible mode of use is to transfer it
_encrypted_ to your local agent and have that prompt for the
passphrase. But that's getting back to my pet extension feature :-)

> Any comments from the rest of the WG?

I posted several comments on the agent draft on 28th April, which
are still in the list archives. The only response I got was from
Damien Miller supporting one of my suggestions. If anyone is
actually collecting comments, please don't overlook those.

Cheers,
Simon
-- 
Simon Tatham         These are my opinions. There are many
<[email-masked]>   like them but these ones are mine.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 16 Jul 2003 04:52:24 -0400

> usually the only one you trust with your private keys. 

well, I was assuming that there may be multiple keys with different
roles involved; host A may be trusted with key A, host B may be
trusted with key B, but neither is trusted with both..

You may trust host A enough to use it temporarily to get access to
host B but not want it to get a copy of key B..

					- Bill

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Jul 2003 06:44:23 -0700

> Any comments from the rest of the WG?

Perhaps an optional message could be added to indicate that a node has
added a key to the [now distributed] agent.  Of course, now we'd have
bidirectional agent channels, with requests and responses going in
either direction.

Nico
--

---

From: Damien Miller <[email-masked]>
Date: Thu, 17 Jul 2003 17:37:55 +1000

> Any comments from the rest of the WG?

Simon Tatham had some comments on the agent protocol (posted 2003-04-29) 
which I think are important.

I especially support his proposed extension mechanism.

-d

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Jul 2003 16:14:47 +0200 (CEST)

> once you've typed the passphrase through your SSH connection.

I think the key words in Bill's comment above are 'over the net', not
'remote'.  I do think that moving a long-term keypair over the net is
indeed not something to be done causally.