One document matched: draft-lee-ipsec-cipher-seed-00.txt
IPSec Working Group Hyanjin Lee (KISA)
Internet Draft Jaeil Lee (KISA)
draft-lee-ipsec-cipher-seed-00.txt June 2004
Expires December 2004 Target category : Standard Track
The SEED Cipher Algorithm and Its Use With IPSec
<draft-lee-ipsec-cipher-seed-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments or suggestions for improvement may be made on the "ietf-
ipsec" mailing list or directly to the author.
Abstract
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. Introduction
This document describes the use of the SEED block cipher algorithm in
Cipher Block Chaining Mode, with an explicit IV, as a confidentiality
Lee, et. al. Expires - December 2004 [Page 1]
INTERNET-DRAFT The Use of SEED with IPSec June 2004
mechanism within the context of the IPsec Encapsulating Security
Payload (ESP).
1.1 SEED
SEED is a symmetric encryption algorithm that had 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
generated from the key scheduling.
SEED is easily implemented in various software and hardware because
it is designed to increase the efficiency of memory storage and the
simplicity in generating keys without degrading the security of the
algorithm. In particular, it can be effectively adopted to a
computing environment with a restricted resources such as a mobile
devices, smart cards and so on.
SEED is robust against known attacks including Differential
cryptanalysis, Linear cryptanalysis and related key attacks, etc.
SEED has gone through wide public scrutinizing procedures.
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
widely used in South Korea for electronic commerce and financial
services operated on wired & wireless PKI.
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 [ARCH], [ESP], and [ROAD].
1.2 Terminology
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 [RFC2119].
Lee, et. al. Expires - December 2004 [Page 2]
INTERNET-DRAFT The Use of SEED with IPSec June 2004
2. The SEED Cipher Algorithm
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
[SEED-ID]. The SEED homepage,
http://www.kisa.or.kr/seed/seed_eng.html, contains a wealth of
information about SEED, including detailed specification, evaluation
report, test vectors, and so on.
2.1 Mode
NIST has defined 5 modes of operation for AES and other FIPS-approved
ciphers [MODES]: 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 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 which
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.
More information on CBC mode can be obtained in [MODES, CRYPTO-S].
For the use of CBC mode in ESP with 64-bit ciphers, please see [CBC].
2.2 Key Size and Numbers of Rounds
SEED supports 128-bit key and has the 16-round Feistel structure.
2.3 Weak Keys
At the time of writing this document there are no known weak keys for
SEED.
2.4 Block Size and Padding
SEED uses a block size of sixteen octets (128 bits).
Padding is required by the SEED to maintain a 16-octet (128-bit)
Lee, et. al. Expires - December 2004 [Page 3]
INTERNET-DRAFT The Use of SEED with IPSec June 2004
blocksize. Padding MUST be added, as specified in [ESP], 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 [ESP], as long as the 16-octet blocksize is maintained.
2.5 Performance
Performance figures of SEED are available at
http://www.kisa.or.kr/seed/seed_eng.html. It also includes
performance comparision with the AES and Camellia cipher.
3. ESP Payload
SEED was designed to follow the same API as the AES cipher.
Therefore, any consideration related to ESP payload is the same as
that of the AES cipher. Details can be found in [AES-IPSEC].
4. Interaction with IKE
SEED was designed to follow the same API as the AES cipher.
Therefore, this section defines only Phase 1 Identifier and Phase 2
Identifier. Any other consideration related to interaction with IKE
is the same as that of the AES cipher. Details can be found in
[AES-IPSEC].
4.1 Phase 1 Identifier
For Phase 1 negotiations, IANA has assigned an Encryption Algorithm
ID of (TBD) for SEED-CBC.
4.2 Phase 2 Identifier
For Phase 2 negotiations, IANA has assigned an ESP Transform
Identifier of (TBD) for ESP_SEED.
4.3 Key Length Attribute
Since the SEED supports 128 bit key lengths, the Key Length attribute
is set with 128 bits.
Lee, et. al. Expires - December 2004 [Page 4]
INTERNET-DRAFT The Use of SEED with IPSec June 2004
4.4 Hash Algorithm Considerations
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
SEED keys and as ESP authenticators for SEED encryption using 128-bit
keys.
5. Security Considerations
No security problem has been found on SEED. SEED is secure against
all known attacks including Differential cryptanalysis, Linear
cryptanalysis and related key attacks, etc. The best known attack is
only exhaustive search for the key (by [CRYPTEC]). For further
security considerations, the reader is encouraged to read [CRYPTEC],
[ISOSEED] and [SEED-EVAL].
6. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
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
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
[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.
Lee, et. al. Expires - December 2004 [Page 5]
INTERNET-DRAFT The Use of SEED with IPSec June 2004
[SEED] Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee,
"The SEED Encryption Algorithm", draft-park-seed-00.txt
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for
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",
John Wiley & Sons, New York, NY, 1995, ISBN
0-471-12845-7.
[CRYPTREC] Information-technology Promotion Agency (IPA), Japan,
CRYPTREC. "SEED Evaluation Report", February, 2002
http://www.kisa.or.kr/seed/seed_eng.html
[DOI] Piper, D., "The Internet IP Security Domain of
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.
[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
within ESP and AH", RFC 2404, November 1998.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[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,
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.
Lee, et. al. Expires - December 2004 [Page 6]
INTERNET-DRAFT The Use of SEED with IPSec June 2004
[ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security
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",
http://www.kisa.or.kr/seed/seed_eng.html"
[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."
Lee, et. al. Expires - December 2004 [Page 7]
INTERNET-DRAFT The Use of SEED with IPSec June 2004
9. Authors' Address
Hyangjin Lee
Korea Information Security Agency
Phone: +82-2-405-5446
FAX : +82-2-405-5419
Email : jiinii@kisa.or.kr
Jaeil Lee
Korea Information Security Agency
Phone: +82-2-405-5300
FAX : +82-2-405-5419
Email: jilee@kisa.or.kr
Lee, et. al. Expires - December 2004 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 01:51:46 |