The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
RFC 4106
Document | Type | RFC - Proposed Standard (June 2005; Errata) | |
---|---|---|---|
Authors | John Viega , David McGrew | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4106 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | (None) |
Network Working Group J. Viega Request for Comments: 4106 Secure Software, Inc. Category: Standards Track D. McGrew Cisco Systems, Inc. June 2005 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) 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 (2005). Abstract This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. Table of Contents 1. Introduction ....................................................2 1.1. Conventions Used in This Document ..........................2 2. AES-GCM .........................................................3 3. ESP Payload Data ................................................3 3.1. Initialization Vector (IV) .................................3 3.2. Ciphertext .................................................4 4. Nonce Format ....................................................4 5. AAD Construction ................................................5 6. Integrity Check Value (ICV) .....................................5 7. Packet Expansion ................................................6 8. IKE Conventions .................................................6 8.1. Keying Material and Salt Values ............................6 8.2. Phase 1 Identifier .........................................6 8.3. Phase 2 Identifier .........................................7 8.4. Key Length Attribute .......................................7 Viega & McGrew Standards Track [Page 1] RFC 4106 GCM ESP June 2005 9. Test Vectors ....................................................7 10. Security Considerations ........................................7 11. Design Rationale ...............................................8 12. IANA Considerations ............................................8 13. Acknowledgements ...............................................9 14. Normative References ...........................................9 15. Informative References .........................................9 1. Introduction This document describes the use of AES in GCM mode (AES-GCM) as an IPsec ESP mechanism for confidentiality and data origin authentication. We refer to this method as AES-GCM-ESP. This mechanism is not only efficient and secure, but it also enables high-speed implementations in hardware. Thus, AES-GCM-ESP allows IPsec connections that can make effective use of emerging 10-gigabit and 40-gigabit network devices. Counter mode (CTR) has emerged as the preferred encryption method for high-speed implementations. Unlike conventional encryption modes such as Cipher Block Chaining (CBC) and Cipher Block Chaining Message Authentication Code (CBC-MAC), CTR can be efficiently implemented at high data rates because it can be pipelined. The ESP CTR protocol describes how this mode can be used with IPsec ESP [RFC3686]. Unfortunately, CTR provides no data origin authentication, and thus the ESP CTR standard requires the use of a data origin authentication algorithm in conjunction with CTR. This requirement is problematic, because none of the standard data origin authentication algorithms can be efficiently implemented for high data rates. GCM solves this problem, because under the hood, it combines CTR mode with a secure, parallelizable, and efficient authentication mechanism. This document does not cover implementation details of GCM. Those details can be found in [GCM], along with test vectors. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Viega & McGrew Standards Track [Page 2] RFC 4106 GCM ESP June 2005Show full document text