1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
|
<pre>Network Working Group H.J. Lee
Request for Comments: 4196 J.H. Yoon
Category: Standards Track S.L. Lee
J.I. Lee
KISA
October 2005
<span class="h1">The SEED Cipher Algorithm and Its Use with IPsec</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the use of the SEED block cipher algorithm in
the Cipher Block Chaining Mode, with an explicit IV, as a
confidentiality mechanism within the context of the IPsec
Encapsulating Security Payload (ESP).
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. SEED</span>
SEED is a national industrial association standard [<a href="#ref-TTASSEED" title=""128-bit Symmetric Block Cipher (SEED)"">TTASSEED</a>] and is
widely used in South Korea for electronic commerce and financial
services that are operated on wired and wireless communications.
SEED is a 128-bit symmetric key block cipher that has been developed
by KISA (Korea Information Security Agency) and a group of experts
since 1998. The input/output block size of SEED is 128-bit and the
key 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 that
is generated from the key scheduling.
SEED is easily implemented in various software and hardware, and it
can be effectively adopted to a computing environment with restricted
resources, such as mobile devices and smart cards.
<span class="grey">Lee, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4196">RFC 4196</a> The Use of SEED with IPsec October 2005</span>
SEED is robust against known attacks including DC (Differential
cryptanalysis), LC (Linear cryptanalysis), and related key attacks.
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)[<a href="#ref-ISOSEED" title=""IT Security techniques - Encryption Algorithms - Part3 : Block ciphers"">ISOSEED</a>][CRYPTREC].
The remainder of this document specifies the use of SEED within the
context of IPsec ESP. For further information on how the various
pieces of ESP fit together to provide security services, please refer
to [<a href="#ref-ARCH" title=""Security Architecture for the Internet Protocol"">ARCH</a>], [<a href="#ref-ESP" title=""IP Encapsulating Security Payload (ESP)"">ESP</a>], and [<a href="#ref-ROAD" title=""IP Security Document Roadmap"">ROAD</a>].
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
as shown) are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="#ref-KEYWORDS" title=""Key words for use in RFCs to Indicate Requirement Levels"">KEYWORDS</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. The SEED Cipher Algorithm</span>
All symmetric block cipher algorithms share common characteristics
and variables, including mode, key size, weak keys, block size, and
rounds. The following sections contain descriptions of the relevant
characteristics of SEED.
The algorithm specification and object identifiers are described in
[<a href="#ref-ISOSEED" title=""IT Security techniques - Encryption Algorithms - Part3 : Block ciphers"">ISOSEED</a>] [<a href="#ref-SEED" title=""The SEED Encryption Algorithm"">SEED</a>]. The SEED homepage,
<a href="http://www.kisa.or.kr/seed/seed_eng.html">http://www.kisa.or.kr/seed/seed_eng.html</a>, contains a wealth of
information about SEED, including a detailed specification,
evaluation report, test vectors, and so on.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Mode</span>
NIST has defined 5 modes of operation for the Advanced Encryption
Standard (AES) [<a href="#ref-AES" title=""Advanced Encryption Standard(AES)">AES</a>] and other FIPS-approved ciphers [<a href="#ref-MODES">MODES</a>]: CBC
(Cipher Block Chaining), ECB (Electronic Codebook), CFB (Cipher
FeedBack), OFB (Output FeedBack), and CTR (Counter). The CBC mode is
well-defined and well-understood for symmetric ciphers, and is
currently required for all other ESP ciphers. This document
specifies the use of the SEED cipher in the CBC mode within ESP.
This mode requires an Initialization Vector (IV) that is the same
size as the block size. Use of a randomly generated IV prevents
generation of identical ciphertext from packets that have identical
data that spans the first block of the cipher algorithm's block size
The IV is XOR'd with the first plaintext block before it is
encrypted. Then for successive blocks, the previous ciphertext block
is XOR'd with the current plaintext before it is encrypted.
<span class="grey">Lee, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4196">RFC 4196</a> The Use of SEED with IPsec October 2005</span>
More information on the CBC mode can be obtained in [<a href="#ref-MODES">MODES</a>]
[<a href="#ref-CRYPTO-S" title=""Applied Cryptography Second Edition"">CRYPTO-S</a>]. For use of the CBC mode in ESP with 64-bit ciphers,
please see [<a href="#ref-CBC" title=""The ESP CBC-Mode Cipher Algorithms"">CBC</a>].
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Key Size and Numbers of Rounds</span>
SEED supports 128-bit key and has the 16-round Feistel structure.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Weak Keys</span>
At the time this document was written, there were no known weak keys
for SEED.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Block Size and Padding</span>
SEED uses a block size of 16 octets (128 bits).
Padding is required by SEED to maintain a 16-octet (128-bit)
blocksize. Padding MUST be added, as specified in [<a href="#ref-ESP" title=""IP Encapsulating Security Payload (ESP)"">ESP</a>], such that
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.
Because of the algorithm specific padding requirement, no additional
padding is required to ensure that the ciphertext terminates on a 4-
octet boundary (i.e., maintaining a 16-octet blocksize guarantees
that the ESP Pad Length and Next Header fields will be right aligned
within a 4-octet word). Additional padding MAY be included, as
specified in [<a href="#ref-ESP" title=""IP Encapsulating Security Payload (ESP)"">ESP</a>], as long as the 16-octet blocksize is maintained.
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Performance</span>
Performance figures of SEED are available at
<a href="http://www.kisa.or.kr/seed/seed_eng.html">http://www.kisa.or.kr/seed/seed_eng.html</a>
<span class="grey">Lee, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4196">RFC 4196</a> The Use of SEED with IPsec October 2005</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. ESP Payload</span>
The ESP Payload is made up of the Initialization Vector(IV) of 16
octets followed by the encrypted payload. Thus, the payload field,
as defined in [<a href="#ref-ESP" title=""IP Encapsulating Security Payload (ESP)"">ESP</a>], is broken down according to the following
diagram:
+---------------+---------------+---------------+---------------+
| |
+ Initialization Vector (16 octets) +
| |
+---------------+---------------+---------------+---------------+
| |
~ Encrypted Payload (variable length, a multiple of 16 octets) ~
| |
+---------------------------------------------------------------+
The IV field MUST be the same size as the block size of the cipher
algorithm being used. The IV MUST be chosen at random and MUST be
unpredictable.
Including the IV in each datagram ensures that decryption of each
received datagram can be performed, even when some datagrams are
dropped or re-ordered in transit.
To avoid CBC encryption of very similar plaintext blocks in different
packets, implementations MUST NOT use a counter or other low-hamming
distance source for IVs.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Test Vectors</span>
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
<span class="grey">Lee, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4196">RFC 4196</a> The Use of SEED with IPsec October 2005</span>
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
<span class="grey">Lee, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4196">RFC 4196</a> The Use of SEED with IPsec October 2005</span>
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
<span class="grey">Lee, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4196">RFC 4196</a> The Use of SEED with IPsec October 2005</span>
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
<span class="grey">Lee, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4196">RFC 4196</a> The Use of SEED with IPsec October 2005</span>
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
<span class="grey">Lee, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4196">RFC 4196</a> The Use of SEED with IPsec October 2005</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Interaction with IKE</span>
This section describes the use of IKE [<a href="#ref-IKE" title=""The Internet Key Exchange (IKE)"">IKE</a>] to establish IPsec ESP
security associations (SAs) that employ SEED in CBC mode.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Phase 1 Identifier</span>
For Phase 1 negotiations, the object identifier of SEED-CBC is
defined in [<a href="#ref-SEED" title=""The SEED Encryption Algorithm"">SEED</a>].
algorithm OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410)
kisa(200004) algorithm(1) }
id-seedCBC OBJECT IDENTIFIER ::= { algorithm seedCBC(4) }
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Phase 2 Identifier</span>
For Phase 2 negotiations, IANA has assigned an ESP Transform
Identifier of (21) for ESP_SEED_CBC.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Key Length Attribute</span>
Since the SEED supports 128-bit key lengths, the Key Length attribute
is set with 128 bits.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Hash Algorithm Considerations</span>
HMAC-SHA-1 [<a href="#ref-HMAC-SHA" title=""The Use of HMAC-SHA-1-96 within ESP and AH"">HMAC-SHA</a>] and HMAC-MD5 [<a href="#ref-HMAC-MD5" title=""The Use of HMAC-MD5-96 within ESP and AH"">HMAC-MD5</a>] are currently
considered of sufficient strength to serve both as IKE generators of
128-bit SEED keys and as ESP authenticators for SEED encryption using
128-bit keys.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
No security problem has been found on SEED. SEED is secure against
all known attacks including Differential cryptanalysis, Linear
cryptanalysis, and related key attacks. The best known attack is
only an exhaustive search for the key (by [<a href="#ref-CRYPTREC" title=""SEED Evaluation Report"">CRYPTREC</a>]). For further
security considerations, the reader is encouraged to read [<a href="#ref-CRYPTREC" title=""SEED Evaluation Report"">CRYPTREC</a>],
[<a href="#ref-ISOSEED" title=""IT Security techniques - Encryption Algorithms - Part3 : Block ciphers"">ISOSEED</a>], and [<a href="#ref-SEED-EVAL" title=""Self Evaluation Report"">SEED-EVAL</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IANA has assigned ESP Transform Identifier (21) to ESP_SEED_CBC.
<span class="grey">Lee, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4196">RFC 4196</a> The Use of SEED with IPsec October 2005</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
The authors want to thank Ph.D Haesuk Kim of Future Systems Inc. and
Brian Kim of OULLIM Information Technology Inc. for providing expert
advice on Test Vector examples.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-CBC">CBC</a>] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", <a href="./rfc2451">RFC 2451</a>, November 1998.
[<a id="ref-ESP">ESP</a>] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", <a href="./rfc2406">RFC 2406</a>, November 1998.
[<a id="ref-IKE">IKE</a>] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", <a href="./rfc2409">RFC 2409</a>, November 1998.
[<a id="ref-KEYWORDS">KEYWORDS</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-SEED">SEED</a>] Park, J., Lee, S., Kim, J., and J. Lee, "The SEED
Encryption Algorithm", <a href="./rfc4009">RFC 4009</a>, February 2005.
[<a id="ref-TTASSEED">TTASSEED</a>] Telecommunications Technology Association (TTA), South
Korea, "128-bit Symmetric Block Cipher (SEED)", TTAS.KO-
12.0004, September, 1998 (In Korean)
<a href="http://www.tta.or.kr/English/new/main/index.htm">http://www.tta.or.kr/English/new/main/index.htm</a>
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative Reference</span>
[<a id="ref-AES">AES</a>] NIST, FIPS PUB 197, "Advanced Encryption Standard(AES),
November 2001.
<a href="http://csrc.nist.gov/publications/fips/fips197/fips-197">http://csrc.nist.gov/publications/fips/fips197/fips-197</a>.
{ps,pdf}
[<a id="ref-ARCH">ARCH</a>] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November 1998.
[<a id="ref-CRYPTO-S">CRYPTO-S</a>] Schneier, B., "Applied Cryptography Second Edition", John
Wiley & Sons, New York, NY, 1995, ISBN 0-471-12845-7.
[<a id="ref-CRYPTREC">CRYPTREC</a>] Information-technology Promotion Agency (IPA), Japan,
CRYPTREC. "SEED Evaluation Report", February, 2002
<a href="http://www.kisa.or.kr/seed/seed_eng.html">http://www.kisa.or.kr/seed/seed_eng.html</a>
<span class="grey">Lee, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4196">RFC 4196</a> The Use of SEED with IPsec October 2005</span>
[<a id="ref-HMAC-MD5">HMAC-MD5</a>] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", <a href="./rfc2403">RFC 2403</a>, November 1998.
[<a id="ref-HMAC-SHA">HMAC-SHA</a>] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", <a href="./rfc2404">RFC 2404</a>, November 1998.
[<a id="ref-ISOSEED">ISOSEED</a>] ISO/IEC JTC 1/SC 27 N3979, "IT Security techniques -
Encryption Algorithms - Part3 : Block ciphers", June
2004.
[<a id="ref-MODES">MODES</a>] Symmetric Key Block Cipher Modes of Operation,
<a href="http://www.nist.gov/modes/">http://www.nist.gov/modes/</a>.
[<a id="ref-ROAD">ROAD</a>] Thayer, R., N. Doraswamy and R. Glenn, "IP Security
Document Roadmap", <a href="./rfc2411">RFC 2411</a>, November 1998.
[<a id="ref-SEED-EVAL">SEED-EVAL</a>] KISA, "Self Evaluation Report",
<a href="http://www.kisa.or.kr/seed/data/Document_pdf/SEED_Self_Evaluation.pdf">http://www.kisa.or.kr/seed/data/Document_pdf/</a>
<a href="http://www.kisa.or.kr/seed/data/Document_pdf/SEED_Self_Evaluation.pdf">SEED_Self_Evaluation.pdf</a>"
Authors' Address
Hyangjin Lee
Korea Information Security Agency
Phone: +82-2-405-5446
Fax : +82-2-405-5319
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
Korea Information Security Agency
Phone: +82-2-405-5200
Fax : +82-2-405-5219
EMail: jilee@kisa.or.kr
<span class="grey">Lee, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4196">RFC 4196</a> The Use of SEED with IPsec October 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
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.
Intellectual Property
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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lee, et al. Standards Track [Page 12]
</pre>
|
