Subject: I-D ACTION:draft-ietf-secsh-publickey-subsystem-03.txt

From: [email-masked]
Date: Wed, 24 Aug 2005 18:50:01 -0400

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 Public-Key Subsystem
	Author(s)	: J. Galbraith, et al.
	Filename	: draft-ietf-secsh-publickey-subsystem-03.txt
	Pages		: 19
	Date		: 2005-8-24
	
SECSH defines an authentication mechanism that is based on public
   keys, but does not define any mechanism for key distribution.  No
   common key management solution exists in current implementations.
   This document describes a protocol that can be used to configure
   public keys in an implementation-independent fashion, allowing client
   software to take on the burden of this configuration.

   This protocol is intended to be used from the Secure Shell Connection
   Protocol [4] as a subsystem, as described in the Section "Starting a
   Shell or a Command".  The subsystem name used with this protocol is
   "publickey".

   The public-key subsystem provides a server-independent mechanism for
   clients to add public keys, remove public keys, and list the current
   public keys known by the server.  Rights to manage public keys are
   specific and limited to the authenticated user.

   A public key may also be associated with various restrictions,
   including a mandatory command or subsystem.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-publickey-subsystem-03.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-publickey-subsystem-03.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: Bill Sommerfeld <[email-masked]>
Date: Wed, 24 Aug 2005 19:57:03 -0400

> 	Filename	: draft-ietf-secsh-publickey-subsystem-03.txt

der Mouse: is this revision acceptable to you?

everyone else: are you ok with this version?

I'm going to extend the WG Last call timer by a week to August 31st
since there's an actual wire protocol changes (a new status code) in
this revision.

					- Bill

---

From: Joseph Galbraith <[email-masked]>
Date: Wed, 24 Aug 2005 18:08:13 -0600

> since there's an actual wire protocol changes (a new status code) in

Do we need to bump the protocol version?  I'm pretty sure
we are already shipping something that say s it conforms
to version 2 that will squawk at the new protocol number.

I think there may be others.

Thanks,

Joseph

---

From: Jon Bright <[email-masked]>
Date: Thu, 25 Aug 2005 08:08:37 +0200

> I think there may be others.

On the one side, it's pretty easy to bump the revision.  On the other 
side, Internet-Drafts blah blah...reference material blah blah...work in 
progress.

My guess would be, most implementations would see the new status code 
and spit it at the user as being unknown, possibly ending the 
(publickey) connection.  Also, this is only an issue if the status code 
gets sent at all - if you're only sending attributes returned by 
listattributes, it shouldn't...

If this does turn out to be a problem, the new status code could die and 
we define GENERAL_FAILURE as the code to send then - but that seems like 
a poor compromise.

-- 
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 25 Aug 2005 14:12:51 +0100

On Thu, 2005-08-25 at 01:08, Joseph Galbraith wrote:
> we are already shipping something that says it conforms

<wg chair hat off>
<end-user hat on>
I think you have to tell us -- you're probably in the best position to
tell us about the relative consequences for your users of:

 1) your currently shipping implementation encountering an unknown error
code.

 2) your currently shipping implementation encountering another
implementation which only supports the hypothetical version 3, because
the drafts documenting v2 and v1 have long expired.

But, in the absence of what I'd think of as a really horrible
implementation bug I'm having difficulty understanding why #1 would be
worse in practice than #2...

							- Bill

---

From: der Mouse <[email-masked]>
Date: Sun, 28 Aug 2005 09:36:05 -0400 (EDT)

> 	Filename	: draft-ietf-secsh-publickey-subsystem-03.txt

This looks good.  I do see a few copy-edit details, whch I shall leave
it up to others to decide on the actual importance of:

Lines 242-244:
   The version packet, as well as all requests and responses described
   in Section 3 are a description of the 'name' field and the data part
   of the packet.
s/3/3,/

Line 304:
   SHOULD be sent.  Note that normally, status messages are only sent by
s/only sent by/sent by only/

Line 367:
   SSH_PUBLICKEY_ACCESS_DENIED
s/$/./

Lines 372-375:
   SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED.  For the purposes of a
   mandatory attribute, storage of the attribute is not sufficient, but
   requires that the server understand and implement the intent of the
   attribute.
That "requires" looks subjectless; strictly, it appears to refer back
to "storage" eight words earlier, but that reads nonsensically.  While
I think the meaning is clear, I'm not confident non-anglophones will
find it as clear as I do; you might want to reword it.  Suggestion:
   SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED.  For the purposes of a
   mandatory attribute, mere storage of the attribute is not
   sufficient; the server must understand and implement the intent of
   the attribute.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: der Mouse <[email-masked]>
Date: Sun, 28 Aug 2005 09:48:32 -0400 (EDT)

> der Mouse: is this revision acceptable to you?

Yes.  There are a few niggling copy-edit details (I just sent mail to
the list about them), but I'd be satisfied with it even if those don't
get fixed.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign