Subject: I-D ACTION:draft-ietf-secsh-agent-02.txt

From: [email-masked]
Date: Mon, 02 Feb 2004 16:07:24 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: Secure Shell Authentication Agent Protocol
	Author(s)	: T. Rinne, S. Lehtinen
	Filename	: draft-ietf-secsh-agent-02.txt
	Pages		: 13
	Date		: 2004-2-2
	
This document describes the Secure Shell authentication agent protocol
(i.e., the protocol used between a client requesting authentication and
the authentication agent).  This protocol usually runs in a machine-spe-
cific local channel or over a forwarded authentication channel.  It is
assumed that the channel is trusted, so no protection for the communica-
tions channel is provided by this protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-agent-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-agent-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-agent-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Simon Tatham <[email-masked]>
Date: Mon, 02 Feb 2004 23:30:15 +0000

> http://www.ietf.org/internet-drafts/draft-ietf-secsh-agent-02.txt

... which contains ...

> The "ssh-rsa" private key format has the following specific encoding:
> 
>   string    "ssh-rsa"
>   mpint     e
>   mpint     d
>   mpint     n
>   mpint     u
>   mpint     p
>   mpint     q

Is there a standard definition of `u', `p' and `q' that I don't know
about? I have a feeling I've seen different implementations use p
and q opposite ways round.

It might be good to make it very clear which of p and q is the
larger prime, and whether u is the inverse of q mod p or vice versa.

> These messages can be sent to either direction. However, the agent MUST
> send these messages only as responses to the client's requests.

Wording nit: is this intended to indicate that the agent must send
extension messages only in response to a client's _extension_
message? If so, it isn't clear; this only seems to say that an agent
can't suddenly volunteer an extension message when no message at all
has been sent from the client.

However, I'm generally happy with this; all my suggestions have
happened, and I think I could usefully get started on some
implementation with this draft.

Cheers,
Simon
-- 
Simon Tatham         "Selfless? I'm so selfless I
<[email-masked]>    don't even know who I am."

---

From: Damien Miller <[email-masked]>
Date: Tue, 03 Feb 2004 11:17:34 +1100

Sorry for not looking at this sooner. Some comments:

1. Why not make the SSH_AGENT_CONSTRAINT_* constraints strings? They are
not performance critical, and this will allow us to use the same
[email-masked] mechanism used elsewhere in the protocol.

2. We should also have some text describing what should happen when an
agent is asked to process an unrecognised extension. I.e should
constraint extensions be "critical"? (I think so)

3. I also have concerns about how "forwarding steps" and "forwarding
path" extensions could be safely implemented beyond one hop. I don't
know of any implementation that does this, so I'd be wary of the
specification anticipating reality.

4. I don't see any value in the SSH_AGENT_RANDOM exchange. If a remote
agent doesn't have a good local randomness source, then it shouldn't be
talking ssh. Trusting random numbers from a remote source could lead to
things like DSA private key exposure.

Furthermore, the ability for a remote attacker to perform arbitrary
requests on your randomness source would increase your exposure to any
implementation vulnerabilities at your end.

5. I'd prefer to see section "4.  Agent Forwarding With Secure Shell"
moved to near the start of the document, but that is just my taste. OTOH
I don't think that it should break the vendor extension section from the
rest of the agent protocol description.

-d

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Feb 2004 09:21:43 -0500

> constraint extensions be "critical"? (I think so)

Probably.  If they are, then we need a wrapper like Kerberos's 
"IF-RELEVANT" (see draft-ietf-krb-wg-kerberos-clarifications-04.txt 
5.2.6.1), which is mandatory-to-implement and has the semantics that 
whatever's inside it is ignored if not supported.

Or, we could go the reverse route, making constraint extensions 
non-critical, but requiring implementation of a wrapper which makes its 
contents critical.  While the two options are semantically equivalent, in 
this case, I think the former approach is better, because of the reduced 
chance of an implementation error leading to a security problem -- an 
implementation which fails to implement IF-RELEVANT correctly is more 
likely to reject a permissible request than to accept an prohibited one.

If we accept your proposal of replacing constraint ID's with strings, we 
can easily achieve this effect simply by partitioning the constraint 
namespace -- any constraint whose name starts with "OPT:" is treated as 
non-critical.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA