idnits 2.17.1 draft-songlee-aes-cmac-prf-128-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 407 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 1) being 111 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 25 instances of too long lines in the document, the longest one being 2 characters 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 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) == Unused Reference: 'AH' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'ROADMAP' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'AES-XCBC-PRF-bis' is defined on line 303, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-CMAC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEv2' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 JunHyuk Song 3 Radha Poovendran 5 University of Washington 7 Jicheol Lee 9 Samsung Electronics 11 Tetsu Iwata 13 INTERNET DRAFT Ibaraki University 15 Expires: August 2, 2006 February 3 2006 17 The AES-CMAC-PRF-128 Algorithm for 19 the Internet Key Exchange Protocol (IKE) 21 draft-songlee-aes-cmac-prf-128-03.txt 23 Status of This Memo 25 By submitting this Internet-Draft, each author represents that any 27 applicable patent or other IPR claims of which he or she is aware 29 have been or will be disclosed, and any of which he or she becomes 31 aware will be disclosed, in accordance with Section 6 of BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 39 Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt. 53 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 Copyright Notice 59 Copyright (C) The Internet Society (2006). 61 Abstract 63 Some implementations of IP Security (IPsec) may want to use a 65 pseudo-random function derived from the Advanced Encryption Standard 67 (AES). This memo describes such an algorithm, called AES-CMAC- 69 PRF-128. 71 1. Introduction 73 [AES-CMAC] describes a method to use the Advanced Encryption 75 Standard (AES) as a message authentication code (MAC) whose output 77 is 128 bits long. 128 bits output is useful as a long-lived pseudo- 79 random function (PRF) in either IKE version 1 or version 2. This 81 document specifies PRF that support fixed and variable key sizes for 83 IKEv2 [IKEv2] Key Derivation Function (KDF) and authentication. 85 2. Basic definitions 87 VK Variable length key for AES-CMAC-PRF-128, Denoted 89 by VK. 91 0^n The string that consists of n zero-bits. 93 0^3 means that 000 in binary format. 95 10^4 means that 10000 in binary format. 97 10^i means that 1 followed by i-times repeated 99 zero's. 101 AES-CMAC AES-CMAC algorithm with 128 bits long key described 103 in section 2.4 of [AES-CMAC]. 105 3. The AES-CMAC-PRF-128 Algorithm 107 The AES-CMAC-PRF-128 algorithm is identical to AES-CMAC defined 109 in [AES-CMAC] except that the 128 bits key length restriction is 111 removed. 113 IKEv2 [IKEv2] uses PRFs for multiple purposes, most notably for 115 generating keying material and authentication of the the IKE_SA. 117 The IKEv2 specification differentiates between PRFs with fixed key 119 sizes and those with variable key sizes 121 When using the PRF described in this document with IKEv2, the PRF is 123 considered to be fixed-length for generating keying material but 125 variable-length for authentication. 127 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 129 + AES-CMAC-PRF-128 + 131 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 133 + + 135 + Input : VK ( Variable length key ) + 137 + : M ( Message to be authenticated ) + 139 + : VKlen ( length of VK ) + 141 + : len ( length of message in octets ) + 143 + Output : PRV ( 128 bits Pseudo Random Variable ) + 145 + + 147 +-------------------------------------------------------------------+ 149 + Variables: K ( 128-bits fixed key ) + 151 + + 153 + Step 1. + 155 + If VKlen is equal to 16 octets then + 157 + Step 1a. K := VK; + 159 + Else + 161 + Step 1b. K := AES-CMAC (0^128, VK, VKlen); + 163 + + 165 + Step 2. + 167 + PRV := AES-CMAC (K,M,len); + 169 + return PRV; + 171 + + 173 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 175 Figure 1. AES-CMAC-PRF-128 Algorithm 177 In step 1, the key for AES-CMAC-PRF-128 is created as follows: 179 o If the key is exactly 128 bits long, use it as-is. 181 o If the key is longer or shorter than 128 bits long, then we derive 183 new key K by performing AES-CMAC algorithm using 128 bits all 185 zero key and VK as the message. This step is described in step 1b. 187 In step 2, we perform AES-CMAC algorithm using K as the key and 189 M as the message. The output of this algorithm is returned. 191 5. Test Vectors 193 ------------------------------------------------------------ 195 Test Case AES-CMAC-PRF-128 with 20-octet input 196 Key : 00010203 04050607 08090a0b 0c0d0e0f edcb 197 Key Length : 18 198 Message : 00010203 04050607 08090a0b 0c0d0e0f 10111213 199 PRF Output : 84a348a4 a45d235b abfffc0d 2b4da09a 201 Test Case AES-CMAC-PRF-128 with 20-octet input 202 Key : 00010203 04050607 08090a0b 0c0d0e0f 203 Key Length : 16 204 Message : 00010203 04050607 08090a0b 0c0d0e0f 10111213 205 PRF Output : 980ae87b 5f4c9c52 14f5b6a8 455e4c2d 207 Test Case AES-CMAC-PRF-128 with 20-octet input 208 Key : 00010203 04050607 0809 209 Key Length : 10 210 Message : 00010203 04050607 08090a0b 0c0d0e0f 10111213 211 PRF Output : 290d9e11 2edb09ee 141fcf64 c0b72f3d 213 ------------------------------------------------------------ 215 6. Security Considerations 217 The security provided by AES-CMAC-PRF-128 is based upon the strength 219 of AES and AES-CMAC. At the time of this writing, there are no known 221 practical cryptographic attacks against AES or AES-CMAC. 223 However as is true with any cryptographic algorithm, part of its 225 strength lies in the secret key, 'K' and the correctness of the 227 implementation in all of the participating systems. 229 Keys need to be chosen at random based on RFC 4086 [RFC4086] 231 and should be kept in safe and periodically refreshed. 233 Whenever keys larger than 128 bits are reduced to meet AES-128 key 235 input size, some entropy might be lost. However, if using collision- 237 resistant hash function such as AES-CMAC when generating new key for 239 pseudo-random function, it preserves sufficient entropy as long as 241 the pseudo-random function to be used requires 128 bits long input key. 243 7. IANA Consideration 245 IANA should allocate a value for IKEv2 Transform Type 2 247 (Pseudo-Random Function) to the PRF_AES128_CMAC algorithm when this 249 document is published. 251 8. Acknowledgement 253 Portions of this text were borrowed from [AES-XCBC-PRF] and 255 [AES-XCBC-PRF_bis], and many thanks to Russ Housley and 257 Paul Hoffman for suggestions and guidance. 259 9. Reference 261 9.1 Normative References 263 [AES-CMAC] JunHyuk Song, Jicheol Lee, Radha Poovendran and 265 Tetsu Iwata, "The AES-CMAC Algorithm," 267 draft-songlee-aes-cmac-03.txt, (work in progress) 269 December 2005. 271 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 273 Protocol", draft-ietf-ipsec-ikev2-17 275 (work in progress), September 2004. 277 [RFC4086] Eastlake 3rd, D., Crocker, S., and J. Schiller, 279 "Randomness Requirements for Security", RFC 4086 281 June 2005 283 9.2. Informative References 285 [AH] Kent, S. and R. Atkinson, "Security Architecture 287 for the Internet Protocol", RFC 2401, November 289 1998. 291 [ROADMAP] Thayer, R., Doraswamy, N. and R. Glenn, "IP 293 Security Document Roadmap", RFC 2411, November 295 1998. 297 [AES-XCBC-PRF] P. Hoffman, "The AES-XCBC-PRF-128 Algorithm for 299 the Internet Key Exchange Protocol (IKE)," 301 RFC3664, Jan 2004. 303 [AES-XCBC-PRF-bis] P. Hoffman, "The AES-XCBC-PRF-128 Algorithm for 305 the Internet Key Exchange Protocol (IKE)," 307 draft-hoffman-rfc3664bis-05.txt 309 (work in progress), October 2005. 311 Author's Address 313 Junhyuk Song 315 Samsung Electronics 317 University of Washington 319 (206) 853-5843 321 songlee@u.washington.edu 323 junhyuk.song@samsung.com 325 Jicheol Lee 327 Samsung Electronics 329 +82-31-279-3605 331 jicheol.lee@samsung.com 333 Radha Poovendran 335 Network Security Lab 337 University of Washington 339 (206) 221-6512 341 radha@ee.washington.edu 343 Tetsu Iwata 345 Ibaraki University 347 iwata@cis.ibaraki.ac.jp 349 Intellectual Property Statement 351 The IETF takes no position regarding the validity or scope of any 353 Intellectual Property Rights or other rights that might be claimed to 355 pertain to the implementation or use of the technology described in 357 this document or the extent to which any license under such rights 359 might or might not be available; nor does it represent that it has 361 made any independent effort to identify any such rights. Information 363 on the procedures with respect to rights in RFC documents can be 365 found in BCP 78 and BCP 79. 367 Copies of IPR disclosures made to the IETF Secretariat and any 369 assurances of licenses to be made available, or the result of an 371 attempt made to obtain a general license or permission for the use of 373 such proprietary rights by implementers or users of this 375 specification can be obtained from the IETF on-line IPR repository at 377 http://www.ietf.org/ipr. 379 The IETF invites any interested party to bring to its attention any 381 copyrights, patents or patent applications, or other proprietary 383 rights that may cover technology that may be required to implement 385 this standard. Please address the information to the IETF at 387 ietf-ipr@ietf.org. 389 Disclaimer of Validity 391 This document and the information contained herein are provided on an 393 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 395 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 397 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 399 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 401 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 403 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 405 Copyright Statement 407 Copyright (C) The Internet Society (2006). This document is subject 409 to the rights, licenses and restrictions contained in BCP 78, and 411 except as set forth therein, the authors retain all their rights. 413 Acknowledgment 415 Funding for the RFC Editor function is currently provided by the 417 Internet Society.