Line 0
Link Here
|
|
|
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
Paul Ford-Hutchinson |
8 |
<draft-murray-auth-ftp-ssl-09.txt> IBM UK Ltd |
9 |
Martin Carpenter |
10 |
Verisign Inc |
11 |
Tim Hudson |
12 |
INTERNET-DRAFT (draft) RSA Australia Ltd |
13 |
Eric Murray |
14 |
Wave Systems Inc |
15 |
Volker Wiegand |
16 |
SuSE Linux |
17 |
|
18 |
2nd April, 2002 |
19 |
This document expires on 2nd October, 2002 |
20 |
|
21 |
|
22 |
Securing FTP with TLS |
23 |
|
24 |
|
25 |
Status of this Memo |
26 |
|
27 |
This document is an Internet-Draft and is in full conformance with |
28 |
all provisions of Section 10 of RFC2026. |
29 |
|
30 |
Internet-Drafts are working documents of the Internet Engineering |
31 |
Task Force (IETF), its areas, and its working groups. Note that |
32 |
other groups may also distribute working documents as Internet- |
33 |
Drafts. |
34 |
|
35 |
Internet-Drafts are draft documents valid for a maximum of six months |
36 |
and may be updated, replaced, or obsoleted by other documents at any |
37 |
time. It is inappropriate to use Internet-Drafts as reference |
38 |
material or to cite them other than as "work in progress." |
39 |
|
40 |
The list of current Internet-Drafts can be accessed at |
41 |
http://www.ietf.org/1id-abstracts.txt |
42 |
|
43 |
The list of Internet-Draft Shadow Directories can be accessed at |
44 |
http://www.ietf.org/shadow.html |
45 |
|
46 |
|
47 |
|
48 |
|
49 |
|
50 |
|
51 |
|
52 |
|
53 |
|
54 |
|
55 |
|
56 |
|
57 |
|
58 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 1] |
59 |
|
60 |
|
61 |
|
62 |
|
63 |
|
64 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
65 |
|
66 |
|
67 |
Index |
68 |
1. .......... Abstract |
69 |
2. .......... Introduction |
70 |
3. .......... Audience |
71 |
4. .......... Session negotiation on the control port |
72 |
5. .......... Response to FEAT command |
73 |
6. .......... Data Connection Behaviour |
74 |
7. .......... Mechanisms for the AUTH Command |
75 |
8. .......... Data Connection Security |
76 |
9. .......... A discussion of negotiation behaviour |
77 |
10. ......... Who negotiates what, where and how |
78 |
11. ......... Timing Diagrams |
79 |
12. ......... Discussion of the REIN command |
80 |
13. ......... Discussion of the STAT and ABOR commands |
81 |
14. ......... Security Considerations |
82 |
15. ......... IANA Considerations |
83 |
16. ......... Other Parameters |
84 |
17. ......... Network Management |
85 |
18. ......... Internationalization |
86 |
19. ......... Scalability & Limits |
87 |
20. ......... Applicability |
88 |
21. ......... Acknowledgements |
89 |
22. ......... References |
90 |
23. ......... Authors' Contact Addresses |
91 |
|
92 |
|
93 |
|
94 |
|
95 |
|
96 |
|
97 |
|
98 |
|
99 |
|
100 |
|
101 |
|
102 |
|
103 |
|
104 |
|
105 |
|
106 |
|
107 |
|
108 |
|
109 |
|
110 |
|
111 |
|
112 |
|
113 |
|
114 |
|
115 |
|
116 |
|
117 |
|
118 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 2] |
119 |
|
120 |
|
121 |
|
122 |
|
123 |
|
124 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
125 |
|
126 |
|
127 |
1. Abstract |
128 |
|
129 |
This document describes a mechanism that can be used by FTP clients |
130 |
and servers to implement security and authentication using the TLS |
131 |
protocol defined by [RFC-2246] and the extensions to the FTP protocol |
132 |
defined by [RFC-2228]. It describes the subset of the extensions |
133 |
that are required and the parameters to be used; discusses some of |
134 |
the policy issues that clients and servers will need to take; |
135 |
considers some of the implications of those policies and discusses |
136 |
some expected behaviours of implementations to allow interoperation. |
137 |
This document is intended to provide TLS support for FTP in a similar |
138 |
way to that provided for SMTP in [RFC-2487] and HTTP in [RFC-2817]. |
139 |
|
140 |
TLS is not the only mechanism for securing file transfer, however it |
141 |
does offer some of the following positive attributes:- |
142 |
|
143 |
- Flexible security levels. TLS can support confidentiality, |
144 |
integrity, authentication or some combination of all of these. |
145 |
This allows clients and servers to dynamically, during a session, |
146 |
decide on the level of security required for a particular data |
147 |
transfer, |
148 |
|
149 |
- It is possible to use TLS identities to authenticate client |
150 |
users and not just client hosts. |
151 |
|
152 |
- Formalised public key management. By use of well established |
153 |
client identity mechnisms (supported by TLS) during the |
154 |
authentication phase, certificate management may be built into a |
155 |
central function. Whilst this may not be desirable for all uses |
156 |
of secured file transfer, it offers advantages in certain |
157 |
structured environments. |
158 |
|
159 |
- Co-existence and interoperation with authentication mechanisms |
160 |
that are already in place for the HTTPS protocol. This allows web |
161 |
browsers to incorporate secure file transfer using the same |
162 |
infrastructure that has been set up to allow secure web browsing. |
163 |
|
164 |
The TLS protocol is a development of the Netscape Communication |
165 |
Corporation's SSL protocol and this document can be used to allow the |
166 |
FTP protocol to be used with either SSL or TLS. The actual protocol |
167 |
used will be decided by the negotiation of the protected session by |
168 |
the TLS/SSL layer. This document will only refer to the TLS |
169 |
protocol, however, it is understood that the Client and Server MAY |
170 |
actually be using SSL if they are so configured. |
171 |
|
172 |
Note that this specification is in accordance with the FTP RFC |
173 |
[RFC-959] and relies on the TLS protocol [RFC-2246] and the FTP |
174 |
security extensions [RFC-2228]. |
175 |
|
176 |
|
177 |
|
178 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 3] |
179 |
|
180 |
|
181 |
|
182 |
|
183 |
|
184 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
185 |
|
186 |
|
187 |
2. Introduction |
188 |
|
189 |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", |
190 |
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and |
191 |
"OPTIONAL" that appear in this document are to be interpreted as |
192 |
described in [RFC-2119]. |
193 |
|
194 |
This document is an attempt to describe how three other documents |
195 |
should combined to provide a useful, interoperable, secure file |
196 |
transfer protocol. Those documents are:- |
197 |
|
198 |
|
199 |
RFC 959 [RFC-959] |
200 |
|
201 |
The description of the Internet File Transfer Protocol |
202 |
|
203 |
RFC 2246 [RFC-2246] |
204 |
|
205 |
The description of the Transport Layer Security protocol |
206 |
(developed from the Netscape Secure Sockets Layer (SSL) |
207 |
protocol version 3.0). |
208 |
|
209 |
RFC 2228 [RFC-2228] |
210 |
|
211 |
Extensions to the FTP protocol to allow negotiation of security |
212 |
mechanisms to allow authentication, confidentiality and message |
213 |
integrity. |
214 |
|
215 |
The File Transfer Protocol (FTP) currently defined in [RFC-959] and |
216 |
in place on the Internet is an excellent mechanism for exchanging |
217 |
files. The security extensions to FTP in [RFC-2228] offer a |
218 |
comprehensive set of commands and responses that can be used to add |
219 |
authentication, integrity and confidentiality to the FTP protocol. |
220 |
The TLS protocol is a popular (due to its wholesale adoption in the |
221 |
HTTP environment) mechanism for generally securing a socket |
222 |
connection. |
223 |
There are many ways in which these three protocols can be combined |
224 |
which would ensure that interoperation is impossible. This document |
225 |
describes one method by which FTP can operate securely in such a way |
226 |
as to provide both flexibility and interoperation. This necessitates |
227 |
a brief description of the actual negotiation mechanism ; a much more |
228 |
detailed description of the policies and practices that would be |
229 |
required and a discussion of the expected behaviours of clients and |
230 |
servers to allow either party to impose their security requirements |
231 |
on the FTP session. |
232 |
|
233 |
|
234 |
3. Audience |
235 |
|
236 |
|
237 |
|
238 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 4] |
239 |
|
240 |
|
241 |
|
242 |
|
243 |
|
244 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
245 |
|
246 |
|
247 |
This document is aimed at developers who wish to implement TLS as a |
248 |
security mechanism to secure FTP clients and/or servers. |
249 |
|
250 |
|
251 |
4. Session negotiation on the control port |
252 |
|
253 |
The server listens on the normal FTP control port {FTP-PORT} and the |
254 |
session initiation is not secured at all. Once the client wishes to |
255 |
secure the session, the AUTH command is sent and the server MAY then |
256 |
allow TLS negotiation to take place. |
257 |
|
258 |
4.1 Client wants a secured session |
259 |
|
260 |
If a client wishes to attempt to secure a session then it SHOULD, |
261 |
in accordance with [RFC-2228] send the AUTH command with the |
262 |
parameter requesting TLS {TLS-PARM}. |
263 |
|
264 |
|
265 |
The client then needs to behave according to its policies depending |
266 |
on the response received from the server and also the result of the |
267 |
TLS negotiation. i.e. A client which receives an AUTH rejection |
268 |
MAY choose to continue with the session unprotected if it so |
269 |
desires. |
270 |
|
271 |
4.2 Server wants a secured session |
272 |
|
273 |
The FTP protocol does not allow a server to directly dictate client |
274 |
behaviour, however the same effect can be achieved by refusing to |
275 |
accept certain FTP commands until the session is secured to an |
276 |
acceptable level to the server. |
277 |
|
278 |
The server response to an 'AUTH TLS' command which it will honour, is |
279 |
'234'. |
280 |
|
281 |
Note. The '334' response as defined in [RFC-2228] implies that an |
282 |
ADAT exchange will folow. This document does not use the ADAT |
283 |
command and so the '334' reply is incorrect. |
284 |
|
285 |
Note. The FTP protocol insists that a USER command be used to |
286 |
identify the entity attempting to use the ftp server. Although the |
287 |
TLS negotiation may be providing authentication information the USER |
288 |
command must still be isssued by the client. However, it will be a |
289 |
server implementation issue to decide which credentials to accept and |
290 |
what consistency checks to make between any client cert used and the |
291 |
parameter on the USER command. |
292 |
|
293 |
5. Response to the FEAT command |
294 |
|
295 |
|
296 |
|
297 |
|
298 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 5] |
299 |
|
300 |
|
301 |
|
302 |
|
303 |
|
304 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
305 |
|
306 |
|
307 |
The FEAT command (introduced in [RFC-2389]) allows servers with |
308 |
additional features to advertise these to a client by responding to |
309 |
the FEAT command. If a server supports the FEAT command then it MUST |
310 |
advertise supported AUTH, PBSZ and PROT commands in the reply as |
311 |
described in section 3.2 of [RFC-2389]. Additionally, the AUTH |
312 |
command should have a reply that identifies 'TLS' as one of the |
313 |
possible parameters to AUTH. It is not necessary to identify the |
314 |
'TLS-C' synonym separately. |
315 |
|
316 |
Example reply (in same style is [RFC-2389]) |
317 |
C> FEAT |
318 |
S> 211-Extensions supported |
319 |
S> AUTH TLS |
320 |
S> PBSZ |
321 |
S> PROT |
322 |
S> 211 END |
323 |
|
324 |
|
325 |
6. Data Connection Behaviour |
326 |
|
327 |
The Data Connection in the FTP model can be used in one of three |
328 |
ways. (Note: these descriptions are not necessarily placed in exact |
329 |
chronological order, but do describe the steps required. - See |
330 |
diagrams later for clarification) |
331 |
|
332 |
i) Classic FTP client/server data exchange |
333 |
|
334 |
- The client obtains a port; sends the port number to the |
335 |
server; the server connects to the client. The client issues a |
336 |
send or receive request to the server on the control connection |
337 |
and the data transfer commences on the data connection. |
338 |
|
339 |
ii) Firewall-Friendly client/server data exchange (as discussed |
340 |
in [RFC-1579]) using the PASV command to reverse the direction |
341 |
of the data connection. |
342 |
|
343 |
- The client requests that the server open a port; the server |
344 |
obtains a port and returns the address and port number to the |
345 |
client; the client connects to the server on this port. The |
346 |
client issues a send or receive request on the control |
347 |
connection and the data transfer commences on the data |
348 |
connection. |
349 |
|
350 |
iii) Client initiated server/server data exchange (proxy or |
351 |
PASV connections) |
352 |
|
353 |
- The client requests that server A opens a port; server A |
354 |
obtains a port and returns it to the client; the client sends |
355 |
|
356 |
|
357 |
|
358 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 6] |
359 |
|
360 |
|
361 |
|
362 |
|
363 |
|
364 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
365 |
|
366 |
|
367 |
this port number to server B. Server B connects to server A. |
368 |
The client sends a send or receive request to server A and the |
369 |
complement to server B and the data transfer commences. In |
370 |
this model server A is the proxy or PASV host and is a client |
371 |
for the Data Connection to server B. |
372 |
|
373 |
For i) and ii) the FTP client MUST be the TLS client and the FTP |
374 |
server MUST be the TLS server. |
375 |
|
376 |
That is to say, it does not matter which side initiates the |
377 |
connection with a connect() call or which side reacts to the |
378 |
connection via the accept() call; the FTP client as defined in |
379 |
[RFC-959] is always the TLS client as defined in [RFC-2246]. |
380 |
|
381 |
In scenario iii) there is a problem in that neither server A nor |
382 |
server B is the TLS client given the fact that an FTP server must act |
383 |
as a TLS server for Firewall-Friendly FTP [RFC-1579]. Thus this is |
384 |
explicitly excluded in the security extensions document [RFC-2228], |
385 |
and in this document. |
386 |
|
387 |
|
388 |
|
389 |
7. Mechanisms for the AUTH Command |
390 |
|
391 |
The AUTH command takes a single parameter to define the security |
392 |
mechanism to be negotiated. As the SSL/TLS protocols self-negotiate |
393 |
their levels there is no need to distinguish SSL vs TLS in the |
394 |
application layer. The proposed mechanism name for negotiating TLS |
395 |
will be the character string identified in {TLS-PARM}. This will |
396 |
allow the client and server to negotiate TLS on the control |
397 |
connection without altering the protection of the data channel. To |
398 |
protect the data channel as well, the PBSZ:PROT command sequence MUST |
399 |
be used. |
400 |
|
401 |
Note: The data connection state MAY be modified by the client issuing |
402 |
the PROT command with the new desired level of data channel |
403 |
protection and the server replying in the affirmative. This data |
404 |
channel protection negotiation can happen at any point in the session |
405 |
(even straight after a PORT or PASV command) and as often as is |
406 |
required. |
407 |
|
408 |
See also Section 15, "IANA Considerations". |
409 |
|
410 |
|
411 |
8. Data Connection Security |
412 |
|
413 |
The Data Connection security level is determined by the PROT command |
414 |
|
415 |
|
416 |
|
417 |
|
418 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 7] |
419 |
|
420 |
|
421 |
|
422 |
|
423 |
|
424 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
425 |
|
426 |
|
427 |
The PROT command, as specified in [RFC-2228] allows client/server |
428 |
negotiation of the security level of the data connection. Once a |
429 |
PROT command has been issued by the client and accepted by the |
430 |
server returning the '200' reply, the security of subsequent data |
431 |
connections MUST be at that level until another PROT command is |
432 |
issued and accepted; the session ends; a REIN command is issued; |
433 |
or the security of the session (via an AUTH command) is re- |
434 |
negotiated. |
435 |
|
436 |
Data Connection Security Negotiation (the PROT command) |
437 |
|
438 |
Note: In line with [RFC-2228], there is no facility for securing |
439 |
the Data connection with an insecure Control connection. |
440 |
Specifically, the PROT command MUST be preceded by a PBSZ command |
441 |
and a PBSZ command MUST be preceded by a successful security data |
442 |
exchange (the TLS negotiation in this case) |
443 |
|
444 |
The command defined in [RFC-2228] to negotiate data connection |
445 |
security is the PROT command. As defined there are four values |
446 |
that the PROT command parameter can take. |
447 |
|
448 |
'C' - Clear - neither Integrity nor Privacy |
449 |
|
450 |
'S' - Safe - Integrity without Privacy |
451 |
|
452 |
'E' - Confidential - Privacy without Integrity |
453 |
|
454 |
'P' - Private - Integrity and Privacy |
455 |
|
456 |
As TLS negotiation encompasses (and exceeds) the Safe / |
457 |
Confidential / Private distinction, only Private (use TLS) and |
458 |
Clear (don't use TLS) are used. |
459 |
|
460 |
For TLS, the data connection can have one of two security levels. |
461 |
|
462 |
1)Clear (requested by 'PROT C') |
463 |
|
464 |
2)Private (requested by 'PROT P') |
465 |
|
466 |
With 'Clear' protection level, the data connection is made without |
467 |
TLS at all. Thus the connection is unauthenticated and has no |
468 |
confidentiality or integrity. This might be the desired behaviour |
469 |
for servers sending file lists, pre-encrypted data or non- |
470 |
sensitive data (e.g. for anonymous FTP servers). |
471 |
|
472 |
If the data connection security level is 'Private' then a TLS |
473 |
negotiation must take place on the data connection, to the |
474 |
satisfaction of the Client and Server prior to any data being |
475 |
|
476 |
|
477 |
|
478 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 8] |
479 |
|
480 |
|
481 |
|
482 |
|
483 |
|
484 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
485 |
|
486 |
|
487 |
transmitted over the connection. The TLS layers of the Client and |
488 |
Server will be responsible for negotiating the exact TLS Cipher |
489 |
Suites that will be used (and thus the eventual security of the |
490 |
connection). |
491 |
|
492 |
|
493 |
In addition, the PBSZ (protection buffer size) command, as |
494 |
detailed in [RFC-2228], is compulsory prior to any PROT command. |
495 |
This document also defines a data channel encapsulation mechanism |
496 |
for protected data buffers. For FTP-TLS, which appears to the FTP |
497 |
application as a streaming protection mechanism, this is not |
498 |
required. Thus the PBSZ command must still be issued, but must |
499 |
have a parameter of '0' to indicate that no buffering is taking |
500 |
place and the data connection should not be encapsulated. |
501 |
Note that PBSZ 0 is not in the grammar of [RFC-2228], section |
502 |
8.1, where it is stated: |
503 |
PBSZ <sp> <decimal-integer> <CRLF> <decimal-integer> ::= any |
504 |
decimal integer from 1 to (2^32)-1 |
505 |
However it should be noted that using a value of '0' to mean a |
506 |
streaming protocol is a reasonable use of '0' for that parameter |
507 |
and is not ambiguous. |
508 |
|
509 |
Initial Data Connection Security |
510 |
|
511 |
The initial state of the data connection MUST be 'Clear' (this is |
512 |
the behaviour as indicated by [RFC-2228].) |
513 |
|
514 |
|
515 |
9. A Discussion of Negotiation Behaviour |
516 |
|
517 |
9.1. The server's view of the control connection |
518 |
|
519 |
A server MAY have a policy statement somewhere that might: |
520 |
|
521 |
- Deny any command before TLS is negotiated (this might cause |
522 |
problems if a SITE or some such command is required prior to |
523 |
login) |
524 |
- Deny certain commands before TLS is negotiated (such as USER, |
525 |
PASS or ACCT) |
526 |
- Deny insecure USER commands for certain users (e.g. not |
527 |
ftp/anonymous) |
528 |
- Deny secure USER commands for certain users (e.g. |
529 |
ftp/anonymous) |
530 |
- Define the level(s) of TLS to be allowed |
531 |
- Define the CipherSuites allowed to be used (perhaps on a per |
532 |
host/domain/... basis) |
533 |
- Allow TLS authentication as a substitute for local |
534 |
authentication. |
535 |
|
536 |
|
537 |
|
538 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 9] |
539 |
|
540 |
|
541 |
|
542 |
|
543 |
|
544 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
545 |
|
546 |
|
547 |
- Define data connection policies (see next section) |
548 |
|
549 |
It is possible that the TLS negotiation may not be completed |
550 |
satisfactorily for the server, in which case it can be one of |
551 |
these states. |
552 |
|
553 |
The TLS negotiation failed completely |
554 |
|
555 |
In this case, the control connection should still be up in |
556 |
unprotected mode and the server SHOULD issue an unprotected |
557 |
'421' reply to end the session. |
558 |
|
559 |
The TLS negotiation completed successfully, but the server |
560 |
decides that the session parameters are not acceptable (e.g. |
561 |
Distinguished Name in the client certificate is not |
562 |
permitted to use the server) |
563 |
|
564 |
In this case, the control connection should still be up in a |
565 |
protected state, so the server MAY either continue to refuse to |
566 |
service commands or issue a protected '421' reply and close the |
567 |
connection. |
568 |
|
569 |
The TLS negotiation failed during the TLS handshake |
570 |
|
571 |
In this case, the control connection is in an unknown state and |
572 |
the server SHOULD simply drop the control connection. |
573 |
|
574 |
Server code will be responsible for implementing the required |
575 |
policies and ensuring that the client is prevented from |
576 |
circumventing the chosen security by refusing to service those |
577 |
commands that are against policy. |
578 |
|
579 |
9.2. The server's view of the data connection |
580 |
|
581 |
The server can take one of four basic views of the data connection |
582 |
|
583 |
1 - Don't allow encryption at all (in which case the PROT |
584 |
command should not allow any value other than 'C' - if it is |
585 |
allowed at all) |
586 |
2 - Allow the client to choose protection or not |
587 |
3 - Insist on data protection (in which case the PROT command |
588 |
must be issued prior to the first attempted data transfer) |
589 |
4 - Decide on one of the above three for each and every data |
590 |
connection |
591 |
|
592 |
The server SHOULD only check the status of the data protection |
593 |
level (for options 3 and 4 above) on the actual command that will |
594 |
initiate the data transfer (and not on the PORT or PASV). The |
595 |
|
596 |
|
597 |
|
598 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 10] |
599 |
|
600 |
|
601 |
|
602 |
|
603 |
|
604 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
605 |
|
606 |
|
607 |
following commands, defined in [RFC-959] cause data connections to |
608 |
be opened and thus may be rejected (before any 1xx) message due to |
609 |
an incorrect PROT setting. |
610 |
|
611 |
|
612 |
STOR |
613 |
RETR |
614 |
NLST |
615 |
LIST |
616 |
STOU |
617 |
APPE |
618 |
|
619 |
|
620 |
The reply to indicate that the PROT setting is incorrect is |
621 |
'521 data connection cannot be opened with this PROT setting' |
622 |
If the protection level indicates that TLS is required, then it |
623 |
should be negotiated once the data connection is made. Thus, the |
624 |
'150' reply only states that the command can be used given the |
625 |
current PROT level. Should the server not like the TLS |
626 |
negotiation then it will close the data port immediately and |
627 |
follow the '150' command with a '522' reply indicating that the |
628 |
TLS negotiation failed or was unacceptable. (Note: this means |
629 |
that the application can pass a standard list of CipherSuites to |
630 |
the TLS layer for negotiation and review the one negotiated for |
631 |
applicability in each instance). |
632 |
|
633 |
It is quite reasonable for the server to insist that the data |
634 |
connection uses a TLS cached session. This might be a cache of a |
635 |
previous data connection or of the control connection. If this is |
636 |
the reason for the the refusal to allow the data transfer then the |
637 |
'522' reply should indicate this. |
638 |
Note: this has an important impact on client design, but allows |
639 |
servers to minimise the cycles used during TLS negotiation by |
640 |
refusing to perform a full negotiation with a previously |
641 |
authenticated client. |
642 |
|
643 |
It should be noted that the TLS authentication of the server will |
644 |
be authentication of the server host itself and not a user on the |
645 |
server host. |
646 |
|
647 |
9.3. The client's view of the control connection |
648 |
|
649 |
In most cases it is likely that the client will be using TLS |
650 |
because the server would refuse to interact insecurely. To allow |
651 |
for this, clients SHOULD be able to be flexible enough to manage |
652 |
the securing of a session at the appropriate time and still allow |
653 |
the user/server policies to dictate exactly when in the session |
654 |
the security is negotiated. |
655 |
|
656 |
|
657 |
|
658 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 11] |
659 |
|
660 |
|
661 |
|
662 |
|
663 |
|
664 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
665 |
|
666 |
|
667 |
In the case where it is the client that is insisting on the |
668 |
securing of the session, it will need to ensure that the |
669 |
negotiations are all completed satisfactorily and will need to be |
670 |
able to inform the user sensibly should the server not support, or |
671 |
be prepared to use, the required security levels. |
672 |
|
673 |
Clients SHOULD be coded in such a manner as to allow the timing of |
674 |
the AUTH, PBSZ and PROT commands to be flexible and dictated by |
675 |
the server. It is quite reasonable for a server to refuse certain |
676 |
commands prior to these commands, similarly it is quite possible |
677 |
that a SITE or quoted command might be needed by a server prior to |
678 |
the AUTH. A client MUST allow a user to override the timing of |
679 |
these commands to suit a specific server. |
680 |
For example, a client SHOULD NOT insist on sending the AUTH as the |
681 |
first command in a session, nor should it insist on issuing a |
682 |
PBSZ, PROT pair directly after the AUTH. This may well be the |
683 |
default behaviour, but must be overridable by a user. |
684 |
|
685 |
Note: The TLS negotiation may not be completed satisfactorily for |
686 |
the client, in which case it will be in one of these states: |
687 |
|
688 |
The TLS negotiation failed completely |
689 |
|
690 |
In this case, the control connection should still be up in |
691 |
unprotected mode and the client should issue an unprotected |
692 |
QUIT command to end the session. |
693 |
|
694 |
The TLS negotiation completed successfully, but the client |
695 |
decides that the session parameters are not acceptable (e.g. |
696 |
Distinguished Name in certificate is not the actual server |
697 |
expected) |
698 |
|
699 |
In this case, the control connection should still be up in a |
700 |
protected state, so the client should issue a protected QUIT |
701 |
command to end the session. |
702 |
|
703 |
The TLS negotiation failed during the TLS handshake |
704 |
|
705 |
In this case, the control connection is in an unknown state |
706 |
and the client should simply drop the control connection. |
707 |
|
708 |
9.4. The client's view of the data connection |
709 |
|
710 |
Client security policies |
711 |
|
712 |
Clients do not typically have 'policies' as such, instead they |
713 |
rely on the user defining their actions and, to a certain extent, |
714 |
are reactive to the server policy. Thus a client will need to |
715 |
|
716 |
|
717 |
|
718 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 12] |
719 |
|
720 |
|
721 |
|
722 |
|
723 |
|
724 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
725 |
|
726 |
|
727 |
have commands that will allow the user to switch the protection |
728 |
level of the data connection dynamically, however, there may be a |
729 |
general 'policy' that attempts all LIST and NLST commands on a |
730 |
Clear connection first (and automatically switches to Private if |
731 |
it fails). In this case there would need to be a user command |
732 |
available to ensure that a given data transfer was not attempted |
733 |
on an insecure data connection. |
734 |
|
735 |
Clients also need to understand that the level of the PROT setting |
736 |
is only checked for a particular data transfer after that transfer |
737 |
has been requested. Thus a refusal by the server to accept a |
738 |
particular data transfer should not be read by the client as a |
739 |
refusal to accept that data protection level in toto, as not only |
740 |
may other data transfers be acceptable at that protection level, |
741 |
but it is entirely possible that the same transfer may be accepted |
742 |
at the same protection level at a later point in the session. |
743 |
|
744 |
It should be noted that the TLS authentication of the client |
745 |
should be authentication of a user on the client host and not the |
746 |
client host itself. |
747 |
|
748 |
|
749 |
|
750 |
|
751 |
|
752 |
|
753 |
|
754 |
|
755 |
|
756 |
|
757 |
|
758 |
|
759 |
|
760 |
|
761 |
|
762 |
|
763 |
|
764 |
|
765 |
|
766 |
|
767 |
|
768 |
|
769 |
|
770 |
|
771 |
|
772 |
|
773 |
|
774 |
|
775 |
|
776 |
|
777 |
|
778 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 13] |
779 |
|
780 |
|
781 |
|
782 |
|
783 |
|
784 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
785 |
|
786 |
|
787 |
10. Who negotiates what, where and how |
788 |
|
789 |
10.1. Do we protect at all ? |
790 |
|
791 |
Client issues 'AUTH TLS', server accepts or rejects. |
792 |
If server needs AUTH, then it refuses to accept certain commands |
793 |
until it gets a successfully protected session. |
794 |
|
795 |
10.2. What level of protection do we use on the Control connection ? |
796 |
|
797 |
Decided entirely by the TLS CipherSuite negotiation. |
798 |
|
799 |
10.3. Do we protect data connections in general ? |
800 |
|
801 |
Client issues PROT command, server accepts or rejects. |
802 |
|
803 |
|
804 |
10.4. Is protection required for a particular data transfer ? |
805 |
|
806 |
A client would already have issued a PROT command if it required |
807 |
the connection to be protected. |
808 |
If a server needs to have the connection protected then it will |
809 |
reply to the STOR/RETR/NLST/... command with a '522' indicating |
810 |
that the current state of the data connection protection level is |
811 |
not sufficient for that data transfer at that time. |
812 |
|
813 |
10.5. What level of protection is required for a particular data |
814 |
transfer ? |
815 |
|
816 |
Decided entirely by the TLS CipherSuite negotiation. |
817 |
|
818 |
Thus it can be seen that, for flexibility, it is desirable for the |
819 |
FTP application to be able to interact with the TLS layer upon which |
820 |
it sits to define and discover the exact TLS CipherSuites that are to |
821 |
be/have been negotiated and make decisions accordingly. |
822 |
|
823 |
|
824 |
|
825 |
|
826 |
|
827 |
|
828 |
|
829 |
|
830 |
|
831 |
|
832 |
|
833 |
|
834 |
|
835 |
|
836 |
|
837 |
|
838 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 14] |
839 |
|
840 |
|
841 |
|
842 |
|
843 |
|
844 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
845 |
|
846 |
|
847 |
11. Timing Diagrams |
848 |
|
849 |
11.1. Establishing a protected session |
850 |
|
851 |
Client Server |
852 |
control data data control |
853 |
==================================================================== |
854 |
|
855 |
socket() |
856 |
bind() |
857 |
socket() |
858 |
connect() ----------------------------------------------> accept() |
859 |
<---------------------------------------------- 220 |
860 |
AUTH TLS ----------------------------------------------> |
861 |
<---------------------------------------------- 234 |
862 |
TLSneg() <----------------------------------------------> TLSneg() |
863 |
PBSZ 0 ----------------------------------------------> |
864 |
<---------------------------------------------- 200 |
865 |
PROT P ----------------------------------------------> |
866 |
<---------------------------------------------- 200 |
867 |
USER fred ----------------------------------------------> |
868 |
<---------------------------------------------- 331 |
869 |
PASS pass ----------------------------------------------> |
870 |
<---------------------------------------------- 230 |
871 |
|
872 |
Note 1: the order of the PBSZ/PROT pair and the USER/PASS pair (with |
873 |
respect to each other) is not important (i.e. the USER/PASS can happen |
874 |
prior to the PBSZ/PROT - or indeed the server can refuse to allow a |
875 |
PBSZ/PROT pair until the USER/PASS pair has happened). |
876 |
|
877 |
Note 2: the PASS command might not be required at all (if the USER |
878 |
parameter and any client identity presented provide sufficient |
879 |
authentication). The server would indicate this by issuing a '232' |
880 |
reply to the USER command instead of the '331' which requests a PASS |
881 |
from the client. |
882 |
|
883 |
Note 3: the AUTH command might not be the first command after the |
884 |
receipt of the 220 welcome message. |
885 |
|
886 |
|
887 |
|
888 |
|
889 |
|
890 |
|
891 |
|
892 |
|
893 |
|
894 |
|
895 |
|
896 |
|
897 |
|
898 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 15] |
899 |
|
900 |
|
901 |
|
902 |
|
903 |
|
904 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
905 |
|
906 |
|
907 |
11.2. A standard data transfer without protection. |
908 |
|
909 |
Client Server |
910 |
control data data control |
911 |
==================================================================== |
912 |
|
913 |
socket() |
914 |
bind() |
915 |
PORT w,x,y,z,a,b -----------------------------------------> |
916 |
<----------------------------------------------------- 200 |
917 |
STOR file ------------------------------------------------> |
918 |
socket() |
919 |
bind() |
920 |
<----------------------------------------------------- 150 |
921 |
accept() <----------- connect() |
922 |
write() -----------> read() |
923 |
close() -----------> close() |
924 |
<----------------------------------------------------- 226 |
925 |
|
926 |
|
927 |
|
928 |
|
929 |
|
930 |
|
931 |
|
932 |
|
933 |
|
934 |
|
935 |
|
936 |
|
937 |
|
938 |
|
939 |
|
940 |
|
941 |
|
942 |
|
943 |
|
944 |
|
945 |
|
946 |
|
947 |
|
948 |
|
949 |
|
950 |
|
951 |
|
952 |
|
953 |
|
954 |
|
955 |
|
956 |
|
957 |
|
958 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 16] |
959 |
|
960 |
|
961 |
|
962 |
|
963 |
|
964 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
965 |
|
966 |
|
967 |
11.3. A firewall-friendly data transfer without protection |
968 |
|
969 |
Client Server |
970 |
control data data control |
971 |
==================================================================== |
972 |
|
973 |
PASV --------------------------------------------------------> |
974 |
socket() |
975 |
bind() |
976 |
<------------------------------------------ 227 (w,x,y,z,a,b) |
977 |
socket() |
978 |
STOR file ---------------------------------------------------> |
979 |
connect() ----------> accept() |
980 |
<-------------------------------------------------------- 150 |
981 |
write() ----------> read() |
982 |
close() ----------> close() |
983 |
<-------------------------------------------------------- 226 |
984 |
|
985 |
|
986 |
Note: Implementors should be aware that then connect()/accept() |
987 |
function is performed prior to the receipt of the reply from the |
988 |
STOR command. This contrasts with situation when (non-firewall- |
989 |
friendly) PORT is used prior to the STOR, and the accept()/connect() |
990 |
is performed after the reply from the aforementioned STOR has been |
991 |
dealt with. |
992 |
|
993 |
|
994 |
|
995 |
|
996 |
|
997 |
|
998 |
|
999 |
|
1000 |
|
1001 |
|
1002 |
|
1003 |
|
1004 |
|
1005 |
|
1006 |
|
1007 |
|
1008 |
|
1009 |
|
1010 |
|
1011 |
|
1012 |
|
1013 |
|
1014 |
|
1015 |
|
1016 |
|
1017 |
|
1018 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 17] |
1019 |
|
1020 |
|
1021 |
|
1022 |
|
1023 |
|
1024 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
1025 |
|
1026 |
|
1027 |
11.4. A standard data transfer with protection |
1028 |
|
1029 |
Client Server |
1030 |
control data data control |
1031 |
==================================================================== |
1032 |
|
1033 |
socket() |
1034 |
bind() |
1035 |
PORT w,x,y,z,a,b --------------------------------------------> |
1036 |
<-------------------------------------------------------- 200 |
1037 |
STOR file ---------------------------------------------------> |
1038 |
socket() |
1039 |
bind() |
1040 |
<-------------------------------------------------------- 150 |
1041 |
accept() <---------- connect() |
1042 |
TLSneg() <----------> TLSneg() |
1043 |
TLSwrite() ----------> TLSread() |
1044 |
TLSshutdown() -------> TLSshutdown() |
1045 |
close() ----------> close() |
1046 |
<-------------------------------------------------------- 226 |
1047 |
|
1048 |
|
1049 |
|
1050 |
|
1051 |
|
1052 |
|
1053 |
|
1054 |
|
1055 |
|
1056 |
|
1057 |
|
1058 |
|
1059 |
|
1060 |
|
1061 |
|
1062 |
|
1063 |
|
1064 |
|
1065 |
|
1066 |
|
1067 |
|
1068 |
|
1069 |
|
1070 |
|
1071 |
|
1072 |
|
1073 |
|
1074 |
|
1075 |
|
1076 |
|
1077 |
|
1078 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 18] |
1079 |
|
1080 |
|
1081 |
|
1082 |
|
1083 |
|
1084 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
1085 |
|
1086 |
|
1087 |
11.5. A firewall-friendly data transfer with protection |
1088 |
|
1089 |
Client Server |
1090 |
control data data control |
1091 |
==================================================================== |
1092 |
|
1093 |
PASV --------------------------------------------------------> |
1094 |
socket() |
1095 |
bind() |
1096 |
<------------------------------------------ 227 (w,x,y,z,a,b) |
1097 |
socket() |
1098 |
STOR file ---------------------------------------------------> |
1099 |
connect() ----------> accept() |
1100 |
<-------------------------------------------------------- 150 |
1101 |
TLSneg() <---------> TLSneg() |
1102 |
TLSwrite() ---------> TLSread() |
1103 |
TLSshutdown() -------> TLSshutdown() |
1104 |
close() ---------> close() |
1105 |
<-------------------------------------------------------- 226 |
1106 |
|
1107 |
|
1108 |
|
1109 |
|
1110 |
|
1111 |
|
1112 |
|
1113 |
|
1114 |
|
1115 |
|
1116 |
|
1117 |
|
1118 |
|
1119 |
|
1120 |
|
1121 |
|
1122 |
|
1123 |
|
1124 |
|
1125 |
|
1126 |
|
1127 |
|
1128 |
|
1129 |
|
1130 |
|
1131 |
|
1132 |
|
1133 |
|
1134 |
|
1135 |
|
1136 |
|
1137 |
|
1138 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 19] |
1139 |
|
1140 |
|
1141 |
|
1142 |
|
1143 |
|
1144 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
1145 |
|
1146 |
|
1147 |
12. Discussion of the REIN command |
1148 |
|
1149 |
The REIN command, defined in [RFC-959], allows the user to reset the |
1150 |
state of the FTP session. From [RFC-959]: |
1151 |
REINITIALIZE (REIN) |
1152 |
This command terminates a USER, flushing all I/O and account |
1153 |
information, except to allow any transfer in progress to be |
1154 |
completed. All parameters are reset to the default settings |
1155 |
and the control connection is left open. This is identical to |
1156 |
the state in which a user finds himself immediately after the |
1157 |
control connection is opened. A USER command may be expected |
1158 |
to follow. |
1159 |
When this command is processed by the server, the TLS session(s) |
1160 |
MUST be cleared and the control and data connections revert to |
1161 |
unprotected, clear communications. It MAY be acceptable to use |
1162 |
cached TLS sessions for subsequent connections, however a server MUST |
1163 |
not mandate this. |
1164 |
|
1165 |
|
1166 |
|
1167 |
|
1168 |
|
1169 |
|
1170 |
|
1171 |
|
1172 |
|
1173 |
|
1174 |
|
1175 |
|
1176 |
|
1177 |
|
1178 |
|
1179 |
|
1180 |
|
1181 |
|
1182 |
|
1183 |
|
1184 |
|
1185 |
|
1186 |
|
1187 |
|
1188 |
|
1189 |
|
1190 |
|
1191 |
|
1192 |
|
1193 |
|
1194 |
|
1195 |
|
1196 |
|
1197 |
|
1198 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 20] |
1199 |
|
1200 |
|
1201 |
|
1202 |
|
1203 |
|
1204 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
1205 |
|
1206 |
|
1207 |
13. Discussion of the STAT and ABOR commands |
1208 |
|
1209 |
The ABOR and STAT commands and the use of TCP Urgent Pointers |
1210 |
|
1211 |
[RFC-959] describes the use of Telnet commands (IP and DM) and the |
1212 |
TCP Urgent pointer to indicate the transmission of commands on the |
1213 |
control channel during the execution of a data transfer. FTP uses |
1214 |
the Telnet Interrupt Process and Data Mark commands in conjunction |
1215 |
with Urgent data to preface two commands: ABOR (Abort Transfer) |
1216 |
and STAT (Status request). |
1217 |
|
1218 |
The Urgent Pointer was used because in a Unix implementation the |
1219 |
receipt of a TCP packet marked as Urgent would result in the the |
1220 |
execution of the SIGURG interrupt handler. This reliance on |
1221 |
interrupt handlers was necessary on systems which did not |
1222 |
implement select() or did not support multiple threads. TLS does |
1223 |
not support the notion of Urgent data. |
1224 |
|
1225 |
When TLS is implemented as a security method in FTP the server |
1226 |
SHOULD NOT rely on the use of SIGURG to process input on the |
1227 |
control channel during data transfers. The client MUST send all |
1228 |
data including Telnet commands across the TLS session. The TLS |
1229 |
session will be corrupted if any data is sent on a socket while |
1230 |
TLS is active. |
1231 |
|
1232 |
|
1233 |
|
1234 |
|
1235 |
|
1236 |
|
1237 |
|
1238 |
|
1239 |
|
1240 |
|
1241 |
|
1242 |
|
1243 |
|
1244 |
|
1245 |
|
1246 |
|
1247 |
|
1248 |
|
1249 |
|
1250 |
|
1251 |
|
1252 |
|
1253 |
|
1254 |
|
1255 |
|
1256 |
|
1257 |
|
1258 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 21] |
1259 |
|
1260 |
|
1261 |
|
1262 |
|
1263 |
|
1264 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
1265 |
|
1266 |
|
1267 |
14. Security Considerations |
1268 |
|
1269 |
This entire document deals with security considerations related to |
1270 |
the File Transfer Protocol. |
1271 |
|
1272 |
14.1. Verification of Authentication tokens |
1273 |
|
1274 |
14.1.1. Server Certificates |
1275 |
|
1276 |
Although it is entirely an implementation decision, it is |
1277 |
recommended that certificates used for server authentication of |
1278 |
the TLS session contain the server identification information |
1279 |
in a similar manner to those used for http servers. (see |
1280 |
[RFC-2818]) |
1281 |
|
1282 |
Similarly, it is recommended that the certificate used for |
1283 |
server authentication of Data connections is the same |
1284 |
certificate as that used for the corresponding Control |
1285 |
connection. |
1286 |
|
1287 |
14.1.2. Client Certificates |
1288 |
|
1289 |
- Deciding which client certificates to allow and defining |
1290 |
which fields define what authentication information is entirely |
1291 |
a server implementation issue. |
1292 |
|
1293 |
- It is also server implementation issue to decide if the |
1294 |
authentication token presented for the data connection must |
1295 |
match the one used for the corresponding control connection. |
1296 |
|
1297 |
14.2. Addressing FTP Security Considerations [RFC-2577] |
1298 |
|
1299 |
14.2.1. Bounce Attack |
1300 |
|
1301 |
A bounce attack should be harder in a secured FTP environment |
1302 |
because: |
1303 |
|
1304 |
- The FTP server that is being used to initiate a false |
1305 |
connection will always be a 'server' in the TLS context. |
1306 |
Therefore, only services that act as 'clients' in the TLS |
1307 |
context could be vulnerable. This would be a counter- |
1308 |
intuitive way to implement TLS on a service. |
1309 |
|
1310 |
- The FTP server would detect that the authentication |
1311 |
credentials for the data connection are not the same as |
1312 |
those for the control connection, thus the server policies |
1313 |
COULD be set to drop the data connection. |
1314 |
|
1315 |
|
1316 |
|
1317 |
|
1318 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 22] |
1319 |
|
1320 |
|
1321 |
|
1322 |
|
1323 |
|
1324 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
1325 |
|
1326 |
|
1327 |
- Genuine users are less likely to initiate such attacks |
1328 |
when the authentication is strong and malicious users are |
1329 |
less likely to gain access to the FTP server if the |
1330 |
authentication is not easily subverted (password guessing, |
1331 |
network tracing, etc...) |
1332 |
|
1333 |
14.2.2. Restricting Access |
1334 |
|
1335 |
This document presents a strong mechanism for solving the issue |
1336 |
raised in this section. |
1337 |
|
1338 |
14.2.3. Protecting Passwords |
1339 |
|
1340 |
The twin solutions of strong authentication and data |
1341 |
confidentiality ensure that this is not an issue when TLS is |
1342 |
used to protect the control session. |
1343 |
|
1344 |
14.2.4. Privacy |
1345 |
|
1346 |
The TLS protocol ensures data confidentiality by encryption. |
1347 |
Privacy (e.g. access to download logs, user profile |
1348 |
information, etc...) is outside the scope of this document (and |
1349 |
[RFC-2577] presumably) |
1350 |
|
1351 |
14.2.5. Protecting Usernames |
1352 |
|
1353 |
This is not an issue when TLS is used as the primary |
1354 |
authentication mechanism. |
1355 |
|
1356 |
14.2.6. Port Stealing |
1357 |
|
1358 |
This proposal will do little for the Denial of Service element |
1359 |
of this section, however, strong authentication on the data |
1360 |
connection will prevent unauthorised connections retrieving or |
1361 |
submitting files. |
1362 |
|
1363 |
14.2.7. Software-Base Security Problems |
1364 |
|
1365 |
Nothing in this proposal will affect the discussion in this |
1366 |
section. |
1367 |
|
1368 |
|
1369 |
15. IANA Considerations |
1370 |
|
1371 |
{FTP-PORT} - The port assigned to the FTP control connection is 21. |
1372 |
|
1373 |
16. Other Parameters |
1374 |
|
1375 |
|
1376 |
|
1377 |
|
1378 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 23] |
1379 |
|
1380 |
|
1381 |
|
1382 |
|
1383 |
|
1384 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
1385 |
|
1386 |
|
1387 |
{TLS-PARM} - The parameter for the AUTH command to indicate that TLS |
1388 |
is required. To request the TLS protocol in accordance with this |
1389 |
document, the client MUST use 'TLS' |
1390 |
|
1391 |
To maintain backward compatability with older versions of this |
1392 |
document, the server SHOULD accept 'TLS-C' as a synonym for 'TLS' |
1393 |
|
1394 |
Note - [RFC-2228] states that these parameters are case- |
1395 |
insensitive. |
1396 |
|
1397 |
|
1398 |
17. Network Management |
1399 |
|
1400 |
NONE |
1401 |
|
1402 |
|
1403 |
18. Internationalization |
1404 |
|
1405 |
NONE |
1406 |
|
1407 |
|
1408 |
19. Scalability & Limits |
1409 |
|
1410 |
There are no issues other than those concerned with the ability of |
1411 |
the server to refuse to have a complete TLS negotiation for each and |
1412 |
every data connection, which will allow servers to retain throughput |
1413 |
whilst using cycles only when necessary. |
1414 |
|
1415 |
|
1416 |
|
1417 |
|
1418 |
|
1419 |
|
1420 |
|
1421 |
|
1422 |
|
1423 |
|
1424 |
|
1425 |
|
1426 |
|
1427 |
|
1428 |
|
1429 |
|
1430 |
|
1431 |
|
1432 |
|
1433 |
|
1434 |
|
1435 |
|
1436 |
|
1437 |
|
1438 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 24] |
1439 |
|
1440 |
|
1441 |
|
1442 |
|
1443 |
|
1444 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
1445 |
|
1446 |
|
1447 |
20. Applicability |
1448 |
|
1449 |
This mechanism is generally applicable as a mechanism for securing |
1450 |
the FTP protocol. It is unlikely that anonymous FTP clients or |
1451 |
servers will require such security (although some might like the |
1452 |
authentication features without the confidentiality). |
1453 |
|
1454 |
|
1455 |
21. Acknowledgements |
1456 |
|
1457 |
o Netscape Communications Corporation for the original SSL protocol. |
1458 |
|
1459 |
o Eric Young for the SSLeay libraries. |
1460 |
|
1461 |
o University of California, Berkley for the original implementations |
1462 |
of FTP and ftpd on which the initial implementation of these |
1463 |
extensions were layered. |
1464 |
|
1465 |
o IETF CAT working group. |
1466 |
|
1467 |
o IETF TLS working group. |
1468 |
|
1469 |
o IETF FTPEXT working group. |
1470 |
|
1471 |
o Jeff Altman for the ABOR and STAT discussion. |
1472 |
|
1473 |
|
1474 |
|
1475 |
|
1476 |
|
1477 |
|
1478 |
|
1479 |
|
1480 |
|
1481 |
|
1482 |
|
1483 |
|
1484 |
|
1485 |
|
1486 |
|
1487 |
|
1488 |
|
1489 |
|
1490 |
|
1491 |
|
1492 |
|
1493 |
|
1494 |
|
1495 |
|
1496 |
|
1497 |
|
1498 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 25] |
1499 |
|
1500 |
|
1501 |
|
1502 |
|
1503 |
|
1504 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
1505 |
|
1506 |
|
1507 |
22. References |
1508 |
|
1509 |
[RFC-959] J. Postel, "File Transfer Protocol" |
1510 |
RFC 959, October 1985. |
1511 |
|
1512 |
[RFC-1579] S. Bellovin, "Firewall-Friendly FTP" |
1513 |
RFC 1579, February 1994. |
1514 |
|
1515 |
[RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate |
1516 |
Requirement Levels" |
1517 |
RFC 2119, March 1997. |
1518 |
|
1519 |
[RFC-2222] J. Myers, "Simple Authentication and Security Layer" |
1520 |
RFC 2222, October 1997. |
1521 |
|
1522 |
[RFC-2228] M. Horowitz, S. Lunt, "FTP Security Extensions" |
1523 |
RFC 2228, October 1997. |
1524 |
|
1525 |
[RFC-2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0" |
1526 |
RFC 2246, January 1999. |
1527 |
|
1528 |
[RFC-2389] P Hethmon, R.Elz, "Feature Negotiation Mechanism for the |
1529 |
File Transfer Protocol" |
1530 |
RFC 2389, August 1998. |
1531 |
|
1532 |
[RFC-2487] P Hoffman, "SMTP Service Extension for Secure SMTP over |
1533 |
TLS" |
1534 |
RFC 2487, January 1999. |
1535 |
|
1536 |
[RFC-2577] M Allman, S Ostermann, "FTP Security Considerations" |
1537 |
RFC 2577, May 1999. |
1538 |
|
1539 |
[RFC-2817] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1" |
1540 |
RFC 2817, May 2000. |
1541 |
|
1542 |
[RFC-2818] E. Rescorla, "HTTP Over TLS" |
1543 |
RFC 2818, May 2000. |
1544 |
|
1545 |
|
1546 |
|
1547 |
|
1548 |
|
1549 |
|
1550 |
|
1551 |
|
1552 |
|
1553 |
|
1554 |
|
1555 |
|
1556 |
|
1557 |
|
1558 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 26] |
1559 |
|
1560 |
|
1561 |
|
1562 |
|
1563 |
|
1564 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
1565 |
|
1566 |
|
1567 |
23. Authors' Contact Addresses |
1568 |
|
1569 |
The FTP-TLS draft information site is at http://www.ford- |
1570 |
hutchinson.com/~fh-1-pfh/ftps-ext.html |
1571 |
|
1572 |
|
1573 |
Please send comments to Paul Ford-Hutchinson at the address below |
1574 |
|
1575 |
Tim Hudson Paul Ford-Hutchinson |
1576 |
RSA Data Security IBM UK Ltd |
1577 |
Australia Pty Ltd PO Box 31 |
1578 |
Birmingham Road |
1579 |
Warwick |
1580 |
United Kingdom |
1581 |
tel - +61 7 3227 4444 +44 1926 462005 |
1582 |
fax - +61 7 3227 4400 +44 1926 496482 |
1583 |
email - tjh@rsasecurity.com.au paulfordh@uk.ibm.com |
1584 |
|
1585 |
Martin Carpenter Eric Murray |
1586 |
Verisign Ltd Wave Systems Inc. |
1587 |
email - mcarpenter@verisign.com ericm@lne.com |
1588 |
|
1589 |
Volker Wiegand |
1590 |
SuSE Linux |
1591 |
email - wiegand@suse.de |
1592 |
|
1593 |
|
1594 |
|
1595 |
|
1596 |
|
1597 |
|
1598 |
|
1599 |
|
1600 |
|
1601 |
|
1602 |
|
1603 |
|
1604 |
|
1605 |
|
1606 |
|
1607 |
|
1608 |
|
1609 |
|
1610 |
|
1611 |
|
1612 |
|
1613 |
|
1614 |
|
1615 |
|
1616 |
|
1617 |
|
1618 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 27] |
1619 |
|
1620 |
|
1621 |
|
1622 |
|
1623 |
|
1624 |
Internet-Draft Secure FTP using TLS 2nd April, 2002 |
1625 |
|
1626 |
|
1627 |
The IETF takes no position regarding the validity or scope of any |
1628 |
intellectual property or other rights that might be claimed to |
1629 |
pertain to the implementation or use of the technology described in |
1630 |
this document or the extent to which any license under such rights |
1631 |
might or might not be available; neither does it represent that it |
1632 |
has made any effort to identify any such rights. Information on the |
1633 |
IETF's procedures with respect to rights in standards-track and |
1634 |
standards-related documentation can be found in BCP-11. Copies of |
1635 |
claims of rights made available for publication and any assurances of |
1636 |
licenses to be made available, or the result of an attempt made to |
1637 |
obtain a general license or permission for the use of such |
1638 |
proprietary rights by implementors or users of this specification can |
1639 |
be obtained from the IETF Secretariat. |
1640 |
|
1641 |
The IETF invites any interested party to bring to its attention any |
1642 |
copyrights, patents or patent applications, or other proprietary |
1643 |
rights which may cover technology that may be required to practice |
1644 |
this standard. Please address the information to the IETF Executive |
1645 |
Director. |
1646 |
|
1647 |
Copyright (C) The Internet Society (2002). All Rights Reserved. |
1648 |
|
1649 |
This document and translations of it may be copied and furnished to |
1650 |
others, and derivative works that comment on or otherwise explain it |
1651 |
or assist in its implementation may be prepared, copied, published |
1652 |
and distributed, in whole or in part, without restriction of any |
1653 |
kind, provided that the above copyright notice and this paragraph are |
1654 |
included on all such copies and derivative works. However, this |
1655 |
document itself may not be modified in any way, such as by removing |
1656 |
the copyright notice or references to the Internet Society or other |
1657 |
Internet organizations, except as needed for the purpose of |
1658 |
developing Internet standards in which case the procedures for |
1659 |
copyrights defined in the Internet Standards process must be |
1660 |
followed, or as required to translate it into languages other than |
1661 |
English. |
1662 |
|
1663 |
The limited permissions granted above are perpetual and will not be |
1664 |
revoked by the Internet Society or its successors or assigns. |
1665 |
|
1666 |
This document and the information contained herein is provided on an |
1667 |
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING |
1668 |
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING |
1669 |
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION |
1670 |
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF |
1671 |
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
1672 |
|
1673 |
This document expires on 2nd October, 2002 |
1674 |
|
1675 |
|
1676 |
|
1677 |
|
1678 |
Ford-Hutchinson, Carpenter, Hudson, Murray & Wiegand FORMFEED[Page 28] |
1679 |
|