idnits 2.17.00 (12 Aug 2021) /tmp/idnits27680/draft-songlee-aes-cmac-96-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 323. ** 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 an Authors' Addresses Section. ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 17 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) == Missing Reference: 'AES' is mentioned on line 111, but not defined == Missing Reference: 'AES-XCBC-MAC' is mentioned on line 213, but not defined == Unused Reference: 'OMAC1' is defined on line 227, but no explicit reference was found in the text == Unused Reference: 'XCBC' is defined on line 233, but no explicit reference was found in the text == Unused Reference: 'IKEv2' is defined on line 276, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-CMAC' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'OMAC1' ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- 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') ** Obsolete normative reference: RFC 2401 (ref. 'AH') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2411 (ref. 'ROADMAP') (Obsoleted by RFC 6071) -- Possible downref: Non-RFC (?) normative reference: ref. 'OMAC1a' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'RFC-HMAC') -- Possible downref: Non-RFC (?) normative reference: ref. 'OMAC1b' -- Possible downref: Non-RFC (?) normative reference: ref. 'XCBCa' -- Possible downref: Non-RFC (?) normative reference: ref. 'XCBCb' == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 JunHyuk Song 2 Radha Poovendran 3 University of Washington 4 Jicheol Lee 5 INTERNET DRAFT Samsung Electronics 6 Expires: May 30, 2006 November 30 2005 8 The AES-CMAC-96 Algorithm and its use with IPsec 9 draft-songlee-aes-cmac-96-03.txt 11 Status of This Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 National Institute of Standards and Technology (NIST) has newly 41 specified the Cipher based MAC (CMAC) which is equivalent to the 42 One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa. 43 OMAC1 efficiently reduces the key size of Extended Cipher Block 44 Chaining mode (XCBC). This memo specifies the use of CMAC mode on 45 authentication mechanism of IPsec Encapsulating Security Payload 46 (ESP) and the Authentication Header (AH) protocols. This new 47 algorithm is named AES-CMAC-96. 49 1. Introduction 51 National Institute of Standards and Technology (NIST) has newly 52 specified the Cipher-based Message Authentication Code (CMAC). 53 CMAC [NIST-CMAC] is a keyed hash function that is based on a 54 symmetric key block cipher such as the Advanced Encryption 55 Standard [NIST-AES]. CMAC is equivalent to the One-Key CBC MAC1 56 (OMAC1) submitted by Iwata and Kurosawa [OMAC1a, OMAC1b]. OMAC1 57 is an improvement of the eXtended Cipher Block Chaining mode (XCBC) 58 submitted by Black and Rogaway [XCBCa, XCBCb], which itself is an 59 improvement of the basic CBC-MAC. XCBC efficiently addresses the 60 security deficiencies of CBC-MAC, and OMAC1 efficiently reduces the 61 key size of XCBC. 63 This memo specifies the usage of CMAC on authentication mechanism 64 of IPsec Encapsulating Security Payload (ESP) [ESP] and the 65 Authentication Header (AH) protocols. This new algorithm is named 66 AES-CMAC-96. For further information on AH and ESP, refer to [AH] 67 and [ROADMAP]. 69 2. Basic definitions 71 CBC Cipher Block Chaining mode of operation for message 72 authentication code. 74 MAC Message Authentication Code. 75 A bit string of a fixed length, computed by MAC 76 generation algorithm, that is used to established 77 the authority and hence, the integrity of a message. 79 CMAC Cipher-based MAC based on an approved symmetric key 80 block cipher, such as the Advanced Encryption 81 Standard. 83 Key (K) 128-bits (16bytes) long key for AES-128 cipher block. 84 Denoted by K. 86 Message (M) Message to be authenticated. 87 Denoted by M. 89 Length (len) The length of message M in bytes. 90 Denoted by len. 91 Minimum value of the length can be 0. The maximum 92 value of the length is not specified in this document. 94 truncate(T,l) Truncate T (MAC) in msb-first order with l bytes. 96 T The output of AES-CMAC 97 Truncated T The truncated output of AES-CMAC-128 in MSB first 98 order. 100 AES-CMAC CMAC generation function based on AES block cipher 101 with 128-bits key 103 AES-CMAC-96 IPsec AH and ESP MAC generation function based on 104 AES-CMAC which truncates MSB 96 bits of 128 bits 105 output 107 3. AES-CMAC 109 The core of AES-CMAC-96 is the AES-CMAC [AES-CMAC]. The underlying 110 algorithm for AES-CMAC are Advanced Encryption Standard cipher block 111 [AES] and recently defined CMAC mode of operation [NIST-CMAC]. 112 AES-CMAC provides stronger assurance of data integrity than a 113 checksum or an error detecting code. The verification of a checksum 114 or an error detecting code detects only accidental modifications of 115 the data, while CMAC is designed to detect intentional, unauthorized 116 modifications of the data, as well as accidental modifications. The 117 output of AES-CMAC can validate the input message. Validating the 118 message provide assurance of the integrity and authenticity over the 119 message from the source. According to [NIST-CMAC] at least 64-bits 120 should be used for against guessing attack. AES-CMAC achieves the 121 similar security goal of HMAC [RFC-HMAC]. Since AES-CMAC is based 122 on a symmetric key block cipher, AES, while HMAC is based on a hash 123 function, such as SHA-1, AES-CMAC is appropriate for information 124 systems in which AES is more readily available than a hash function. 125 For detail information about AES-CMAC is available in [AES-CMAC] and 126 [NIST-CMAC]. 128 4. AES-CMAC-96 130 For use in IPsec message authentication on AH and ESP, AES-CMAC-96 131 should be used. AES-CMAC-96 is a AES-CMAC with 96-bit-long truncated 132 output in most significant bit first order. The output of 96 bits 133 MAC that will meet the default authenticator length as specified 134 in [AH]. The result of truncation should be taken in most 135 significant bits first order. For further information on AES-CMAC, 136 refer to [AES-CMAC] and [NIST-CMAC]. 138 Figure 1 describes AES-CMAC-96 algorithm: 140 In step 1, AES-CMAC is applied to the message 'M' in length 'len' 141 with key 'K' 143 In step 2, Truncate output block, T with 12 byte in msb-first-order 144 and return TT. 146 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 147 + Algorithm AES-CMAC-96 + 148 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 149 + + 150 + Input : K (128-bit Key described in section 4.1) + 151 + : M ( message to be authenticated ) + 152 + : len ( length of message in bytes ) + 153 + Output : Truncated T (Truncated output with length 12 bytes) + 154 + + 155 +-------------------------------------------------------------------+ 156 + + 157 + Step 1. T := AES-CMAC (K,M,len); + 158 + Step 2. TT := truncate (T, 12); + 159 + return TT; + 160 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 162 Figure 1 Algorithm AES-CMAC-96 164 5. Test Vectors 166 These test cases same as defined in [NIST-CMAC] with one exception of 167 96 bits truncation 168 -------------------------------------------------- 169 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 170 Subkey Generation 171 AES_128(key,0) 7df76b0c 1ab899b3 3e42f047 b91b546f 172 K1 fbeed618 35713366 7c85e08f 7236a8de 173 K2 f7ddac30 6ae266cc f90bc11e e46d513b 175 Test Case 1: len = 0 176 M 177 AES_CMAC_96 bb1d6929 e9593728 7fa37d12 179 Test Case 2: len = 16 180 M 6bc1bee2 2e409f96 e93d7e11 7393172a 181 AES_CMAC_96 070a16b4 6b4d4144 f79bdd9d 183 Test Case 3: len = 40 184 M 6bc1bee2 2e409f96 e93d7e11 7393172a 185 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 186 30c81c46 a35ce411 187 AES_CMAC_96 dfa66747 de9ae630 30ca3261 189 Test Case 4: len = 64 190 M 6bc1bee2 2e409f96 e93d7e11 7393172a 191 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 192 30c81c46 a35ce411 e5fbc119 1a0a52ef 193 f69f2445 df4f9b17 ad2b417b e66c3710 194 AES_CMAC_96 51f0bebf 7e3b9d92 fc497417 195 -------------------------------------------------- 196 6. Interaction with the ESP Cipher Mechanism 198 As of this writing, there are no known issues which preclude the use 199 of AES-CMAC-96 with any specific cipher algorithm. 201 7. Security Considerations 203 See security consideration of [AES-CMAC]. 205 8. IANA Consideration 207 IANA should allocate a value for IKEv2 Transform Type 3 (Integrity 208 Algorithm) to the AES-CMAC-PRF-128 algorithm when this document is 209 published. 211 9. Acknowledgement 213 Portions of this text were borrowed from [NIST-CMAC] and [AES-XCBC-MAC]. 214 We would like to thank to Russ Housley for his useful comments. 216 10. References 218 10.1. Normative References 219 [NIST-CMAC] NIST, Special Publication 800-38B Draft,"Recommendation 220 for Block Cipher Modes of Operation: The CMAC Method 221 for Authentication," March 9, 2005 223 [NIST-AES] NIST, FIPS 197, "Advanced Encryption Standard (AES)," 224 November 2001. 225 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf 227 [OMAC1] "OMAC: One-Key CBC MAC," Tetsu Iwata and Kaoru Kurosawa, 228 Department of Computer and Information Sciences, 229 Ilbaraki University, March 10, 2003. 230 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 231 Payload (ESP)", RFC 2406, November 1998. 233 [XCBC] Black, J. and P. Rogaway, "A Suggestion for Handling 234 Arbitrary-Length Messages with the CBC MAC," NIST 235 Second Modes of Operation Workshop, August 2001. 236 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 237 xcbc-mac/xcbc-mac-spec.pdf 239 [AES-CMAC] JunHyuk Song, Jicheol Lee, Radha Poovendran, Tetsu Iwata 240 "The AES-CMAC Algorithm" draft-songlee-aes-cmac-02.txt, 241 October 2005 (Work in progress) 242 10.2. Informative References 244 [AH] Kent, S. and R. Atkinson, "Security Architecture for the 245 Internet Protocol", RFC 2401, November 1998. 247 [ROADMAP] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security 248 Document Roadmap", RFC 2411, November 1998. 250 [OMAC1a] Tetsu Iwata and Kaoru Kurosawa, "OMAC: One-Key CBC MAC," 251 Fast Software Encryption, FSE 2003, LNCS 2887, 252 pp. 129-153, Springer-Verlag, 2003. 254 [RFC-HMAC] Hugo Krawczyk, Mihir Bellare and Ran Canetti, 255 "HMAC: Keyed-Hashing for Message Authentication," 256 RFC2104, February 1997. 258 [OMAC1b] Tetsu Iwata and Kaoru Kurosawa, "OMAC: One-Key CBC MAC," 259 Submission to NIST, December 2002. 260 Available from the NIST modes of operation web site at 261 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 262 omac/omac-spec.pdf 264 [XCBCa] John Black and Phillip Rogaway, "A Suggestion for 265 Handling Arbitrary-Length Messages with the CBC MAC," 266 NIST Second Modes of Operation Workshop, August 2001. 267 Available from the NIST modes of operation web site at 268 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 269 xcbc-mac/xcbc-mac-spec.pdf 271 [XCBCb] John Black and Phillip Rogaway, "CBC MACs for 272 Arbitrary-Length Messages: The Three-Key 273 Constructions," Journal of Cryptology, Vol. 18, No. 2, 274 pp. 111-132, Springer-Verlag, Spring 2005. 276 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 277 Protocol", draft-ietf-ipsec-ikev2-17 278 (work in progress), September 2004. 280 11. Author's Address 282 Junhyuk Song 283 University of Washington 284 Samsung Electronics 285 (206) 853-5843 286 songlee@ee.washington.edu 287 junhyuk.song@samsung.com 289 Jicheol Lee 290 Samsung Electronics 291 +82-31-279-3605 292 jicheol.lee@samsung.com 294 Radha Poovendran 295 Network Security Lab (NSL) 296 Dept. of Electrical Engineering 297 University of Washington 298 (206) 221-6512 299 radha@ee.washington.edu 301 Intellectual Property Statement 303 The IETF takes no position regarding the validity or scope of any 304 Intellectual Property Rights or other rights that might be claimed to 305 pertain to the implementation or use of the technology described in 306 this document or the extent to which any license under such rights 307 might or might not be available; nor does it represent that it has 308 made any independent effort to identify any such rights. Information 309 on the procedures with respect to rights in RFC documents can be 310 found in BCP 78 and BCP 79. 312 Copies of IPR disclosures made to the IETF Secretariat and any 313 assurances of licenses to be made available, or the result of an 314 attempt made to obtain a general license or permission for the use of 315 such proprietary rights by implementers or users of this 316 specification can be obtained from the IETF on-line IPR repository at 317 http://www.ietf.org/ipr. 319 The IETF invites any interested party to bring to its attention any 320 copyrights, patents or patent applications, or other proprietary 321 rights that may cover technology that may be required to implement 322 this standard. Please address the information to the IETF at 323 ietf-ipr@ietf.org. 325 Disclaimer of Validity 327 This document and the information contained herein are provided on an 328 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 329 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 330 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 331 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 332 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 333 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 335 Copyright Statement 337 Copyright (C) The Internet Society (2005). This document is subject 338 to the rights, licenses and restrictions contained in BCP 78, and 339 except as set forth therein, the authors retain all their rights. 341 Acknowledgment 343 Funding for the RFC Editor function is currently provided by the 344 Internet Society.