draft-ietf-secsh-filexfer-11.txt | draft-ietf-secsh-filexfer-12.txt | |||
---|---|---|---|---|
Secure Shell Working Group J. Galbraith | Secure Shell Working Group J. Galbraith | |||
Internet-Draft VanDyke Software | Internet-Draft VanDyke Software | |||
Expires: July 21, 2006 O. Saarenmaa | Expires: July 29, 2006 O. Saarenmaa | |||
F-Secure | F-Secure | |||
January 17, 2006 | January 25, 2006 | |||
SSH File Transfer Protocol | SSH File Transfer Protocol | |||
draft-ietf-secsh-filexfer-11.txt | draft-ietf-secsh-filexfer-12.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 35 | skipping to change at page 1, line 35 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on July 21, 2006. | This Internet-Draft will expire on July 29, 2006. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
The SSH File Transfer Protocol provides secure file transfer | The SSH File Transfer Protocol provides secure file transfer | |||
functionality over any reliable data stream. It is the standard file | functionality over any reliable data stream. It is the standard file | |||
transfer protocol for use with the SSH2 protocol. This document | transfer protocol for use with the SSH2 protocol. This document | |||
skipping to change at page 3, line 13 | skipping to change at page 3, line 13 | |||
8.9. Canonicalizing the Server-Side Path Name . . . . . . . . . 44 | 8.9. Canonicalizing the Server-Side Path Name . . . . . . . . . 44 | |||
8.9.1. Best Practice for Dealing with Paths . . . . . . . . . 46 | 8.9.1. Best Practice for Dealing with Paths . . . . . . . . . 46 | |||
9. Responses from the Server to the Client . . . . . . . . . . . 47 | 9. Responses from the Server to the Client . . . . . . . . . . . 47 | |||
9.1. Status Response . . . . . . . . . . . . . . . . . . . . . 47 | 9.1. Status Response . . . . . . . . . . . . . . . . . . . . . 47 | |||
9.2. Handle Response . . . . . . . . . . . . . . . . . . . . . 51 | 9.2. Handle Response . . . . . . . . . . . . . . . . . . . . . 51 | |||
9.3. Data Response . . . . . . . . . . . . . . . . . . . . . . 52 | 9.3. Data Response . . . . . . . . . . . . . . . . . . . . . . 52 | |||
9.4. Name Response . . . . . . . . . . . . . . . . . . . . . . 52 | 9.4. Name Response . . . . . . . . . . . . . . . . . . . . . . 52 | |||
9.5. Attrs Response . . . . . . . . . . . . . . . . . . . . . . 53 | 9.5. Attrs Response . . . . . . . . . . . . . . . . . . . . . . 53 | |||
10. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 53 | 10. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 53 | |||
11. Implementation Considerations . . . . . . . . . . . . . . . . 54 | 11. Implementation Considerations . . . . . . . . . . . . . . . . 54 | |||
12. Security Considerations . . . . . . . . . . . . . . . . . . . 55 | 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 | |||
13. Changes from Previous Protocol Versions . . . . . . . . . . . 56 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 55 | |||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 | 14. Changes from Previous Protocol Versions . . . . . . . . . . . 56 | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . . 56 | 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 | |||
14.2. Informative References . . . . . . . . . . . . . . . . . . 57 | 15.1. Normative References . . . . . . . . . . . . . . . . . . . 56 | |||
15.2. Informative References . . . . . . . . . . . . . . . . . . 57 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 59 | Intellectual Property and Copyright Statements . . . . . . . . . . 59 | |||
1. Introduction | 1. Introduction | |||
This protocol provides secure file transfer (and more generally file | This protocol provides secure file transfer (and more generally file | |||
system access.) It is designed so that it could be used to implement | system access.) It is designed so that it could be used to implement | |||
a secure remote file system service, as well as a secure file | a secure remote file system service, as well as a secure file | |||
transfer service. | transfer service. | |||
skipping to change at page 15, line 8 | skipping to change at page 15, line 8 | |||
This protocol represents file names as strings. File names are | This protocol represents file names as strings. File names are | |||
assumed to use the slash ('/') character as a directory separator. | assumed to use the slash ('/') character as a directory separator. | |||
File names starting with a slash are "absolute", and are relative to | File names starting with a slash are "absolute", and are relative to | |||
the root of the file system. Names starting with any other character | the root of the file system. Names starting with any other character | |||
are relative to the user's default directory (home directory). Note | are relative to the user's default directory (home directory). Note | |||
that identifying the user is assumed to take place outside of this | that identifying the user is assumed to take place outside of this | |||
protocol. | protocol. | |||
Servers SHOULD interpret a path name component ".." (Section 12) as | Servers SHOULD interpret a path name component ".." (Section 13) as | |||
referring to the parent directory, and "." as referring to the | referring to the parent directory, and "." as referring to the | |||
current directory. | current directory. | |||
An empty path name is valid, and it refers to the user's default | An empty path name is valid, and it refers to the user's default | |||
directory (usually the user's home directory). | directory (usually the user's home directory). | |||
Otherwise, no syntax is defined for file names by this specification. | Otherwise, no syntax is defined for file names by this specification. | |||
Clients should not make any other assumptions; however, they can | Clients should not make any other assumptions; however, they can | |||
splice path name components returned by SSH_FXP_READDIR together | splice path name components returned by SSH_FXP_READDIR together | |||
using a slash ('/') as the separator, and that will work as expected. | using a slash ('/') as the separator, and that will work as expected. | |||
skipping to change at page 18, line 48 | skipping to change at page 18, line 48 | |||
SSH_FILEXFER_TYPE_FIFO 9 | SSH_FILEXFER_TYPE_FIFO 9 | |||
On a POSIX system, these values would be derived from the mode field | On a POSIX system, these values would be derived from the mode field | |||
of the stat structure. SPECIAL should be used for files that are of | of the stat structure. SPECIAL should be used for files that are of | |||
a known type which cannot be expressed in the protocol. UNKNOWN | a known type which cannot be expressed in the protocol. UNKNOWN | |||
should be used if the type is not known. | should be used if the type is not known. | |||
7.3. Size | 7.3. Size | |||
The 'size' field specifies the number of bytes that can be read from | The 'size' field specifies the number of bytes that can be read from | |||
the file, or in other words, the location of the end-of-file. This | the file, or in other words, the location of the end-of-file. | |||
attribute MUST NOT be present during file creation. | ||||
If this field is present during file creation, it indicates the | ||||
number of bytes the client intends to transfer, but SHOULD NOT effect | ||||
the creation of the file. The server can use this information to | ||||
determine if the client sent all the intended data and the file was | ||||
transfered in it's entirity. | ||||
If this field is present during a setstat operation, the file MUST be | If this field is present during a setstat operation, the file MUST be | |||
extended or truncated to the specified size. | extended or truncated to the specified size. | |||
Files opened with the SSH_FXF_TEXT flag may have a size that is | Files opened with the SSH_FXF_TEXT flag may have a size that is | |||
greater or less than the value of the size field. The server MAY | greater or less than the value of the size field. The server MAY | |||
fail setstat operations specifying size for files opened with the | fail setstat operations specifying size for files opened with the | |||
SSH_FXF_TEXT flag. | SSH_FXF_TEXT flag. | |||
7.4. allocation-size | 7.4. allocation-size | |||
skipping to change at page 55, line 12 | skipping to change at page 55, line 12 | |||
when the data size matches the channel's max packet, and the channel | when the data size matches the channel's max packet, and the channel | |||
window is a multiple of the channel packet size. | window is a multiple of the channel packet size. | |||
Implementations MUST be aware that requests do not have to be | Implementations MUST be aware that requests do not have to be | |||
satisfied in the order issued. (See Request Synchronization and | satisfied in the order issued. (See Request Synchronization and | |||
Reordering (Section 4.1).) | Reordering (Section 4.1).) | |||
Implementations MUST also be aware that read requests may not return | Implementations MUST also be aware that read requests may not return | |||
all the requested data, even if the data is available. | all the requested data, even if the data is available. | |||
12. Security Considerations | 12. IANA Considerations | |||
An IANA registry needs to be created containing: | ||||
o The packet types define defined in Section 4.3 | ||||
o The extension specified in this draft, which are: 'text-seek', | ||||
'supported2', 'acl-supported', 'newline', 'versions', 'version- | ||||
select', 'filename-charset', 'filename-translation-control' | ||||
13. Security Considerations | ||||
It is assumed that both ends of the connection have been | It is assumed that both ends of the connection have been | |||
authenticated and that the connection has privacy and integrity | authenticated and that the connection has privacy and integrity | |||
features. Such security issues are left to the underlying transport | features. Such security issues are left to the underlying transport | |||
protocol, except to note that if this is not the case, an attacker | protocol, except to note that if this is not the case, an attacker | |||
could manipulate files on the server at will and thus wholly | could manipulate files on the server at will and thus wholly | |||
compromise the server. | compromise the server. | |||
This protocol provides file system access to arbitrary files on the | This protocol provides file system access to arbitrary files on the | |||
server (constrained only by the server implementation). It is the | server (constrained only by the server implementation). It is the | |||
skipping to change at page 56, line 21 | skipping to change at page 56, line 30 | |||
cannot be used to bypass access checks or controls. | cannot be used to bypass access checks or controls. | |||
If the server implementation limits access to certain parts of the | If the server implementation limits access to certain parts of the | |||
file system, extra care must be taken in parsing file names which | file system, extra care must be taken in parsing file names which | |||
contain the '..' path element, and when following symbolic links, | contain the '..' path element, and when following symbolic links, | |||
shortcuts, or other filesystem objects which might transpose the path | shortcuts, or other filesystem objects which might transpose the path | |||
to refer to an object outside of the restricted area. There have | to refer to an object outside of the restricted area. There have | |||
been numerous reported security bugs where a ".." in a path name has | been numerous reported security bugs where a ".." in a path name has | |||
allowed access outside the intended area. | allowed access outside the intended area. | |||
13. Changes from Previous Protocol Versions | 14. Changes from Previous Protocol Versions | |||
RFC EDITOR: PLEASE REMOVE ENTIRE SECTION BEFORE PUBLISHING | RFC EDITOR: PLEASE REMOVE ENTIRE SECTION BEFORE PUBLISHING | |||
Please refer to the following web page for pervious versions of the | Please refer to the following web page for pervious versions of the | |||
protocol: | protocol: | |||
http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/ | http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/ | |||
RFC EDITOR: END PLEASE REMOVE ENTIRE SECTION BEFORE PUBLISHING | RFC EDITOR: END PLEASE REMOVE ENTIRE SECTION BEFORE PUBLISHING | |||
14. References | 15. References | |||
14.1. Normative References | 15.1. Normative References | |||
[RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., | [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., | |||
Beame, C., Eisler, M., and D. Noveck, "NFS version 4 | Beame, C., Eisler, M., and D. Noveck, "NFS version 4 | |||
Protocol", RFC 3010, December 2000. | Protocol", RFC 3010, December 2000. | |||
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) | [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) | |||
Protocol Architecture", RFC 4251, January 2006. | Protocol Architecture", RFC 4251, January 2006. | |||
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) | [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) | |||
Transport Layer Protocol", RFC 4253, January 2006. | Transport Layer Protocol", RFC 4253, January 2006. | |||
[RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) | [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) | |||
Connection Protocol", RFC 4254, January 2006. | Connection Protocol", RFC 4254, January 2006. | |||
[IEEE.1003-1.1996] | [IEEE.1003-1.1996] | |||
Institute of Electrical and Electronics Engineers, | Institute of Electrical and Electronics Engineers, | |||
"Information Technology - Portable Operating System | "Information Technology - Portable Operating System | |||
Interface (POSIX) - Part 1: System Application Program | Interface (POSIX) - Part 1: System Application Program | |||
Interface (API) [C Language]", IEEE Standard 1003.2, 1996. | Interface (API) [C Language]", IEEE Standard 1003.2, 1996. | |||
14.2. Informative References | 15.2. Informative References | |||
[RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet | [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet | |||
Mail Extensions) Part One: Mechanisms for Specifying and | Mail Extensions) Part One: Mechanisms for Specifying and | |||
Describing the Format of Internet Message Bodies", | Describing the Format of Internet Message Bodies", | |||
RFC 1521, September 1993. | RFC 1521, September 1993. | |||
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", | [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", | |||
RFC 2246, January 1999. | RFC 2246, January 1999. | |||
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and | [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and | |||
End of changes. 12 change blocks. | ||||
17 lines changed or deleted | 31 lines changed or added | |||
This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |