RFC 3664

The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)

📅 published January 2004, from ietf

RFC 3664: The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) 🎀

Okay bestie, this is RFC 3664 💖 It was written by Paul Hoffman of the VPN Consortium and it's a Standards Track document, dated January 2004. The title block doesn't list anything it obsoletes or updates. ✨

Status of This Memo

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2004). All Rights Reserved. 💜

Abstract

Some IP Security (IPsec) implementations might want a pseudo-random function built on the Advanced Encryption Standard (AES) 🔥 This document describes that algorithm, called AES-XCBC-PRF-128 💅

1. Introduction 🦋

[AES-XCBC-MAC] describes a way to use AES as a message authentication code (MAC) with a 96-bit output 🧚 96 bits is totally fine for a MAC, but it's too short to be a long-lived pseudo-random function (PRF) in either IKE version 1 or version 2 💀 Both IKE versions use the PRF to make keys, and how strong those keys are depends on how long the PRF output is. A PRF with 96 bits of output makes keys that are easier to brute force than one with 128 bits of output 😭

Here's the good news: you can get a 128-bit PRF out of most of [AES-XCBC-MAC] with one tiny change. Just skip the step that cuts the 128-bit value down to 96 bits ✨ Iconic, honestly.

2. The AES-XCBC-PRF-128 Algorithm 💖

The AES-XCBC-PRF-128 algorithm is the same as [AES-XCBC-MAC], except the truncation step in section 4.3 of [AES-XCBC-MAC] is not performed 🙈 So there's no processing after section 4.2 of [AES-XCBC-MAC]. Simple!

You can use the test vectors in section 4.6 for AES-XCBC-PRF-128, but only the ones labeled "AES-XCBC-MAC". Skip the ones labeled "AES-XCBC-MAC-96" 🍓

3. Security Considerations 🔥

Okay, this section is serious, so listen up 👑 The security of AES-XCBC-MAC-PRF comes from the strength of AES. When this was written, there were no known practical cryptographic attacks against AES or AES-XCBC-MAC-PRF 🌈

But here's the thing: any cryptographic algorithm is only as strong as the key management mechanism around it, the strength of the secret key, and whether every participating system implements it correctly 😭 [AES-XCBC-MAC] has test vectors to help you check that your AES-XCBC-MAC-PRF code is correct. All of those test vectors show the full MAC value before it gets truncated to 96 bits. The PRF uses the full MAC value, not the truncated one. Don't mix those up, bestie! 💀

4. Intellectual Property Statement 💅

The IETF doesn't take a position on whether any intellectual property or other rights claimed to cover the technology in this document are valid or in scope. It also doesn't say whether licenses for those rights are available, and it hasn't tried to find out what rights exist 🫶 Info about the IETF's rules for rights in standards-track and standards-related documents is in BCP-11. Copies of claimed rights that were submitted for publication, along with any assurances of licenses, or the results of attempts to get a general license for implementers or users, can be obtained from the IETF Secretariat 📎

The IETF also invites anyone to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practice this standard. Send that info to the IETF Executive Director 💌

5. References 🧚

5.1. Normative References

[AES-XCBC-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.

6. Author's Address 🌸

Paul Hoffman
VPN Consortium
127 Segre Place
Santa Cruz, CA  95060  USA

EMail: paul.hoffman@vpnc.org

Copyright (C) The Internet Society (2004). All Rights Reserved. ✨

This document and translations of it may be copied and given to others. Derivative works that comment on or explain it, or help with implementing it, may also be written, copied, published, and distributed, in whole or in part, with no restrictions at all. The one condition is that the copyright notice and this paragraph appear on every copy and every derivative work 🎀 But this document itself can't be modified in any way, like removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are when it's needed to develop Internet standards (then the Internet Standards process copyright procedures have to be followed) or when it's translated into languages other than English 🌈

The permissions above are perpetual and won't be revoked by the Internet Society or its successors or assignees 🦋

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 😭

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from