< draft-lee-ipsec-cipher-seed-00.txt		draft-lee-ipsec-cipher-seed-01.txt >
	IPSec Working Group Hyanjin Lee (KISA)		Internet Draft Hyangjin Lee (KISA)
	Internet Draft Jaeil Lee (KISA)		draft-lee-ipsec-cipher-seed-01.txt Jaeho Yoon (KISA)
	draft-lee-ipsec-cipher-seed-00.txt June 2004		Expires August 2005 Seoklae Lee (KISA)
	Expires December 2004 Target category : Standard Track		Jaeil Lee (KISA)
			February 2005
	The SEED Cipher Algorithm and Its Use With IPSec		The SEED Cipher Algorithm and Its Use With IPSec
	<draft-lee-ipsec-cipher-seed-00.txt>		<draft-lee-ipsec-cipher-seed-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			or will be disclosed, and any of which I become aware will be
			disclosed, in accordance with RFC 3668.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		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		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
	Comments or suggestions for improvement may be made on the "ietf-		This Internet-Draft will expire on August 22, 2005.
	ipsec" mailing list or directly to the author.
			Copyright Notice
			Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document describes the use of the SEED block cipher algorithm in		This document describes the use of the SEED block cipher algorithm in
	Cipher Block Chaining Mode, with an explicit IV, as a confidentiality		Cipher Block Chaining Mode, with an explicit IV, as a confidentiality
	mechanism within the context of the IPsec Encapsulating Security		mechanism within the context of the IPsec Encapsulating Security
	Payload (ESP).		Payload (ESP).
	1. Introduction		1. Introduction
	This document describes the use of the SEED block cipher algorithm in
	Cipher Block Chaining Mode, with an explicit IV, as a confidentiality
	mechanism within the context of the IPsec Encapsulating Security
	Payload (ESP).
	1.1 SEED		1.1 SEED
	SEED is a symmetric encryption algorithm that had been developed by		SEED is a national industrial association standard [TTASSEED] and is
	KISA (Korea Information Security Agency) and a group of experts since		widely used in South Korea for electronic commerce and financial
	1998. The input/output block size of SEED is 128-bit and the key		services operated on wired & wireless communications.
	length is also 128-bit. SEED has the 16-round Feistel structure. A
	128-bit input is divided into two 64-bit blocks and the right 64-bit
	block is an input to the round function with a 64-bit subkey
	generated from the key scheduling.
	SEED is easily implemented in various software and hardware because		SEED is a 128-bit symmetric key block cipher that has been developed
	it is designed to increase the efficiency of memory storage and the		by KISA (Korea Information Security Agency) and a group of experts
	simplicity in generating keys without degrading the security of the		since 1998. The input/output block size of SEED is 128-bit and the
	algorithm. In particular, it can be effectively adopted to a		key length is also 128-bit. SEED has the 16-round Feistel structure.
	computing environment with a restricted resources such as a mobile		A 128-bit input is divided into two 64-bit blocks and the right
	devices, smart cards and so on.		64-bit block is an input to the round function with a 64-bit subkey
			generated from the key scheduling.
	SEED is robust against known attacks including Differential		SEED is easily implemented in various software and hardware and it
	cryptanalysis, Linear cryptanalysis and related key attacks, etc.		can be effectively adopted to a computing environment with a
	SEED has gone through wide public scrutinizing procedures.		restricted resources such as mobile devices, smart cards and so on.
	Especially, it has been evaluated and also considered
	cryptographically secure by trustworhty organizations such as ISO/IEC
	JTC 1/SC 27 and Japan CRYTEC (Cryptography Reasearch and Evaluation
	Comittees) [ISOSEED][CRYPTEC]. SEED has been submitted to other
	several standardization bodies such as ISO (ISO/IEC 18033-3), IETF
	S/MIME Mail Security [SEED-SMIME] and it is under consideration.
	SEED is a national industrial association standard [TTASSEED] and is		SEED is robust against known attacks including DC (Differential
	widely used in South Korea for electronic commerce and financial		cryptanalysis), LC (Linear cryptanalysis), and related key attacks.
	services operated on wired & wireless PKI.		SEED has gone through wide public scrutinizing procedures. It has
			been evaluated and is considered cryptographically secure by credible
			organizations such as ISO/IEC JTC 1/SC 27 and Japan CRYPTREC
			(Cryptography Research and Evaluation Committees)[ISOSEED][CRYPTREC].
	The remainder of this document specifies the use of SEED within the		The remainder of this document specifies the use of SEED within the
	context of IPsec ESP. For further information on how the various		context of IPsec ESP. For further information on how the various
	pieces of ESP fit together to provide security services, please refer		pieces of ESP fit together to provide security services, please refer
	to [ARCH], [ESP], and [ROAD].		to [ARCH], [ESP], and [ROAD].
	1.2 Terminology		1.2 Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
	"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,		"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
	as shown) are to be interpreted as described in [RFC2119].		as shown) are to be interpreted as described in RFC2119.
	2. The SEED Cipher Algorithm		2. The SEED Cipher Algorithm
	All symmetric block cipher algorithms share common characteristics		All symmetric block cipher algorithms share common characteristics
	and variables, including mode, key size, weak keys, block size, and		and variables, including mode, key size, weak keys, block size, and
	rounds. The following sections contain descriptions of the relevant		rounds. The following sections contain descriptions of the relevant
	characteristics of SEED.		characteristics of SEED.
	The algorithm specification and object identifiers are described in		The algorithm specification and object identifiers are described in
	[SEED-ID]. The SEED homepage,		[ISOSEED, SEED]. The SEED homepage,
	http://www.kisa.or.kr/seed/seed_eng.html, contains a wealth of		http://www.kisa.or.kr/seed/seed_eng.html, contains a wealth of
	information about SEED, including detailed specification, evaluation		information about SEED, including detailed specification, evaluation
	report, test vectors, and so on.		report, test vectors, and so on.
	2.1 Mode		2.1 Mode
	NIST has defined 5 modes of operation for AES and other FIPS-approved		NIST has defined 5 modes of operation for AES and other FIPS-approved
	ciphers [MODES]: CBC (Cipher Block Chaining), ECB (Electronic		ciphers [MODES]: CBC (Cipher Block Chaining), ECB (Electronic
	CodeBook), CFB (Cipher FeedBack), OFB (Output FeedBack) and CTR		Codebook), CFB (Cipher FeedBack), OFB (Output FeedBack) and CTR
	(Counter). The CBC mode is well-defined and well-understood for		(Counter). The CBC mode is well-defined and well-understood for
	symmetric ciphers, and is currently required for all other ESP		symmetric ciphers, and is currently required for all other ESP
	ciphers. This document specifies the use of the SEED cipher in CBC		ciphers. This document specifies the use of the SEED cipher in CBC
	mode within ESP. This mode requires an Initialization Vector (IV)		mode within ESP. This mode requires an Initialization Vector (IV)
	that is the same size as the block size. Use of a randomly generated		that is the same size as the block size. Use of a randomly generated
	IV prevents generation of identical ciphertext from packets which		IV prevents generation of identical ciphertext from packets which
	have identical data that spans the first block of the cipher		have identical data that spans the first block of the cipher
	algorithm's block size		algorithm's block size
	The IV is XOR'd with the first plaintext block before it is		The IV is XOR'd with the first plaintext block before it is
	skipping to change at page 4, line 9 ¶		skipping to change at page 3, line 47 ¶
	2.4 Block Size and Padding		2.4 Block Size and Padding
	SEED uses a block size of sixteen octets (128 bits).		SEED uses a block size of sixteen octets (128 bits).
	Padding is required by the SEED to maintain a 16-octet (128-bit)		Padding is required by the SEED to maintain a 16-octet (128-bit)
	blocksize. Padding MUST be added, as specified in [ESP], such that		blocksize. Padding MUST be added, as specified in [ESP], such that
	the data to be encrypted (which includes the ESP Pad Length and Next		the data to be encrypted (which includes the ESP Pad Length and Next
	Header fields) has a length that is a multiple of 16 octets.		Header fields) has a length that is a multiple of 16 octets.
	Because of the algorithm specific padding requirement, no additional		Because of the algorithm specific padding requirement, no additional
	padding is required to ensure that the ciphertext terminates on a 4-		padding is required to ensure that the ciphertext terminates on a
	octet boundary (i.e. maintaining a 16-octet blocksize guarantees that		4-octet boundary (i.e. maintaining a 16-octet blocksize guarantee
	the ESP Pad Length and Next Header fields will be right aligned		that the ESP Pad Length and Next Header fields will be right aligned
	within a 4-octet word). Additional padding MAY be included, as		within a 4-octet word). Additional padding MAY be included, as
	specified in [ESP], as long as the 16-octet blocksize is maintained.		specified in [ESP], as long as the 16-octet blocksize is maintained.
	2.5 Performance		2.5 Performance
	Performance figures of SEED are available at		Performance figures of SEED are available at
	http://www.kisa.or.kr/seed/seed_eng.html. It also includes		http://www.kisa.or.kr/seed/seed_eng.html
	performance comparision with the AES and Camellia cipher.
	3. ESP Payload		3. ESP Payload
	SEED was designed to follow the same API as the AES cipher.		The ESP Payload is made up of the Initialization Vector(IV) of 16
	Therefore, any consideration related to ESP payload is the same as		octets followed by encrypted payload. Thus the payload field, as
	that of the AES cipher. Details can be found in [AES-IPSEC].		define in [ESP], is broken down according to the following diagram :
	4. Interaction with IKE		+---------------+---------------+---------------+---------------+
			| |
			+ Initialization Vector (16 octets) +
			| |
			+---------------+---------------+---------------+---------------+
			| |
			~ Encrypted Payload (variable length, a multiple of 16 octets) ~
			| |
			+---------------------------------------------------------------+
	SEED was designed to follow the same API as the AES cipher.		The IV field MUST be the same size as the block size of the cipher
	Therefore, this section defines only Phase 1 Identifier and Phase 2		algorithm being used. The IV MUST be chosen at random, and MUST be
	Identifier. Any other consideration related to interaction with IKE		unpredictable.
	is the same as that of the AES cipher. Details can be found in
	[AES-IPSEC].
	4.1 Phase 1 Identifier		Including the IV in each datagram ensures that decryption of each
			received datagram can be performed, even when some datagrams are
			dropped, or datagrams are re-ordered in transit.
	For Phase 1 negotiations, IANA has assigned an Encryption Algorithm		To avoid CBC encryption of very similar plaintext blocks in different
	ID of (TBD) for SEED-CBC.		packets, implementations MUST NOT use a counter or other low-Hamming
			distance source for IVs.
	4.2 Phase 2 Identifier		4. Test Vectors
			The first 2 test cases test SEED-CBC encryption. Each test case
			includes key, the plaintext, and the resulting ciphertext. All data
			are hexadecimal numbers(not prefixed by "0x").
			The last 4 test cases illustrate sample ESP packets using SEED-CBC
			for encryption. All data are hexadecimal numbers(not prefixed by
			"0x").
			Case #1 : Encrypting 32 bytes (2 blocks) using SEED-CBC with
			128-bit key
			Key : ed2401ad 22fa2559 91bafdb0 1fefd697
			IV : 93eb149f 92c9905b ae5cd34d a06c3c8e
			PlainText : b40d7003 d9b6904b 35622750 c91a2457
			5bb9a632 364aa26e 3ac0cf3a 9c9d0dcb
			CipherText : f072c5b1 a0588c10 5af8301a dcd91dd0
			67f68221 55304bf3 aad75ceb 44341c25
			Case #2 : Encrypting 64 bytes (4 blocks) using SEED-CBC with
			128-bit key
			Key : 88e34f8f 081779f1 e9f39437 0ad40589
			IV : 268d66a7 35a81a81 6fbad9fa 36162501
			PlainText : d76d0d18 327ec562 b15e6bc3 65ac0c0f
			8d41e0bb 938568ae ebfd92ed 1affa096
			394d20fc 5277ddfc 4de8b0fc e1eb2b93
			d4ae40ef 4768c613 b50b8942 f7d4b9b3
			CipherText : a293eae9 d9aebfac 37ba714b d774e427
			e8b706d7 e7d9a097 228639e0 b62b3b34
			ced11609 cef2abaa ec2edf97 9308f379
			c31527a8 267783e5 cba35389 82b48d06
			Case #3 : Sample transport-mode ESP packet (ping 192.168.123.100)
			Key : 90d382b4 10eeba7a d938c46c ec1a82bf
			SPI : 4321
			Source address : 192.168.123.3
			Destination address : 192.168.123.100
			Sequence number : 1
			IV : e96e8c08 ab465763 fd098d45 dd3ff893
			Original packet :
			IP header (20 bytes) : 45000054 08f20000 4001f9fe c0a87b03 c0a87b64
			Data (64 bytes) :
			08000ebd a70a0000 8e9c083d b95b0700
			08090a0b 0c0d0e0f 10111213 14151617
			18191a1b 1c1d1e1f 20212223 24252627
			28292a2b 2c2d2e2f 30313233 34353637
			Augment data with :
			Padding : 01020304 05060708 090a0b0c 0d0e
			Pad length : 0e
			Next header : 01 (ICMP)
			Pre-encryption Data with padding, pad length and next header(80
			bytes):
			08000ebd a70a0000 8e9c083d b95b0700
			08090a0b 0c0d0e0f 10111213 14151617
			18191a1b 1c1d1e1f 20212223 24252627
			28292a2b 2c2d2e2f 30313233 34353637
			01020304 05060708 090a0b0c 0d0e0e01
			Post-encryption packet with SPI, Sequence number, IV :
			IP Header : 45000054 08f20000 4001f9fe c0a87b03 c0a87b64
			SPI/Seq # : 00004321 00000001
			IV : e96e8c08 ab465763 fd098d45 dd3ff893
			Encrypted Data (80 bytes) :
			e7ebaa03 cf45ef09 021b3011 b40d3769
			be96ebae cd4222f6 b6f84ce5 b2d5cdd1
			60eb6b0e 5a47d16a 501a4d10 7b2d7cc8
			ab86ba03 9a000972 66374fa8 f87ee0fb
			ef3805db faa144a2 334a34db 0b0f81ca
			Case #4 : Sample transport-mode ESP packet
			(ping -p 77 -s 20 192.168.123.100)
			Key : 90d382b4 10eeba7a d938c46c ec1a82bf
			SPI : 4321
			Source address : 192.168.123.3
			Destination address : 192.168.123.100
			Sequence number : 8
			IV : 69d08df7 d203329d b093fc49 24e5bd80
			Original packet:
			IP header (20 bytes) : 45000030 08fe0000 4001fa16 c0a87b03 c0a87b64
			Data (28 bytes) :
			0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777
			Augment data with :
			Padding : 0102
			Pad length : 02
			Next header : 01 (ICMP)
			Pre-encryption Data with padding, pad length and
			next header(32 bytes):
			0800b5e8 a80a0500 a69c083d 0b660e00
			77777777 77777777 77777777 01020201
			Post-encryption packet with SPI, Sequence number, IV :
			IP header : 4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64
			SPI/Seq # : 00004321 00000008
			IV : 69d08df7 d203329d b093fc49 24e5bd80
			Encrypted Data (32 bytes) :
			b9ad6e19 e9a6a2fa 02569160 2c0af541
			db0b0807 e1f660c7 3ae2700b 5bb5efd1
			Case #5 : Sample tunnel-mode ESP packet (ping 192.168.123.200)
			Key : 01234567 89abcdef 01234567 89abcdef
			SPI : 8765
			Source address : 192.168.123.3
			Destination address : 192.168.123.200
			Sequence number : 2
			IV : f4e76524 4f6407ad f13dc138 0f673f37
			Original packet :
			IP header (20 bytes) : 45000054 09040000 4001f988 c0a87b03 c0a87bc8
			Data (64 bytes) :
			08009f76 a90a0100 b49c083d 02a20400
			08090a0b 0c0d0e0f 10111213 14151617
			18191a1b 1c1d1e1f 20212223 24252627
			28292a2b 2c2d2e2f 30313233 34353637
			Augment data with :
			Padding : 01020304 05060708 090a
			Pad length : 0a
			Next header : 04 (IP-in-IP)
			Pre-encryption Data with original IP header, padding, pad length and
			next header (96 bytes) :
			45000054 09040000 4001f988 c0a87b03
			c0a87bc8 08009f76 a90a0100 b49c083d
			02a20400 08090a0b 0c0d0e0f 10111213
			14151617 18191a1b 1c1d1e1f 20212223
			24252627 28292a2b 2c2d2e2f 30313233
			34353637 01020304 05060708 090a0a04
			Post-encryption packet with SPI, Sequence number, IV :
			IP header : 4500008c 09050000 4032f91e c0a87b03 c0a87bc8
			SPI/Seq # : 00008765 00000002
			IV : f4e76524 4f6407ad f13dc138 0f673f37
			Encrypted Data (96 bytes):
			2638aa7b 05e71b54 9348082b 67b47b26
			c565aed4 737f0bcb 439c0f00 73e7913c
			3c8a3e4f 5f7a5062 003b78ed 7ca54a08
			c7ce047d 5bec14e4 8cba1005 32a12097
			8d7f5503 204ef661 729b4ea1 ae6a9178
			59a5caac 46e810bd 7875bd13 d6f57b3d
			Case #6 : Sample tunnel-mode ESP packet
			(ping -p ff -s 40 192.168.123.200)
			Key : 01234567 89abcdef 01234567 89abcdef
			SPI : 8765
			Source address : 192.168.123.3
			Destination address : 192.168.123.200
			Sequence number : 5
			IV : 85d47224 b5f3dd5d 2101d4ea 8dffab22
			Original packet :
			IP header (20 bytes) :
			45000044 090c0000 4001f990 c0a87b03 c0a87bc8
			Data (48 bytes) :
			0800d63c aa0a0200 c69c083d a3de0300
			ffffffff ffffffff ffffffff ffffffff
			ffffffff ffffffff ffffffff ffffffff
			Augment data with :
			Padding : 01020304 05060708 090a
			Pad length : 0a
			Next header : 04 (IP-in-IP)
			Pre-encryption Data with original IP header, padding, pad length and
			next header (80 bytes):
			45000044 090c0000 4001f990 c0a87b03
			c0a87bc8 0800d63c aa0a0200 c69c083d
			a3de0300 ffffffff ffffffff ffffffff
			ffffffff ffffffff ffffffff ffffffff
			ffffffff 01020304 05060708 090a0a04
			Post-encryption packet with SPI, Sequence number, IV :
			IP header : 4500007c 090d0000 4032f926 c0a87b03 c0a87bc8
			SPI/Seq # : 00008765 00000005
			IV : 85d47224 b5f3dd5d 2101d4ea 8dffab22
			Encrypted Data (80 bytes) :
			311168e0 bc36ac4e 59802bd5 192c5734
			8f3d29c8 90bab276 e9db4702 91f79ac7
			79571929 c170f902 ffb2f08b d448f782
			31671414 ff29b7e0 168e1c87 09ba2b67
			a56e0fbc 4ff6a936 d859ed57 6c16ef1b
			5. Interaction with IKE
			5.1 Phase 1 Identifier
			For Phase 1 negotiations, the object identifier of SEED-CBC is
			defined in [SEED].
			algorithm OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410)
			kisa(200004) algorithm(1) }
			id-seedCBC OBJECT IDENTIFIER ::= { algorithm seedCBC(4) }
			5.2 Phase 2 Identifier
	For Phase 2 negotiations, IANA has assigned an ESP Transform		For Phase 2 negotiations, IANA has assigned an ESP Transform
	Identifier of (TBD) for ESP_SEED.		Identifier of (TBD) for ESP_SEED_CBC.
	4.3 Key Length Attribute		5.3 Key Length Attribute
	Since the SEED supports 128 bit key lengths, the Key Length attribute		Since the SEED supports 128 bit key lengths, the Key Length attribute
	is set with 128 bits.		is set with 128 bits.
	4.4 Hash Algorithm Considerations		5.4 Hash Algorithm Considerations
	HMAC-SHA-1[HMAC-SHA] and HMAC-MD5 [HMAC-MD5] are currently considered		HMAC-SHA-1[HMAC-SHA] and HMAC-MD5 [HMAC-MD5] are currently considered
	of sufficient strength to serve both as IKE generators of 128-bit		of sufficient strength to serve both as IKE generators of 128-bit
	SEED keys and as ESP authenticators for SEED encryption using 128-bit		SEED keys and as ESP authenticators for SEED encryption using 128-bit
	keys.		keys.
	5. Security Considerations		6. Security Considerations
	No security problem has been found on SEED. SEED is secure against		No security problem has been found on SEED. SEED is secure against
	all known attacks including Differential cryptanalysis, Linear		all known attacks including Differential cryptanalysis, Linear
	cryptanalysis and related key attacks, etc. The best known attack is		cryptanalysis and related key attacks, etc. The best known attack is
	only exhaustive search for the key (by [CRYPTEC]). For further		only exhaustive search for the key (by [CRYPTREC]). For further
	security considerations, the reader is encouraged to read [CRYPTEC],		security considerations, the reader is encouraged to read
	[ISOSEED] and [SEED-EVAL].		[CRYPTREC], [ISOSEED] and [SEED-EVAL].
	6. Intellectual Property Statement		7. IANA Considerations
	The IETF takes no position regarding the validity or scope of any		IANA has assigned ESP Transform Identifier (TBD) to ESP_SEED_CBC.
	intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to
	obtain a general license or permission for the use of such
	proprietary rights by implementors or users of this specification can
	be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		8. Acknowledgments
	copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive
	Director.
	7. References		The authors want to thank Ph.D Haesuk Kim in FuturSystems and Brian
			Kim in OULLIM for providing expert advice on Test Vector examples.
	[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard(AES),		9. References
	November 2001.
	http://csrc.nist.gov/publications/fips/fips197/fips-197.{ps,pdf}
	[AES-IPSEC] Frankel, S., S. Kelly, and R. Glenn, "The AES Cipher		9.1 Normative References
	Algorithm and Its Use With IPsec," RFC 3602,
	September, 2003.		[TTASSEED] Telecommunications Technology Association (TTA),
			South Korea, "128-bit Symmetric Block Cipher (SEED)",
			TTAS.KO-12.0004, September, 1998 (In Korean)
			http://www.tta.or.kr/English/new/main/index.htm
			[CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
			Algorithms," RFC 2451, November 1998.
			[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
			Payload (ESP)", RFC 2406, November 1998.
			[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
			(IKE)", RFC 2409, November 1998.
	[SEED] Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee,		[SEED] Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee,
	"The SEED Encryption Algorithm", draft-park-seed-00.txt		"The SEED Encryption Algorithm", RFC4009, February 2005.
	[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate		9.2 Informative Reference
	Requirement Levels", BCP 14, RFC 2119, March 1997.
			[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard(AES),
			November 2001.
			http://csrc.nist.gov/publications/fips/fips197/fips-197.
			{ps,pdf}
			[AES-IPSEC] Frankel, S., S. Kelly, and R. Glenn, "The AES Cipher
			Algorithm and Its Use With IPsec," RFC 3602,
			September, 2003.
	[ARCH] Kent, S. and R. Atkinson, "Security Architecture for		[ARCH] Kent, S. and R. Atkinson, "Security Architecture for
	the Internet Protocol", RFC 2401, November 1998.		the Internet Protocol", RFC 2401, November 1998.
	[CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
	Algorithms," RFC 2451, November 1998.
	[CRYPTO-S] Schneier, B., "Applied Cryptography Second Edition",		[CRYPTO-S] Schneier, B., "Applied Cryptography Second Edition",
	John Wiley & Sons, New York, NY, 1995, ISBN		John Wiley & Sons, New York, NY, 1995, ISBN
	0-471-12845-7.		0-471-12845-7.
	[CRYPTREC] Information-technology Promotion Agency (IPA), Japan,		[CRYPTREC] Information-technology Promotion Agency (IPA), Japan,
	CRYPTREC. "SEED Evaluation Report", February, 2002		CRYPTREC. "SEED Evaluation Report", February, 2002
	http://www.kisa.or.kr/seed/seed_eng.html		http://www.kisa.or.kr/seed/seed_eng.html
	[DOI] Piper, D., "The Internet IP Security Domain of		[HMAC-MD5] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
	Interpretation for ISAKMP," RFC 2407, November 1998.
	[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
	Payload (ESP)", RFC 2406, November 1998.
	[HMAC-MD5] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
	ESP and AH", RFC 2403, November 1998.		ESP and AH", RFC 2403, November 1998.
	[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96		[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
	within ESP and AH", RFC 2404, November 1998.		within ESP and AH", RFC 2404, November 1998.
	[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange		[ISOSEED] ISO/IEC JTC 1/SC 27 N3979, "IT Security techniques -
	(IKE)", RFC 2409, November 1998.		Encryption Algorithms - Part3 : Block ciphers", June
			2004.
	[ISOSEED] ISO/IEC JTC 1/SC 27, "National Body contributions on NP 18033
	"Encryption Algorithms" in Response to SC 27 N2563
	(ATT.3 Korea Contribution)", ISO/IEC JTC 1/SC 27 N2656r1
	(n2656_3.zip), October, 2000
	[MODES] Symmetric Key Block Cipher Modes of Operation,		[MODES] Symmetric Key Block Cipher Modes of Operation,
	http://www.nist.gov/modes/.		http://www.nist.gov/modes/.
	[RFC2026] Bradner, S., "The Internet Standards Process --
	Revision 3", RFC2026, October 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC-2119, March 1997.
	[ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security		[ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security
	Document Roadmap", RFC 2411, November 1998.		Document Roadmap", RFC 2411, November 1998.
	[SEED] KISA, "SEED Algorithm Specification",
	http://www.kisa.or.kr/seed/seed_eng.html"
	[SEED-EVAL] KISA, "Self Evaluation Report",		[SEED-EVAL] KISA, "Self Evaluation Report",
	http://www.kisa.or.kr/seed/seed_eng.html"		http://www.kisa.or.kr/seed/data/Document_pdf/
			SEED_Self_Evaluation.pdf"
	[SEED-ID] Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee,
	"The SEED Encryption Algorithm",
	draft-park-seed-01.txt, April, 2004.
	[SEED-SMIME] Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee,
	"Use of the SEED Encryption Algorithm in CMS",
	draft-ietf-smime-cms-01.txt, April, 2004.
	8. Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.
	This document and translations of it may be copied and furnished
	to others, and derivative works that comment on or otherwise
	explain it or assist in its implmentation may be prepared, copied,
	published and distributed, in whole or in part, without
	restriction of any kind, provided that the above copyright notice
	and this paragraph are included on all such copies and derivative
	works. However, this document itself may not be modified in any
	way, such as by removing the copyright notice or references to the
	Internet Society or other Internet organizations, except as needed
	for the purpose of developing Internet standards in which case the
	procedures for copyrights defined in the Internet Standards
	process must be followed, or as required to translate it into
	languages other than English.
	The limited permissions granted above are perpetual and will not
	be revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on
	an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
	PURPOSE."
	9. Authors' Address		10. Authors' Address
	Hyangjin Lee		Hyangjin Lee
	Korea Information Security Agency		Korea Information Security Agency
	Phone: +82-2-405-5446		Phone: +82-2-405-5446
	FAX : +82-2-405-5419		FAX : +82-2-405-5419
	Email : jiinii@kisa.or.kr		Email : jiinii@kisa.or.kr
			Jaeho Yoon
			Korea Information Security Agency
			Phone: +82-2-405-5434
			FAX : +82-2-405-5219
			Email : jhyoon@kisa.or.kr
			Seoklae Lee
			Korea Information Security Agency
			Phone: +82-2-405-5230
			FAX : +82-2-405-5219
			Email : sllee@kisa.or.kr
	Jaeil Lee		Jaeil Lee
	Korea Information Security Agency		Korea Information Security Agency
	Phone: +82-2-405-5300		Phone: +82-2-405-5300
	FAX : +82-2-405-5419		FAX : +82-2-405-5419
	Email: jilee@kisa.or.kr		Email: jilee@kisa.or.kr
			Intellectual Property Statement
			The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
			Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
			Disclaimer of Validity
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Copyright Statement
			Copyright (C) The Internet Society (2005). This document is subject
			to the rights, licenses and restrictions contained in BCP 78, and
			except as set forth therein, the authors retain all their rights.
			Acknowledgment
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes. 46 change blocks.
	167 lines changed or deleted		324 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/