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/