JunHyuk
Network Working Group J. Song
Radha
Request for Comments: 4615 R. Poovendran
Category: Standards Track University of Washington
Jicheol
J. Lee
Samsung Electronics
Tetsu
T. Iwata
INTERNET DRAFT Ibaraki
Nagoya University
Expires:
August 2, 2006 February 3 2006
The AES-CMAC-PRF-128 Advanced Encryption Standard-Cipher-based
Message Authentication Code-Pseudo-Random Function-128
(AES-CMAC-PRF-128) Algorithm for the
Internet Key Exchange Protocol (IKE)
draft-songlee-aes-cmac-prf-128-03.txt
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of
This document specifies an Internet standards track protocol for the
Internet Engineering
Task Force (IETF), its areas, community, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid requests discussion and suggestions for a maximum
improvements. Please refer to the current edition of six months the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list status of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list this protocol. Distribution of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 derived from (PRF) based on the Advanced Encryption
Standard (AES). This memo describes such an algorithm, called AES-CMAC-
PRF-128.
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
1. Introduction
[AES-CMAC]
[RFC4493] describes a method to use the Advanced Encryption Standard
(AES) as a message authentication code Message Authentication Code (MAC) whose that has a 128-bit
output
is 128 bits long. 128 bits length. The 128-bit output is useful as a long-lived pseudo-
random function (PRF) in either IKE version 1 or version 2. (PRF). This document specifies a PRF that support supports
fixed and variable key sizes for IKEv2 [IKEv2] [RFC4306] Key Derivation
Function (KDF) and authentication.
2. Basic definitions Definitions
VK Variable length Variable-length key for AES-CMAC-PRF-128, Denoted denoted
by VK.
0^n
0^128 The string that consists of n zero-bits.
0^3 means that 000 in binary format.
10^4 means that 10000 128 zero-bits, which is
equivalent to 0x00000000000000000000000000000000 in binary format.
10^i means that 1 followed by i-times repeated
zero's.
hexadecimal notation.
AES-CMAC The AES-CMAC algorithm with 128 bits a 128-bit long key described
in section 2.4 of [AES-CMAC]. [RFC4493].
3. The AES-CMAC-PRF-128 Algorithm
The AES-CMAC-PRF-128 algorithm is identical to AES-CMAC defined in [AES-CMAC]
[RFC4493] except that the 128 bits 128-bit key length restriction is removed.
IKEv2 [IKEv2] [RFC4306] uses PRFs for multiple purposes, most notably for
generating keying material and authentication of the the IKE_SA. The
IKEv2 specification differentiates between PRFs with fixed key sizes
and those with variable key sizes sizes.
When using AES-CMAC-PRF-128 as the PRF described in this document with IKEv2, the PRF AES-CMAC-
PRF-128 is considered to be fixed-length take fixed size (16 octets) keys for
generating keying material but
variable-length 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.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ AES-CMAC-PRF-128 +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ +
+ Input : VK ( Variable length key ) (Variable-length key) +
+ : M ( Message to be authenticated ) (Message, i.e., the input data of the PRF) +
+ : VKlen ( length (length of VK ) in octets) +
+ : len ( length (length of message M in octets ) octets) +
+ Output : PRV ( 128 bits Pseudo Random Variable ) (128-bit Pseudo-Random Variable) +
+ +
+-------------------------------------------------------------------+
+ Variables: Variable: K ( 128-bits fixed (128-bit key ) for AES-CMAC) +
+ +
+ Step 1. +
+ If VKlen is equal to 16 octets then +
+ Step 1a. then +
+ K := VK; +
+ Else +
+ Step 1b. else +
+ K := AES-CMAC (0^128, AES-CMAC(0^128, VK, VKlen); +
+ +
+ Step 2. +
+ PRV := AES-CMAC (K,M,len); AES-CMAC(K, M, len); +
+ return PRV; +
+ +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 1. The AES-CMAC-PRF-128 Algorithm
In step 1, the key 128-bit key, K, for AES-CMAC-PRF-128 AES-CMAC is created derived as follows:
o If the key key, VK, is exactly 128 bits long, bits, then we use it as-is.
o If the key it is longer or shorter than 128 bits long, bits, then we derive
new key K the key,
K, by performing applying the AES-CMAC algorithm using 128 bits all
zero 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 perform apply the AES-CMAC algorithm using K as the key and M
as the input message. The output of this algorithm is returned.
5.
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
------------------------------------------------------------
6.
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 However, as
is true with any cryptographic algorithm, part of its strength lies
in the secret key, 'K' VK, and the correctness of the implementation in
all of the participating systems.
Keys need The key, VK, needs to be chosen at random
independently and randomly based on RFC 4086 [RFC4086] [RFC4086], and both
keys, VK and K, should be kept in safe and periodically refreshed.
Whenever keys larger
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 are reduced and it is shortened to meet the AES-128
key
input size, then some entropy might be lost. However, if using collision-
resistant hash function such as AES-CMAC when generating long as VK is
longer than 128 bits, then the new key for
pseudo-random function, it key, K, preserves sufficient
entropy, i.e., the entropy as long as of K is about 128 bits.
Therefore, we recommend the pseudo-random function use of VK that is longer than or equal to be used requires
128 bits long input key.
7. bits, and we discourage the use of VK that is shorter than or
equal to 64 bits, because of the small entropy.
6. IANA Consideration Considerations
IANA should allocate has allocated a value of 8 for IKEv2 Transform Type 2
(Pseudo-Random (Pseudo-
Random Function) to the PRF_AES128_CMAC algorithm when this
document is published.
8. Acknowledgement algorithm.
7. Acknowledgements
Portions of this text were borrowed from [AES-XCBC-PRF] and
[AES-XCBC-PRF_bis], [RFC3664] and many [RFC4434].
Many thanks to Russ Housley and Paul Hoffman for suggestions and
guidance.
9. Reference
9.1 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
[AES-CMAC] JunHyuk
[RFC4493] Song, Jicheol JH., Poovendran, R., Lee, Radha Poovendran J., and
Tetsu T. Iwata, "The
AES-CMAC Algorithm,"
draft-songlee-aes-cmac-03.txt, (work in progress)
December 2005.
[IKEv2] Algorithm", RFC 4493, June 2006.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17
(work in progress), September 2004. RFC
4306, December 2005.
[RFC4086] Eastlake 3rd, Eastlake, D., Crocker, S., and J. 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086 4086,
June 2005
9.2. 2005.
8.2. Informative References
[AH] Kent, S. and R. Atkinson, "Security Architecture
for the Internet Protocol", RFC 2401, November
1998.
[ROADMAP] Thayer, R., Doraswamy, N. and R. Glenn, "IP
Security Document Roadmap", RFC 2411, November
1998.
[AES-XCBC-PRF] P.
[RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE),"
RFC3664, Jan (IKE)", RFC 3664, January
2004.
[AES-XCBC-PRF-bis] P.
[RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE),"
draft-hoffman-rfc3664bis-05.txt
(work in progress), October 2005.
Author's Address
Junhyuk (IKE)", RFC 4434, February
2006.
Authors' Addresses
JunHyuk Song
Samsung Electronics
University of Washington
Phone: (206) 853-5843
songlee@u.washington.edu
junhyuk.song@samsung.com
Jicheol Lee
Samsung Electronics
+82-31-279-3605
jicheol.lee@samsung.com
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
Ibaraki
Nagoya University
iwata@cis.ibaraki.ac.jp
EMail: iwata@cse.nagoya-u.ac.jp
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 Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society. IETF
Administrative Support Activity (IASA).