idnits 2.17.1 draft-bonachea-sftp-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 () is 739378 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) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Bonachea 2 S. McPeak 3 Updates: RFC 2228 4 Internet-Draft 5 Expires in January, 2000 June, 1999 7 Protocol Negotiation Extensions to Secure FTP 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document presents refinements to RFC 2228, "FTP Security 34 Extensions" (October 1997) [1]. It lends support for more efficient 35 and secure protocol negotiation in the presence of multiple protocol 36 possibilities, by adding one new optional command and several new 37 reply codes. 39 The following new optional command is introduced in this 40 specification: 42 DIGT (Protocol Negotiation Digest) 44 This document also seeks to solidify several issues that were left 45 underspecified in RFC 2228. Specifically, it adds additional reply 46 codes to cover cases not mentioned in the original specification and 47 it defines a legal naming convention for security mechanisms. 49 1. Introduction 51 Recently, the authors implemented the RFC 2228 protocol, FTP Security 52 Extensions [1]. This protocol extends the basic File Transfer 53 Protocol (FTP) specified in RFC 959 [2], adding security services 54 including authentication and privacy. We assume the reader is 55 familiar with RFC 2228. 57 During the implementation of RFC 2228 we found it necessary and 58 useful to make several changes to the protocol. This memo details 59 those changes. 61 Section 2 describes changes which extend RFC 2228, to improve 62 security and efficiency. Section 3 closes specification holes in RFC 63 2228 itself. Section 4 lifts a RFC 959 restriction, thereby improving 64 total system security. 66 2. Protocol Negotiation Improvements 68 DIGT (Protocol Negotiation Digest) command 70 This new command provides a way for a client to verify that an 71 attacker didn't interfere with the protocol negotiation sequence. 72 This is important because a client that supports multiple security 73 mechanisms might be "tricked" into using its weakest security 74 mechanism by an attacker who interferes with protocol negotiation 75 (i.e. by modifying the appropriate mechanism acceptance replies to 76 look like refusals). The client may issue this optional command at 77 any time after authentication is complete, and the server will reply 78 with a secure hash digest computed over the entire protocol 79 negotiation exchange. The client can then compare this digest to the 80 locally computed digest to verify that both server and client 81 experienced the same protocol negotiation sequence (i.e. there was no 82 outside interference). The hash function is Sha1, and is computed 83 over the entire negotiation sequence from the first character in the 84 first client command (usually an AUTH), to the last character in the 85 server reply which indicates the security data exchange is complete 86 (the LF character on a 234 or 235 reply). The form of the server 87 reply to DIGT will be: 89 211 DIGT=base64data 90 ; base64data is a placeholder for the actual digest block, 91 ; which must be encoded using the base64 format, as 92 ; described in RFC 2228 (see [1] for details). 94 The server may also send a 502 response if the DIGT command is not 95 implemented. 97 Note the efficacy of this security measure depends on the client 98 asking for the digest faster than an attacker can compromise the 99 current (weaker) security mechanism and substitute a modified digest. 101 Efficiency improvements to protocol negotiation 103 RFC 2228 allows for the possibility of clients and servers that 104 implement a large number of security mechanisms, yet it provides no 105 efficient means for the client to discover and request a supported 106 mechanism. Under the RFC 2228 specification, the client repeatedly 107 issues AUTH commands for each security mechanism it supports (in 108 order of preference) until finding one the server will accept. For 109 clients that implement a large number of mechanisms, this could 110 potentially lead to an unreasonably large number of network round 111 trips in order to complete the protocol negotiation sequence. In 112 order to alleviate this problem, this specification adds two new 113 optional server reply codes that allow the server to reveal a list of 114 acceptable security mechanisms in a single reply. This enables the 115 client to perform the search locally and select an acceptable 116 mechanism in a single network roundtrip. 118 The new reply codes to the AUTH command are: 120 504 Security mechanism unrecognized. [LIST=mechlist] 121 504 Security mechanism unrecognized. [ILST=mechlist] 123 Here, mechlist is a space-delimited list of security mechanisms that 124 the server understands and might accept from this client. The keyword 125 LIST indicates that mechlist is a complete list of acceptable 126 security mechanisms, and any mechanisms not listed will be refused. 127 The keyword ILST indicates that mechlist is an incomplete list of 128 acceptable security mechanisms, and that other acceptable unlisted 129 security mechanisms might exist. The square brackets are not to be 130 included in the actual reply, but indicate that the mechanism list is 131 optional. 133 3. Amendments to RFC 2228 135 New server replies 137 This section presents several new server reply codes which were 138 missing in the original specification. 140 234 Security data exchange complete. [ADAT=base64data] 141 ; This reply to AUTH indicates the security data exchange 142 ; completed successfully. The square brackets are not to be 143 ; included in the reply, but indicate that security data in 144 ; the reply is optional. 146 This reply code existed in RFC 2228, but did not allow for the 147 possibility of the server sending security data (for protocols where 148 the only data exchange necessary is for the server to send a block to 149 the client). 151 503 Reauthentication is prohibited. 152 ; This reply code to an AUTH indicates that a successful 153 ; security data exchange has completed, and this server is 154 ; unwilling to begin a new authentication session (the 155 ; client must "hang up" and reconnect) 157 RFC 2228 specifies that a server may prohibit the client from 158 reissuing the AUTH command in order to establish new authentication, 159 but provides no reply code to communicate this. 161 PBSZ Negotiation 163 During PBSZ (Protocol Buffer Size) negotiation, the client proposes a 164 buffer size, and the server may accept this size, reply with a 165 smaller size, or give an error. The size agreed upon is subsequently 166 used during data transfers as a maximum bound on the size of each 167 encrypted block. However, some protocol mechanisms have a minimum 168 encrypted block size, and RFC 2228 doesn't provide a way for the 169 server to indicate that the proposed block size is too small. To 170 remedy this, this specification adds a new reply code: 172 538 PBSZ too small. [PBSZmin=numBytes] 173 ; This reply to PBSZ indicates the proposed buffer size is 174 ; unacceptably small. The server may also include an optional 175 ; string of the form PBSZmin=numBytes to indicate the smallest 176 ; buffer size it will accept. The square brackets are not to be 177 ; included in the reply, but indicate that the PBSZmin argument 178 ; in the reply is optional. 180 Protocol Mechanism Naming Specification 182 The guidelines provided by RFC 2228 for the naming of new protocol 183 mechanisms are somewhat vague, and as such are insufficient for the 184 purposes of successful protocol negotiation as described in section 185 2. Following is a revised, more rigorous specification for the 186 naming of protocol mechanisms: 188 The protocol mechanism name must not exceed 255 characters, and may 189 only contain the characters with codes 33...126 in the USASCII 190 character set. Names are case-insensitive. All names must be 191 registered with the IANA, except names beginning with "X-", which are 192 reserved for local use. 194 4. Miscellaneous changes to RFC 2228 196 Port 20 restriction for outgoing server data connections: 198 RFC 2228 is a superset specification of RFC 959 [2], which defines 199 the basic FTP protocol. RFC 959 requires that while in active mode, 200 all outgoing data connections from the FTP server must be bound to 201 port 20, as a weak form of authentication. However, most FTP clients 202 fail to enforce this port restriction (i.e. they don't check). 203 However, implementation experience has shown that the port 204 restriction is also the only hindrance to running a legitimate RFC 205 2228 server as an entirely user-level proxy (which augments overall 206 system security). Because RFC 2228 provides more comprehensive 207 support for strong, cryptographic authentication mechanisms, it has 208 made the port 20 restriction for outgoing server data connections 209 obsolete, and the restriction is hereby lifted. 211 5. Security Considerations 213 This entire memo is about security mechanisms. 215 6. References 217 [1] - M. Horowitz and S. J. Lunt. FTP Security Extensions. 218 RFC 2228, October, 1997 220 [2] - J. Postel and J. Reynolds. File Transfer Protocol (FTP). 221 RFC 959, October, 1985 223 7. Authors' Addresses 225 Dan Bonachea 226 Computer Science Division 227 566 Soda Hall 228 Berkeley, CA 94720 USA 229 Phone: +1 510 642-8493 230 Email: bonachea@cs.berkeley.edu 232 Scott McPeak 233 Computer Science Division 234 566 Soda Hall 235 Berkeley, CA 94720 USA 236 Phone: +1 510 642-8493 237 Email: smcpeak@cs.berkeley.edu