idnits 2.17.00 (12 Aug 2021) /tmp/idnits27252/draft-songlee-aes-cmac-96-02.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 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 278. ** 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 == It seems as if not all pages are separated by form feeds - found 6 form feeds but 8 pages 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 8 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 212, 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 (~~), 5 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 30, 2005 May 31 2005 6 The AES-CMAC-96 Algorithm and its use with IPsec 7 draft-songlee-aes-cmac-96-02.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. 91 Length (len) The length of message M in bytes. 92 Denoted by len. 93 Minimum value of the length can be 0. The maximum 94 value of the length is not specified in this document. 96 truncate(T,l) Truncate T (MAC) in msb-first order with l bytes. 98 T The output of AES-CMAC-128. 100 Truncated T The truncated output of AES-CMAC-128 in MSB first 101 order. 103 AES-CMAC CMAC generation function based on AES block cipher 104 with 128-bits key 106 AES-CMAC-96 IPsec AH and ESP MAC generation function based on 107 CMAC-AES-128 which truncates MSB 96 bits of 128 bits 108 output 110 4. AES-CMAC-96 112 The underlying algorithm for AES-CMAC-96 are Advanced Encryption 113 Standard cipher block [AES] and recently defined CMAC mode of 114 operation [NIST-CMAC]. The output of AES-CMAC can validate the 115 input message. Validating the message provide assurance of the 116 integrity and authenticity over the message from the source. 117 According to [NIST-CMAC] at least 64-bits should be used for 118 against guessing attack. 120 For use in IPsec message authentication on AH and ESP, AES-CMAC-96 121 should be used. AES-CMAC-96 is a AES-CMAC with 96-bit-long truncated 122 output in most significant bit first order. The output of 96 bits 123 MAC that will meet the default authenticator length as specified 124 in [AH]. The result of truncation should be taken in most 125 significant bits first order. For further information on 126 AES-CMAC, refer to [AES-CMAC] and [NIST-CMAC]. 128 Figure 1 describes AES-CMAC-96 algorithm: 130 In step 1, AES-CMAC is applied to the message 'M' in length 'len' 131 with key 'K' 133 In step 2, Truncate output block, T with 12 byte in msb-first-order 134 and return TT. 136 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 137 + Algorithm AES-CMAC-96 + 138 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 139 + + 140 + Input : K (128-bit Key described in section 4.1) + 141 + : M ( message to be authenticated ) + 142 + : len ( length of message in bytes ) + 143 + Output : Truncated T (Truncated output with length 12 bytes) + 144 + + 145 +-------------------------------------------------------------------+ 146 + + 147 + Step 1. T := AES-CMAC (K,M,len); + 148 + Step 2. TT := truncate (T, 12); + 149 + return TT; + 150 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 152 Figure 1 Algorithm AES-CMAC-96 154 5. Test Vectors 156 These test cases same as defined in [NIST-CMAC] with one exception of 157 96 bits truncation 158 -------------------------------------------------- 159 K 2b7e1516 28aed2a6 abf71588 09cf4f3c 160 Subkey Generation 161 AES_128(key,0) 7df76b0c 1ab899b3 3e42f047 b91b546f 162 K1 fbeed618 35713366 7c85e08f 7236a8de 163 K2 f7ddac30 6ae266cc f90bc11e e46d513b 165 Example 1: len = 0 166 M 167 AES_CMAC_96 bb1d6929 e9593728 7fa37d12 169 Example 2: len = 16 170 M 6bc1bee2 2e409f96 e93d7e11 7393172a 171 AES_CMAC_96 070a16b4 6b4d4144 f79bdd9d 173 Example 3: len = 40 174 M 6bc1bee2 2e409f96 e93d7e11 7393172a 175 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 176 30c81c46 a35ce411 177 AES_CMAC_96 dfa66747 de9ae630 30ca3261 179 Example 4: len = 64 180 M 6bc1bee2 2e409f96 e93d7e11 7393172a 181 ae2d8a57 1e03ac9c 9eb76fac 45af8e51 182 30c81c46 a35ce411 e5fbc119 1a0a52ef 183 f69f2445 df4f9b17 ad2b417b e66c3710 184 AES_CMAC_96 51f0bebf 7e3b9d92 fc497417 185 -------------------------------------------------- 186 6. Interaction with the ESP Cipher Mechanism 188 As of this writing, there are no known issues which preclude the use 189 of AES-CMAC-96 with any specific cipher algorithm. 191 7. Security Considerations 193 The security provided by AES-CMAC-96 is based upon the strength of 194 AES. At the time of this writing there are no practical 195 cryptographic attacks against AES or AES-CMAC-96. 197 As is true with any cryptographic algorithm, part of its strength 198 lies in the correctness of the algorithm implementation, the security 199 of the key management mechanism and its implementation, the strength 200 of the associated secret key, and upon the correctness of the 201 implementation in all of the participating systems. This document 202 contains test vectors to assist in verifying the correctness of 203 AES-CMAC-96 code. 205 8. IANA Consideration 207 TBD 209 9. Acknowledgement 211 Portions of this text were borrowed from [NIST-CMAC] and 212 [AES-XCBC-MAC]. We would like to thank to OMAC1 author Tetsu Iwata 213 and Kaoru Kurosawa, and CMAC author Morris Dworkin. 215 10. References 217 [NIST-CMAC] NIST, Special Publication 800-38B Draft,"Recommendation 218 for Block Cipher Modes of Operation: The CMAC Method 219 for Authentication," March 9, 2005 221 [AES] NIST, FIPS 197, "Advanced Encryption Standard (AES)," 222 November 2001. 223 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf 225 [OMAC1] "OMAC: One-Key CBC MAC," Tetsu Iwata and Kaoru Kurosawa, 226 Department of Computer and Information Sciences, 227 Ilbaraki University, March 10, 2003. 229 [AH] Kent, S. and R. Atkinson, "IP Authentication Header", 230 RFC 2402, November 1998. 232 [ROADMAP] Thayer, R., N. Doraswamy, and R. Glenn, "IP Security 233 Document Roadmap", RFC 2411, November 1998. 235 [XCBC] Black, J. and P. Rogaway, "A Suggestion for Handling 236 Arbitrary-Length Messages with the CBC MAC," NIST 237 Second Modes of Operation Workshop, August 2001. 238 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 239 xcbc-mac/xcbc-mac-spec.pdf 241 [AES-CMAC] JunHyuk Song and Jicheol Lee, "The AES-CMAC Algorithm" 242 draft-songlee-aes-cmac-00.txt, May 2005 244 11. Author's Address 246 Junhyuk Song 247 Samsung Electronics 248 +82-31-279-3639 249 santajunman@hanafos.com 251 Jicheol Lee 252 Samsung Electronics 253 +82-31-279-3605 254 jicheol.lee@samsung.com 256 Intellectual Property Statement 258 The IETF takes no position regarding the validity or scope of any 259 Intellectual Property Rights or other rights that might be claimed to 260 pertain to the implementation or use of the technology described in 261 this document or the extent to which any license under such rights 262 might or might not be available; nor does it represent that it has 263 made any independent effort to identify any such rights. Information 264 on the procedures with respect to rights in RFC documents can be 265 found in BCP 78 and BCP 79. 267 Copies of IPR disclosures made to the IETF Secretariat and any 268 assurances of licenses to be made available, or the result of an 269 attempt made to obtain a general license or permission for the use of 270 such proprietary rights by implementers or users of this 271 specification can be obtained from the IETF on-line IPR repository at 272 http://www.ietf.org/ipr. 274 The IETF invites any interested party to bring to its attention any 275 copyrights, patents or patent applications, or other proprietary 276 rights that may cover technology that may be required to implement 277 this standard. Please address the information to the IETF at 278 ietf-ipr@ietf.org. 280 Disclaimer of Validity 282 This document and the information contained herein are provided on an 283 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 284 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 285 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 286 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 287 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 288 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 290 Copyright Statement 292 Copyright (C) The Internet Society (2005). This document is subject 293 to the rights, licenses and restrictions contained in BCP 78, and 294 except as set forth therein, the authors retain all their rights. 296 Acknowledgment 298 Funding for the RFC Editor function is currently provided by the 299 Internet Society.