idnits 2.17.1 draft-lee-ipsec-cipher-seed-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 521. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 12 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 134: '... blocksize. Padding MUST be added, as specified in [ESP], such that...' RFC 2119 keyword, line 142: '...Additional padding MAY be included, as...' RFC 2119 keyword, line 166: '... The IV field MUST be the same size ...' RFC 2119 keyword, line 167: '...ng used. The IV MUST be chosen at ran...' RFC 2119 keyword, line 175: '... implementations MUST NOT use a counte...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 202 has weird spacing: '...38568ae ebfd9...' == Line 203 has weird spacing: '...de8b0fc e1eb2...' == Line 207 has weird spacing: '...ef2abaa ec2ed...' == Line 219 has weird spacing: '...001f9fe c0a87...' == Line 221 has weird spacing: '...8000ebd a70a0...' == (10 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 7009 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IKE' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'AES' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'AES-IPSEC' is defined on line 439, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'TTASSEED' ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4009 (ref. 'SEED') (Obsoleted by RFC 4269) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'ARCH') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2411 (ref. 'ROAD') (Obsoleted by RFC 6071) Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Hyangjin Lee (KISA) 3 draft-lee-ipsec-cipher-seed-01.txt Jaeho Yoon (KISA) 4 Expires August 2005 Seoklae Lee (KISA) 5 Jaeil Lee (KISA) 6 February 2005 8 The SEED Cipher Algorithm and Its Use With IPSec 10 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on August 22, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes the use of the SEED block cipher algorithm in 44 Cipher Block Chaining Mode, with an explicit IV, as a confidentiality 45 mechanism within the context of the IPsec Encapsulating Security 46 Payload (ESP). 48 1. Introduction 50 1.1 SEED 52 SEED is a national industrial association standard [TTASSEED] and is 53 widely used in South Korea for electronic commerce and financial 54 services operated on wired & wireless communications. 56 SEED is a 128-bit symmetric key block cipher that has been developed 57 by KISA (Korea Information Security Agency) and a group of experts 58 since 1998. The input/output block size of SEED is 128-bit and the 59 key length is also 128-bit. SEED has the 16-round Feistel structure. 60 A 128-bit input is divided into two 64-bit blocks and the right 61 64-bit block is an input to the round function with a 64-bit subkey 62 generated from the key scheduling. 64 SEED is easily implemented in various software and hardware and it 65 can be effectively adopted to a computing environment with a 66 restricted resources such as mobile devices, smart cards and so on. 68 SEED is robust against known attacks including DC (Differential 69 cryptanalysis), LC (Linear cryptanalysis), and related key attacks. 70 SEED has gone through wide public scrutinizing procedures. It has 71 been evaluated and is considered cryptographically secure by credible 72 organizations such as ISO/IEC JTC 1/SC 27 and Japan CRYPTREC 73 (Cryptography Research and Evaluation Committees)[ISOSEED][CRYPTREC]. 75 The remainder of this document specifies the use of SEED within the 76 context of IPsec ESP. For further information on how the various 77 pieces of ESP fit together to provide security services, please refer 78 to [ARCH], [ESP], and [ROAD]. 80 1.2 Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 83 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 84 as shown) are to be interpreted as described in RFC2119. 86 2. The SEED Cipher Algorithm 88 All symmetric block cipher algorithms share common characteristics 89 and variables, including mode, key size, weak keys, block size, and 90 rounds. The following sections contain descriptions of the relevant 91 characteristics of SEED. 93 The algorithm specification and object identifiers are described in 94 [ISOSEED, SEED]. The SEED homepage, 95 http://www.kisa.or.kr/seed/seed_eng.html, contains a wealth of 96 information about SEED, including detailed specification, evaluation 97 report, test vectors, and so on. 99 2.1 Mode 101 NIST has defined 5 modes of operation for AES and other FIPS-approved 102 ciphers [MODES]: CBC (Cipher Block Chaining), ECB (Electronic 103 Codebook), CFB (Cipher FeedBack), OFB (Output FeedBack) and CTR 104 (Counter). The CBC mode is well-defined and well-understood for 105 symmetric ciphers, and is currently required for all other ESP 106 ciphers. This document specifies the use of the SEED cipher in CBC 107 mode within ESP. This mode requires an Initialization Vector (IV) 108 that is the same size as the block size. Use of a randomly generated 109 IV prevents generation of identical ciphertext from packets which 110 have identical data that spans the first block of the cipher 111 algorithm's block size 113 The IV is XOR'd with the first plaintext block before it is 114 encrypted. Then for successive blocks, the previous ciphertext block 115 is XOR'd with the current plaintext, before it is encrypted. 117 More information on CBC mode can be obtained in [MODES, CRYPTO-S]. 118 For the use of CBC mode in ESP with 64-bit ciphers, please see [CBC]. 120 2.2 Key Size and Numbers of Rounds 122 SEED supports 128-bit key and has the 16-round Feistel structure. 124 2.3 Weak Keys 126 At the time of writing this document there are no known weak keys for 127 SEED. 129 2.4 Block Size and Padding 131 SEED uses a block size of sixteen octets (128 bits). 133 Padding is required by the SEED to maintain a 16-octet (128-bit) 134 blocksize. Padding MUST be added, as specified in [ESP], such that 135 the data to be encrypted (which includes the ESP Pad Length and Next 136 Header fields) has a length that is a multiple of 16 octets. 138 Because of the algorithm specific padding requirement, no additional 139 padding is required to ensure that the ciphertext terminates on a 140 4-octet boundary (i.e. maintaining a 16-octet blocksize guarantee 141 that the ESP Pad Length and Next Header fields will be right aligned 142 within a 4-octet word). Additional padding MAY be included, as 143 specified in [ESP], as long as the 16-octet blocksize is maintained. 145 2.5 Performance 147 Performance figures of SEED are available at 148 http://www.kisa.or.kr/seed/seed_eng.html 150 3. ESP Payload 152 The ESP Payload is made up of the Initialization Vector(IV) of 16 153 octets followed by encrypted payload. Thus the payload field, as 154 define in [ESP], is broken down according to the following diagram : 156 +---------------+---------------+---------------+---------------+ 157 | | 158 + Initialization Vector (16 octets) + 159 | | 160 +---------------+---------------+---------------+---------------+ 161 | | 162 ~ Encrypted Payload (variable length, a multiple of 16 octets) ~ 163 | | 164 +---------------------------------------------------------------+ 166 The IV field MUST be the same size as the block size of the cipher 167 algorithm being used. The IV MUST be chosen at random, and MUST be 168 unpredictable. 170 Including the IV in each datagram ensures that decryption of each 171 received datagram can be performed, even when some datagrams are 172 dropped, or datagrams are re-ordered in transit. 174 To avoid CBC encryption of very similar plaintext blocks in different 175 packets, implementations MUST NOT use a counter or other low-Hamming 176 distance source for IVs. 178 4. Test Vectors 180 The first 2 test cases test SEED-CBC encryption. Each test case 181 includes key, the plaintext, and the resulting ciphertext. All data 182 are hexadecimal numbers(not prefixed by "0x"). 184 The last 4 test cases illustrate sample ESP packets using SEED-CBC 185 for encryption. All data are hexadecimal numbers(not prefixed by 186 "0x"). 188 Case #1 : Encrypting 32 bytes (2 blocks) using SEED-CBC with 189 128-bit key 190 Key : ed2401ad 22fa2559 91bafdb0 1fefd697 191 IV : 93eb149f 92c9905b ae5cd34d a06c3c8e 192 PlainText : b40d7003 d9b6904b 35622750 c91a2457 193 5bb9a632 364aa26e 3ac0cf3a 9c9d0dcb 194 CipherText : f072c5b1 a0588c10 5af8301a dcd91dd0 195 67f68221 55304bf3 aad75ceb 44341c25 197 Case #2 : Encrypting 64 bytes (4 blocks) using SEED-CBC with 198 128-bit key 199 Key : 88e34f8f 081779f1 e9f39437 0ad40589 200 IV : 268d66a7 35a81a81 6fbad9fa 36162501 201 PlainText : d76d0d18 327ec562 b15e6bc3 65ac0c0f 202 8d41e0bb 938568ae ebfd92ed 1affa096 203 394d20fc 5277ddfc 4de8b0fc e1eb2b93 204 d4ae40ef 4768c613 b50b8942 f7d4b9b3 205 CipherText : a293eae9 d9aebfac 37ba714b d774e427 206 e8b706d7 e7d9a097 228639e0 b62b3b34 207 ced11609 cef2abaa ec2edf97 9308f379 208 c31527a8 267783e5 cba35389 82b48d06 210 Case #3 : Sample transport-mode ESP packet (ping 192.168.123.100) 211 Key : 90d382b4 10eeba7a d938c46c ec1a82bf 212 SPI : 4321 213 Source address : 192.168.123.3 214 Destination address : 192.168.123.100 215 Sequence number : 1 216 IV : e96e8c08 ab465763 fd098d45 dd3ff893 218 Original packet : 219 IP header (20 bytes) : 45000054 08f20000 4001f9fe c0a87b03 c0a87b64 220 Data (64 bytes) : 221 08000ebd a70a0000 8e9c083d b95b0700 222 08090a0b 0c0d0e0f 10111213 14151617 223 18191a1b 1c1d1e1f 20212223 24252627 224 28292a2b 2c2d2e2f 30313233 34353637 226 Augment data with : 227 Padding : 01020304 05060708 090a0b0c 0d0e 228 Pad length : 0e 229 Next header : 01 (ICMP) 231 Pre-encryption Data with padding, pad length and next header(80 232 bytes): 233 08000ebd a70a0000 8e9c083d b95b0700 234 08090a0b 0c0d0e0f 10111213 14151617 235 18191a1b 1c1d1e1f 20212223 24252627 236 28292a2b 2c2d2e2f 30313233 34353637 237 01020304 05060708 090a0b0c 0d0e0e01 239 Post-encryption packet with SPI, Sequence number, IV : 240 IP Header : 45000054 08f20000 4001f9fe c0a87b03 c0a87b64 241 SPI/Seq # : 00004321 00000001 242 IV : e96e8c08 ab465763 fd098d45 dd3ff893 243 Encrypted Data (80 bytes) : 244 e7ebaa03 cf45ef09 021b3011 b40d3769 245 be96ebae cd4222f6 b6f84ce5 b2d5cdd1 246 60eb6b0e 5a47d16a 501a4d10 7b2d7cc8 247 ab86ba03 9a000972 66374fa8 f87ee0fb 248 ef3805db faa144a2 334a34db 0b0f81ca 250 Case #4 : Sample transport-mode ESP packet 251 (ping -p 77 -s 20 192.168.123.100) 252 Key : 90d382b4 10eeba7a d938c46c ec1a82bf 253 SPI : 4321 254 Source address : 192.168.123.3 255 Destination address : 192.168.123.100 256 Sequence number : 8 257 IV : 69d08df7 d203329d b093fc49 24e5bd80 259 Original packet: 260 IP header (20 bytes) : 45000030 08fe0000 4001fa16 c0a87b03 c0a87b64 261 Data (28 bytes) : 262 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 264 Augment data with : 265 Padding : 0102 266 Pad length : 02 267 Next header : 01 (ICMP) 269 Pre-encryption Data with padding, pad length and 270 next header(32 bytes): 271 0800b5e8 a80a0500 a69c083d 0b660e00 272 77777777 77777777 77777777 01020201 274 Post-encryption packet with SPI, Sequence number, IV : 275 IP header : 4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64 276 SPI/Seq # : 00004321 00000008 277 IV : 69d08df7 d203329d b093fc49 24e5bd80 278 Encrypted Data (32 bytes) : 279 b9ad6e19 e9a6a2fa 02569160 2c0af541 280 db0b0807 e1f660c7 3ae2700b 5bb5efd1 282 Case #5 : Sample tunnel-mode ESP packet (ping 192.168.123.200) 283 Key : 01234567 89abcdef 01234567 89abcdef 284 SPI : 8765 285 Source address : 192.168.123.3 286 Destination address : 192.168.123.200 287 Sequence number : 2 288 IV : f4e76524 4f6407ad f13dc138 0f673f37 289 Original packet : 290 IP header (20 bytes) : 45000054 09040000 4001f988 c0a87b03 c0a87bc8 291 Data (64 bytes) : 292 08009f76 a90a0100 b49c083d 02a20400 293 08090a0b 0c0d0e0f 10111213 14151617 294 18191a1b 1c1d1e1f 20212223 24252627 295 28292a2b 2c2d2e2f 30313233 34353637 297 Augment data with : 298 Padding : 01020304 05060708 090a 299 Pad length : 0a 300 Next header : 04 (IP-in-IP) 302 Pre-encryption Data with original IP header, padding, pad length and 303 next header (96 bytes) : 304 45000054 09040000 4001f988 c0a87b03 305 c0a87bc8 08009f76 a90a0100 b49c083d 306 02a20400 08090a0b 0c0d0e0f 10111213 307 14151617 18191a1b 1c1d1e1f 20212223 308 24252627 28292a2b 2c2d2e2f 30313233 309 34353637 01020304 05060708 090a0a04 311 Post-encryption packet with SPI, Sequence number, IV : 312 IP header : 4500008c 09050000 4032f91e c0a87b03 c0a87bc8 313 SPI/Seq # : 00008765 00000002 314 IV : f4e76524 4f6407ad f13dc138 0f673f37 315 Encrypted Data (96 bytes): 316 2638aa7b 05e71b54 9348082b 67b47b26 317 c565aed4 737f0bcb 439c0f00 73e7913c 318 3c8a3e4f 5f7a5062 003b78ed 7ca54a08 319 c7ce047d 5bec14e4 8cba1005 32a12097 320 8d7f5503 204ef661 729b4ea1 ae6a9178 321 59a5caac 46e810bd 7875bd13 d6f57b3d 323 Case #6 : Sample tunnel-mode ESP packet 324 (ping -p ff -s 40 192.168.123.200) 325 Key : 01234567 89abcdef 01234567 89abcdef 326 SPI : 8765 327 Source address : 192.168.123.3 328 Destination address : 192.168.123.200 329 Sequence number : 5 330 IV : 85d47224 b5f3dd5d 2101d4ea 8dffab22 332 Original packet : 333 IP header (20 bytes) : 334 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 335 Data (48 bytes) : 336 0800d63c aa0a0200 c69c083d a3de0300 337 ffffffff ffffffff ffffffff ffffffff 338 ffffffff ffffffff ffffffff ffffffff 340 Augment data with : 341 Padding : 01020304 05060708 090a 342 Pad length : 0a 343 Next header : 04 (IP-in-IP) 345 Pre-encryption Data with original IP header, padding, pad length and 346 next header (80 bytes): 347 45000044 090c0000 4001f990 c0a87b03 348 c0a87bc8 0800d63c aa0a0200 c69c083d 349 a3de0300 ffffffff ffffffff ffffffff 350 ffffffff ffffffff ffffffff ffffffff 351 ffffffff 01020304 05060708 090a0a04 353 Post-encryption packet with SPI, Sequence number, IV : 354 IP header : 4500007c 090d0000 4032f926 c0a87b03 c0a87bc8 355 SPI/Seq # : 00008765 00000005 356 IV : 85d47224 b5f3dd5d 2101d4ea 8dffab22 357 Encrypted Data (80 bytes) : 358 311168e0 bc36ac4e 59802bd5 192c5734 359 8f3d29c8 90bab276 e9db4702 91f79ac7 360 79571929 c170f902 ffb2f08b d448f782 361 31671414 ff29b7e0 168e1c87 09ba2b67 362 a56e0fbc 4ff6a936 d859ed57 6c16ef1b 364 5. Interaction with IKE 366 5.1 Phase 1 Identifier 368 For Phase 1 negotiations, the object identifier of SEED-CBC is 369 defined in [SEED]. 371 algorithm OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410) 372 kisa(200004) algorithm(1) } 374 id-seedCBC OBJECT IDENTIFIER ::= { algorithm seedCBC(4) } 376 5.2 Phase 2 Identifier 378 For Phase 2 negotiations, IANA has assigned an ESP Transform 379 Identifier of (TBD) for ESP_SEED_CBC. 381 5.3 Key Length Attribute 383 Since the SEED supports 128 bit key lengths, the Key Length attribute 384 is set with 128 bits. 386 5.4 Hash Algorithm Considerations 388 HMAC-SHA-1[HMAC-SHA] and HMAC-MD5 [HMAC-MD5] are currently considered 389 of sufficient strength to serve both as IKE generators of 128-bit 390 SEED keys and as ESP authenticators for SEED encryption using 128-bit 391 keys. 393 6. Security Considerations 395 No security problem has been found on SEED. SEED is secure against 396 all known attacks including Differential cryptanalysis, Linear 397 cryptanalysis and related key attacks, etc. The best known attack is 398 only exhaustive search for the key (by [CRYPTREC]). For further 399 security considerations, the reader is encouraged to read 400 [CRYPTREC], [ISOSEED] and [SEED-EVAL]. 402 7. IANA Considerations 404 IANA has assigned ESP Transform Identifier (TBD) to ESP_SEED_CBC. 406 8. Acknowledgments 408 The authors want to thank Ph.D Haesuk Kim in FuturSystems and Brian 409 Kim in OULLIM for providing expert advice on Test Vector examples. 411 9. References 413 9.1 Normative References 415 [TTASSEED] Telecommunications Technology Association (TTA), 416 South Korea, "128-bit Symmetric Block Cipher (SEED)", 417 TTAS.KO-12.0004, September, 1998 (In Korean) 418 http://www.tta.or.kr/English/new/main/index.htm 420 [CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 421 Algorithms," RFC 2451, November 1998. 423 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 424 Payload (ESP)", RFC 2406, November 1998. 426 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange 427 (IKE)", RFC 2409, November 1998. 429 [SEED] Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee, 430 "The SEED Encryption Algorithm", RFC4009, February 2005. 432 9.2 Informative Reference 434 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard(AES), 435 November 2001. 436 http://csrc.nist.gov/publications/fips/fips197/fips-197. 437 {ps,pdf} 439 [AES-IPSEC] Frankel, S., S. Kelly, and R. Glenn, "The AES Cipher 440 Algorithm and Its Use With IPsec," RFC 3602, 441 September, 2003. 443 [ARCH] Kent, S. and R. Atkinson, "Security Architecture for 444 the Internet Protocol", RFC 2401, November 1998. 446 [CRYPTO-S] Schneier, B., "Applied Cryptography Second Edition", 447 John Wiley & Sons, New York, NY, 1995, ISBN 448 0-471-12845-7. 450 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 451 CRYPTREC. "SEED Evaluation Report", February, 2002 452 http://www.kisa.or.kr/seed/seed_eng.html 454 [HMAC-MD5] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 455 ESP and AH", RFC 2403, November 1998. 457 [HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 458 within ESP and AH", RFC 2404, November 1998. 460 [ISOSEED] ISO/IEC JTC 1/SC 27 N3979, "IT Security techniques - 461 Encryption Algorithms - Part3 : Block ciphers", June 462 2004. 464 [MODES] Symmetric Key Block Cipher Modes of Operation, 465 http://www.nist.gov/modes/. 467 [ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security 468 Document Roadmap", RFC 2411, November 1998. 470 [SEED-EVAL] KISA, "Self Evaluation Report", 471 http://www.kisa.or.kr/seed/data/Document_pdf/ 472 SEED_Self_Evaluation.pdf" 474 10. Authors' Address 476 Hyangjin Lee 477 Korea Information Security Agency 478 Phone: +82-2-405-5446 479 FAX : +82-2-405-5419 480 Email : jiinii@kisa.or.kr 481 Jaeho Yoon 482 Korea Information Security Agency 483 Phone: +82-2-405-5434 484 FAX : +82-2-405-5219 485 Email : jhyoon@kisa.or.kr 487 Seoklae Lee 488 Korea Information Security Agency 489 Phone: +82-2-405-5230 490 FAX : +82-2-405-5219 491 Email : sllee@kisa.or.kr 493 Jaeil Lee 494 Korea Information Security Agency 495 Phone: +82-2-405-5300 496 FAX : +82-2-405-5419 497 Email: jilee@kisa.or.kr 499 Intellectual Property Statement 501 The IETF takes no position regarding the validity or scope of any 502 Intellectual Property Rights or other rights that might be claimed to 503 pertain to the implementation or use of the technology described in 504 this document or the extent to which any license under such rights 505 might or might not be available; nor does it represent that it has 506 made any independent effort to identify any such rights. Information 507 on the procedures with respect to rights in RFC documents can be 508 found in BCP 78 and BCP 79. 510 Copies of IPR disclosures made to the IETF Secretariat and any 511 assurances of licenses to be made available, or the result of an 512 attempt made to obtain a general license or permission for the use of 513 such proprietary rights by implementers or users of this 514 specification can be obtained from the IETF on-line IPR repository at 515 http://www.ietf.org/ipr. 517 The IETF invites any interested party to bring to its attention any 518 copyrights, patents or patent applications, or other proprietary 519 rights that may cover technology that may be required to implement 520 this standard. Please address the information to the IETF at 521 ietf-ipr@ietf.org. 523 Disclaimer of Validity 525 This document and the information contained herein are provided on an 526 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 527 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 528 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 529 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 530 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 531 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 533 Copyright Statement 535 Copyright (C) The Internet Society (2005). This document is subject 536 to the rights, licenses and restrictions contained in BCP 78, and 537 except as set forth therein, the authors retain all their rights. 539 Acknowledgment 541 Funding for the RFC Editor function is currently provided by the 542 Internet Society.