draft-ietf-secsh-scp-sftp-ssh-uri-01.txt   draft-ietf-secsh-scp-sftp-ssh-uri-02.txt 
Network Working Group Network Working Group S. Suehring
Internet Draft S. Suehring Internet-Draft
Document: draft-ietf-secsh-scp-sftp-ssh-uri- Sentry Insurance Expires: December 16, 2005 J. Salowey
01.txt J. Salowey
Cisco Systems Cisco Systems
Expires: April 2004 October 2003 June 14, 2005
SCP/SFTP/SSH URI Format SCP/SFTP/SSH URI Format
draft-ietf-secsh-scp-sftp-ssh-uri-01.txt draft-ietf-secsh-scp-sftp-ssh-uri-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 10 of RFC2026. applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet Draft will expire on February 8, 2004. This Internet-Draft will expire on December 16, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes the Uniform Resource Identifiers used to This document describes the Uniform Resource Identifiers used to
locate resources for the SCP, SFTP, and SSH protocols. The document locate resources for the SCP, SFTP, and SSH protocols. The document
describes the generic syntax involved in URI definitions as well as describes the generic syntax involved in URI definitions as well as
specific definitions for each protocol. These specific definitions specific definitions for each protocol. These specific definitions
may include user credentials such as username and password and also may include user credentials such as username and password and also
may include other parameters such as fingerprint. In addition, may include other parameters such as fingerprint. In addition,
security considerations and examples are also provided within this security considerations and examples are also provided within this
document. document.
SCP/SFTP/SSH URI Format October 2003
Table of Contents Table of Contents
1. General Syntax.................................................2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 SSH URI....................................................2 2. General Syntax . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 SCP and SFTP URI...........................................2 2.1 SSH URI . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Parameters.....................................................3 2.2 SCP and SFTP URI . . . . . . . . . . . . . . . . . . . . . 3
2.1 SSH connection parameters..................................3 3. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 SFTP Parameters............................................4 3.1 SSH connection parameters . . . . . . . . . . . . . . . . 4
3. Examples.......................................................4 3.2 SFTP Parameters . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations........................................4 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Normative References..............................................5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
Non-Normative References..........................................6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author Information................................................6 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6
6.2 Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
1. General Syntax 1. Introduction
This document describes the Uniform Resource Identifiers (URIs) to be
used with the SSH, SCP, and SFTP protocols.
2. General Syntax
The URI for each protocol shall consist of the scheme and the scheme The URI for each protocol shall consist of the scheme and the scheme
specific portion separated by a colon ":", as discussed in RFC 2396 specific portion separated by a colon ":", as discussed in [RFC3986]
[1]. This specification shall adopt the definitions "port", "host", This specification shall adopt the definitions "port", "host",
"scheme", "userinfo", and "authority" from RFC 2396. "scheme", "userinfo", and "authority" from [RFC3986].
1.1 SSH URI 2.1 SSH URI
The SSH scheme shall consist of the protocol acronym followed by a The SSH scheme shall consist of the protocol acronym followed by a
colon ":" and a double slash "//" in accordance with RFC 2718. colon ":" and a double slash "//" in accordance with [RFC2718].
The first component of the scheme specific portion MAY include The first component of the scheme specific portion MAY include
credentials (userinfo) consisting of a username and optionally also credentials (userinfo) consisting of a username and optionally also
including a password. Including the password in the URL is NOT including a password, separated by a colon ":". Including the
RECOMMENDED. The username and password components are separated by a password in the URI is NOT RECOMMENDED and is deprecated in
single colon ":". accordance with [RFC3986]
Following the userinfo, if present, the at-sign "@" shall precede the One or more optional connection parameters (conn-parameters) may be
authority section of the URI. Optionally, the authority section MAY specified within the userinfo section of the URI. These conn-
also include the port preceded by a colon ":". If the port is not parameters are separated from the credentials by a semi-colon ";" and
included, the default port is assumed. Following the port additional from each other by a comma ",".
parameters may be specified. These parameters are defined in the
connection parameters section.
ssh_URI = "ssh://" [ userinfo "@" ] host [ ":" port ] Following the userinfo, if present, and the conn-parameters, if
[;conn-parameter=value] 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 ":". If the port is not included, the default
port is assumed.
1.2 SCP and SFTP URI ssh_URI = "ssh://" [ userinfo ] [ ";"conn-parameter=value ] [ "@" ]
host [ ":" port ]
2.2 SCP and SFTP URI
For SCP and SFTP, the scheme portion (scp: or sftp:) is followed by a For SCP and SFTP, the scheme portion (scp: or sftp:) is followed by a
double slash "//". double slash "//".
SCP/SFTP/SSH URI Format October 2003 Both SCP and SFTP URIs are terminated by a single slash "/" followed
Both SCP and SFTP URLs are terminated by a single slash "/" followed
by the path information to the requested resource. by the path information to the requested resource.
The first component of the scheme specific portion MAY include The first component of the scheme specific portion MAY include
credentials (userinfo) consisting of a username and optionally also credentials (userinfo) consisting of a username and optionally also
including a password. Including the password in the URL is NOT including a password, separated by a colon ":". Including the
RECOMMENDED. The username and password components are separated by a password in the URI is NOT RECOMMENDED and is deprecated in
single colon ":". accordance with [RFC3986]
Following the userinfo, if present, the at-sign "@" shall precede the One or more optional connection parameters (conn-parameters) may be
authority section of the URL. Optionally, the authority section MAY specified within the userinfo section of the URI. These conn-
also include the port preceded by a colon ":". If the port is not parameters are separated from the credentials by a semi-colon ";" and
included, the default port is assumed. Following the port additional from each other by a comma ",".
parameters may be specified. These parameters are defined in the
connection parameters section.
scp_URI = "scp://" [ userinfo "@" ] host [ ":" port ] Following the userinfo, if present, and the conn-parameters, if
[ ; parameter = value ] [ abs_path ] 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 ":". If the port is not included, the default
port is assumed.
scp_URI = "scp://" [userinfo ] [ ";"conn-parameter=value ] [ "@" ]
host [ ":" port ] [abs_path ]
Following the port additional parameters may be specified. These Following the port additional parameters may be specified. These
parameters are defined in the connection parameters section. parameters are defined in the connection parameters section.
Following the path additional sftp specific parameters may be Following the path additional sftp specific parameters may be
specified. specified.
sftp_URI = "sftp://" [ userinfo "@" ] host [ ":" port ] sftp_URI = "sftp://" [ userinfo ] [ ";"conn-parameter=value] [ "@" ]
[;conn-parameter=value] [ abs_path ] [;sftp-parameter=value] host [ ":" port ] [ abs_path ] [ ";"sftp-parameter=value ]
The URIs for SFTP and SCP are hierarcical URIs where each component The URIs for SFTP and SCP are hierarchical URIs where each component
of the abs_path consists of path elements separated by a '/'. This is of the abs_path consists of path elements separated by a '/'. This
the same format as used in the FTP URL described in section 2.2.2 of formatting is meant to represent the path information as in Section 5
[5]. of [I-D.ietf-secsh-filexfer].
2. Parameters 3. Parameters
2.1 SSH connection parameters 3.1 SSH connection parameters
The following parameters are associated with an SSH connection and The following parameters are associated with an SSH connection and
are applicable to SSH, SFTP and SCP. All parameters are optional and are applicable to SSH, SFTP and SCP. All parameters are optional and
MUST NOT overwrite configured defaults. Individual parameters are MUST NOT overwrite configured defaults. Individual parameters are
separated by a comma (","). separated by a comma (","). Additional parameters MAY be used.
fingerprint fingerprint
The fingerprint parameter contains the fingerprint of the host key The fingerprint parameter contains the fingerprint of the host key
for the host specified in the URL. The fingerprint is encoded as for the host specified in the URL. The fingerprint is encoded as
host-key-alg:fingerprint. Host-key-alg is host public key algorithm host-key-alg-fingerprint. Host-key-alg is host public key
defined [4] and the fingerprint format is defined in [2]. algorithm defined in [I-D.ietf-secsh-transport] and the
fingerprint format is [I-D.ietf-secsh-publickeyfile]. For use in
SCP/SFTP/SSH URI Format October 2003 a URI, the fingerprint shall use a single dash "-" as a separator
instead of the colon ":" as described in [I-D.ietf-secsh-
This parameter MUST NOT overwrite a key that is already configured publickeyfile]. This parameter MUST NOT overwrite a key that is
for the host. The fingerprint MAY be used to validate the already configured for the host. The fingerprint MAY be used to
authenticity of the host key if the URL was obtained from an validate the authenticity of the host key if the URL was obtained
authenticated source with its integrity protected. If this parameter from an authenticated source with its integrity protected. If
is not included then the validity of the host key is validated using this parameter is not included then the validity of the host key
another method. See Security Considerations section for additional is validated using another method. See Security Considerations
considerations. There MUST be only one fingerprint parameter per section for additional considerations. There MUST be only one
host-key-alg for a given URL. fingerprint parameter per host-key-alg for a given URL.
2.2 SFTP Parameters 3.2 SFTP Parameters
The SFTP parameters determine how to handle the file transfer The SFTP parameters determine how to handle the file transfer
character translation. character translation. Additional parameters MAY be used.
newline newline
The newline parameter determines how the server translates new line The newline parameter determines how the server translates new
indicators. The possible choices are usually "\r" or "\n" or "\r\n". line indicators. The default is CRLF and implemented in
The default is "\r\n". accordance with Section 4.3 of [I-D.ietf-secsh-filexfer].
typecode typecode
The typecode identifies the type of file which determines how it will The typecode identifies the type of file which determines how it
be treated. Possible values are "i" for binary files, "a" for text will be treated. Possible values are "i" for binary files, "a"
files, and "d" for directory listings. for text files, and "d" for directory listings.
3. Examples 4. Examples
The following section shows basic examples of URLs for each protocol. The following section shows basic examples of URLs for each protocol.
This section should not be considered to include all possible This section should not be considered to include all possible
combinations of URLs for each protocol. combinations of URLs for each protocol.
ssh://user@host ssh://user@host
ssh://user@host:2222 ssh://user@host:2222
ssh://joeuser@example.com;fingerprint=ssh-dss:c1:b1:30:29:d7:b8 ssh://user;fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-
:de:6c:97:77:10:d7:46:41:63:87 77-10-d7-46-41-63-87@example.com
scp://user:password@host/file.txt scp://user@host.example.com/file.txt
sftp://user@host/dir/path/file.txt sftp://user@host/dir/path/file.txt
sftp://joeuser@example.com:2222;fingerprint=ssh-dss:c1:b1:30 sftp://user;newline=CR,fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de
:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87, -6c-97-77-10-d7-46-41-63-87@example.com:2222/
4. Security Considerations
SCP/SFTP/SSH URI Format October 2003 5. Security Considerations
In general, URIs themselves have no security considerations. In general, URIs themselves have no security considerations.
However, since the password for each scheme can optionally be However, since the password for each scheme can optionally be
included within the URL it should be noted that doing so poses a included within the URI it should be noted that doing so poses a
security risk. Since URLs are usually sent in the clear with no security risk. Since URIs are usually sent in the clear with no
encryption or other security, any password or other credentials encryption or other security, any password or other credentials
(userinfo) included could be seen by a potential attacker. (userinfo) included could be seen by a potential attacker.
Care must also be taken in handling fingerprints associated with URLs Care must also be taken in handling fingerprints associated with URIs
because URLs transmitted or stored without protection may be modified because URIs transmitted or stored without protection may be modified
by an attacker. In general an implementation cannot determine the by an attacker. In general an implementation cannot determine the
source of a URL so a fingerprint received in a URL should have no source of a URI so a fingerprint received in a URI should have no
more trust associated with it than a raw public key received in the more trust associated with it than a raw public key received in the
SSH protocol itself. If a locally configured key exists for the SSH protocol itself. If a locally configured key exists for the
server already it MUST NOT be automatically overwritten with server already it MUST NOT be automatically overwritten with
information from the URL. If the host is unknown then the information from the URI. If the host is unknown then the
implementation should treat the fingerprint received with the same implementation should treat the fingerprint received with the same
caution that it does with any unknown public key. The client MAY caution that it does with any unknown public key. The client MAY
offer the fingerprint and URL for external validation before allowing offer the fingerprint and URI for external validation before allowing
a connection based on this information. If the client chooses to make a connection based on this information. If the client chooses to
a connection based on the URL information and it finds that the make a connection based on the URI information and it finds that the
public key in the URL and the public key offered by the server do not public key 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 match then it SHOULD provide a warning and provide a means to abort
the connection. Sections 3.1 and 8.2.4 of [3] provide a good the connection. Sections 4.1 and 9.2.4 of [I-D.ietf-secsh-
discussion of handling public keys received in the SSH protocol. architecture] provide a good discussion of handling public keys
received in the SSH protocol.
Normative References 6. References
[1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 6.1 Normative References
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[2] Markus Friedl, "SSH Fingerprint Format", [I-D.ietf-secsh-architecture]
http://www.ietf.org/internet-drafts/draft-ietf-secsh-fingerprint- Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
01.txt, work in progress draft-ietf-secsh-architecture-22 (work in progress),
March 2005.
[3] Ylonen, T., "SSH Protocol Architecture", [I-D.ietf-secsh-filexfer]
http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture- Galbraith, J., "SSH File Transfer Protocol",
14.txt, work in progreess draft-ietf-secsh-filexfer-09 (work in progress),
June 2005.
[4] Ylonen, T., "SSH Transport Layer Protocol", [I-D.ietf-secsh-publickeyfile]
http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport- Galbraith, J. and R. Thayer, "SSH Public Key File Format",
16.txt, work in progress draft-ietf-secsh-publickeyfile-08 (work in progress),
April 2005.
[5] Hoffman, P., Definitions of Early URI Schemes", [I-D.ietf-secsh-transport]
http://www.ietf.org/internet-drafts/draft-hoffman-rfc1738bis-00.txt, Lonvick, C., "SSH Transport Layer Protocol",
work in progress draft-ietf-secsh-transport-24 (work in progress),
March 2005.
SCP/SFTP/SSH URI Format October 2003 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November 1999.
Non-Normative References [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
Masinter, L., et. al., "Guidelines for new URL Schemes", RFC 2718, 6.2 Informative References
November 1999.
Mealling, M., Denenberg, R., "Report from the Joint W3C/IETF URI [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/
Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, IETF URI Planning Interest Group: Uniform Resource
and Uniform Resource Names (URNs): Clarifications and Identifiers (URIs), URLs, and Uniform Resource Names
Recommendations", RFC 3305, August 2002. (URNs): Clarifications and Recommendations", RFC 3305,
August 2002.
Author Information Authors' Addresses
Steve Suehring Steve Suehring
Sentry Insurance PO BOX 1033
1800 North Point Dr, G2/61-17
Stevens Point, WI 54481 Stevens Point, WI 54481
suehring@braingia.com US
Email: suehring@braingia.com
Joseph Salowey Joseph Salowey
Cisco Systems Cisco Systems
2901 Third Avenue 2901 3rd Ave
Seattle, WA 98121 Seattle, WA 98121
E-mail: jsalowey@cisco.com US
Email: jsalowey@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
SCP/SFTP/SSH URI Format October 2003
Copyright (C) The Internet Society (2003). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2005). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/