idnits 2.17.1 draft-ietf-secsh-scp-sftp-ssh-uri-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 316. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 85: '...he scheme specific portion MAY include...' RFC 2119 keyword, line 88: '...n the URI is NOT RECOMMENDED and is de...' RFC 2119 keyword, line 98: '...uthority section MAY also include the ...' RFC 2119 keyword, line 113: '...he scheme specific portion MAY include...' RFC 2119 keyword, line 116: '...n the URI is NOT RECOMMENDED and is de...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 14, 2005) is 6890 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-secsh-architecture' is defined on line 242, but no explicit reference was found in the text == Unused Reference: 'RFC3305' is defined on line 271, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-secsh-filexfer-09 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-secsh-filexfer' == Outdated reference: A later version (-13) exists of draft-ietf-secsh-publickeyfile-08 ** Downref: Normative reference to an Informational draft: draft-ietf-secsh-publickeyfile (ref. 'I-D.ietf-secsh-publickeyfile') ** Obsolete normative reference: RFC 2718 (Obsoleted by RFC 4395) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Suehring 3 Internet-Draft 4 Expires: December 16, 2005 J. Salowey 5 Cisco Systems 6 June 14, 2005 8 SCP/SFTP/SSH URI Format 9 draft-ietf-secsh-scp-sftp-ssh-uri-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 16, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes the Uniform Resource Identifiers used to 43 locate resources for the SCP, SFTP, and SSH protocols. The document 44 describes the generic syntax involved in URI definitions as well as 45 specific definitions for each protocol. These specific definitions 46 may include user credentials such as username and password and also 47 may include other parameters such as fingerprint. In addition, 48 security considerations and examples are also provided within this 49 document. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. General Syntax . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1 SSH URI . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2 SCP and SFTP URI . . . . . . . . . . . . . . . . . . . . . 3 57 3. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1 SSH connection parameters . . . . . . . . . . . . . . . . 4 59 3.2 SFTP Parameters . . . . . . . . . . . . . . . . . . . . . 5 60 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 64 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 66 Intellectual Property and Copyright Statements . . . . . . . . 8 68 1. Introduction 70 This document describes the Uniform Resource Identifiers (URIs) to be 71 used with the SSH, SCP, and SFTP protocols. 73 2. General Syntax 75 The URI for each protocol shall consist of the scheme and the scheme 76 specific portion separated by a colon ":", as discussed in [RFC3986] 77 This specification shall adopt the definitions "port", "host", 78 "scheme", "userinfo", and "authority" from [RFC3986]. 80 2.1 SSH URI 82 The SSH scheme shall consist of the protocol acronym followed by a 83 colon ":" and a double slash "//" in accordance with [RFC2718]. 85 The first component of the scheme specific portion MAY include 86 credentials (userinfo) consisting of a username and optionally also 87 including a password, separated by a colon ":". Including the 88 password in the URI is NOT RECOMMENDED and is deprecated in 89 accordance with [RFC3986] 91 One or more optional connection parameters (conn-parameters) may be 92 specified within the userinfo section of the URI. These conn- 93 parameters are separated from the credentials by a semi-colon ";" and 94 from each other by a comma ",". 96 Following the userinfo, if present, and the conn-parameters, if 97 present the at-sign "@" shall precede the authority section of the 98 URI. Optionally, the authority section MAY also include the port 99 preceded by a colon ":". If the port is not included, the default 100 port is assumed. 102 ssh_URI = "ssh://" [ userinfo ] [ ";"conn-parameter=value ] [ "@" ] 103 host [ ":" port ] 105 2.2 SCP and SFTP URI 107 For SCP and SFTP, the scheme portion (scp: or sftp:) is followed by a 108 double slash "//". 110 Both SCP and SFTP URIs are terminated by a single slash "/" followed 111 by the path information to the requested resource. 113 The first component of the scheme specific portion MAY include 114 credentials (userinfo) consisting of a username and optionally also 115 including a password, separated by a colon ":". Including the 116 password in the URI is NOT RECOMMENDED and is deprecated in 117 accordance with [RFC3986] 119 One or more optional connection parameters (conn-parameters) may be 120 specified within the userinfo section of the URI. These conn- 121 parameters are separated from the credentials by a semi-colon ";" and 122 from each other by a comma ",". 124 Following the userinfo, if present, and the conn-parameters, if 125 present the at-sign "@" shall precede the authority section of the 126 URI. Optionally, the authority section MAY also include the port 127 preceded by a colon ":". If the port is not included, the default 128 port is assumed. 130 scp_URI = "scp://" [userinfo ] [ ";"conn-parameter=value ] [ "@" ] 131 host [ ":" port ] [abs_path ] 133 Following the port additional parameters may be specified. These 134 parameters are defined in the connection parameters section. 135 Following the path additional sftp specific parameters may be 136 specified. 138 sftp_URI = "sftp://" [ userinfo ] [ ";"conn-parameter=value] [ "@" ] 139 host [ ":" port ] [ abs_path ] [ ";"sftp-parameter=value ] 141 The URIs for SFTP and SCP are hierarchical URIs where each component 142 of the abs_path consists of path elements separated by a '/'. This 143 formatting is meant to represent the path information as in Section 5 144 of [I-D.ietf-secsh-filexfer]. 146 3. Parameters 148 3.1 SSH connection parameters 150 The following parameters are associated with an SSH connection and 151 are applicable to SSH, SFTP and SCP. All parameters are optional and 152 MUST NOT overwrite configured defaults. Individual parameters are 153 separated by a comma (","). Additional parameters MAY be used. 155 fingerprint 157 The fingerprint parameter contains the fingerprint of the host key 158 for the host specified in the URL. The fingerprint is encoded as 159 host-key-alg-fingerprint. Host-key-alg is host public key 160 algorithm defined in [I-D.ietf-secsh-transport] and the 161 fingerprint format is [I-D.ietf-secsh-publickeyfile]. For use in 162 a URI, the fingerprint shall use a single dash "-" as a separator 163 instead of the colon ":" as described in [I-D.ietf-secsh- 164 publickeyfile]. This parameter MUST NOT overwrite a key that is 165 already configured for the host. The fingerprint MAY be used to 166 validate the authenticity of the host key if the URL was obtained 167 from an authenticated source with its integrity protected. If 168 this parameter is not included then the validity of the host key 169 is validated using another method. See Security Considerations 170 section for additional considerations. There MUST be only one 171 fingerprint parameter per host-key-alg for a given URL. 173 3.2 SFTP Parameters 175 The SFTP parameters determine how to handle the file transfer 176 character translation. Additional parameters MAY be used. 178 newline 180 The newline parameter determines how the server translates new 181 line indicators. The default is CRLF and implemented in 182 accordance with Section 4.3 of [I-D.ietf-secsh-filexfer]. 184 typecode 186 The typecode identifies the type of file which determines how it 187 will be treated. Possible values are "i" for binary files, "a" 188 for text files, and "d" for directory listings. 190 4. Examples 192 The following section shows basic examples of URLs for each protocol. 193 This section should not be considered to include all possible 194 combinations of URLs for each protocol. 196 ssh://user@host 198 ssh://user@host:2222 200 ssh://user;fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97- 201 77-10-d7-46-41-63-87@example.com 203 scp://user@host.example.com/file.txt 205 sftp://user@host/dir/path/file.txt 207 sftp://user;newline=CR,fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de 208 -6c-97-77-10-d7-46-41-63-87@example.com:2222/ 210 5. Security Considerations 212 In general, URIs themselves have no security considerations. 213 However, since the password for each scheme can optionally be 214 included within the URI it should be noted that doing so poses a 215 security risk. Since URIs are usually sent in the clear with no 216 encryption or other security, any password or other credentials 217 (userinfo) included could be seen by a potential attacker. 219 Care must also be taken in handling fingerprints associated with URIs 220 because URIs transmitted or stored without protection may be modified 221 by an attacker. In general an implementation cannot determine the 222 source of a URI so a fingerprint received in a URI should have no 223 more trust associated with it than a raw public key received in the 224 SSH protocol itself. If a locally configured key exists for the 225 server already it MUST NOT be automatically overwritten with 226 information from the URI. If the host is unknown then the 227 implementation should treat the fingerprint received with the same 228 caution that it does with any unknown public key. The client MAY 229 offer the fingerprint and URI for external validation before allowing 230 a connection based on this information. If the client chooses to 231 make a connection based on the URI information and it finds that the 232 public key in the URI and the public key offered by the server do not 233 match then it SHOULD provide a warning and provide a means to abort 234 the connection. Sections 4.1 and 9.2.4 of [I-D.ietf-secsh- 235 architecture] provide a good discussion of handling public keys 236 received in the SSH protocol. 238 6. References 240 6.1 Normative References 242 [I-D.ietf-secsh-architecture] 243 Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 244 draft-ietf-secsh-architecture-22 (work in progress), 245 March 2005. 247 [I-D.ietf-secsh-filexfer] 248 Galbraith, J., "SSH File Transfer Protocol", 249 draft-ietf-secsh-filexfer-09 (work in progress), 250 June 2005. 252 [I-D.ietf-secsh-publickeyfile] 253 Galbraith, J. and R. Thayer, "SSH Public Key File Format", 254 draft-ietf-secsh-publickeyfile-08 (work in progress), 255 April 2005. 257 [I-D.ietf-secsh-transport] 258 Lonvick, C., "SSH Transport Layer Protocol", 259 draft-ietf-secsh-transport-24 (work in progress), 260 March 2005. 262 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 263 "Guidelines for new URL Schemes", RFC 2718, November 1999. 265 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 266 Resource Identifier (URI): Generic Syntax", STD 66, 267 RFC 3986, January 2005. 269 6.2 Informative References 271 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ 272 IETF URI Planning Interest Group: Uniform Resource 273 Identifiers (URIs), URLs, and Uniform Resource Names 274 (URNs): Clarifications and Recommendations", RFC 3305, 275 August 2002. 277 Authors' Addresses 279 Steve Suehring 280 PO BOX 1033 281 Stevens Point, WI 54481 282 US 284 Email: suehring@braingia.com 286 Joseph Salowey 287 Cisco Systems 288 2901 3rd Ave 289 Seattle, WA 98121 290 US 292 Email: jsalowey@cisco.com 294 Intellectual Property Statement 296 The IETF takes no position regarding the validity or scope of any 297 Intellectual Property Rights or other rights that might be claimed to 298 pertain to the implementation or use of the technology described in 299 this document or the extent to which any license under such rights 300 might or might not be available; nor does it represent that it has 301 made any independent effort to identify any such rights. Information 302 on the procedures with respect to rights in RFC documents can be 303 found in BCP 78 and BCP 79. 305 Copies of IPR disclosures made to the IETF Secretariat and any 306 assurances of licenses to be made available, or the result of an 307 attempt made to obtain a general license or permission for the use of 308 such proprietary rights by implementers or users of this 309 specification can be obtained from the IETF on-line IPR repository at 310 http://www.ietf.org/ipr. 312 The IETF invites any interested party to bring to its attention any 313 copyrights, patents or patent applications, or other proprietary 314 rights that may cover technology that may be required to implement 315 this standard. Please address the information to the IETF at 316 ietf-ipr@ietf.org. 318 Disclaimer of Validity 320 This document and the information contained herein are provided on an 321 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 322 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 323 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 324 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 325 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 326 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 328 Copyright Statement 330 Copyright (C) The Internet Society (2005). This document is subject 331 to the rights, licenses and restrictions contained in BCP 78, and 332 except as set forth therein, the authors retain all their rights. 334 Acknowledgment 336 Funding for the RFC Editor function is currently provided by the 337 Internet Society.