summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4615.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4615.txt')
-rw-r--r--doc/rfc/rfc4615.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc4615.txt b/doc/rfc/rfc4615.txt
new file mode 100644
index 0000000..9954f06
--- /dev/null
+++ b/doc/rfc/rfc4615.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Basic Definitions ...............................................2
+ 3. The AES-CMAC-PRF-128 Algorithm ..................................2
+ 4. Test Vectors ....................................................4
+ 5. Security Considerations .........................................4
+ 6. IANA Considerations .............................................5
+ 7. Acknowledgements ................................................5
+ 8. References ......................................................5
+ 8.1. Normative References .......................................5
+ 8.2. Informative References .....................................5
+
+
+
+
+
+Song, et al. Standards Track [Page 1]
+
+RFC 4615 AES-CMAC-PRF-128 for IKE August 2006
+
+
+1. Introduction
+
+ [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.
+
+2. Basic Definitions
+
+ VK Variable-length key for AES-CMAC-PRF-128, denoted
+ by VK.
+
+ 0^128 The string that consists of 128 zero-bits, which is
+ equivalent to 0x00000000000000000000000000000000 in
+ hexadecimal notation.
+
+ AES-CMAC The AES-CMAC algorithm with a 128-bit long key described
+ in section 2.4 of [RFC4493].
+
+3. The AES-CMAC-PRF-128 Algorithm
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Song, et al. Standards Track [Page 3]
+
+RFC 4615 AES-CMAC-PRF-128 for IKE August 2006
+
+
+4. Test Vectors
+
+ ------------------------------------------------------------
+
+ Test Case AES-CMAC-PRF-128 with 20-octet input
+ Key : 00010203 04050607 08090a0b 0c0d0e0f edcb
+ Key Length : 18
+ Message : 00010203 04050607 08090a0b 0c0d0e0f 10111213
+ PRF Output : 84a348a4 a45d235b abfffc0d 2b4da09a
+
+ Test Case AES-CMAC-PRF-128 with 20-octet input
+ Key : 00010203 04050607 08090a0b 0c0d0e0f
+ Key Length : 16
+ Message : 00010203 04050607 08090a0b 0c0d0e0f 10111213
+ PRF Output : 980ae87b 5f4c9c52 14f5b6a8 455e4c2d
+
+ Test Case AES-CMAC-PRF-128 with 20-octet input
+ Key : 00010203 04050607 0809
+ Key Length : 10
+ Message : 00010203 04050607 08090a0b 0c0d0e0f 10111213
+ PRF Output : 290d9e11 2edb09ee 141fcf64 c0b72f3d
+
+ ------------------------------------------------------------
+
+5. Security Considerations
+
+ 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.
+
+
+
+
+
+
+Song, et al. Standards Track [Page 4]
+
+RFC 4615 AES-CMAC-PRF-128 for IKE August 2006
+
+
+6. IANA Considerations
+
+ IANA has allocated a value of 8 for IKEv2 Transform Type 2 (Pseudo-
+ Random Function) to the PRF_AES128_CMAC algorithm.
+
+7. Acknowledgements
+
+ 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.
+
+8. References
+
+8.1. Normative References
+
+ [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
+ AES-CMAC Algorithm", RFC 4493, June 2006.
+
+ [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
+ 4306, December 2005.
+
+ [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+ "Randomness Requirements for Security", BCP 106, RFC 4086,
+ June 2005.
+
+8.2. Informative References
+
+ [RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
+ Internet Key Exchange Protocol (IKE)", RFC 3664, January
+ 2004.
+
+ [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
+ Internet Key Exchange Protocol (IKE)", RFC 4434, February
+ 2006.
+
+
+
+
+
+
+
+
+
+
+
+Song, et al. Standards Track [Page 5]
+
+RFC 4615 AES-CMAC-PRF-128 for IKE August 2006
+
+
+Authors' Addresses
+
+ JunHyuk Song
+ Samsung Electronics
+ University of Washington
+ Phone: (206) 853-5843
+
+ EMail: junhyuk.song@samsung.com, junhyuk.song@gmail.com
+
+
+ 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).
+
+
+
+
+
+
+
+Song, et al. Standards Track [Page 7]
+