Network Working Group J. Song Request for Comments: 4615 R. Poovendran Category: Standards Track University of Washington J. Lee Samsung Electronics T. Iwata Nagoya University August 2006
The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Some implementations of IP Security (IPsec) may want to use a pseudo-random function (PRF) based on the Advanced Encryption Standard (AES). This memo describes such an algorithm, called AES-CMAC-PRF-128. It supports fixed and variable key sizes.
[RFC4493] describes a method to use the Advanced Encryption Standard (AES) as a Message Authentication Code (MAC) that has a 128-bit output length. The 128-bit output is useful as a long-lived pseudo- random function (PRF). This document specifies a PRF that supports fixed and variable key sizes for IKEv2 [RFC4306] Key Derivation Function (KDF) and authentication.
The AES-CMAC-PRF-128 algorithm is identical to AES-CMAC defined in [RFC4493] except that the 128-bit key length restriction is removed.
IKEv2 [RFC4306] uses PRFs for multiple purposes, most notably for generating keying material and authentication of the IKE_SA. The IKEv2 specification differentiates between PRFs with fixed key sizes and those with variable key sizes.
When using AES-CMAC-PRF-128 as the PRF described in IKEv2, AES-CMAC- PRF-128 is considered to take fixed size (16 octets) keys for generating keying material but it takes variable key sizes for authentication.
That is, when generating keying material, "half the bits must come from Ni and half from Nr, taking the first bits of each" as described in IKEv2, section 2.14; but for authenticating with shared secrets (IKEv2, section 2.16), the shared secret does not have to be 16 octets and the length may vary.
Song, et al. Standards Track [Page 2]
RFC 4615 AES-CMAC-PRF-128 for IKE August 2006
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + AES-CMAC-PRF-128 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + + Input : VK (Variable-length key) + + : M (Message, i.e., the input data of the PRF) + + : VKlen (length of VK in octets) + + : len (length of M in octets) + + Output : PRV (128-bit Pseudo-Random Variable) + + + +-------------------------------------------------------------------+ + Variable: K (128-bit key for AES-CMAC) + + + + Step 1. If VKlen is equal to 16 + + Step 1a. then + + K := VK; + + Step 1b. else + + K := AES-CMAC(0^128, VK, VKlen); + + Step 2. PRV := AES-CMAC(K, M, len); + + return PRV; + + + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 1. The AES-CMAC-PRF-128 Algorithm
In step 1, the 128-bit key, K, for AES-CMAC is derived as follows:
o If the key, VK, is exactly 128 bits, then we use it as-is.
o If it is longer or shorter than 128 bits, then we derive the key, K, by applying the AES-CMAC algorithm using the 128-bit all-zero string as the key and VK as the input message. This step is described in step 1b.
In step 2, we apply the AES-CMAC algorithm using K as the key and M as the input message. The output of this algorithm is returned.
The security provided by AES-CMAC-PRF-128 is based upon the strength of AES and AES-CMAC. At the time of this writing, there are no known practical cryptographic attacks against AES or AES-CMAC. However, as is true with any cryptographic algorithm, part of its strength lies in the secret key, VK, and the correctness of the implementation in all of the participating systems. The key, VK, needs to be chosen independently and randomly based on RFC 4086 [RFC4086], and both keys, VK and K, should be kept safe and periodically refreshed. Section 4 presents test vectors that assist in verifying the correctness of the AES-CMAC-PRF-128 code.
If VK is longer than 128 bits and it is shortened to meet the AES-128 key size, then some entropy might be lost. However, as long as VK is longer than 128 bits, then the new key, K, preserves sufficient entropy, i.e., the entropy of K is about 128 bits.
Therefore, we recommend the use of VK that is longer than or equal to 128 bits, and we discourage the use of VK that is shorter than or equal to 64 bits, because of the small entropy.
Portions of this text were borrowed from [RFC3664] and [RFC4434]. Many thanks to Russ Housley and Paul Hoffman for suggestions and guidance. We also thank Alfred Hoenes for many useful comments.
We acknowledge support from the following grants: Collaborative Technology Alliance (CTA) from US Army Research Laboratory, DAAD19-01-2-0011; Presidential Award from Army Research Office,- W911NF-05-1-0491; ONR YIP N00014-04-1-0479. Results do not reflect any position of the funding agencies.
Radha Poovendran Network Security Lab University of Washington Phone: (206) 221-6512
EMail: radha@ee.washington.edu
Jicheol Lee Samsung Electronics Phone: +82-31-279-3605
EMail: jicheol.lee@samsung.com
Tetsu Iwata Nagoya University
EMail: iwata@cse.nagoya-u.ac.jp
Song, et al. Standards Track [Page 6]
RFC 4615 AES-CMAC-PRF-128 for IKE August 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).