RFC 4615

RFC 4615: AES-CMAC-PRF-128 for IKE 🎀

Okay bestie, this one is RFC 4615, and it's giving "a PRF for IKE that finally takes variable-length keys" ✨. Here's the tea:

• Number: 4615
• Title: 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)
• Authors: JunHyuk Song (Samsung Electronics and University of Washington), Radha Poovendran (University of Washington), Jicheol Lee (Samsung Electronics), and Tetsu Iwata (Nagoya University) 🌸
• Category: Standards Track, from the Network Working Group 💜
• Date: August 2006 🍓
• Obsoletes and updates: the header doesn't list anything it obsoletes or updates, so it doesn't claim either one 🙈

Status of This Memo 📜

Okay so this doc is an Internet standards track protocol spec for the whole Internet community, and it's literally asking people for discussion and suggestions for improvements 💬. If you want the official standardization state and status, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 🦋.

Copyright Notice ⭐

Copyright (C) The Internet Society (2006). Full legal stuff is at the very end of the doc 💅.

Abstract 🌈

Some IP Security (IPsec) implementations want a pseudo-random function (PRF) built on the Advanced Encryption Standard (AES) 🔐. This memo describes that algorithm, called AES-CMAC-PRF-128, and it works with both 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 ✨

Okay so [RFC4493] describes how to use AES as a Message Authentication Code (MAC) with a 128-bit output length 🔑. That 128-bit output is super useful as a long-lived pseudo-random function (PRF) 💖. This document specifies a PRF that supports fixed and variable key sizes, and it's meant for the IKEv2 [RFC4306] Key Derivation Function (KDF) and authentication 🫶.

2. Basic Definitions 💜

Here are the key terms, all in one place 💅:

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 🦋

Okay the main event 🔥. AES-CMAC-PRF-128 is basically identical to the AES-CMAC from [RFC4493], except the 128-bit key length restriction is gone 🙌.

IKEv2 [RFC4306] uses PRFs for lots of stuff, but the big ones are generating keying material and authenticating the IKE_SA 🔐. IKEv2 splits PRFs into two groups: ones with fixed key sizes and ones with variable key sizes. It's giving organization 📋.

Here's the twist: when AES-CMAC-PRF-128 is the PRF in IKEv2, it counts as taking fixed size keys (16 octets) for generating keying material, but it takes variable key sizes for authentication 🧩.

So for 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 when authenticating with shared secrets (IKEv2, section 2.16), the shared secret doesn't have to be 16 octets, and its length can vary 🌸.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+                        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 🎀

Now the step-by-step. In step 1, the 128-bit key K for AES-CMAC gets derived like this:

• If the key VK is exactly 128 bits, then we use it as-is ✅.
• If it's longer or shorter than 128 bits, then we derive the key K by running AES-CMAC with the 128-bit all-zero string 0^128 as the key and VK as the input message. This is step 1b 🧪.

In step 2, we run AES-CMAC with K as the key and M as the input message, and whatever that gives back is the output 💫.

Heads up 👀: the zero-string trick in step 1b is how short or long VK gets turned into a proper 128-bit K.

More in part 2, bestie 💖

Intellectual Property

Okay so, the IETF is staying neutral here 💅. It takes no position on whether any Intellectual Property Rights or other rights someone might claim over the tech in this doc are valid, or how far they reach. It also can't promise any license is available, and it hasn't independently gone hunting for those rights 👀. If you want the rules for rights in RFC documents, check out BCP 78 and BCP 79 🎀.

Any IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, plus the results of attempts to get a general license or permission for implementers or users, can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🦋.

The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard to speak up 📣. Send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🫶✨.