< draft-ietf-ipsec-ciph-cbc-02.txt		draft-ietf-ipsec-ciph-cbc-03.txt >
	Internet Engineering Task Force R. Pereira		Internet Engineering Task Force R. Pereira
	IP Security Working Group TimeStep Corporation		IP Security Working Group TimeStep Corporation
	Internet Draft R. Adams		Internet Draft R. Adams
	Expires in six months Cisco Systems Inc.		Expires in six months Cisco Systems Inc.
	March 10, 1998		September 4, 1998
	The ESP CBC-Mode Cipher Algorithms		The ESP CBC-Mode Cipher Algorithms
	<draft-ietf-ipsec-ciph-cbc-02.txt>		<draft-ietf-ipsec-ciph-cbc-03.txt>
	Status of this Memo		Status of this Memo
	This document is a submission to the IETF Internet Protocol		This document is a submission to the IETF Internet Protocol
	Security (IPSEC) Working Group. Comments are solicited and should		Security (IPSEC) Working Group. Comments are solicited and should
	be addressed to the working group mailing list (ipsec@tis.com) or		be addressed to the working group mailing list (ipsec@tis.com) or
	to the editor.		to the editor.
	This document is an Internet-Draft. Internet Drafts are working		This document is an Internet-Draft. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	skipping to change at page 2, line 5 ¶		skipping to change at page 2, line 5 ¶
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	Abstract		Abstract
	This document describes how to use CBC-mode cipher algorithms with		This document describes how to use CBC-mode cipher algorithms with
	the IPSec ESP (Encapsulating Security Payload) Protocol. It not		the IPSec ESP (Encapsulating Security Payload) Protocol. It not
	only clearly states how to use certain cipher algorithms, but also		only clearly states how to use certain cipher algorithms, but also
	how to use all CBC-mode cipher algorithms.		how to use all CBC-mode cipher algorithms.
	Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98		Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98
	Table of Contents		Table of Contents
	1. Introduction...................................................2		1. Introduction...................................................2
	1.1 Specification of Requirements...............................2		1.1 Specification of Requirements...............................2
	2. Cipher Algorithms..............................................3		2. Cipher Algorithms..............................................3
	2.1 Mode........................................................3		2.1 Mode........................................................3
	2.2 Key Size....................................................3		2.2 Key Size....................................................3
	2.3 Weak Keys...................................................4		2.3 Weak Keys...................................................4
	2.4 Block Size and Padding......................................6		2.4 Block Size and Padding......................................6
	2.5 Rounds......................................................6		2.5 Rounds......................................................6
	2.6 Backgrounds.................................................6		2.6 Backgrounds.................................................6
	2.7 Performance.................................................9		2.7 Performance.................................................9
	3. ESP Payload...................................................10		3. ESP Payload....................................................9
	3.1 ESP Environmental Considerations...........................10		3.1 ESP Environmental Considerations............................9
	3.2 Keying Material............................................10		3.2 Keying Material............................................10
	4. Security Considerations.......................................11		4. Security Considerations.......................................10
	5. References....................................................11		5. References....................................................10
	6. Acknowledgments...............................................12		6. Acknowledgments...............................................12
	7. Editors' Addresses............................................13		7. Editors' Addresses............................................12
	1. Introduction		1. Introduction
	The Encapsulating Security Payload (ESP) [Kent98] provides		The Encapsulating Security Payload (ESP) [Kent98] provides
	confidentiality for IP datagrams by encrypting the payload data to		confidentiality for IP datagrams by encrypting the payload data to
	be protected. This specification describes the ESP use of CBC-mode		be protected. This specification describes the ESP use of CBC-mode
	cipher algorithms.		cipher algorithms.
	While this document does not describe the use of the default cipher		While this document does not describe the use of the default cipher
	algorithm DES, the reader should be familiar with that document.		algorithm DES, the reader should be familiar with that document.
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	Furthermore, this document is a companion to [Kent98] and MUST be		Furthermore, this document is a companion to [Kent98] and MUST be
	read in its context.		read in its context.
	1.1 Specification of Requirements		1.1 Specification of Requirements
	The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD		The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
	NOT", and "MAY" that appear in this document are to be interpreted		NOT", and "MAY" that appear in this document are to be interpreted
	as described in [Bradner97].		as described in [Bradner97].
	Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98		Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98
	2. Cipher Algorithms		2. Cipher Algorithms
	All symmetric block cipher algorithms share common characteristics		All symmetric block cipher algorithms share common characteristics
	and variables. These include mode, key size, weak keys, block		and variables. These include mode, key size, weak keys, block
	size, and rounds. All of which will be explained below.		size, and rounds. All of which will be explained below.
	While this document illustrates certain cipher algorithms such as		While this document illustrates certain cipher algorithms such as
	Blowfish [Schneier93], CAST-128 [Adams97], 3DES, IDEA [Lai], and		Blowfish [Schneier93], CAST-128 [Adams97], 3DES, IDEA [Lai] [MOV],
	RC5 [Baldwin96], any other block cipher algorithm may be used with		and RC5 [Baldwin96], any other block cipher algorithm may be used
	ESP if all of the variables described within this document are		with ESP if all of the variables described within this document are
	clearly defined.		clearly defined.
	2.1 Mode		2.1 Mode
	All symmetric block cipher algorithms described or insinuated		All symmetric block cipher algorithms described or insinuated
	within this document use Cipher Block Chaining (CBC) mode. This		within this document use Cipher Block Chaining (CBC) mode. This
	mode requires an Initialization Vector (IV) that is the same size		mode requires an Initialization Vector (IV) that is the same size
	as the block size. Use of a randomly generated IV prevents		as the block size. Use of a randomly generated IV prevents
	generation of identical ciphertext from packets which have		generation of identical ciphertext from packets which have
	identical data that spans the first block of the cipher algorithm's		identical data that spans the first block of the cipher algorithm's
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	harder to break than shorter ones.		harder to break than shorter ones.
	This document stipulates that all key sizes MUST be a multiple of 8		This document stipulates that all key sizes MUST be a multiple of 8
	bits.		bits.
	This document does specify the default key size for each cipher		This document does specify the default key size for each cipher
	algorithm. This size was chosen by consulting experts on the		algorithm. This size was chosen by consulting experts on the
	algorithm and by balancing strength of the algorithm with		algorithm and by balancing strength of the algorithm with
	performance.		performance.
	Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98		Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98
	+==============+==================+=================+==========+		+==============+==================+=================+==========+
	| Algorithm | Key Sizes (bits) | Popular Sizes | Default |		| Algorithm | Key Sizes (bits) | Popular Sizes | Default |
	+==============+==================+=================+==========+		+==============+==================+=================+==========+
	| CAST-128 [1] | 40 to 128 | 40, 64, 80, 128 | 128 |		| CAST-128 [1] | 40 to 128 | 40, 64, 80, 128 | 128 |
	+--------------+------------------+-----------------+----------+		+--------------+------------------+-----------------+----------+
	| RC5 | 40 to 2040 | 40, 128, 160 | 128 |		| RC5 | 40 to 2040 | 40, 128, 160 | 128 |
	+--------------+------------------+-----------------+----------+		+--------------+------------------+-----------------+----------+
	| IDEA | 128 | 128 | 128 |		| IDEA | 128 | 128 | 128 |
	+--------------+------------------+-----------------+----------+		+--------------+------------------+-----------------+----------+
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 33 ¶
	[1] With CAST-128, keys less than 128 bits MUST be padded with		[1] With CAST-128, keys less than 128 bits MUST be padded with
	zeros in the rightmost, or least significant, positions out to 128		zeros in the rightmost, or least significant, positions out to 128
	bits since the CAST-128 key schedule assumes an input key of 128		bits since the CAST-128 key schedule assumes an input key of 128
	bits. Thus if you had a key with a size of 80 bits '3B5D831CFE',		bits. Thus if you had a key with a size of 80 bits '3B5D831CFE',
	it would be padded to produce a key with a size of 128 bits		it would be padded to produce a key with a size of 128 bits
	'3B5D831CFE000000'.		'3B5D831CFE000000'.
	[2] The first 3DES key is taken from the first 64 bits, the second		[2] The first 3DES key is taken from the first 64 bits, the second
	from the next 64 bits, and the third from the last 64 bits.		from the next 64 bits, and the third from the last 64 bits.
	Implementations MUST take into consideration the parity bits when		Implementations MUST take into consideration the parity bits when
	initially accepting a new set of keys.		initially accepting a new set of keys. Each of the three keys is
			really 56 bits in length with the extra 8 bits used for parity.
	The reader should note that the minimum key size for all of the		The reader should note that the minimum key size for all of the
	above cipher algorithms is 40 bits, and that the authors strongly		above cipher algorithms is 40 bits, and that the authors strongly
	advise that implementations do NOT use key sizes smaller than 40		advise that implementations do NOT use key sizes smaller than 40
	bits.		bits.
	2.3 Weak Keys		2.3 Weak Keys
	Weak key checks SHOULD be performed. If such a key is found, the		Weak key checks SHOULD be performed. If such a key is found, the
	key SHOULD be rejected and a new SA requested. Some cipher		key SHOULD be rejected and a new SA requested. Some cipher
	algorithms have weak keys or keys that MUST not be used due to		algorithms have weak keys or keys that MUST not be used due to
	their weak nature.		their weak nature.
			New weak keys might be discovered, so this document does not in any
			way contain all possible weak keys for these ciphers. Please check
			with other sources of cryptography such as [MOV] and [Schneier] for
			further weak keys.
			Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98
	CAST-128:		CAST-128:
	No known weak keys.		No known weak keys.
	Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98
	RC5:		RC5:
	No known weak keys when used with 16 rounds.		No known weak keys when used with 16 rounds.
	IDEA:		IDEA:
	IDEA has weak keys of the following form [Crypto93]:		IDEA has been found to have weak keys. Please check with [MOV] and
			[Schneier] for more information.
	0000,0000,0x00,0000,0000,000x,xxxx,x000
	where "x" can be any hexadecimal number.
	Keys of this form guarantee the value of bit-wise XOR of resultant
	ciphertext pairs from the bit-wise XOR of certain plaintext pairs.
	Blowfish:		Blowfish:
	Weak keys for Blowfish have been discovered. Weak keys are keys		Weak keys for Blowfish have been discovered. Weak keys are keys
	that produce the identical entries in a given S-box.		that produce the identical entries in a given S-box.
	Unfortunately, there is no way to test for weak keys before the S-		Unfortunately, there is no way to test for weak keys before the S-
	box values are generated. However, the chances of randomly		box values are generated. However, the chances of randomly
	generating such a key are small.		generating such a key are small.
	3DES:		3DES:
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	For DES-EDE3, there is no known need to reject weak or		For DES-EDE3, there is no known need to reject weak or
	complementation keys. Any weakness is obviated by the use of		complementation keys. Any weakness is obviated by the use of
	multiple keys.		multiple keys.
	However, if the first two or last two independent 64-bit keys are		However, if the first two or last two independent 64-bit keys are
	equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the		equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the
	same as DES. Implementers MUST reject keys that exhibit this		same as DES. Implementers MUST reject keys that exhibit this
	property.		property.
	Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98		Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98
	2.4 Block Size and Padding		2.4 Block Size and Padding
	All of the algorithms described in this document use a block size		All of the algorithms described in this document use a block size
	of eight octets (64 bits).		of eight octets (64 bits).
	Padding is used to align the payload type and pad length octets as		Padding is used to align the payload type and pad length octets as
	specified in [Kent98]. Padding must be sufficient to align the		specified in [Kent98]. Padding must be sufficient to align the
	data to be encrypted to an eight octet (64 bit) boundary.		data to be encrypted to an eight octet (64 bit) boundary.
	skipping to change at page 6, line 30 ¶		skipping to change at page 6, line 30 ¶
	exist when it is not negotiated.		exist when it is not negotiated.
	+====================+============+======================+		+====================+============+======================+
	| Algorithm | Negotiable | Default Rounds |		| Algorithm | Negotiable | Default Rounds |
	+====================+============+======================+		+====================+============+======================+
	| CAST-128 | No | key<=80 bits, 12 |		| CAST-128 | No | key<=80 bits, 12 |
	| | | key>80 bits, 16 |		| | | key>80 bits, 16 |
	+--------------------+------------+----------------------+		+--------------------+------------+----------------------+
	| RC5 | No | 16 |		| RC5 | No | 16 |
	+--------------------+------------+----------------------+		+--------------------+------------+----------------------+
	| IDEA [1] | 4, 8 | 8 |		| IDEA | No | 8 |
	+--------------------+------------+----------------------+		+--------------------+------------+----------------------+
	| Blowfish | No | 16 |		| Blowfish | No | 16 |
	+--------------------+------------+----------------------+		+--------------------+------------+----------------------+
	| 3DES | No | 48 (16x3) |		| 3DES | No | 48 (16x3) |
	+--------------------+------------+----------------------+		+--------------------+------------+----------------------+
	Notes:
	[1] Although there are no known attacks against four round IDEA,
	those choosing to use four round IDEA for performance reasons may
	wish to use a shorter key lifetime (presumably via site specific
	policy).
	2.6 Backgrounds		2.6 Backgrounds
	CAST-128:		CAST-128:
	The CAST design procedure was originally developed by Carlisle		The CAST design procedure was originally developed by Carlisle
	Adams and Stafford Travares at Queen's University, Kingston,		Adams and Stafford Tavares at Queen's University, Kingston,
	Ontario, Canada. Subsequent enhancements have been made over the		Ontario, Canada. Subsequent enhancements have been made over the
	years by Carlisle Adams and Michael Wiener of Entrust Technologies.		years by Carlisle Adams and Michael Wiener of Entrust Technologies.
	CAST-128 is the result of applying the CAST Design Procedure as		CAST-128 is the result of applying the CAST Design Procedure as
	outlined in [Adams97].		outlined in [Adams97].
	Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98		Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98
	RC5:		RC5:
	The RC5 encryption algorithm was developed by Ron Rivest for RSA		The RC5 encryption algorithm was developed by Ron Rivest for RSA
	Data Security Inc. in order to address the need for a high-		Data Security Inc. in order to address the need for a high-
	performance software and hardware ciphering alternative to DES.		performance software and hardware ciphering alternative to DES. It
			is patented (pat.no. 5,724,428). A description of RC5 may be found
			in [MOV] and [Schneier].
	IDEA:		IDEA:
	Xuejia Lai and James Massey developed the IDEA (International Data		Xuejia Lai and James Massey developed the IDEA (International Data
	Encryption Algorithm) algorithm. The algorithm is described in		Encryption Algorithm) algorithm. The algorithm is described in
	detail in [Lai] and [Schneier].		detail in [Lai], [Schneier] and [MOV].
	The IDEA algorithm is patented in Europe and in the United States		The IDEA algorithm is patented in Europe and in the United States
	with patent application pending in Japan. Licenses are required		with patent application pending in Japan. Licenses are required
	for commercial uses of IDEA.		for commercial uses of IDEA.
	For patent and licensing information, contact:		For patent and licensing information, contact:
	Ascom Systec AG, Dept. CMVV		Ascom Systec AG, Dept. CMVV
	Gewerbepark, CH-5506		Gewerbepark, CH-5506
	Magenwil, Switzerland		Magenwil, Switzerland
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	cipher algorithm. The algorithm is described in detail in		cipher algorithm. The algorithm is described in detail in
	[Schneier93], [Schneier95] and [Schneier].		[Schneier93], [Schneier95] and [Schneier].
	3DES:		3DES:
	This DES variant, colloquially known as "Triple DES" or as DES-		This DES variant, colloquially known as "Triple DES" or as DES-
	EDE3, processes each block three times, each time with a different		EDE3, processes each block three times, each time with a different
	key. This technique of using more than one DES operation was		key. This technique of using more than one DES operation was
	proposed in [Tuchman79].		proposed in [Tuchman79].
	Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98		Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98
	P1 P2 Pi		P1 P2 Pi
	| | |		| | |
	IV->->(X) +>->->->(X) +>->->->(X)		IV->->(X) +>->->->(X) +>->->->(X)
	v ^ v ^ v		v ^ v ^ v
	+-----+ ^ +-----+ ^ +-----+		+-----+ ^ +-----+ ^ +-----+
	k1->| E | ^ k1->| E | ^ k1->| E |		k1->| E | ^ k1->| E | ^ k1->| E |
	+-----+ ^ +-----+ ^ +-----+		+-----+ ^ +-----+ ^ +-----+
	| ^ | ^ |		| ^ | ^ |
	v ^ v ^ v		v ^ v ^ v
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	ciphertext block.		ciphertext block.
	Note that when all three keys (k1, k2 and k3) are the same, DES-		Note that when all three keys (k1, k2 and k3) are the same, DES-
	EDE3-CBC is equivalent to DES-CBC. This property allows the DES-		EDE3-CBC is equivalent to DES-CBC. This property allows the DES-
	EDE3 hardware implementations to operate in DES mode without		EDE3 hardware implementations to operate in DES mode without
	modification.		modification.
	For more explanation and implementation information for Triple DES,		For more explanation and implementation information for Triple DES,
	see [Schneier95].		see [Schneier95].
	Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98		Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98
	2.7 Performance		2.7 Performance
	For a comparison table of the speed of any of these and other		For a comparison table of the estimated speed of any of these and
	cipher algorithms, please see [Schneier97].		other cipher algorithms, please see [Schneier97] or for an up-to-
			date performance comparison, please see [Bosseleaers].
	CAST-128:
	CAST runs approximately 3 times faster than a highly optimized DES
	implementation and runs 5-6 times faster than the DES
	implementations found in typical applications. This is based on a
	non-optimized C++ implementation of CAST-128. It can therefore be
	tuned to give even higher performance, if this is required.
	RC5:
	Benchmark numbers from RSA Data Security suggest that RC5-CBC runs
	about twice as fast as Eric Young's DES-CBC implementation from
	SSLeay on the popular 32-bit CPUs.
	IDEA:
	Normal eight round IDEA is approximately twice as fast as DES on
	386 and 486 processors. However on a Pentium, both eight round
	IDEA and 56 bit key, 16 round DES require about the same number of
	clock cycles per byte encrypted. Four round IDEA is twice as fast
	as eight round IDEA.
	Blowfish:
	Blowfish is designed to encrypt data very efficiently on 32 bit
	processors. Although setting up the keys for Blowfish is complex
	and time consuming, actual encryption is efficient. Sixteen round
	Blowfish uses only 18 clock cycles per byte encrypted on a Pentium
	versus 45 clock cycles for 16 round DES with a 56 bit key, and 108
	for 48 round Triple-DES.
	3DES:
	Triple DES is approximately 2.5 times slower than "single" DES
	(rather than 3 times), because inner permutations may be removed.
	Phil Karn has tuned DES-EDE3-CBC software to achieve very fast
	performance. Other DES speed estimates may be found at [Schneier,
	page 279].
	Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98
	3. ESP Payload		3. ESP Payload
	The ESP payload is made up of the IV followed by raw cipher-text.		The ESP payload is made up of the IV followed by raw cipher-text.
	Thus the payload field, as defined in [Kent98], is broken down		Thus the payload field, as defined in [Kent98], is broken down
	according to the following diagram:		according to the following diagram:
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| |		| |
	+ Initialization Vector (8 octets) +		+ Initialization Vector (8 octets) +
	skipping to change at page 10, line 44 ¶		skipping to change at page 10, line 5 ¶
	To avoid ECB encryption of very similar plaintext blocks in		To avoid ECB encryption of very similar plaintext blocks in
	different packets, implementations MUST NOT use a counter or other		different packets, implementations MUST NOT use a counter or other
	low-Hamming distance source for IVs.		low-Hamming distance source for IVs.
	3.1 ESP Environmental Considerations		3.1 ESP Environmental Considerations
	Currently, there are no known issues regarding interactions between		Currently, there are no known issues regarding interactions between
	these algorithms and other aspects of ESP, such as use of certain		these algorithms and other aspects of ESP, such as use of certain
	authentication schemes.		authentication schemes.
			Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98
	3.2 Keying Material		3.2 Keying Material
	The minimum number of bits sent from the key exchange protocol to		The minimum number of bits sent from the key exchange protocol to
	this ESP algorithm must be greater or equal to the key size.		this ESP algorithm must be greater or equal to the key size.
	The cipher's encryption and decryption key is taken from the first		The cipher's encryption and decryption key is taken from the first
	<x> bits of the keying material, where <x> represents the required		<x> bits of the keying material, where <x> represents the required
	key size.		key size.
	Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98
	4. Security Considerations		4. Security Considerations
	Implementations are encouraged to use the largest key sizes they		Implementations are encouraged to use the largest key sizes they
	can when taking into account performance considerations for their		can when taking into account performance considerations for their
	particular hardware and software configuration. Note that		particular hardware and software configuration. Note that
	encryption necessarily impacts both sides of a secure channel, so		encryption necessarily impacts both sides of a secure channel, so
	such consideration must take into account not only the client side,		such consideration must take into account not only the client side,
	but the server as well.		but the server as well.
	The case for using random values for IVs has been refined with the		For information on the case for using random values please see
	following summary provided by Steve Bellovin. Refer to [Bell97] for		[Bell97].
	further information.
	For further security considerations, the reader is encouraged to		For further security considerations, the reader is encouraged to
	read the documents that describe the actual cipher algorithms.		read the documents that describe the actual cipher algorithms.
	5. References		5. References
	[Adams97] C. Adams, "The CAST-128 Encryption Algorithm",		[Adams97] C. Adams, "The CAST-128 Encryption Algorithm",
	RFC2144, 1997.		RFC2144, 1997.
	[Atkinson98]S. Kent, R. Atkinson, "Security Architecture for the		[Atkinson98]S. Kent, R. Atkinson, "Security Architecture for the
	Internet Protocol", draft-ietf-ipsec-arch-sec-03		Internet Protocol", draft-ietf-ipsec-arch-sec-04
	[Baldwin96] R.W. Baldwin, R. Rivest, "The RC5, RC5-CBC, RC5-CBC-		[Baldwin96] R.W. Baldwin, R. Rivest, "The RC5, RC5-CBC, RC5-CBC-
	Pad, and RC5-CTS Algorithms", RFC2040, October 1996		Pad, and RC5-CTS Algorithms", RFC2040, October 1996
	[Bell97] S. Bellovin, "Probable Plaintext Cryptanalysis of the		[Bell97] S. Bellovin, "Probable Plaintext Cryptanalysis of the
	IP Security Protocols", Proceedings of the Symposium		IP Security Protocols", Proceedings of the Symposium
	on Network and Distributed System Security, San Diego,		on Network and Distributed System Security, San Diego,
	CA, pp. 155-160, February 1997 (also		CA, pp. 155-160, February 1997 (also
	http://www.research.att.com/~smb/probtxt.{ps, pdf}).		http://www.research.att.com/~smb/probtxt.{ps, pdf}).
			[Bosselaers]A. Bosselaers, "Performance of Pentium
			implementations",
			http://www.esat.kuleuven.ac.be/~bosselae/
	[Bradner97] S. Bradner, "Key words for use in RFCs to indicate		[Bradner97] S. Bradner, "Key words for use in RFCs to indicate
	Requirement Levels", RFC2119, March 1997		Requirement Levels", RFC2119, March 1997
	[Crypto93] J. Daeman, R. Govaerts, J. Vandewalle, "Weak Keys for		Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98
			[Crypto93] J. Daemen, R. Govaerts, J. Vandewalle, "Weak Keys for
	IDEA", Advances in Cryptology, CRYPTO 93 Proceedings,		IDEA", Advances in Cryptology, CRYPTO 93 Proceedings,
	Springer-Verlag, pp. 224-230.		Springer-Verlag, pp. 224-230.
	[FIPS-46] US National Bureau of Standards, "Data Encryption		[FIPS-46] US National Bureau of Standards, "Data Encryption
	Standard", Federal Information Processing Standard		Standard", Federal Information Processing Standard
	(FIPS) Publication 46, January 1977.		(FIPS) Publication 46, January 1977.
	[Kent98] S. Kent, Atkinson, R., "IP Encapsulating Security		[Kent98] S. Kent, Atkinson, R., "IP Encapsulating Security
	Payload (ESP)", draft-ietf-ipsec-esp-v2-03		Payload (ESP)", draft-ietf-ipsec-esp-v2-04
	Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98
	[Lai] X. Lai, "On the Design and Security of Block Ciphers",		[Lai] X. Lai, "On the Design and Security of Block Ciphers",
	ETH Series in Information Processing, v. 1, Konstanz:		ETH Series in Information Processing, v. 1, Konstanz:
	Hartung-Gorre Verlag, 1992.		Hartung-Gorre Verlag, 1992.
	[Madson98] C. Madson, N. Dorswamy, "The ESP DES-CBC Cipher		[Madson98] C. Madson, N. Dorswamy, "The ESP DES-CBC Cipher
	Algorithm With Explicit IV", draft-ietf-ipsec-ciph-		Algorithm With Explicit IV", draft-ietf-ipsec-ciph-
	des-expiv-02		des-expiv-02
			[MOV] A. Menezes, P. Van Oorschot, S. Vanstone, "Handbook of
			Applied Cryptography", CRC Press, 1997. ISBN 0-8493-
			8523-7
	[Schneier] B. Schneier, "Applied Cryptography Second Edition",		[Schneier] B. Schneier, "Applied Cryptography Second Edition",
	John Wiley & Sons, New York, NY, 1995. ISBN 0-471-		John Wiley & Sons, New York, NY, 1995. ISBN 0-471-
	12845-7		12845-7
	[Schneier93]B. Schneier, "Description of a New Variable-Length		[Schneier93]B. Schneier, "Description of a New Variable-Length
	Key, 64-Bit Block Cipher", from "Fast Software		Key, 64-Bit Block Cipher", from "Fast Software
	Encryption, Cambridge Security Workshop Proceedings",		Encryption, Cambridge Security Workshop Proceedings",
	Springer-Verlag, 1994, pp. 191-204.		Springer-Verlag, 1994, pp. 191-204.
	http://www.counterpane.com/bfsverlag.html		http://www.counterpane.com/bfsverlag.html
	skipping to change at page 12, line 39 ¶		skipping to change at page 12, line 5 ¶
	[Schneier97]B. Scheier, "Speed Comparisons of Block Ciphers on a		[Schneier97]B. Scheier, "Speed Comparisons of Block Ciphers on a
	Pentium." February 1997,		Pentium." February 1997,
	http://www.counterpane.com/speed.html		http://www.counterpane.com/speed.html
	[Thayer97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security		[Thayer97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security
	Document Roadmap", draft-ietf-ipsec-doc-roadmap-02		Document Roadmap", draft-ietf-ipsec-doc-roadmap-02
	[Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to		[Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to
	DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41.		DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41.
			Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98
	6. Acknowledgments		6. Acknowledgments
	This document is a merger of most of the ESP cipher algorithm		This document is a merger of most of the ESP cipher algorithm
	documents. This merger was done to facilitate greater		documents. This merger was done to facilitate greater
	understanding of the commonality of all of the ESP algorithms and		understanding of the commonality of all of the ESP algorithms and
	to further the development of these algorithm within ESP.		to further the development of these algorithm within ESP.
	The content of this document is based on suggestions originally		The content of this document is based on suggestions originally
	from Stephen Kent and subsequent discussions from the IPSec mailing		from Stephen Kent and subsequent discussions from the IPSec mailing
	list as well as other IPSec drafts.		list as well as other IPSec drafts.
	For CAST, special thanks to Carlisle Adams and Paul Van Oorschot		Special thanks to Carlisle Adams and Paul Van Oorschot both of
	both of Entrust Technologies who provided input and review.		Entrust Technologies who provided input and review of CAST.
	For 3DES, thanks to all of the editors of the previous ESP 3DES		Thanks to all of the editors of the previous ESP 3DES documents; W.
	documents; W. Simpson, N. Doraswamy, P. Metzger, and P. Karn.		Simpson, N. Doraswamy, P. Metzger, and P. Karn.
	Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98		Thanks to Brett Howard from TimeStep for his original work of ESP-
			RC5.
	For RC5, thanks to Brett Howard from TimeStep for his original		Thanks to Markku-Juhani Saarinen, Helger Lipmaa and Bart Preneel
	work.		for their input on IDEA and other ciphers.
	7. Editors' Addresses		7. Editors' Addresses
	Roy Pereira		Roy Pereira
	<rpereira@timestep.com>		<rpereira@timestep.com>
	TimeStep Corporation		TimeStep Corporation
	+1 (613) 599-3610 x 4808		+1 (613) 599-3610 x 4808
	Rob Adams		Rob Adams
	<adams@cisco.com>		<adams@cisco.com>
	skipping to change at page 13, line 34 ¶		skipping to change at page 13, line 5 ¶
	Robert W. Baldwin		Robert W. Baldwin
	<baldwin@rsa.com> or <baldwin@lcs.mit.edu>		<baldwin@rsa.com> or <baldwin@lcs.mit.edu>
	RSA Data Security, Inc.		RSA Data Security, Inc.
	+1 (415) 595-8782		+1 (415) 595-8782
	Greg Carter		Greg Carter
	<carterg@entrust.com>		<carterg@entrust.com>
	Entrust Technologies		Entrust Technologies
	+1 (613) 763-1358		+1 (613) 763-1358
			Internet Draft The ESP CBC-Mode Cipher Algorithms Sep-98
	Rodney Thayer		Rodney Thayer
	rodney@sabletech.com		rodney@sabletech.com
	Sable Technology Corporation		Sable Technology Corporation
	+1 (617) 332-7292		+1 (617) 332-7292
	The IPSec working group can be contacted via the IPSec working		The IPSec working group can be contacted via the IPSec working
	group's mailing list (ipsec@tis.com) or through its chairs:		group's mailing list (ipsec@tis.com) or through its chairs:
	Robert Moskowitz		Robert Moskowitz
	rgm@icsa.net		rgm@icsa.net
	International Computer Security Association		International Computer Security Association
	Theodore Y. Ts’o		Theodore Y. Ts'o
	tytso@MIT.EDU		tytso@MIT.EDU
	Massachusetts Institute of Technology		Massachusetts Institute of Technology
End of changes. 38 change blocks.
	99 lines changed or deleted		67 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/