idnits 2.17.1 draft-lee-tls-seed-01.txt: -(220): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 244. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 234. ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 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 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 (January 2005) is 7039 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: 'SEED' is defined on line 151, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SEED' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 3268 (ref. 'AES-TLS') (Obsoleted by RFC 5246) == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-01 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Hyangjin Lee(KISA) 3 INTERNET-DRAFT Jaeho Yoon(KISA) 4 Document: draft-lee-tls-seed-01.txt Jaeil Lee(KISA) 5 Expiration Date: July 2005 January 2005 7 Addition of SEED Ciphersuites to Transport Layer Security (TLS) 9 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document proposes the addition of new cipher suites to the 37 Transport Layer Security (TLS) protocol to support the SEED 38 encryption algorithm as a bulk cipher algorithm. 40 1. Introduction 42 This document proposes the addition of new cipher suites to the TLS 43 protocol [TLS] to support the SEED encryption algorithm as a bulk 44 cipher algorithm. 46 1.1. SEED 48 SEED is a symmetric encryption algorithm that had been developed by 49 KISA(Korea Information Security Agency) and a group of experts since 50 1998. The input/output block size of SEED is 128-bit and the key 51 length is also 128-bit. SEED has the 16-round Feistel structure. A 52 128-bit input is divided into two 64-bit blocks and the right 64-bit 53 block is an input to the round function with a 64-bit subkey 54 generated from the key scheduling. 56 SEED is easily implemented in various software and hardware because 57 it is designed to increase the efficiency of memory storage and the 58 simplicity in generating keys without degrading the security of the 59 algorithm. In particular, it can be effectively adopted to a 60 computing environment with a restricted resources such as a mobile 61 devices, smart cards and so on. 63 SEED is a national industrial association standard [TTASSEED] and is 64 widely used in South Korea for electronic commerce and financial 65 services operated on wired & wireless PKI. 67 The algorithm specification and object identifiers are described in 68 [SEED-ID]. The SEED homepage, 69 http://www.kisa.or.kr/seed/seed_eng.html, contains a wealth of 70 information about SEED, including detailed specification, evaluation 71 report, test vectors, and so on. 73 1.2. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 76 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 77 as shown) are to be interpreted as described in [RFC2119]. 79 2. Proposed Cipher Suites 81 The new ciphersuites proposed here have the following definitions: 83 CipherSuite TLS_RSA_WITH_SEED_CBC_SHA = { 0x00, 0x96}; 84 CipherSuite TLS_DH_DSS_WITH_SEED_CBC_SHA = { 0x00, 0x97}; 85 CipherSuite TLS_DH_RSA_WITH_SEED_CBC_SHA = { 0x00, 0x98}; 86 CipherSuite TLS_DHE_DSS_WITH_SEED_CBC_SHA = { 0x00, 0x99}; 87 CipherSuite TLS_DHE_RSA_WITH_SEED_CBC_SHA = { 0x00, 0x9A}; 88 CipherSuite TLS_DH_anon_WITH_SEED_CBC_SHA = { 0x00, 0x9B}; 90 3. CipherSuite Definitions 91 3.1. Cipher 93 All the ciphersuites described here use SEED in cipher block 94 chaining(CBC) mode as a bulk cipher algorithm. SEED is a 128-bit 95 block cipher with 128-bit key size. 97 3.2. Hash 99 All the ciphersuites described here use SHA-1 [SHA-1] in an HMAC 100 construction as described in section 5 of [TLS]. 102 3.3. Key exchange 104 The ciphersuites defined here differ in the type of certificate and 105 key exchange method. They use the following options: 107 CipherSuite Key Exchange Algorithm 109 TLS_RSA_WITH_SEED_CBC_SHA RSA 110 TLS_DH_DSS_WITH_SEED_CBC_SHA DH_DSS 111 TLS_DH_RSA_WITH_SEED_CBC_SHA DH_RSA 112 TLS_DHE_DSS_WITH_SEED_CBC_SHA DHE_DSS 113 TLS_DHE_RSA_WITH_SEED_CBC_SHA DHE_RSA 114 TLS_DH_anon_WITH_SEED_CBC_SHA DH_anon 116 For the meanings of the terms RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA 117 and DH_anon, please refer to sections 7.4.2 and 7.4.3 of [TLS]. 119 4. IANA considerations 121 IANA does not currently have a registry for TLS-related numbers, so 122 there are no IANA actions associated with this document. 124 5. Security Considerations 126 It is not believed that the new ciphersuites are ever less secure 127 than the corresponding older ones. No security problem has been found 128 on SEED. SEED is robust against known attacks including Differential 129 cryptanalysis, Linear cryptanalysis and related key attacks, etc. 130 SEED has gone through wide public scrutinizing procedures. 131 Especially, it has been evaluated and also considered 132 cryptographically secure by trustworthy organizations such as ISO/IEC 133 JTC 1/SC 27 and Japan CRYPTREC (Cryptography Research and Evaluation 134 Committees) [ISOSEED][CRYPTREC]. SEED has been submitted to other 135 several standardization bodies such as ISO(ISO/IEC 18033-3), IETF 136 S/MIME Mail Security [SEED-SMIME] and it is under consideration. For 137 further security considerations, the reader is encouraged to read 138 [SEED-EVAL]. 140 For other security considerations, please refer to the security of 141 the corresponding older ciphersuites described in [TLS] and [AES- 142 TLS]. 144 6. References 146 6.1 Normative Reference 148 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 149 Requirement Levels", BCP 14, RFC 2119, March 1997. 151 [SEED] KISA, "SEED Algorithm Specification", 152 http://www.kisa.or.kr/seed/seed_eng.html" 154 [TLS] T. Dierks, and C. Allen, "The TLS Protocol Version 1.0", 155 RFC 2246, January 1999. 157 6.2 Informative Reference 159 [AES-TLS] P. Chown, "Advanced Encryption Standard (AES) 160 Ciphersuites for Transport Layer Security (TLS)", 161 RFC 3268, June 2002. 163 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 164 CRYPTREC. "SEED Evaluation Report", February, 2002 165 http://www.kisa.or.kr/seed/seed_eng.html 167 [ISOSEED] ISO/IEC JTC 1/SC 27, "National Body contributions on 168 NP 18033 "Encryption Algorithms" in Response to SC 27 169 N2563 (ATT.3 Korea Contribution)", ISO/IEC JTC 1/SC 27 170 N2656r1 (n2656_3.zip), October, 2000 172 [SEED-EVAL] KISA, "Self Evaluation Report", 173 http://www.kisa.or.kr/seed/seed_eng.html" 175 [SEED-ID] Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee, 176 "The SEED Encryption Algorithm", draft-park-seed-01.txt, 177 April, 2004. 179 [SEED-SMIME] Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee, 180 "Use of the SEED Encryption Algorithm in CMS", 181 draft-ietf-smime-cms-01.txt, April, 2004. 183 [SHA-1] FIPS PUB 180-1, "Secure Hash Standard", National Institute 184 of Standards and Technology, U.S. Department of Commerce, 185 April 17, 1995. 187 [TTASSEED] Telecommunications Technology Association (TTA), 188 South Korea, "128-bit Symmetric Block Cipher (SEED)", 189 TTAS.KO-12.0004, September, 1998 (In Korean) 190 http://www.tta.or.kr/English/new/main/index.htm 192 7. Authors�� Addresses 194 Hyangjin Lee 195 Korea Information Security Agency 196 Phone: +82-2-405-5446 197 FAX : +82-2-405-5499 198 Email: jiinii@kisa.or.kr 200 Jaeho Yoon 201 Korea Information Security Agency 202 Phone: +82-2-405-5434 203 FAX : +82-2-405-5499 204 Email: jhyoon@kisa.or.kr 206 Jaeil Lee 207 Korea Information Security Agency 208 Phone: +82-2-405-5300 209 FAX : +82-2-405-5499 210 Email: jilee@kisa.or.kr 212 Intellectual Property Statement 214 The IETF takes no position regarding the validity or scope of any 215 Intellectual Property Rights or other rights that might be claimed 216 to pertain to the implementation or use of the technology described 217 in this document or the extent to which any license under such 218 rights might or might not be available; nor does it represent that 219 it has made any independent effort to identify any such rights. 220 Information on the IETF��s procedures with respect to rights in IETF 221 Documents can be found in BCP 78 and BCP 79. 223 Copies of IPR disclosures made to the IETF Secretariat and any 224 assurances of licenses to be made available, or the result of an 225 attempt made to obtain a general license or permission for the use 226 of such proprietary rights by implementers or users of this 227 specification can be obtained from the IETF on-line IPR repository 228 at http://www.ietf.org/ipr. 230 The IETF invites any interested party to bring to its attention any 231 copyrights, patents or patent applications, or other proprietary 232 rights that may cover technology that may be required to implement 233 this standard. Please address the information to the IETF at 234 ietf-ipr@ietf.org. 236 Disclaimer of Validity 238 This document and the information contained herein are provided on an 239 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 240 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 241 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 242 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 243 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 244 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 246 Copyright Statement 248 Copyright (C) The Internet Society (2005). This document is subject 249 to the rights, licenses and restrictions contained in BCP 78, and 250 except as set forth therein, the authors retain all their rights. 252 Acknowledgment 254 Funding for the RFC Editor function is currently provided by the 255 Internet Society.