The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
RFC 4106
|
| Document |
Type |
|
RFC - Proposed Standard
(June 2005; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4106 (Proposed Standard)
|
|
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
Show full document text