Re: SSH URI Draft

[Jacob Nevins <jacobn+secsh at chiark.greenend.org.uk>]

Thanks for reviving this. Support for ssh: URIs is frequently
requested by users of our implementation.

As well as my own comments, I've had a look back through the mailing
list archives to see if any of the comments on the earlier drafts
still apply (although most of the discussion has become irrelevant
with the removal of SFTP).

Steve Suehring writes:
> Please let me know any feedback on the draft.  After a short period I'll 
> be submitting it to the IETF.

My biggest remaining problem is with the use of the words "overwrite"
and "overwritten" throughout the text, as noted in 2005:

> 5.1   SSH connection parameters
  [...]
>                                                                    All
>    parameters are optional and MUST NOT overwrite configured defaults.  
  [...]
>                   This parameter MUST NOT overwrite a key that is 
>       already configured for the host.
  [...]
> 8.  Security Considerations
  [...]
>                          If a locally configured key exists for the
>    server already it MUST NOT be automatically overwritten with
>    information from the URI.

This could easily be interpreted to mean only that no permanent change
should be made to an implementation's persistent cache of known host
keys, rather than the stronger requirement that I believe is intended:
that the fingerprint in the URL is only a hint, and any locally known
mapping between hostname and host key should continue to be taken into
account.

I think "overwrite" and "overwritten" should thus be replaced
throughout with "override" and "overridden". (Joe Salowey agreed in
principle with this textual change 2005-Sep-02.)


Section 5.1:
>                                   There MUST be only one fingerprint
>       parameter present in a given URI.

There's been lots of discussion of this restriction in the past;
IIRC several people on the list wanted to be able to support multiple
host key fingerprints in a URI, and no-one provided a good reason for
the restriction.

In 2003, you wrote:
| I've been racking my brain on this because I really thought there was a
| reason for the limitation.  I can't find it in the archives so maybe I
| didn't share that thought.  In any event, it seems as though the
| consensus is definitely for multiple fingerprints.

(Guess: a very early draft didn't specify a host key algorithm in the
URI; perhaps the restriction was something to do with that?)

In any case, if the consensus is that multiple fingerprints are OK, I
suggest removing the above sentence and adding the following text:

"Any number of fingerprint parameters may be present in a given URI."

and in Section 8 "Security Considerations", change the following
sentence:

>                                             If the client chooses to
>    make a connection based on the URI information and it finds that the
>    fingerprint in the URI and the public key offered by the server do
>    not match then it SHOULD provide a warning and provide a means to
>    abort the connection.

to the somewhat clumsy: "If the client chooses to make a connection
based on the URI information and it finds that, for a given host key
algorithm for which fingerprint(s) are specified in the URI, the
public key offered by the server does not match any of the
fingerprints in the URI, then it SHOULD provide a warning and provide
a means to abort the connection."

(The last change reflects the fact that some operators of clusters
with multiple servers behind a single hostname seem to like to have
different host keys on each server, and to have client implementations
able to record multiple host keys against a single hostname, and
accept any of them. I believe the OpenSSH client implements this
behaviour. Personally I'd give all the servers the same host key if
they were truly indistinguishable from a security point of view, but
hey. If this part proves controversial, it shouldn't hold up the
draft; we could dodge the problem by only allowing up to one
fingerprint parameter per unique host-key-alg type.)


In 2005, Ben Harris wrote:
| The interpretation of the password part of userinfo isn't specified.
| In particular, it's not clear whether it only applies to "password"
| athentication, or also to "keyboard-interactive".

This comment is still relevant. Many server implementations present a
"password" type authentication that ought to work with a password in
the "userinfo" part of the URI as "keyboard-interactive" over SSH.

What our implementation does in a similar situation (password
specified on the command-line) is to feed the supplied password to
either the first "password" authentication, or the first
"keyboard-interactive" (RFC4256) prompt which has the "echo" flag
cleared, and bomb out if any further "interactive" authentication is
required beyond that.

That's somewhat heuristic, though; would we want to attempt to capture
that in this document? Actual use of this field is usually a bad idea
and is deprecated, but unless it's banned outright, its meaning should
probably be specified.


I'm a bit uncomfortable with the "host-key-alg-fingerprint" encoding
as there's a theoretical ambiguity there. I'll elaborate in a followup
to the other post.


Does an IANA registry need setting up for connection parameters?


Nits:

Section 4.3, last sentence: "the" should be "they".

Sections 4.4 and 4.5 refer to "Section 4.1" as defining host-key
fingerprints, but Section 4.1 is "Scheme Name". The references should
be to Section 5.1.