idnits 2.17.00 (12 Aug 2021) /tmp/idnits26616/draft-songlee-aes-cmac-96-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 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 282. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 12 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '3' on line 67 == Missing Reference: 'AES-XCBC-MAC' is mentioned on line 216, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-CMAC' -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'OMAC1' ** Obsolete normative reference: RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2411 (ref. 'ROADMAP') (Obsoleted by RFC 6071) -- Possible downref: Non-RFC (?) normative reference: ref. 'XCBC' == Outdated reference: draft-songlee-aes-cmac has been published as RFC 4493 ** Downref: Normative reference to an Informational draft: draft-songlee-aes-cmac (ref. 'AES-CMAC') Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 JunHyuk Song 2 Jicheol Lee 3 INTERNET DRAFT Samsung Electronics 4 Expires: November 24, 2005 May 25 2005 6 The AES-CMAC-96 Algorithm and its use with IPsec 7 draft-songlee-aes-cmac-96-01.txt 9 Status of This Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2005). 36 Abstract 38 National Institute of Standards and Technology (NIST) has newly 39 specified the Cipher based MAC (CMAC) which is equivalent to the 40 One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa. 41 OMAC1 efficiently reduces the key size of Extended Cipher Block 42 Chaining mode (XCBC). This memo specifies the use of CMAC mode on 43 authentication mechanism of IPsec Encapsulating Security Payload 44 (ESP) and the Authentication Header (AH) protocols. This new 45 algorithm is named AES-CMAC-96. 47 1. Introduction 49 National Institute of Standards and Technology (NIST) has newly 50 specified the Cipher based MAC (CMAC). CMAC [NIST-CMAC] is a keyed 51 hashed function that is based on a symmetric key block cipher such 52 as Advanced Encryption Standard [AES]. CMAC is equivalent to the 53 One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa 54 [OMAC1]. Although the OMAC1 algorithm is based on the eXtended Cipher 55 Block Chaining mode (XCBC) algorithm submitted by Rogaway and Black 56 [XCBC], OMAC1 efficiently reduces the key size of XCBC. 57 This memo specifies the usage of CMAC on authentication mechanism 58 of IPsec Encapsulating Security Payload (ESP) and the Authentication 59 Header (AH) protocols. This new algorithm is named AES-CMAC-96. 60 For further information on AH and ESP, refer to [AH] and [ROADMAP]. 62 2. Specification of Language 64 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC 2119 [3]. 68 In addition, the following words are used to signify the requirements 69 of the specification. 71 3. Basic definitions 73 CBC Cipher Block Chaining mode of operation for message 74 authentication code. 76 MAC Message Authentication Code. 77 A bitstring of a fixed length, computed by MAC 78 generation algorithm, that is used to established 79 the authority and hence, the integrity of a message. 81 CMAC Cipher-based MAC based on an approved symmetric key 82 block cipher, such as the Advanced Encryption 83 Standard. 85 Key (K) 128-bits (16bytes) long key for AES-128 cipher block. 86 Denoted by K. 88 Message (M) Message to be authenticated. 89 Denoted by M. 90 The total message M is denoted by sequence of M_i 91 where M_i is the i'th block with size 128-bit. 92 Message can be null message which means that the 93 length of M is 0. 95 Length (len) The length of message M in bytes. 96 Denoted by len. 97 Minimum value of the length can be 0. The maximum 98 value of the length is not specified in this document. 100 truncate(T,l) Truncate T (MAC) in msb-first order with l bytes. 102 T The output of AES-CMAC-128. 104 Truncated T The truncated output of AES-CMAC-128 in MSB first 105 order. 107 AES-CMAC CMAC generation function based on AES block cipher 108 with 128-bits key 110 AES-CMAC-96 IPsec AH and ESP MAC generation function based on 111 CMAC-AES-128 which truncates MSB 96 bits of 128 bits 112 output 114 4. AES-CMAC-96 116 The underlying algorithm for AES-CMAC-96 are Advanced Encryption 117 Standard cipher block [AES] and recently defined CMAC mode of 118 operation [NIST-CMAC]. The output of AES-CMAC can validate the 119 input message. Validating the message provide assurance of the 120 integrity and authenticity over the message from the source. 121 According to [NIST-CMAC] at least 64-bits should be used for 122 against guessing attack. 124 For use in IPsec message authentication on AH and ESP, AES-CMAC-96 125 should be used. AES-CMAC-96 is a AES-CMAC with 96-bit-long truncated 126 output in most significant bit first order. The output of 96 bits 127 MAC that will meet the default authenticator length as specified 128 in [AH]. The result of truncation should be taken in most 129 significant bits first order. For further information on 130 AES-CMAC, refer to [AES-CMAC] and [NIST-CMAC]. 132 Figure 1 describes AES-CMAC-96 algorithm: 134 In step 1, AES-CMAC is applied to the message 'M' in length 'len' 135 with key 'K' 137 In step 2, Truncate output block, T with 12 byte in msb-first-order 138 and return TT. 140 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 141 + Algorithm AES-CMAC-96 + 142 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 143 + + 144 + Input : K (128-bit Key described in section 4.1) + 145 + : M ( message to be authenticated ) + 146 + : len ( length of message in bytes ) + 147 + Output : Truncated T (Truncated output with length 12 bytes) + 148 + + 149 +-------------------------------------------------------------------+ 150 + + 151 + Step 1. T := AES-CMAC-128 (K,M,len); + 152 + Step 2. TT := truncate (T, 12); + 153 + return TT; + 154 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 156 Figure 1 Algorithm AES-CMAC-96 158 5. Test Vectors 160 These test cases same as defined in [NIST-CMAC] with one exception of 161 96 bits truncation 162 -------------------------------------------------- 163 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 164 Subkey Generation 165 AES_128(key,0) 7df76b0c 1ab899b3 3e42f047 b91b546f 166 K1 fbeed618 35713366 7c85e08f 7236a8de 167 K2 f7ddac30 6ae266cc f90bc11e e46d513b 169 Example 1: len = 0 170 M 171 AES_CMAC_96 bb1d6929 e9593728 7fa37d12 173 Example 2: len = 16 174 M 6bc1bee2 2e409f96 e93d7e11 7393172a 175 AES_CMAC_96 070a16b4 6b4d4144 f79bdd9d 177 Example 3: len = 40 178 M 6bc1bee2 2e409f96 e93d7e11 7393172a 179 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 180 30c81c46 a35ce411 181 AES_CMAC_96 dfa66747 de9ae630 30ca3261 183 Example 4: len = 64 184 M 6bc1bee2 2e409f96 e93d7e11 7393172a 185 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 186 30c81c46 a35ce411 e5fbc119 1a0a52ef 187 f69f2445 df4f9b17 ad2b417b e66c3710 188 AES_CMAC_96 51f0bebf 7e3b9d92 fc497417 189 -------------------------------------------------- 190 6. Interaction with the ESP Cipher Mechanism 192 As of this writing, there are no known issues which preclude the use 193 of AES-CMAC-96 with any specific cipher algorithm. 195 7. Security Considerations 197 The security provided by AES-CMAC-96 is based upon the strength of 198 AES. At the time of this writing there are no practical 199 cryptographic attacks against AES or AES-CMAC-96. 201 As is true with any cryptographic algorithm, part of its strength 202 lies in the correctness of the algorithm implementation, the security 203 of the key management mechanism and its implementation, the strength 204 of the associated secret key, and upon the correctness of the 205 implementation in all of the participating systems. This document 206 contains test vectors to assist in verifying the correctness of 207 AES-CMAC-96 code. 209 8. IANA Consideration 211 TBD 213 9. Acknowledgement 215 Portions of this text were borrowed from [NIST-CMAC] and 216 [AES-XCBC-MAC]. We would like to thank to OMAC1 author Tetsu Iwata 217 and Kaoru Kurosawa, and CMAC author Morris Dworkin. 219 10. References 221 [NIST-CMAC] NIST, Special Publication 800-38B Draft,"Recommendation 222 for Block Cipher Modes of Operation: The CMAC Method 223 for Authentication," March 9, 2005 225 [AES] NIST, FIPS 197, "Advanced Encryption Standard (AES)," 226 November 2001. 227 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf 229 [OMAC1] "OMAC: One-Key CBC MAC," Tetsu Iwata and Kaoru Kurosawa, 230 Department of Computer and Information Sciences, 231 Ilbaraki University, March 10, 2003. 233 [AH] Kent, S. and R. Atkinson, "IP Authentication Header", 234 RFC 2402, November 1998. 236 [ROADMAP] Thayer, R., N. Doraswamy, and R. Glenn, "IP Security 237 Document Roadmap", RFC 2411, November 1998. 239 [XCBC] Black, J. and P. Rogaway, "A Suggestion for Handling 240 Arbitrary-Length Messages with the CBC MAC," NIST 241 Second Modes of Operation Workshop, August 2001. 242 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 243 xcbc-mac/xcbc-mac-spec.pdf 245 [AES-CMAC] JunHyuk Song and Jicheol Lee, "The AES-CMAC Algorithm" 246 draft-songlee-aes-cmac-00.txt, May 2005 248 11. Author's Address 250 Junhyuk Song 251 Samsung Electronics 252 +82-31-279-3639 253 santajunman@hanafos.com 255 Jicheol Lee 256 Samsung Electronics 257 +82-31-279-3605 258 jicheol.lee@samsung.com 260 Intellectual Property Statement 262 The IETF takes no position regarding the validity or scope of any 263 Intellectual Property Rights or other rights that might be claimed to 264 pertain to the implementation or use of the technology described in 265 this document or the extent to which any license under such rights 266 might or might not be available; nor does it represent that it has 267 made any independent effort to identify any such rights. Information 268 on the procedures with respect to rights in RFC documents can be 269 found in BCP 78 and BCP 79. 271 Copies of IPR disclosures made to the IETF Secretariat and any 272 assurances of licenses to be made available, or the result of an 273 attempt made to obtain a general license or permission for the use of 274 such proprietary rights by implementers or users of this 275 specification can be obtained from the IETF on-line IPR repository at 276 http://www.ietf.org/ipr. 278 The IETF invites any interested party to bring to its attention any 279 copyrights, patents or patent applications, or other proprietary 280 rights that may cover technology that may be required to implement 281 this standard. Please address the information to the IETF at 282 ietf-ipr@ietf.org. 284 Disclaimer of Validity 286 This document and the information contained herein are provided on an 287 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 288 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 289 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 290 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 291 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 292 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 294 Copyright Statement 296 Copyright (C) The Internet Society (2005). This document is subject 297 to the rights, licenses and restrictions contained in BCP 78, and 298 except as set forth therein, the authors retain all their rights. 300 Acknowledgment 302 Funding for the RFC Editor function is currently provided by the 303 Internet Society.