idnits 2.17.1 draft-songlee-aes-cmac-96-04.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 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 325. ** 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 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 16 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 214, but not defined == Unused Reference: 'OMAC1' is defined on line 250, but no explicit reference was found in the text == Unused Reference: 'XCBC' is defined on line 272, but no explicit reference was found in the text == Unused Reference: 'IKEv2' is defined on line 278, 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' ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) == Outdated reference: A later version (-03) exists of draft-songlee-aes-cmac-02 ** 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. 'OMAC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'OMAC1b' -- Possible downref: Non-RFC (?) normative reference: ref. 'XCBCa' -- Possible downref: Non-RFC (?) normative reference: ref. 'XCBCb' -- Possible downref: Non-RFC (?) normative reference: ref. 'XCBC' Summary: 11 errors (**), 0 flaws (~~), 8 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: August 2, 2006 February 3 2006 8 The AES-CMAC-96 Algorithm and its use with IPsec 9 draft-songlee-aes-cmac-96-04.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 (2006). 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 message authentication code that is based on 54 a 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 (16 octets) long key for AES-128 cipher 84 block. Denoted by K. 86 Message (M) Message to be authenticated. 87 Denoted by M. 89 Length (len) The length of message M in octets. 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 octet. 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 is taken in most significant bits 135 first order. For further information on AES-CMAC, refer to 136 [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 octets in 144 msb-first-order 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 octets ) + 153 + Output : Truncated T (Truncated output with length 12 octets)+ 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 AUTH_AES_CMAC_96 algorithm when this document is 209 published. 211 9. Acknowledgement 213 Portions of this text were borrowed from [NIST-CMAC] and 214 [AES-XCBC-MAC]. We would like to thank to Russ Housley for his 215 useful comments. 217 10. References 219 10.1. Normative References 220 [NIST-CMAC] NIST, Special Publication 800-38B Draft,"Recommendation 221 for Block Cipher Modes of Operation: The CMAC Method 222 for Authentication," March 9, 2005 224 [NIST-AES] NIST, FIPS 197, "Advanced Encryption Standard (AES)," 225 November 2001. 226 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf 228 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 229 Payload (ESP)", RFC 2406, November 1998. 231 [AES-CMAC] JunHyuk Song, Jicheol Lee, Radha Poovendran, Tetsu Iwata 232 "The AES-CMAC Algorithm" draft-songlee-aes-cmac-02.txt, 233 October 2005 (Work in progress) 234 10.2. Informative References 236 [AH] Kent, S. and R. Atkinson, "Security Architecture for the 237 Internet Protocol", RFC 2401, November 1998. 239 [ROADMAP] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security 240 Document Roadmap", RFC 2411, November 1998. 242 [OMAC1a] Tetsu Iwata and Kaoru Kurosawa, "OMAC: One-Key CBC MAC," 243 Fast Software Encryption, FSE 2003, LNCS 2887, 244 pp. 129-153, Springer-Verlag, 2003. 246 [RFC-HMAC] Hugo Krawczyk, Mihir Bellare and Ran Canetti, 247 "HMAC: Keyed-Hashing for Message Authentication," 248 RFC2104, February 1997. 250 [OMAC1] "OMAC: One-Key CBC MAC," Tetsu Iwata and Kaoru Kurosawa, 251 Department of Computer and Information Sciences, 252 Ilbaraki University, March 10, 2003. 254 [OMAC1b] Tetsu Iwata and Kaoru Kurosawa, "OMAC: One-Key CBC MAC," 255 Submission to NIST, December 2002. 256 Available from the NIST modes of operation web site at 257 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 258 omac/omac-spec.pdf 260 [XCBCa] John Black and Phillip Rogaway, "A Suggestion for 261 Handling Arbitrary-Length Messages with the CBC MAC," 262 NIST Second Modes of Operation Workshop, August 2001. 263 Available from the NIST modes of operation web site at 264 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 265 xcbc-mac/xcbc-mac-spec.pdf 267 [XCBCb] John Black and Phillip Rogaway, "CBC MACs for 268 Arbitrary-Length Messages: The Three-Key 269 Constructions," Journal of Cryptology, Vol. 18, No. 2, 270 pp. 111-132, Springer-Verlag, Spring 2005. 272 [XCBC] Black, J. and P. Rogaway, "A Suggestion for Handling 273 Arbitrary-Length Messages with the CBC MAC," NIST 274 Second Modes of Operation Workshop, August 2001. 275 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 276 xcbc-mac/xcbc-mac-spec.pdf 278 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 279 Protocol", draft-ietf-ipsec-ikev2-17 280 (work in progress), September 2004. 282 11. Author's Address 284 Junhyuk Song 285 University of Washington 286 Samsung Electronics 287 (206) 853-5843 288 songlee@ee.washington.edu 289 junhyuk.song@samsung.com 291 Jicheol Lee 292 Samsung Electronics 293 +82-31-279-3605 294 jicheol.lee@samsung.com 296 Radha Poovendran 297 Network Security Lab (NSL) 298 Dept. of Electrical Engineering 299 University of Washington 300 (206) 221-6512 301 radha@ee.washington.edu 303 Intellectual Property Statement 305 The IETF takes no position regarding the validity or scope of any 306 Intellectual Property Rights or other rights that might be claimed to 307 pertain to the implementation or use of the technology described in 308 this document or the extent to which any license under such rights 309 might or might not be available; nor does it represent that it has 310 made any independent effort to identify any such rights. Information 311 on the procedures with respect to rights in RFC documents can be 312 found in BCP 78 and BCP 79. 314 Copies of IPR disclosures made to the IETF Secretariat and any 315 assurances of licenses to be made available, or the result of an 316 attempt made to obtain a general license or permission for the use of 317 such proprietary rights by implementers or users of this 318 specification can be obtained from the IETF on-line IPR repository at 319 http://www.ietf.org/ipr. 321 The IETF invites any interested party to bring to its attention any 322 copyrights, patents or patent applications, or other proprietary 323 rights that may cover technology that may be required to implement 324 this standard. Please address the information to the IETF at 325 ietf-ipr@ietf.org. 327 Disclaimer of Validity 329 This document and the information contained herein are provided on an 330 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 331 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 332 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 333 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 334 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 335 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 337 Copyright Statement 339 Copyright (C) The Internet Society (2006). This document is subject 340 to the rights, licenses and restrictions contained in BCP 78, and 341 except as set forth therein, the authors retain all their rights. 343 Acknowledgment 345 Funding for the RFC Editor function is currently provided by the 346 Internet Society.