Uniform Resource Identifier (URI) Scheme for Secure Shell (SSH)
draft-salowey-secsh-uri-00

Below is Joe's response in response to Cullen's comments. I've edited out comments which are wrong/irrelevant.
Note that I don't believe that all of these need to be addressed,


Joe Salowey wrote:

>Thanks for the speedy review, some comments and questions inline below:
>
>On Nov 17, 2010, at 12:25 PM, Cullen Jennings wrote: 
>
>>Several things in this draft surprised me a bit thought nothing looked completely broken. I
>>
>>You need an IANA registry for the parameters and a way new parameters get added
>>
>[Joe] OK, Although I think this was more important when the draft also covered SFTP, I'm not sure that an SSH terminal session needs additional parameters, but I'm sure someone will think of something.

[...snip...]

>>It says the fingerprint is in 4716 format but the examples have ssh-dss in them that does not look like that format. I would have expected they type of the fingerprint to be on the left not the right of the equal sign so instead of 
>>
>
>[Joe] ssh-dss is actually the public key algorithm of the key (ssh-rsa, ssh-dss, etc.) represented by Host-key-alg and not the type of fingerprint.  An ssh server may have more than one host key for supporting different algorithms.  The hash for the fingerprint is defined in 4716 and is set to MD5.  Maybe we should move away from 4716 so we can have hash agility in the way you show below.  I believe we had some limited discussion of this in the past, but that was a while ago. 
>
>>fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-77-10-d7-46-41-63-87@host.example.com
>>
>>I would have expected
>>
>>md5-fingerprint=c1-b1-30-29-d7-b8-de-6c-97-77-10-d7-46-41-63-87@host.example.com
>>
>>I was surprised to see the c-param added to the user instead of the right hand side of URI
>>
>>so Instead of
>>ssh://user;foo=bar@example.com
>>
>>I would have expected
>>ssh://user@example.com;foo=bar
>>
>>   
>>
>[Joe] we had some discussion of this previously and I believe it was the other way at some point. I couldn't find a resolution so I left it as it was.  Looking at it now, It seems like belongs on the right hand side of the URI since is is not about the user, but parameter is about the resource.
>
>>I was surprised that the c-param required the equal so I can not have a parameter like  "useFooMode" but must instead have a parameter like "useFooMode=1"
>>
>
>[Joe] I'm not sure why we did it that way.  If it aligns with current practice we should change it.

[...]

>>GIven a major use of SSH is SCP, I wish this URI worked for file paths as well   
>>
>[Joe] There are multiple SSH file xfer protocols: Sftp and scp.  These were originally covered in the draft, but there was no stable reference for them so I decided to defer them to another document.  I was thinking they would have their own URI schemes.
>
>>The draft says
>> This document is discussed on the IETF SSH list: ietf-ssh@netbsd.org
>>
>>I realize that was the list for the closed WG but I don't think that is an IETF list. It is not under IETF rules and is not listedhttp://www.ietf.org/list/nonwg.html. I would highly suggest moving the conversation to an IETF list.
>>
>
>[Joe] OK, that is the old SSH WG list which is still active.  I guess we can discuss on the IETF list unless there is another one that is more appropriate. 

My initial AD review:

> 3.3.  URI Scheme Syntax
>
>    sshURI        =  "ssh:" hier-part
>    hier-part    =  "//" authority path-abempty
>    authority    =  [ [ ssh-info ] "@" ] host [ ":" port ]
>    host          = 
>    port          = 
>    path-abempty  = 
>    ssh-info      =  [ userinfo ] [";" c-param *("," c-param)]
>    userinfo      = 
>    c-param      =  paramname "=" paramvalue
>    paramname    =  *( ALPHA / DIGIT / "-" )
>    paramvalue    =  *( ALPHA / DIGIT / "-" )

This looks fine, but I need to double check if this is consistent with RFC 3986. You don't need to do anything yet.

One minor thing: some URI scheme didn't specify that an absent path is the same as "/" and this caused some interop problems. E.g. HTTP is treating http://www.example.com and http://www.example.com/ as the same. I think other schemes should do the same.

>    The following reserved characters from [RFC3986] are used as
>    delimiters within the SSH URI: ";", ",", ":", and "=" .  They must
>    not be escaped when used as delimiters and must be escaped when the
>    appear in other uses.

s/must/MUST (twice)?

> 3.4.  URI Semantics
>
>    If the userinfo or connection parameters are present the at-sign "@"
>    shall precede the authority section of the URI.  Optionally, the
>    authority section MAY also include the port preceded by a colon ":".
>    The host SHOULD be a non-empty string.  If the port is not included,
>    the default port is assumed.

I think repeating the default SSH port here might be a good idea.

> 4.1.  SSH connection parameters
>
>    The following parameters are associated with an SSH connection and
>    are applicable to SSH and SFTP.

SFTP needs an Informative Reference, or it needs to be removed.
Joe agreed that it would be better to cover SFTP in a separate document.

>    All parameters are optional and MUST
>    NOT overwrite configured defaults.  Individual parameters are

Some explanation about why MUST NOT is used here would be nice.

>    separated by a comma (",").

From SecDir review by Rob Austein. This comment is likely need some additional text:

This draft defines URI syntax and semantics for ssh.  The proposed
mechanism is straightforward, and the authors have shown laudable
restraint in defining only the minimum necessary to do the job.

I have no serious security concerns regarding this document, but did
notice one omission: the (otherwise quite good) discussion of the
fingerprint option gives no guidance on interaction with RFC 4255.
Such a discussion need not be very long (a paragraph would do), but
should cover both the presence and absence of a verified DNSSEC
signature for the SSHFP RRset, as the recommendations presumably will
be different for those two cases.

Upon approval of this document, IANA understands that there is a single
IANA Action that needs to be completed.

Upon approval, a new, permanent URI scheme is to be registered in the
URI Schemes registry located at:

http://www.iana.org/assignments/uri-schemes.html

The URI scheme is to be: SSH
The Reference is to be: [RFC-to-be]

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Uniform Resource Identifier (URI) Scheme for Secure Shell (SSH)) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Uniform Resource Identifier (URI) Scheme for Secure Shell (SSH)'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-12-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-salowey-secsh-uri/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-salowey-secsh-uri/