RE: SSH URI Draft

["Joseph Salowey (jsalowey)" <jsalowey at cisco.com>]

Hi Jacob,

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

> -----Original Message-----
> From: ietf-ssh-owner at NetBSD.org 
> [mailto:ietf-ssh-owner at NetBSD.org] On Behalf Of Jacob Nevins
> Sent: Sunday, October 11, 2009 1:30 PM
> To: ietf-ssh at netbsd.org
> Subject: Re: SSH URI Draft
> 
> 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.)
> 
[Joe] I'm still in agreement. 

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

[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 
> draft; we could dodge the problem by only allowing up to one 
> fingerprint parameter per unique host-key-alg type.)
> 
[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. 
> 
> 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.
> 
[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.
> 
> 
> Does an IANA registry need setting up for connection parameters?
> 
[Joe] Good question, I think this is covered by the URI registration. 

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