idnits 2.17.1 draft-ietf-secsh-scp-sftp-ssh-uri-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 5) being 67 lines == 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 abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 61: '...he scheme specific portion MAY include...' RFC 2119 keyword, line 64: '... RECOMMENDED. The username and pass...' RFC 2119 keyword, line 69: '...uthority section MAY also include the ...' RFC 2119 keyword, line 85: '...he scheme specific portion MAY include...' RFC 2119 keyword, line 88: '... RECOMMENDED. The username and pass...' (13 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 (August 8, 2003) is 7560 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) ** Obsolete normative reference: RFC 2718 (ref. '2') (Obsoleted by RFC 4395) -- Unexpected draft version: The latest known version of draft-ietf-secsh-fingerprint is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. '3' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Suehring 2 Internet-Draft Sentry Insurance 3 Expires February 8, 2004 J. Salowey 4 Cisco Systems 5 August 8, 2003 7 SCP/SFTP/SSH URI Format 8 draft-ietf-secsh-scp-sftp-ssh-uri-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 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 General Syntax 51 The URI for each protocol shall consist of the scheme and the scheme 52 specific portion separated by a colon ":", as discussed in RFC 2396 53 [1]. This specification shall adopt the definitions "port", "host", 54 "scheme", "userinfo", and "authority" from RFC 2396. 56 SSH URI 58 The SSH scheme shall consist of the protocol acronym followed by a 59 colon ":" and a double slash "//" in accordance with RFC 2718 [2]. 61 The first component of the scheme specific portion MAY include 62 credentials (userinfo) consisting of a username and optionally also 63 including a password. Including the password in the URL is NOT 64 RECOMMENDED. The username and password components are separated by 65 a single colon ":". 67 Following the userinfo, if present, the at-sign "@" shall 68 precede the authority section of the URI. Optionally, the 69 authority section MAY also include the port preceded by a colon ":". 70 If the port is not included, port 22 is assumed. Following the port 71 additional parameters may be specified. These parameters are 72 defined in the connection parameters section. 74 ssh_URI = "ssh://" [ userinfo "@" ] host [ ":" port ] 75 [;conn-parameter=value] 77 SCP and SFTP URI 79 For SCP and SFTP, the scheme portion (scp: or sftp:) is followed by 80 a double slash "//". 82 Both SCP and SFTP URLs are terminated by a single slash "/" followed 83 by the path information to the requested resource. 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. Including the password in the URL is NOT 88 RECOMMENDED. The username and password components are separated by 89 a single colon ":". 91 Following the userinfo, if present, the at-sign "@" shall precede 92 the authority section of the URL. Optionally, the authority section 93 MAY also include the port preceded by a colon ":". If the port is 94 not included, port 22 is assumed. Following the port additional 95 parameters may be specified. These parameters are defined in the 96 connection parameters section. 98 scp_URI = "scp://" [ userinfo "@" ] host [ ":" port ] 99 [ ; parameter = value ] [ abs_path ] 101 Following the port additional parameters may be specified. These 102 parameters are defined in the connection parameters section. 103 Following the path additional sftp specific parameters may be 104 specified. 106 sftp_URI = "sftp://" [ userinfo "@" ] host [ ":" port ] 107 [;conn-parameter=value] [ abs_path ] [;sftp-parameter=value] 109 Parameters 111 SSH connection parameters 113 The following parameters are associated with an SSH connection and 114 are applicable to SSH, SFTP and SCP. All parameters are optional 115 and MUST NOT overwrite configured defaults. Individual parameters 116 are separated by a comma (","). 118 fingerprint 120 The fingerprint parameter contains the fingerprint of the host key 121 for the host specified in the URL. The fingerprint is encoded as 122 in [3]. This parameter MUST NOT overwrite a key that is already 123 configured for the host. They fingerprint MAY be used to validate 124 the authenticity of the host key if the URL was obtained from an 125 authenticated source with its integrity protected. If this 126 parameter is not included then the validity of the host key is 127 validated using another method. See Security Considerations section 128 for additional considerations. There MUST be only one fingerprint 129 parameter for a given URL. 131 cipher 133 The cipher parameter indicates an acceptable encryption mechanism to 134 use in making the connection. The value is the string specifying the 135 SSH cipher type. This parameter MUST NOT add a mechanism to a 136 configured list of default configured acceptable encryption types. 137 If this parameter is not specified then the default configured cipher 138 list is used. There may be more than one cipher parameter. 140 integrity 142 The integrity parameter indicates an acceptable data integrity 143 mechanism to use in making the connection. The value is the string 144 specifying the SSH data integrity type. This parameter MUST NOT add 145 a mechanism to a configured list of default configured acceptable 146 data integrity types. If this parameter is not specified then the 147 default configured data integrity list is used. There may be more 148 than one integrity parameter. 150 key-xchg 152 The key-xchg parameter indicates an acceptable key exchange mechanism 153 to use when making the connection. The value is the string 154 specifying the SSH key exchange type. This parameter MUST NOT add a 155 mechanism to a configured list of default configured acceptable key 156 exchange types. If this parameter is not specified then the default 157 configured key exchange list is used. There may be more than one 158 key-xchg parameter. 160 host-key-alg 162 The host-key-alg parameter indicates an host key to use when making 163 the connection. The value is the string specifying the SSH host key 164 type. This parameter MUST NOT add a mechanism to a configured list 165 of default configured acceptable host key types. If this parameter 166 is not specified then the default configured host key type list is 167 used. There may be more than one host-key-alg parameter. 169 user-auth 171 The user-auth parameter indicates a user authentication mechanism to 172 use when making the connection. The value is the string specifying 173 the SSH user authentication mechanism type. This parameter MUST NOT 174 add a mechanism to a configured list of default configured 175 acceptable user authentication mechanism types. If this parameter 176 is not specified then the default configured user authentication 177 mechanism type list is used. There may be more than one user-auth 178 parameter. 180 SFTP Parameters 182 The SFTP parameters determine how to handle the file transfer 183 character translation. 185 newline 187 The newline parameter determines how the server translates new line 188 indicators. The possible choices are usually "\r" or "\n" or "\r\n". 189 The default is "\r\n". 191 typecode 193 The typecode identifies the type of file which determines how it 194 will be treated. Possible values are "i" for binary files, "a" for 195 text files, and "d" for directory listings. 197 Examples 199 The following section shows basic examples of URLs for each 200 protocol. This section should not be considered to include all 201 possible combinations of URLs for each protocol. 203 ssh://user@host 205 ssh://user@host:2222 207 ssh://joeuser@example.com;fingerprint=c1:b1:30:29:d7:b8:de:6c 208 :97:77:10:d7:46:41:63:87,cipher=aes-cbc 210 scp://user:password@host/file.txt 212 sftp://user@host/dir/path/file.txt 213 sftp://joeuser@example.com:2222;fingerprint=c1:b1:30:29:d7:b8 214 :de:6c:97:77:10:d7:46:41:63:87,cipher= 215 aes-cbc/pub/docs/test.txt;typecode=a 217 Security Considerations 219 In general, URIs themselves have no security considerations. 220 However, since the password for each scheme can optionally be 221 included within the URL it should be noted that doing so poses a 222 security risk. Since URLs are usually sent in the clear with no 223 encryption or other security, any password or other credentials 224 (userinfo) included could be seen by a potential attacker. 226 The fingerprint should only be used to validate the host key only if 227 the URL can be determined to be authentic from a trusted entity. 228 For example, the URL may be received through secure email or HTTPS 229 from a trusted and verifiable source. It is possible that the SSH 230 implementation may not be able to determine if the URL is authentic 231 in which case it SHOULD prompt the user to either allow or disallow 232 the connection based on the information provided. The SSH 233 implementation MUST NOT overwrite a currently configured public key 234 based on the URL alone. 236 The other connection parameters MUST NOT add any mechanism to the 237 list of configured acceptable mechanisms defined in the SSH client. 239 Normative References 241 [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource 242 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 244 [2] Masinter, L., et. al., "Guidelines for new URL Schemes", RFC 245 2718, November 1999. 247 [3] Markus Friedl, "SSH Fingerprint Format", 248 http://www.ietf.org/internet-drafts/ 249 draft-ietf-secsh-fingerprint-01.txt, 250 work in progress 252 Non-Normative References 254 Mealling, M., Denenberg, R., "Report from the Joint W3C/IETF URI 255 Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, 256 and Uniform Resource Names (URNs): Clarifications and 257 Recommendations", RFC 3305, August 2002. 259 Author Information 261 Steve Suehring 262 Sentry Insurance 263 1800 North Point Dr, G2/61-17 264 Stevens Point, WI 54481 265 suehring@braingia.com 267 Joseph Salowey 268 Cisco Systems 269 2901 Third Avenue 270 Seattle, WA 98121 271 E-mail: jsalowey@cisco.com 273 Intellectual Property Statement 275 The IETF takes no position regarding the validity or scope of any 276 intellectual property or other rights that might be claimed to 277 pertain to the implementation or use of the technology described in 278 this document or the extent to which any license under such rights 279 might or might not be available; neither does it represent that it 280 has made any effort to identify any such rights. Information on the 281 IETF's procedures with respect to rights in standards-track and 282 standards-related documentation can be found in BCP-11. Copies of 283 claims of rights made available for publication and any assurances of 284 licenses to be made available, or the result of an attempt made to 285 obtain a general license or permission for the use of such 286 proprietary rights by implementors or users of this specification can 287 be obtained from the IETF Secretariat. 289 The IETF invites any interested party to bring to its attention any 290 copyrights, patents or patent applications, or other proprietary 291 rights which may cover technology that may be required to practice 292 this standard. Please address the information to the IETF Executive 293 Director. 295 Full Copyright Statement 297 Copyright (C) The Internet Society (2003). All Rights Reserved. 299 This document and translations of it may be copied and furnished to 300 others, and derivative works that comment on or otherwise explain it 301 or assist in its implementation may be prepared, copied, published 302 and distributed, in whole or in part, without restriction of any 303 kind, provided that the above copyright notice and this paragraph are 304 included on all such copies and derivative works. However, this 305 document itself may not be modified in any way, such as by removing 306 the copyright notice or references to the Internet Society or other 307 Internet organizations, except as needed for the purpose of 308 developing Internet standards in which case the procedures for 309 copyrights defined in the Internet Standards process must be 310 followed, or as required to translate it into languages other than 311 English. 313 The limited permissions granted above are perpetual and will not be 314 revoked by the Internet Society or its successors or assignees. 316 This document and the information contained herein is provided on an 317 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 318 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 319 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 320 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 321 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 323 Acknowledgement 325 Funding for the RFC Editor function is currently provided by the 326 Internet Society.