idnits 2.17.1 draft-ietf-secsh-scp-sftp-ssh-uri-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-ietf-secsh-scp-sftp-ssh-uri-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-secsh-scp-sftp-ssh-uri-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-secsh-scp-sftp-ssh-uri-', but the file name used is 'draft-ietf-secsh-scp-sftp-ssh-uri-01' == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 77: '...he scheme specific portion MAY include...' RFC 2119 keyword, line 80: '... RECOMMENDED. The username and pass...' RFC 2119 keyword, line 84: '... Optionally, the authority section MAY...' RFC 2119 keyword, line 103: '...he scheme specific portion MAY include...' RFC 2119 keyword, line 106: '... RECOMMENDED. The username and pass...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 2003) is 7470 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) ** Obsolete normative reference: RFC 2396 (ref. '1') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1738 (ref. '5') (Obsoleted by RFC 4248, RFC 4266) Summary: 7 errors (**), 1 flaw (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft S. Suehring 3 Document: draft-ietf-secsh-scp-sftp-ssh-uri- Sentry Insurance 4 01.txt J. Salowey 5 Cisco Systems 6 Expires: April 2004 October 2003 8 SCP/SFTP/SSH URI Format 9 draft-ietf-secsh-scp-sftp-ssh-uri-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet Draft will expire on February 8, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document describes the Uniform Resource Identifiers used to 41 locate resources for the SCP, SFTP, and SSH protocols. The document 42 describes the generic syntax involved in URI definitions as well as 43 specific definitions for each protocol. These specific definitions 44 may include user credentials such as username and password and also 45 may include other parameters such as fingerprint. In addition, 46 security considerations and examples are also provided within this 47 document. 49 SCP/SFTP/SSH URI Format October 2003 51 Table of Contents 53 1. General Syntax.................................................2 54 1.1 SSH URI....................................................2 55 1.2 SCP and SFTP URI...........................................2 56 2. Parameters.....................................................3 57 2.1 SSH connection parameters..................................3 58 2.2 SFTP Parameters............................................4 59 3. Examples.......................................................4 60 4. Security Considerations........................................4 61 Normative References..............................................5 62 Non-Normative References..........................................6 63 Author Information................................................6 65 1. General Syntax 67 The URI for each protocol shall consist of the scheme and the scheme 68 specific portion separated by a colon ":", as discussed in RFC 2396 69 [1]. This specification shall adopt the definitions "port", "host", 70 "scheme", "userinfo", and "authority" from RFC 2396. 72 1.1 SSH URI 74 The SSH scheme shall consist of the protocol acronym followed by a 75 colon ":" and a double slash "//" in accordance with RFC 2718. 77 The first component of the scheme specific portion MAY include 78 credentials (userinfo) consisting of a username and optionally also 79 including a password. Including the password in the URL is NOT 80 RECOMMENDED. The username and password components are separated by a 81 single colon ":". 83 Following the userinfo, if present, the at-sign "@" shall precede the 84 authority section of the URI. Optionally, the authority section MAY 85 also include the port preceded by a colon ":". If the port is not 86 included, the default port is assumed. Following the port additional 87 parameters may be specified. These parameters are defined in the 88 connection parameters section. 90 ssh_URI = "ssh://" [ userinfo "@" ] host [ ":" port ] 91 [;conn-parameter=value] 93 1.2 SCP and SFTP URI 95 For SCP and SFTP, the scheme portion (scp: or sftp:) is followed by a 96 double slash "//". 98 SCP/SFTP/SSH URI Format October 2003 100 Both SCP and SFTP URLs are terminated by a single slash "/" followed 101 by the path information to the requested resource. 103 The first component of the scheme specific portion MAY include 104 credentials (userinfo) consisting of a username and optionally also 105 including a password. Including the password in the URL is NOT 106 RECOMMENDED. The username and password components are separated by a 107 single colon ":". 109 Following the userinfo, if present, the at-sign "@" shall precede the 110 authority section of the URL. Optionally, the authority section MAY 111 also include the port preceded by a colon ":". If the port is not 112 included, the default port is assumed. Following the port additional 113 parameters may be specified. These parameters are defined in the 114 connection parameters section. 116 scp_URI = "scp://" [ userinfo "@" ] host [ ":" port ] 117 [ ; parameter = value ] [ abs_path ] 119 Following the port additional parameters may be specified. These 120 parameters are defined in the connection parameters section. 121 Following the path additional sftp specific parameters may be 122 specified. 124 sftp_URI = "sftp://" [ userinfo "@" ] host [ ":" port ] 125 [;conn-parameter=value] [ abs_path ] [;sftp-parameter=value] 127 The URIs for SFTP and SCP are hierarcical URIs where each component 128 of the abs_path consists of path elements separated by a '/'. This is 129 the same format as used in the FTP URL described in section 2.2.2 of 130 [5]. 132 2. Parameters 134 2.1 SSH connection parameters 136 The following parameters are associated with an SSH connection and 137 are applicable to SSH, SFTP and SCP. All parameters are optional and 138 MUST NOT overwrite configured defaults. Individual parameters are 139 separated by a comma (","). 141 fingerprint 143 The fingerprint parameter contains the fingerprint of the host key 144 for the host specified in the URL. The fingerprint is encoded as 145 host-key-alg:fingerprint. Host-key-alg is host public key algorithm 146 defined [4] and the fingerprint format is defined in [2]. 148 SCP/SFTP/SSH URI Format October 2003 150 This parameter MUST NOT overwrite a key that is already configured 151 for the host. The fingerprint MAY be used to validate the 152 authenticity of the host key if the URL was obtained from an 153 authenticated source with its integrity protected. If this parameter 154 is not included then the validity of the host key is validated using 155 another method. See Security Considerations section for additional 156 considerations. There MUST be only one fingerprint parameter per 157 host-key-alg for a given URL. 159 2.2 SFTP Parameters 161 The SFTP parameters determine how to handle the file transfer 162 character translation. 164 newline 166 The newline parameter determines how the server translates new line 167 indicators. The possible choices are usually "\r" or "\n" or "\r\n". 168 The default is "\r\n". 170 typecode 172 The typecode identifies the type of file which determines how it will 173 be treated. Possible values are "i" for binary files, "a" for text 174 files, and "d" for directory listings. 176 3. Examples 178 The following section shows basic examples of URLs for each protocol. 179 This section should not be considered to include all possible 180 combinations of URLs for each protocol. 182 ssh://user@host 184 ssh://user@host:2222 186 ssh://joeuser@example.com;fingerprint=ssh-dss:c1:b1:30:29:d7:b8 187 :de:6c:97:77:10:d7:46:41:63:87 189 scp://user:password@host/file.txt 191 sftp://user@host/dir/path/file.txt 193 sftp://joeuser@example.com:2222;fingerprint=ssh-dss:c1:b1:30 194 :29:d7:b8:de:6c:97:77:10:d7:46:41:63:87, 196 4. Security Considerations 198 SCP/SFTP/SSH URI Format October 2003 200 In general, URIs themselves have no security considerations. 201 However, since the password for each scheme can optionally be 202 included within the URL it should be noted that doing so poses a 203 security risk. Since URLs are usually sent in the clear with no 204 encryption or other security, any password or other credentials 205 (userinfo) included could be seen by a potential attacker. 207 Care must also be taken in handling fingerprints associated with URLs 208 because URLs transmitted or stored without protection may be modified 209 by an attacker. In general an implementation cannot determine the 210 source of a URL so a fingerprint received in a URL should have no 211 more trust associated with it than a raw public key received in the 212 SSH protocol itself. If a locally configured key exists for the 213 server already it MUST NOT be automatically overwritten with 214 information from the URL. If the host is unknown then the 215 implementation should treat the fingerprint received with the same 216 caution that it does with any unknown public key. The client MAY 217 offer the fingerprint and URL for external validation before allowing 218 a connection based on this information. If the client chooses to make 219 a connection based on the URL information and it finds that the 220 public key in the URL and the public key offered by the server do not 221 match then it SHOULD provide a warning and provide a means to abort 222 the connection. Sections 3.1 and 8.2.4 of [3] provide a good 223 discussion of handling public keys received in the SSH protocol. 225 Normative References 227 [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 228 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 230 [2] Markus Friedl, "SSH Fingerprint Format", 231 http://www.ietf.org/internet-drafts/draft-ietf-secsh-fingerprint- 232 01.txt, work in progress 234 [3] Ylonen, T., "SSH Protocol Architecture", 235 http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture- 236 14.txt, work in progreess 238 [4] Ylonen, T., "SSH Transport Layer Protocol", 239 http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport- 240 16.txt, work in progress 242 [5] Hoffman, P., Definitions of Early URI Schemes", 243 http://www.ietf.org/internet-drafts/draft-hoffman-rfc1738bis-00.txt, 244 work in progress 246 SCP/SFTP/SSH URI Format October 2003 248 Non-Normative References 250 Masinter, L., et. al., "Guidelines for new URL Schemes", RFC 2718, 251 November 1999. 253 Mealling, M., Denenberg, R., "Report from the Joint W3C/IETF URI 254 Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, 255 and Uniform Resource Names (URNs): Clarifications and 256 Recommendations", RFC 3305, August 2002. 258 Author Information 260 Steve Suehring 261 Sentry Insurance 262 1800 North Point Dr, G2/61-17 263 Stevens Point, WI 54481 264 suehring@braingia.com 266 Joseph Salowey 267 Cisco Systems 268 2901 Third Avenue 269 Seattle, WA 98121 270 E-mail: jsalowey@cisco.com 272 Intellectual Property Statement 274 The IETF takes no position regarding the validity or scope of any 275 intellectual property or other rights that might be claimed to 276 pertain to the implementation or use of the technology described in 277 this document or the extent to which any license under such rights 278 might or might not be available; neither does it represent that it 279 has made any effort to identify any such rights. Information on the 280 IETF's procedures with respect to rights in standards-track and 281 standards-related documentation can be found in BCP-11. Copies of 282 claims of rights made available for publication and any assurances of 283 licenses to be made available, or the result of an attempt made to 284 obtain a general license or permission for the use of such 285 proprietary rights by implementors or users of this specification can 286 be obtained from the IETF Secretariat. 288 The IETF invites any interested party to bring to its attention any 289 copyrights, patents or patent applications, or other proprietary 290 rights which may cover technology that may be required to practice 291 this standard. Please address the information to the IETF Executive 292 Director. 294 Full Copyright Statement 296 SCP/SFTP/SSH URI Format October 2003 298 Copyright (C) The Internet Society (2003). All Rights Reserved. 300 This document and translations of it may be copied and furnished to 301 others, and derivative works that comment on or otherwise explain it 302 or assist in its implementation may be prepared, copied, published 303 and distributed, in whole or in part, without restriction of any 304 kind, provided that the above copyright notice and this paragraph are 305 included on all such copies and derivative works. However, this 306 document itself may not be modified in any way, such as by removing 307 the copyright notice or references to the Internet Society or other 308 Internet organizations, except as needed for the purpose of 309 developing Internet standards in which case the procedures for 310 copyrights defined in the Internet Standards process must be 311 followed, or as required to translate it into languages other than 312 English. 314 The limited permissions granted above are perpetual and will not be 315 revoked by the Internet Society or its successors or assignees. 317 This document and the information contained herein is provided on an 318 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 319 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 320 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 321 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 322 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 324 Acknowledgement 326 Funding for the RFC Editor function is currently provided by the 327 Internet Society.