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/