Subject: SSH URI Draft

From: Steve Suehring <[email-masked]>
Date: Thu, 8 Oct 2009 11:19:56 -0500

Hello,

Attached is a revised draft of the SSH URI proposal.

This draft removes the SCP and SFTP URI sections, adds an example, and 
updates the status of some of the references as well as changes for new 
IETF requirements, among other changes.

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

Note that this draft is currently named as an individual submission.  If 
we find that it should go within another WG then it may be renamed as 
appropriate.

Here are previous drafts:

http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/

Steve

---

From: Jacob Nevins <[email-masked]>
Date: Sun, 11 Oct 2009 21:30:14 +0100

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).

> 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.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 12 Oct 2009 21:19:55 -0700

Hi Jacob,

Thanks for tracking this down.  Comments in-line below:

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jacob Nevins
> Sent: Sunday, October 11, 2009 1:30 PM
> To: [email-masked]
> Subject: Re: SSH URI Draft
> 
> 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.
> 
> 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.
> 
> throughout with "override" and "overridden". (Joe Salowey 
> agreed in principle with this textual change 2005-Sep-02.)
> 
[Joe] I'm still in agreement. 

> 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 
> (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:
> 
> 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."
> 

[Joe] Wouldn't you want to provide a warning as well if the host key
algorithm did not match the fingerprints?  

> (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 
[Joe] OK, I need to think about this.  Right now I can't see a problem
with multiple host keys, except perhaps some difficulty in the URI
format. 
> 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.
> 
> 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.
> 
[Joe]  I'm not sure how much we should specify.  The password
authentication piece is pretty straight forward.  I suppose if we said
first keyboard interactive prompt that wouldn't be to complex.  Behavior
beyond this could be tricky. 

> 
> 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.
> 
> 
[Joe] Good question, I think this is covered by the URI registration. 

> 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.
>