RE: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt

["Joseph Salowey" <jsalowey%cisco.com@localhost>]

> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost 
> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Joel N. Weber II
> Sent: Wednesday, August 13, 2003 10:35 AM
> To: ietf-ssh%NetBSD.org@localhost
> Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt
> 
> 
> Is there a good reason to define scp URLs in addition to sftp URLs?
> 
[Joe] SCP is is use today, we thought it would be useful.

> I don't think explicitly specifying port 22 in all cases 
> where the URL doesn't specify a port number is correct; what 
> about SRV DNS records?
[Joe] So the suggestion would be something like:

If the URL doesn't specify a port number the it should check for a SRV
DNS record if it is available, if it is not then it should use port 22.

> 
> What is the rationale for allowing the URL to specify 
> information about ciphers, integrity protection, etc?  It 
> seems allowing this to be specified might allow an attacker 
> providing a URL to perform a downgrade attack, which at the 
> very least should be mentioned in the security considerations 
> section.  There doesn't seem to be anything prohibiting an 
> attacker from specifying ``none'', either.

[Joe]  This was added as an afterthought to the fingerprint parameter.
The thought was that the this would allow the URL to specify what
parameters should be used.  However for parameters that are negotiated
such as cipher, integrity, etc. It's not clear that they add much value.
The list should not add to what is configured as acceptable to the
client confiuration.  If the client allows none in its default
configuration there is a potential problem whether the URL speficies it
or not.  Perhaps it would be better to let the SSH negotiation take care
of this and remove it from the URL.      
 
> It looks to me like there is no mechanism for specifying the 
> public key host key algorithm to be used, nor does the 
> fingerprint contain that information.  Combined with only 
> allowing one fingerprint, that has the potential to cause 
> interoperability problems: if I have a server with one 
> ssh-rsa key, and one ssh-dss key, and some clients happen to 
> prefer ssh-rsa over ssh-dss and others are the other way 
> around, how do I provide a URL with a fingerprint that will 
> work with both types of clients?
> 
[Joe] Yes, I didn't think about this.  There should be a way to
accomplish this.  It seems like we may need to allow for multiple
fingerprints and multiple host algortihms.  Perhaps the fingerprint
parameter should be something like
fingerprint=<hostkeyalg>:<fingerprint>;


> 
> 
> 
> 
> 
>