RFC 3566

The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec

📅 published September 2003, from ietf

The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec 🎀

Okay bestie, here's the header tea first 💅 This is an RFC (basically an IETF spec for how Internet protocols work) from September 2003 🦋. It's a Standards Track doc, so it's an official Internet standards track protocol 🔥. The authors are S. Frankel from NIST and H. Herbert from Intel ✨. The title block doesn't list anything this RFC obsoletes or updates, so there's nothing to report on that front 🙈.

Status of this Memo ✨

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

Copyright (C) The Internet Society (2003). All Rights Reserved. 🫶

Abstract 🦋

Okay so a Message Authentication Code (MAC) is a key-dependent one-way hash function 🔐 A popular way to build one is to use a block cipher with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm is secure for messages of a pre-selected fixed length, but it's been shown to be insecure across messages of varying lengths, like the ones you find in typical IP datagrams 💀. This memo specifies the use of AES in CBC mode with a set of extensions to fix that limitation. The new algorithm is named AES-XCBC-MAC-96 ✨🎀

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Specification of Requirements  . . . . . . . . . . . . . .   2
3.  Basic CBC-MAC with Obligatory 10* Padding  . . . . . . . .   3
4.  AES-XCBC-MAC-96  . . . . . . . . . . . . . . . . . . . . .   3
    4.1.  Keying Material. . . . . . . . . . . . . . . . . . .   5
    4.2.  Padding  . . . . . . . . . . . . . . . . . . . . . .   6
    4.3.  Truncation . . . . . . . . . . . . . . . . . . . . .   6
    4.4.  Interaction with the ESP Cipher Mechanism. . . . . .   6
    4.5.  Performance. . . . . . . . . . . . . . . . . . . . .   6
    4.6.  Test Vectors . . . . . . . . . . . . . . . . . . . .   7
5.  Security Considerations  . . . . . . . . . . . . . . . . .   8
6.  IANA Considerations  . . . . . . . . . . . . . . . . . . .   8
7.  Intellectual Property Rights Statement . . . . . . . . . .   8
8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . .   8
9.  References . . . . . . . . . . . . . . . . . . . . . . . .   9
    9.1.  Normative References . . . . . . . . . . . . . . . .   9
    9.2.  Informative References . . . . . . . . . . . . . . .   9
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . .  10
11. Full Copyright Statement . . . . . . . . . . . . . . . . .  11

1. Introduction ✨

Message authentication gives you data integrity and data origin authentication with respect to the original message source 💖 Same MAC definition as before: a key-dependent one-way hash function, usually built from a block cipher in CBC mode. The classic CBC-MAC is secure for messages of a pre-selected fixed length [CBC-MAC-2], but it's been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams [CBC-MAC-2, section 5]. Honestly, it's giving trouble: it's trivial to produce forgeries for a second message given the MAC of a prior message. [HANDBOOK, section 9.62, p. 354] 😭

This memo specifies the use of AES [AES] in CBC mode [MODES], with a set of extensions [XCBC-MAC-1] to get around that limitation. The new algorithm is named AES-XCBC-MAC-96. AES has a bigger block size (128 bits) and a longer key (128 bits), so the new algorithm can hold up against continuing advances in crypto-analytic techniques and computational capability 🔥 AES-XCBC-MAC-96 is used as an authentication mechanism in the IPsec Encapsulating Security Payload (ESP) and the Authentication Header (AH) protocols. For more on ESP, check [ESP] and [ROADMAP]. For more on AH, check [AH] and [ROADMAP] 🧚

The goal here is to make sure the datagram is authentic and can't be modified in transit 🍓 How much integrity and data origin authentication you get depends on how widely the secret key is shared. If the key is known only by the source and destination, this algorithm gives both data origin authentication and data integrity for datagrams sent between the two parties. Plus, only a party with the identical key can verify the hash 👑

2. Specification of Requirements 💅

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that appear in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC-2119] ✨

3. Basic CBC-MAC with Obligatory 10* Padding 🌸

CBC-MAC uses a block cipher for encryption. The block cipher turns b bits of plaintext into b bits of ciphertext 🦋 The basic CBC-MAC [CBC-MAC-1, CBC-MAC-2] with Obligatory 10* Padding over a b-bit block cipher is calculated like this for a message M:

(1) Append a single 1 bit to M. Then append the minimum number of 0 bits to M so the length of M is a multiple of b. [NOTE: This is 1 of several padding schemes that can be used for CBC-MAC. Several others are described in [MODES].]

(2) Break M into n blocks, M[1] ... M[n], where the blocksize of blocks M[1] ... M[n] is b bits.

(3) Define E[0] = 0x00000000000000000000000000000000

(4) For each block M[i], where i = 1 ... n: XOR M[i] with E[i-1], then encrypt the result with Key K, yielding E[i].

(5) E[n] is the b-bit authenticator.

Basic CBC-MAC with obligatory 10* padding has been shown to be secure for messages up to (but not including) a pre-selected fixed length, where the length is a multiple of the blocksize. 🙈 But it's not suitable for IPsec, for these reasons:

  • Any IPsec authenticator MUST be able to handle messages of arbitrary length. The basic CBC-MAC can't securely handle messages that go past the pre-selected fixed length. 💀
  • For messages shorter than the pre-selected fixed length, padding the message up to that length may need extra encryption operations, which adds an unacceptable computational penalty. 😭

4. AES-XCBC-MAC-96 🎀

[AES] describes the underlying AES algorithm, while [CBC-MAC-1] and [XCBC-MAC-1] describe the AES-XCBC-MAC algorithm ✨

AES-XCBC-MAC-96 is a variant of the basic CBC-MAC with obligatory 10* padding, but it's secure for messages of arbitrary length 👑 Its calculations need a lot of encryption operations, and this encryption MUST be done with AES using a 128-bit key. Given a 128-bit secret key K, AES-XCBC-MAC-96 is calculated like this for a message M made of n blocks, M[1] ... M[n]. The blocksize of blocks M[1] ... M[n-1] is 128 bits, and the blocksize of block M[n] is between 1 and 128 bits:

(1) Derive 3 128-bit keys (K1, K2 and K3) from the 128-bit secret key K, like so:

K1 = 0x01010101010101010101010101010101 encrypted with Key K
K2 = 0x02020202020202020202020202020202 encrypted with Key K
K3 = 0x03030303030303030303030303030303 encrypted with Key K

(2) Define E[0] = 0x00000000000000000000000000000000

(3) For each block M[i], where i = 1 ... n-1: XOR M[i] with E[i-1], then encrypt the result with Key K1, yielding E[i].

(4) For block M[n]:

a) If the blocksize of M[n] is 128 bits: XOR M[n] with E[n-1] and Key K2, then encrypt the result with Key K1, yielding E[n].

b) If the blocksize of M[n] is less than 128 bits:

i) Pad M[n] with a single "1" bit, followed by the number of "0" bits (possibly none) required to increase M[n]'s blocksize to 128 bits.

ii) XOR M[n] with E[n-1] and Key K3, then encrypt the result with Key K1, yielding E[n].

(5) The authenticator value is the leftmost 96 bits of the 128-bit E[n].

NOTE1: If M is the empty string, pad and encrypt as in (4)(b) to create M[1] and E[1]. This will never be the case for ESP or AH, but it's included for completeness' sake. 🧚

NOTE2: [CBC-MAC-1] defines K1 as follows:

K1 = Constant1A encrypted with Key K |
   Constant1B encrypted with Key K.

However, the second encryption operation is only needed for AES-XCBC-MAC with keys greater than 128 bits. So it's not included in the definition of AES-XCBC-MAC-96 🙈

AES-XCBC-MAC-96 verification goes like this: when you get the AES-XCBC-MAC-96 authenticator, the entire 128-bit value gets computed, and the first 96 bits are compared to the value stored in the authenticator field ✨

4.1. Keying Material 🔐

AES-XCBC-MAC-96 is a secret key algorithm. For use with either ESP or AH, a fixed key length of 128 bits MUST be supported. Key lengths other than 128 bits MUST NOT be supported, so only 128-bit keys are used by AES-XCBC-MAC-96 💖

AES-XCBC-MAC-96 actually needs 384 bits of keying material (128 bits for the AES keysize, plus 2 times the blocksize). That keying material can come from the key generation mechanism, or it can be generated from a single 128-bit key. The second approach was picked for AES-XCBC-MAC-96, since it's analogous to other authenticators used within IPsec. The reason AES-XCBC-MAC-96 uses 3 keys is so the length of the input stream doesn't need to be known in advance. That can be useful for systems that do one-pass assembly of large packets 🦋

A strong pseudo-random function MUST be used to generate the required 128-bit key. This key, along with the 3 derived keys (K1, K2 and K3), should be used for no purposes other than those specified in the algorithm. In particular, they should not be used as keys in another cryptographic setting. Those kinds of abuses will invalidate the security of the authentication algorithm 💀

At the time of writing, there are no specified weak keys for use with AES-XCBC-MAC-96. That doesn't mean weak keys don't exist. If, at some point, a set of weak keys for AES-XCBC-MAC-96 is identified, the use of those weak keys MUST be rejected, followed by a request for replacement keys or a newly negotiated Security Association 🌈

[ARCH] describes the general mechanism for getting keying material when multiple keys are needed for a single SA (for example, when an ESP SA needs a key for confidentiality and a key for authentication) ✨

To provide data origin authentication, the key distribution mechanism must make sure that unique keys are allocated, and that they're distributed only to the parties participating in the communication 🫶

Current attacks don't call for a specific recommended frequency for key changes. However, periodic key refreshment is a fundamental security practice. It helps against potential weaknesses of the function and the keys, reduces the information available to a cryptanalyst, and limits the damage from a compromised key 👑

4.2. Padding ✨

AES-XCBC-MAC-96 works on 128-bit blocks of data 🧱. The padding rules live in [CBC-MAC-1] and are part of the XCBC algorithm, so they come along for the ride 💖. If you build AES-XCBC-MAC-96 according to [CBC-MAC-1], you do not need to add any extra padding as far as AES-XCBC-MAC-96 is concerned 🎀. As for "implicit packet padding" as defined in [AH], none is required here 🌸.

4.3. Truncation 🦋

AES-XCBC-MAC gives you a 128-bit authenticator value 💜. AES-XCBC-MAC-96 is made by truncating that 128-bit value the way [HMAC] describes, and it gets verified in [XCBC-MAC-2] ✨. For use with either ESP or AH, a truncated value using the first 96 bits MUST be supported 🔥. When sending, the truncated value gets stored in the authenticator field 📦. When receiving, the entire 128-bit value gets computed, and then the first 96 bits are compared to what's sitting in the authenticator field 👀. No other authenticator value lengths are supported by AES-XCBC-MAC-96, so don't even try 💅.

The 96-bit length was picked because it's the default authenticator length in [AH], and it meets the security requirements described in [XCBC-MAC-2] 👑.

4.4. Interaction with the ESP Cipher Mechanism 🧚

As of this writing, there are no known issues that stop AES-XCBC-MAC-96 from being used with any specific cipher algorithm 🌈.

4.5. Performance ⭐

For any CBC MAC variant, most of the heavy lifting happens in the underlying block cipher 💪. This algorithm makes the minimum number of AES invocations, one for each block of the message or fraction thereof, so its performance matches classic CBC-MAC 🏃‍♀️✨.

The key expansion needs 3 extra AES encryption operations 🔐, but you can do those once in advance for each secret key, which is very chill 🫶.

4.6. Test Vectors 🍓

These test cases were given to us by John Black, co-author of the XCBC-MAC algorithm, who checked them with 2 independent implementations 🙌. Everything below is in hexadecimal numbers 🔢.

Test Case #1   : AES-XCBC-MAC-96 with 0-byte input
Key (K)        : 000102030405060708090a0b0c0d0e0f
Message (M)    : <empty string>
AES-XCBC-MAC   : 75f0251d528ac01c4573dfd584d79f29
AES-XCBC-MAC-96: 75f0251d528ac01c4573dfd5

Test Case #2   : AES-XCBC-MAC-96 with 3-byte input
Key (K)        : 000102030405060708090a0b0c0d0e0f
Message (M)    : 000102
AES-XCBC-MAC   : 5b376580ae2f19afe7219ceef172756f
AES-XCBC-MAC-96: 5b376580ae2f19afe7219cee

Test Case #3   : AES-XCBC-MAC-96 with 16-byte input
Key (K)        : 000102030405060708090a0b0c0d0e0f
Message (M)    : 000102030405060708090a0b0c0d0e0f
AES-XCBC-MAC   : d2a246fa349b68a79998a4394ff7a263
AES-XCBC-MAC-96: d2a246fa349b68a79998a439

Test Case #4   : AES-XCBC-MAC-96 with 20-byte input
Key (K)        : 000102030405060708090a0b0c0d0e0f
Message (M)    : 000102030405060708090a0b0c0d0e0f10111213
AES-XCBC-MAC   : 47f51b4564966215b8985c63055ed308
AES-XCBC-MAC-96: 47f51b4564966215b8985c63

Test Case #5   : AES-XCBC-MAC-96 with 32-byte input
Key (K)        : 000102030405060708090a0b0c0d0e0f
Message (M)    : 000102030405060708090a0b0c0d0e0f10111213141516171819
                 1a1b1c1d1e1f
AES-XCBC-MAC   : f54f0ec8d2b9f3d36807734bd5283fd4
AES-XCBC-MAC-96: f54f0ec8d2b9f3d36807734b

Test Case #6   : AES-XCBC-MAC-96 with 34-byte input
Key (K)        : 000102030405060708090a0b0c0d0e0f
Message (M)    : 000102030405060708090a0b0c0d0e0f10111213141516171819
                 1a1b1c1d1e1f2021
AES-XCBC-MAC   : becbb3bccdb518a30677d5481fb6b4d8
AES-XCBC-MAC-96: becbb3bccdb518a30677d548

Test Case #7   : AES-XCBC-MAC-96 with 1000-byte input
Key (K)        : 000102030405060708090a0b0c0d0e0f
Message (M)    : 00000000000000000000 ... 00000000000000000000
                 [1000 bytes]

AES-XCBC-MAC   : f0dafee895db30253761103b5d84528f
AES-XCBC-MAC-96: f0dafee895db30253761103b

5. Security Considerations 🔒

Okay bestie, this part is SERIOUS 😭🔐 The security of AES-XCBC-MAC-96 is based on the strength of AES 💪. At the time of this writing, there are no practical cryptographic attacks against AES or AES-XCBC-MAC-96 🙏.

As with any cryptographic algorithm, part of its strength depends on the correctness of the algorithm implementation 🧠. It also depends on the security of the key management mechanism and its implementation 🗝️, the strength of the associated secret key 💎, and the correctness of the implementation in all of the participating systems 🖥️. This document includes test vectors to help you verify that your AES-XCBC-MAC-96 code is correct ✅, so use them!! 🫶

6. IANA Considerations 📋

IANA has assigned AH Transform Identifier 9 to AH_AES-XCBC-MAC 🎉. IANA has also assigned AH/ESP Authentication Algorithm Value 9 to AES-XCBC-MAC 🌟.

7. Intellectual Property Rights Statement ⚖️

The IETF takes no position on whether any intellectual property or other rights that might be claimed to apply to the implementation or use of the technology in this document are valid or in scope, or on whether any license under those rights might be available. It also doesn't say it has tried to find any such rights 🤷‍♀️. Info about the IETF's procedures for rights in standards-track and standards-related documents can be found in BCP-11 📚. Copies of claimed rights that were made available for publication, plus any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can be obtained from the IETF Secretariat 📬.

8. Acknowledgments 🫶

Portions of this text were unabashedly borrowed from [HMAC-SHA] 😂.

Huge thanks to the XCBC-MAC authors for their expert advice and super quick replies to our questions 🙏. Thanks to Phil Rogaway for providing values for the XCBC-MAC constants 🔢, and to John Black for detailed corrections to the algorithm specifications and for providing the test cases 🌷. Thanks also to Andrew Krywaniuk for insisting on (and providing wording for) a rationale for the 3-key approach 💅✨.

9. References 📚

9.1. Normative References

9.2. Informative References

  • [ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
  • [CBC-MAC-2] Bellare, M., J. Kilian and P. Rogaway, "The Security of the Cipher Block Chaining Message Authentication Code," Journal of Computer and System Sciences (JCSS), Vol. 61, No. 3, December 2000, pp. 362-399. http://www.cse.ucsd.edu/users/mihir/papers/cbc.{ps,pdf}
  • [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
  • [HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
  • [HANDBOOK] Menezes, A., P. Van Oorschot and S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997.
  • [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques," NIST Special Publication 800-38A, December 2001. http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
  • [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [ROADMAP] Thayer, R., N. Doraswamy, and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
  • [XCBC-MAC-2] Rogaway, Phil, email communications, October 2001.

10. Authors' Addresses 🖊️

Sheila Frankel
NIST - National Institute of Standards and Technology
820 West Diamond Ave.
Room 677
Gaithersburg, MD 20899

Phone: +1 (301) 975-3297
EMail: sheila.frankel@nist.gov


Howard C. Herbert
Intel Corporation
Lan Access Division
5000 West Chandler Blvd.
MS-CH7-404
Chandler, Arizona 85226

Phone: +1 (480) 554-3116
EMail: howard.c.herbert@intel.com

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is 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