< draft-ietf-cat-ftpkeasj-00.txt		draft-ietf-cat-ftpkeasj-01.txt >
	CAT Working Group Russell Housley (SPYRUS)		CAT Working Group Russell Housley (SPYRUS)
	<draft-ietf-cat-ftpkeasj-00.txt> William A. Nace (NSA)		<draft-ietf-cat-ftpkeasj-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
	July 1997		Expire in six months January 1999
	Encryption using KEA and SKIPJACK		Encryption using KEA and SKIPJACK
	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 encrypt a file transfer using the		This document defines a method to encrypt a file transfer using the
	FTP specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October		FTP specification RFC 959, 'FILE TRANSFER PROTOCOL (FTP)' (October
	1985) and the work in progress document "FTP Security Extensions"		1985) and the work in progress document 'FTP Security Extensions'
	<draft-ietf-cat-ftpsec-09.txt>[1]. This method will use the Key		<draft-ietf-cat-ftpsec-09.txt>[1]. This method will use the Key
	Exchange Algorithm (KEA) to give mutual authentication and establish		Exchange Algorithm (KEA) to give mutual authentication and establish
	the data encryption keys. SKIPJACK is used to encrypt file data and		the data encryption keys. SKIPJACK is used to encrypt file data and
	the FTP command channel.		the FTP command channel.
	1.0 Introduction		1.0 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 proposed security extensions to		Technology (CAT) Working Group has proposed 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 Key Exchange Algorithm (KEA)		mechanisms may be provisioned using the Key Exchange Algorithm (KEA)
	in conjunction with the SKIPJACK symmetric encryption algorithm.		in conjunction with the SKIPJACK symmetric encryption algorithm.
	The FTP Security Extensions are likely to become a standards track		The FTP Security Extensions are likely to become a standards track
	RFC in 1997. It provides:		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 -- normally done in conjunction with user
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	* 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
	additionally, be ready to protect FTP commands and data.		may, additionally, 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 ENC (integrity		encoded results are sent as the data field within a ENC (integrity
	and confidentiality) command. Base64 is an encoding for mapping		and confidentiality) command. Base64 is an encoding for mapping
	binary data onto a textual character set that is able to pass through		binary data onto a textual character set that is able to pass through
	most 7-bit systems without loss. The server sends back responses in		most 7-bit systems without loss. The server sends back responses in
	new result codes which allow the identical protections and Base64		new result codes which allow the identical protections and Base64
	encoding to be applied to the results. Protection of the data trans-		encoding to be applied to the results. Protection of the data
	fers can be specified via the PROT command which supports the same		transfers can be specified via the PROT command which supports the
	protections as those afforded the other FTP commands. PROT commands		same protections as those afforded the other FTP commands. PROT
	may be sent on a transfer-by-transfer basis, however, the session		commands may be sent on a transfer-by-transfer basis, however, the
	parameters may not be changed within a session.		session parameters may not be changed within a session.
	2.0 Key Exchange Algorithm (KEA) Profile		2.0 Key Exchange Algorithm (KEA) Profile
	This paper profiles KEA with SKIPJACK to achieve certain security		This paper profiles KEA with SKIPJACK to achieve certain security
	services when used in conjunction with the FTP Security Extensions		services when used in conjunction with the FTP Security Extensions
	framework. FTP entities may use KEA to give mutual authentication		framework. FTP entities may use KEA to give mutual authentication
	and establish data encryption keys. We specify a simple token format		and establish data encryption keys. We specify a simple token format
	and set of exchanges to deliver these services. Functions that may		and set of exchanges to deliver these services. Functions that may
	be performed by the Fortezza Crypto Card.		be performed by the Fortezza Crypto Card.
	The reader should be familiar with the extensions in order to under-		The reader should be familiar with the extensions in order to
	stand the protocol steps that follow. In the context of the FTP		understand the protocol steps that follow. In the context of the FTP
	Security Extensions, we suggest the usage of KEA with SKIPJACK for		Security Extensions, we suggest the usage of KEA with SKIPJACK for
	authentication, integrity, and confidentiality.		authentication, integrity, and confidentiality.
	A client may mutually authenticate with a server. What follows are		A client may mutually authenticate with a server. What follows are
	the protocol steps necessary to perform KEA authentication under the		the protocol steps necessary to perform KEA authentication under the
	FTP Security Extensions framework. Where failure modes are encoun-		FTP Security Extensions framework. Where failure modes are
	tered, the return codes follow those specified in the Extensions.		encountered, the return codes follow those specified in the
	They are not enumerated in this document as they are invariant among		Extensions. They are not enumerated in this document as they are
	the mechanisms used. The certificates are ASN.1 encoded.		invariant among the mechanisms used. The certificates are ASN.1
			encoded.
	The exchanges detailed below presume a working knowledge of the FTP		The exchanges detailed below presume a working knowledge of the FTP
	Security Extensions. The notation for concatenation is " || ".		Security Extensions. The notation for concatenation is " || ".
	Decryption of encrypted data and certification path validation is		Decryption of encrypted data and certification path validation is
	implicitly assumed, but is not shown.		implicitly assumed, but is not shown.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Client Server		Client Server
	AUTH KEA-SKIPJACK -->		AUTH KEA-SKIPJACK -->
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 29 ¶
	In order to ensure that the length of the plain text is a multiple of		In order to ensure that the length of the plain text is a multiple of
	the cryptographic block size, padding shall be performed as follows.		the cryptographic block size, padding shall be performed as follows.
	The input to the SKIPJACK CBC encryption process shall be padded to a		The input to the SKIPJACK CBC encryption process shall be padded to a
	multiple of 8 octets. Let n be the length in octets of the input.		multiple of 8 octets. Let n be the length in octets of the input.
	Pad the input by appending 8 - (n mod 8) octets to the end of the		Pad the input by appending 8 - (n mod 8) octets to the end of the
	message, each having the value 8 - (n mod 8), the number of octets		message, each having the value 8 - (n mod 8), the number of octets
	being added. In hexadecimal, he possible pad strings are: 01, 0202,		being added. In hexadecimal, he possible pad strings are: 01, 0202,
	030303, 04040404, 0505050505, 060606060606, 07070707070707, and		030303, 04040404, 0505050505, 060606060606, 07070707070707, and
	0808080808080808. All input is padded with 1 to 8 octets to produce		0808080808080808. All input is padded with 1 to 8 octets to produce
	a multiple of 8 octets in length. This pad technique is used when-		a multiple of 8 octets in length. This pad technique is used
	ever SKIPJACK CBC encryption is performed.		whenever SKIPJACK CBC encryption is performed.
	An ICV is calculated over the plaintext security label and padding.		An ICV is calculated over the plaintext security label and padding.
	The ICV algorithm used is the 32-bit one's complement addition of		The ICV algorithm used is the 32-bit one's complement addition of
	each 32-bit block followed by 32 zero bits. This ICV technique is		each 32-bit block followed by 32 zero bits. This ICV technique is
	used in conjunction with SKIPJACK CBC encryption to provide data		used in conjunction with SKIPJACK CBC encryption to provide data
	integrity.		integrity.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Label Type 1 Octet		Label Type 1 Octet
	Label Length 4 octets		Label Length 4 octets
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 19 ¶
	2-255 Reserved for Future Use To Be Determined		2-255 Reserved for Future Use To Be Determined
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Figure 3		Figure 3
	FTP command channel operations are now confidentiality protected. To		FTP command channel operations are now confidentiality protected. To
	provide integrity, the command sequence number, padding, and ICV are		provide integrity, the command sequence number, padding, and ICV are
	appended to each command prior to encryption.		appended to each command prior to encryption.
	Sequence integrity is provided by using a 16-bit sequence number		Sequence integrity is provided by using a 16-bit sequence number
	which is incremented for each command. The sequence number is ini-		which is incremented for each command. The sequence number is
	tialized with the least significant 16-bits of Ra. The server		initialized with the least significant 16-bits of Ra. The server
	response will include the same sequence number as the client command.		response will include the same sequence number as the client command.
	An ICV is calculated over the individual commands (including the car-		An ICV is calculated over the individual commands (including the
	riage return and line feed required to terminate commands), the		carriage return and line feed required to terminate commands), the
	sequence number, and pad.		sequence number, and pad.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Client Server		Client Server
	ENC Base64(Encrypt("PBSZ 65535"		ENC Base64(Encrypt("PBSZ 65535"
	|| SEQ || pad || ICV )) -->		|| SEQ || pad || ICV )) -->
	<-- 632 Base64(Encrypt("200" ||		<-- 632 Base64(Encrypt("200" ||
	SEQ || pad || ICV))		SEQ || pad || ICV))
	ENC Base64(Encrypt("USER yee"		ENC Base64(Encrypt("USER yee"
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 48 ¶
	ENC Base64(Encrypt("PASS		ENC Base64(Encrypt("PASS
	fortezza" || SEQ ||		fortezza" || SEQ ||
	pad || ICV)) -->		pad || ICV)) -->
	<-- 631 Base64(Sign("230"))		<-- 631 Base64(Sign("230"))
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Figure 4		Figure 4
	After decryption, both parties verifying the integrity of the PBSZ		After decryption, both parties verifying the integrity of the PBSZ
	commands by checking for the expected sequence number and correct		commands by checking for the expected sequence number and correct
	ICV. The correct SKIPJACK key calculation, ICV checking, and the		ICV. The correct SKIPJACK key calculation, ICV checking, and the
	validation of the certificates containing the KEA public keys pro-		validation of the certificates containing the KEA public keys
	vides mutual identification and authentication.		provides mutual identification and authentication.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Client Server		Client Server
	ENC Base64(Encrypt("PROT P" ||		ENC Base64(Encrypt("PROT P" ||
	SEQ || pad || ICV)) -->		SEQ || pad || ICV)) -->
	<-- 632 Base64(Encrypt("200" || SEQ		<-- 632 Base64(Encrypt("200" || SEQ
	|| pad || ICV))		|| pad || ICV))
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Figure 5		Figure 5
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 4 ¶
	Pad 1 to 8 octets		Pad 1 to 8 octets
	ICV 8 octets		ICV 8 octets
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Figure 7		Figure 7
	2.1 Pre-encrypted File Support		2.1 Pre-encrypted File Support
	In order to support both on-the-fly encryption and pre-encrypted		In order to support both on-the-fly encryption and pre-encrypted
	files, a token is defined for carrying a file encryption key (FEK).		files, a token is defined for carrying a file encryption key (FEK).
	To prevent truncation and ensure file integrity, the token also		To prevent truncation and ensure file integrity, the token also
	includes a hash computed on the complete file. The token also con-		includes a hash computed on the complete file. The token also
	tains the security label associate with the file. This FEK is		contains the security label associate with the file. This FEK is
	wrapped in the session TEK. The token is encrypted in the session		wrapped in the session TEK. The token is encrypted in the session
	TEK using SKIPJACK CBC mode. The token contains a 12 octet wrapped		TEK using SKIPJACK CBC mode. The token contains a 12 octet wrapped
	FEK, a 20 octet file hash, a 24 octet file IV, a 1 octet label type,		FEK, a 20 octet file hash, a 24 octet file IV, a 1 octet label type,
	a 4 octet label length, a variable length label value, a one to 8		a 4 octet label length, a variable length label value, a one to 8
	octet pad, and an 8 octet ICV. The first 24 octets of the token are		octet pad, and an 8 octet ICV. The first 24 octets of the token are
	the plaintext IV used to encrypt the remainder of the token. The		the plaintext IV used to encrypt the remainder of the token. The
	token requires its own encryption IV because it is transmitted across		token requires its own encryption IV because it is transmitted across
	the data channel, not the command channel, and ordering between the		the data channel, not the command channel, and ordering between the
	channels cannot be guaranteed. Storage of precomputed keys and		channels cannot be guaranteed. Storage of precomputed keys and
	hashes for files in the file system is a local implementation matter;		hashes for files in the file system is a local implementation matter;
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 36 ¶
	Label Type 1 octet		Label Type 1 octet
	Label Length 4 octets		Label Length 4 octets
	Label Label Length octets		Label Label Length octets
	Pad 1 to 8 octets		Pad 1 to 8 octets
	ICV 8 octets		ICV 8 octets
	----------------------------------------------------------------------		----------------------------------------------------------------------
	Figure 8		Figure 8
	3.0 Table of Key Terminology		3.0 Table of Key Terminology
	In order to clarify the usage of various keys in this protocol, Fig-		In order to clarify the usage of various keys in this protocol,
	ure 9 summarizes key types and their usage:		Figure 9 summarizes key types and their usage:
	----------------------------------------------------------------------		----------------------------------------------------------------------
	Key Type Usage		Key Type Usage
	TEK Encryption of token at the beginning of each		TEK Encryption of token at the beginning of each
	file, also wraps the MEK		file, also wraps the MEK
	MEK Encryption of command channel		MEK Encryption of command channel
	FEK Encryption of the file itself (may be done out		FEK Encryption of the file itself (may be done out
	of scope of FTP)		of scope of FTP)
	----------------------------------------------------------------------		----------------------------------------------------------------------
	Figure 9		Figure 9
	4.0 Security Considerations		4.0 Security Considerations
	This entire memo is about security mechanisms. For KEA to provide		This entire memo is about security mechanisms. For KEA to provide
	the authentication and key management discussed, the implementation		the authentication and key management discussed, the implementation
	must protect the private key from disclosure. For SKIPJACK to pro-		must protect the private key from disclosure. For SKIPJACK to
	vide the confidentiality discussed, the implementation must protect		provide the confidentiality discussed, the implementation must
	the shared symmetric keys from disclosure.		protect the shared symmetric keys 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>,		RFC 2228. October 1997.
	November, 1996.
	[2] - Message Security Protocol 4.0 (MSP), Revision A. Secure Data		[2] - Message Security Protocol 4.0 (MSP), Revision A. Secure Data
	Network System (SDNS) Specification, SDN.701,		Network System (SDNS) Specification, SDN.701,
	February 6, 1997.		February 6, 1997.
	7.0 Author's Address		7.0 Author's Address
	Russell Housley		Russell Housley
	SPYRUS		SPYRUS
	PO Box 1198		381 Elden Street
	Herndon, VA 20172		Suite 1120
			Herndon, VA 20170
	USA		USA
	Phone: +1 703 435-7344		Phone: +1 703 707-0696
	Email: housley@spyrus.com		Email: housley@spyrus.com
	DIRNSA		DIRNSA
	Attn: X22 (W. Nace)		Attn: X22 (W. Nace)
	9800 Savage Road		9800 Savage Road
	Fort Meade, MD 20755-6000		Fort Meade, MD 20755-6000
	USA		USA
	Phone: +1 410 859-4464		Phone: +1 410 859-4464
	Email: WANace@missi.ncsc.mil		Email: WANace@missi.ncsc.mil
	Peter Yee		Peter Yee
	SPYRUS		SPYRUS
	2460 N. First Street		5303 Betsy Ross Drive
	Suite 100		Santa Clara, CA 95054
	San Jose, CA 95131-1023
	USA		USA
	Phone: +1 408 432-8180		Phone: +1 408 327-1901
	Email: yee@spyrus.com		Email: yee@spyrus.com
End of changes. 25 change blocks.
	60 lines changed or deleted		60 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/