< draft-ietf-cat-ftpdsaauth-00.txt		draft-ietf-cat-ftpdsaauth-01.txt >
	CAT Working Group Russell Housley (SPYRUS)		CAT Working Group Russell Housley (SPYRUS)
	<draft-ietf-cat-ftpdsaauth-00.txt> William A. Nace (NSA)		<draft-ietf-cat-ftpdsaauth-01.txt> William A. Nace (NSA)
	Updates: RFC 959 Peter Yee (SPYRUS)		Updates: RFC 959 Peter Yee (SPYRUS)
	Internet-Draft Expire in six months		Internet-Draft Expire in six months
	July 1997		February 1998
	FTP Authentication Using DSA		FTP Authentication Using DSA
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working doc-		This document is an Internet-Draft. Internet-Drafts are working
	uments of the Internet Engineering Task Force (IETF), its areas, and		documents of the Internet Engineering Task Force (IETF), its areas,
	its working groups. Note that other groups may also distribute work-		and its working groups. Note that other groups may also distribute
	ing documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are Draft documents valid for a maximum of six months		Internet-Drafts are Draft documents valid for a maximum of six months
	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 mate-		time. It is inappropriate to use Internet-Drafts as reference
	rial or to cite them other than as ''work in progress.''		material or to cite them other than as ''work in progress.''
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, please check the
	"1id-abstRacts.txt" listing contained in the Internet-Drafts Shadow		"1id-abstRacts.txt" listing contained in the Internet-Drafts Shadow
	Directories on ds.internic.net (US East Coast), nic.nordu.net		Directories on ds.internic.net (US East Coast), nic.nordu.net
	Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).		Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
	Distribution of this memo is unlimited. Please send comments to the		Distribution of this memo is unlimited. Please send comments to the
	<cat-ietf@mit.edu> mailing list.		<cat-ietf@mit.edu> mailing list.
	Abstract		Abstract
	This document defines a method to secure file transfers using the FTP		This document defines a method to secure file transfers using the FTP
	specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985)		specification RFC 959, ''FILE TRANSFER PROTOCOL (FTP)'' (October 1985)
	and the work in progress document "FTP Security Extensions" <Draft-		and the work in progress document ''FTP Security Extensions'' <Draft-
	ietf-cat-ftpsec-09.txt>[1]. This method will use the extensions pro-		ietf-cat-ftpsec-09.txt>[1]. This method will use the extensions
	posed in the "FTP Security Extensions" Draft document along with a		proposed in the ''FTP Security Extensions'' Draft document along with a
	public/private digital signature.		public/private digital signature.
	1 Introduction		1 Introduction
	The File Transfer Protocol (FTP) provides no protocol security except		The File Transfer Protocol (FTP) provides no protocol security except
	for a user authentication password which is transmitted in the clear.		for a user authentication password which is transmitted in the clear.
	In addition, the protocol does not protect the file transfer session		In addition, the protocol does not protect the file transfer session
	beyond the original authentication phase.		beyond the original authentication phase.
	The Internet Engineering Task Force (IETF) Common Authentication		The Internet Engineering Task Force (IETF) Common Authentication
	Technology (CAT) Working Group has specified security extensions to		Technology (CAT) Working Group has specified security extensions to
	FTP. These extensions allow the protocol to use more flexible secu-		FTP. These extensions allow the protocol to use more flexible
	rity schemes, and in particular allows for various levels of protec-		security schemes, and in particular allows for various levels of
	tion for the FTP command and data connections. This document		protection for the FTP command and data connections. This document
	describes a profile for the FTP Security Extensions by which these		describes a profile for the FTP Security Extensions by which these
	mechanisms may be provisioned using the DSA[2] and SHA-1[3] algo-		mechanisms may be provisioned using the DSA[2] and SHA-1[3]
	rithms. The FTP Security Extensions do not attempt to provide for		algorithms. The FTP Security Extensions do not attempt to provide
	security when FTP is used in proxy mode. The profile proposed in		for security when FTP is used in proxy mode. The profile proposed in
	this document does not remove this limitation.		this document does not remove this limitation.
	2 FTP Security Extensions		2 FTP Security Extensions
	The IETF CAT Working Group has produced an Internet Draft that seeks		The IETF CAT Working Group has produced an Internet Draft that seeks
	to improve the security of FTP. This Internet Draft is likely to		to improve the security of FTP. This Internet Draft is likely to
	become a standards track RFC in 1997. It provides:		become a standards track RFC in 1997. It provides:
	* user authentication -- augmenting the normal password mechanism;		* user authentication -- augmenting the normal password mechanism;
	* server authentication -- normally done in conjunction with user		* server authentication -- done in conjunction with user
	authentication;		authentication or authenticates the server to an anonymous user;
	* session parameter negotiation -- in particular, encryption keys		* session parameter negotiation -- in particular, encryption keys
	and attributes;		and attributes;
	* command connection protection -- integrity, confidentiality, or		* command connection protection -- integrity, confidentiality, or
	both;		both;
	* data transfer protection -- same as for command connection		* data transfer protection -- same as for command connection
	protection.		protection.
	In order to support the above security services, the two FTP entities		In order to support the above security services, the two FTP entities
	negotiate a mechanism. This process is open-ended and completes when		negotiate a mechanism. This process is open-ended and completes when
	both entities agree on an acceptable mechanism or when the initiating		both entities agree on an acceptable mechanism or when the initiating
	party (always the client) is unable to suggest an agreeable mecha-		party (always the client) is unable to suggest an agreeable
	nism. Once the entities agree upon a mechanism, they may commence		mechanism. Once the entities agree upon a mechanism, they may
	authentication and/or parameter negotiation.		commence authentication and/or parameter negotiation.
	Authentication and parameter negotiation occur within an unbounded		Authentication and parameter negotiation occur within an unbounded
	series of exchanges. At the completion of the exchanges, the enti-		series of exchanges. At the completion of the exchanges, the
	ties will either be authenticated (unilateral or mutually), and may		entities will either be authenticated (unilateral or mutually), and
	be ready to protect FTP commands and data.		may be ready to protect FTP commands and data.
	Following the exchanges, the entities negotiate the size of the		Following the exchanges, the entities negotiate the size of the
	buffers they will use in protecting the commands and data that fol-		buffers they will use in protecting the commands and data that
	low. This process is accomplished in two steps: the client offers a		follow. This process is accomplished in two steps: the client offers
	suggested buffer size and the server may either refuse it, counter		a suggested buffer size and the server may either refuse it, counter
	it, or accept it.		it, or accept it.
	At this point, the entities may issue protected commands within the		At this point, the entities may issue protected commands within the
	bounds of the parameters negotiated through the security exchanges.		bounds of the parameters negotiated through the security exchanges.
	Protected commands are issued by applying the protection services		Protected commands are issued by applying the protection services
	required to the normal commands and Base64 encoding the results. The		required to the normal commands and Base64 encoding the results. The
	encoded results are sent as the data field within a MIC (integrity).		encoded results are sent as the data field within a MIC (integrity).
	Base64 is an encoding for mapping binary data onto a textual charac-		Base64 is an encoding for mapping binary data onto a textual
	ter set that is able to pass through 7-bit systems without loss. The		character set that is able to pass through 7-bit systems without
	server sends back responses in new result codes which allow the iden-		loss. The server sends back responses in new result codes which
	tical protections and Base64 encoding to be applied to the results.		allow the identical protections and Base64 encoding to be applied to
	Protection of the data transfers can be specified via the PROT com-		the results. Protection of the data transfers can be specified via
	mand which supports the same protections as those afforded the other		the PROT command which supports the same protections as those
	FTP commands. PROT commands may be sent on a transfer-by-transfer		afforded the other FTP commands. PROT commands may be sent on a
	basis, however, the session parameters may not be changed within a		transfer-by-transfer basis; however, the session parameters, such as
	session.		PBSZ, may not be changed without sending another AUTH command. Be
			aware that support for subsequent AUTH commands may not be permitted
			by all implementations.
	3 Use of Digital Signature Algorithm (DSA)		3 Use of Digital Signature Algorithm (DSA)
	This paper a profile in which DSA may be used to achieve certain		This paper a profile in which DSA may be used to achieve certain
	security services when used in conjunction with the FTP Security		security services when used in conjunction with the FTP Security
	Extensions framework. As stated above, the reader should be familiar		Extensions framework. As stated above, the reader should be familiar
	with the extensions in order to understand the protocol steps that		with the extensions in order to understand the protocol steps that
	follow. In the context of the FTP Security Extensions, we use DSA		follow. In the context of the FTP Security Extensions, we use DSA
	with SHA-1 for authentication and integrity.		with SHA-1 for authentication and integrity.
	3.1 DSA Profile		3.1 DSA Profile
	FTP entities may use DSA to give either unilateral or mutual authen-		FTP entities may use DSA to give either unilateral or mutual
	tication as well as to provide integrity services for commands and		authentication as well as to provide integrity services for commands
	data transfers. This specification follows the tokens and exchanges		and data transfers. This specification follows the tokens and
	defined in FIPS PUB 196[4], including Appendix A on ASN.1 encoding of		exchanges defined in FIPS PUB 196[4], including Appendix A on ASN.1
	messages and tokens.		encoding of messages and tokens.
	3.1.1 Unilateral Authentication with DSA		3.1.1 Unilateral Authentication with DSA
	A client may unilaterally authenticate its identity to a server.		A client may unilaterally authenticate its identity to a server.
	What follows are the protocol steps necessary to perform DSA authen-		What follows are the protocol steps necessary to perform DSA
	tication as specified in FIPS PUB 196 under the FTP Security Exten-		authentication as specified in FIPS PUB 196 under the FTP Security
	sions framework. Where failure modes are encountered, the return		Extensions framework. Where failure modes are encountered, the
	codes follow those specified in the Extensions. They are not enumer-		return codes follow those specified in the Extensions. They are not
	ated here as they are invariant among mechanisms. FIPS PUB 196		enumerated here as they are invariant among mechanisms. FIPS PUB 196
	employs a set of exchanges which are transferred to provide authenti-		employs a set of exchanges which are transferred to provide
	cation. Each exchange employs various fields and tokens, some of		authentication. Each exchange employs various fields and tokens,
	which are optional. In addition, each token has several subfields		some of which are optional. In addition, each token has several
	that are optional. A conformant subset of the fields and subfields		subfields that are optional. A conformant subset of the fields and
	for use with FTP have been selected. Therefore, the exchanges below		subfields for use with FTP have been selected. Therefore, the
	do not show the FIPS PUB 196 notation indicating optional fields,		exchanges below do not show the FIPS PUB 196 notation indicating
	while only the mandatory subfields are allowed. The tokens are ASN.1		optional fields, while only the mandatory subfields are allowed. The
	encoded per Appendix A of FIPS PUB 196, and each token is named to		tokens are ASN.1 encoded per Appendix A of FIPS PUB 196, and each
	indicate the direction in which it flows (i.e., TokenBA flows from		token is named to indicate the direction in which it flows (i.e.,
	Party B to Party A). In Figure 1, the client binds the last trans-		TokenBA flows from Party B to Party A). In Figure 1, the client
	mission (token identifier, certificate, and token) together as an		binds the last transmission (token identifier, certificate, and
	ASN.1 sequence.		token) together as an ASN.1 sequence.
	The exchanges detailed below presume a knowledge of FIPS PUB 196 and		The exchanges detailed below presume a knowledge of FIPS PUB 196 and
	the FTP Security Extensions. The client is Party A, while the server		the FTP Security Extensions. The client is Party A, while the server
	is Party B. The notation for concatenation is " || ". The pseudo-		is Party B. The notation for concatenation is " || ". The pseudo-
	function Sequence is used to indicate that its parameters are to be		function Sequence is used to indicate that its parameters are to be
	joined as an ASN.1 SEQUENCE. Verification of signed data, and in		joined as an ASN.1 SEQUENCE. Verification of signed data, and in
	particular certification path verification is implicitly assumed, but		particular certification path verification is implicitly assumed, but
	is not shown.		is not shown.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 40 ¶
	<-- 234		<-- 234
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Figure 1		Figure 1
	With this example, the client is now authenticated to the server.		With this example, the client is now authenticated to the server.
	Additional functionality available to client and server includes the		Additional functionality available to client and server includes the
	use of MIC protected commands and the ability to send signed data.		use of MIC protected commands and the ability to send signed data.
	The Sign function used in the figures below appends a nonce to the		The Sign function used in the figures below appends a nonce to the
	end of the parameter, and then computes a DSA with SHA-1 signature		end of the parameter, and then computes a DSA with SHA-1 signature
	over the parameter followed by a nonce. The 40 octet signature		over the parameter followed by a nonce. The 40 octet signature
	value, as described in FIPS PUB 186, is composed of two 20 octet val-		value, as described in FIPS PUB 186, is composed of two 20 octet
	ues, r followed by s. The nonce is comprised of a two octet command		values, r followed by s. The nonce is comprised of a two octet
	counter and the Ra value from TokenAB. Since both the client and		command counter and the Ra value from TokenAB. Since both the client
	server have the Ra value from TokenAB and both can calculate the com-		and server have the Ra value from TokenAB and both can calculate the
	mand counter, the nonce is not transmitted. The command counter is		command counter, the nonce is not transmitted. The command counter
	initialized to the least significant two octets of the Ra value from		is initialized to the least significant two octets of the Ra value
	TokenAB, and it is incremented each time the client issues a command.		from TokenAB, and it is incremented each time the client issues a
	The Sign function output is composed of the 40 octet signature value		command. The Sign function output is composed of the 40 octet
	followed by the parameter. An example follows:		signature value followed by the parameter. An example follows:
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Client Server		Client Server
	MIC Base64(Sign("PBSZ 65535")) -->		MIC Base64(Sign("PBSZ 65535")) -->
	<-- 200 PBSZ=32767		<-- 200 PBSZ=32767
	MIC Base64(Sign("USER yee")) -->		MIC Base64(Sign("USER yee")) -->
	<-- 331		<-- 331
	MIC Base64(Sign("PASS fortezza")) -->		MIC Base64(Sign("PASS fortezza")) -->
	<-- 230		<-- 230
	MIC Base64(Sign("PROT S")) -->		MIC Base64(Sign("PROT S")) -->
	<-- 200		<-- 200
	MIC Base64(Sign("STOR foo.bar")) -->		MIC Base64(Sign("STOR foo.bar")) -->
	<-- 150		<-- 150
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Figure 2		Figure 2
	Data now flows from the client to the server as specified in the		Data now flows from the client to the server as specified in the
	Extensions. Specifically, the file is broken up into blocks of data		Extensions. Specifically, the file is broken up into blocks of data
	of less than the negotiated protection buffer size (32768 bytes in		of less than the negotiated protection buffer size (32767 bytes in
	the example exchanges). Each protection buffer contains a safe token		the example exchanges). Each protection buffer contains a safe token
	followed by file data. A common safe token structure is used for		followed by file data. A common safe token structure is used for
	unilateral and mutual authentication. The safe token structure is		unilateral and mutual authentication. The safe token structure is
	described in section 3.1.3.		described in section 3.1.3.
	3.1.2 Mutual Authentication with DSA		3.1.2 Mutual Authentication with DSA
	The PDU flow for mutual authentication is slightly more complex, as		The PDU flow for mutual authentication is slightly more complex, as
	shown:		shown:
	skipping to change at page 5, line 50 ¶		skipping to change at page 5, line 50 ¶
	ADAT Base64(Sequence(TokenID ||		ADAT Base64(Sequence(TokenID ||
	CertA || TokenAB ||		CertA || TokenAB ||
	absigValue)) -->		absigValue)) -->
	<-- 235 ADAT=Base64(Sequence(		<-- 235 ADAT=Base64(Sequence(
	TokenID || CertB ||		TokenID || CertB ||
	TokenBA2 || ba2sigValue))		TokenBA2 || ba2sigValue))
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Figure 3		Figure 3
	Data retrieval and other FTP operations can now be performed with		Data retrieval and other FTP operations can now be performed with
	signature protection. As before, the FTP entities negotiate a pro-		signature protection. As before, the FTP entities negotiate a
	tection buffer size. Likewise, a two octet command counter combined		protection buffer size. Likewise, a two octet command counter
	with the Ra value from TokenAB is used as a nonce in the Sign		combined with the Ra value from TokenAB is used as a nonce in the
	function.		Sign function.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Client Server		Client Server
	MIC Base64(Sign("PBSZ 65535")) -->		MIC Base64(Sign("PBSZ 65535")) -->
	<-- 631 Base64(Sign		<-- 631 Base64(Sign
	("200 PBSZ=32767"))		("200 PBSZ=32767"))
	MIC Base64(Sign("USER yee")) -->		MIC Base64(Sign("USER yee")) -->
	<-- 631 Base64(Sign("331"))		<-- 631 Base64(Sign("331"))
	MIC Base64(Sign("PASS fortezza")) -->		MIC Base64(Sign("PASS fortezza")) -->
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 4 ¶
	Figure 5		Figure 5
	The safe token is comprised of the signature value, buffer size,		The safe token is comprised of the signature value, buffer size,
	nonce, file count, and buffer count. The signature covers the buffer		nonce, file count, and buffer count. The signature covers the buffer
	size, nonce, file count, buffer count, and the file data buffer.		size, nonce, file count, buffer count, and the file data buffer.
	Buffer size is the number of octets contained in file data buffer.		Buffer size is the number of octets contained in file data buffer.
	This buffer size must be less than the negotiated PBSZ value, and the		This buffer size must be less than the negotiated PBSZ value, and the
	maximum buffer size is PBSZ minus 58. If the buffer size is not		maximum buffer size is PBSZ minus 58. If the buffer size is not
	equal to PBSZ minus 58, then this buffer is the final buffer of the		equal to PBSZ minus 58, then this buffer is the final buffer of the
	file. If the file ends on a full buffer boundary, a buffer with the		file. If the file ends on a full buffer boundary, a buffer with the
	buffer size set to zero will be sent. The nonce is the least signif-		buffer size set to zero will be sent. The nonce is the least
	icant 64 bits of the Rb field of TokenBA1. File count is a sequence		significant 64 bits of the Rb field of TokenBA1. File count is a
	counter of protected files transferred, starting at zero. Buffer		sequence counter of protected files transferred, starting at zero.
	count is the number of protected buffers sent for this file, starting		Buffer count is the number of protected buffers sent for this file,
	at zero.		starting at zero.
	4.0 Security Considerations		4.0 Security Considerations
	This entire memo is about security mechanisms. For DSA to provide		This entire memo is about security mechanisms. For DSA to provide
	the authentication discussed, the implementation must protect the		the authentication discussed, the implementation must protect the
	private key from disclosure.		private key from disclosure.
	5.0 Acknowledgements		5.0 Acknowledgements
	I would like to thank Todd Horting for insights gained during imple-		I would like to thank Todd Horting for insights gained during
	mentation of this specification.		implementation of this specification.
	6.0 References		6.0 References
	[1] - M. Horowitz and S. J. Lunt. FTP Security Extensions.		[1] - M. Horowitz and S. J. Lunt. FTP Security Extensions.
	Internet-Draft <draft-ietf-cat-ftpsec-09.txt>,		Internet-Draft <draft-ietf-cat-ftpsec-09.txt>,
	November, 1996.		November, 1996.
	[2] - Digital Signature Standard (DSS). FIPS Pub 186.		[2] - Digital Signature Standard (DSS). FIPS Pub 186.
	May 19, 1994.		May 19, 1994.
End of changes. 19 change blocks.
	81 lines changed or deleted		83 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/