Suite B Cryptographic Suites for IPsec
Four ready-made IPsec option bundles that line up with the NSA's Suite B algorithms.
Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 6379, DOI 10.17487/RFC6379, October 2011, <https://www.rfc-editor.org/info/rfc6379>.
@misc{rfc6379,
series = {Request for Comments},
number = 6379,
howpublished = {RFC 6379},
publisher = {RFC Editor},
doi = {10.17487/RFC6379},
url = {https://www.rfc-editor.org/info/rfc6379},
author = {L. Law and J. Solinas},
title = {{Suite B Cryptographic Suites for IPsec}},
pagetotal = 7,
year = 2011,
month = oct,
} RFC text
Contents
Internet Engineering Task Force (IETF) L. Law
Request for Comments: 6379 J. Solinas
Obsoletes: 4869 NSA
Category: Informational October 2011
ISSN: 2070-1721
Suite B Cryptographic Suites for IPsec
Abstract
This document proposes four cryptographic user interface suites
("UI suites") for IP Security (IPsec), similar to the two suites
specified in RFC 4308. The four new suites provide compatibility
with the United States National Security Agency's Suite B
specifications. This document obsoletes RFC 4869, which presented
earlier versions of these suites.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6379.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. Requirements Terminology ........................................2
3. New UI Suites ...................................................2
3.1. Suite "Suite-B-GCM-128" ....................................3
3.2. Suite "Suite-B-GCM-256" ....................................3
3.3. Suite "Suite-B-GMAC-128" ...................................4
3.4. Suite "Suite-B-GMAC-256" ...................................4
4. Security Considerations .........................................4
5. IANA Considerations .............................................5
6. Changes from RFC 4869 ...........................................5
7. References ......................................................5
7.1. Normative References .......................................5
7.2. Informative References .....................................6
1. Introduction
[RFC4308] proposes two optional cryptographic user interface suites
("UI suites") for IPsec. The two suites, VPN-A and VPN-B, represent
commonly used present day corporate VPN security choices and
anticipated future choices, respectively. [RFC4869] proposed four
new UI suites based on implementations of the United States National
Security Agency's Suite B algorithms (see [SuiteB]).
As with the VPN suites, the Suite B suites are simply collections of
values for some options in IPsec. Use of UI suites does not change
the IPsec protocols in any way.
This document reduces the scope of the suites in [RFC4869] while
retaining the original suite names. A detailed list of the changes
is given in Section 6. This document obsoletes RFC 4869.
2. Requirements Terminology
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].
3. New UI Suites
Each of the following UI suites provides choices for ESP (see
[RFC4303]) and for Internet Key Exchange (IKEv2) (see [RFC5996]).
The four suites are differentiated by the choice of cryptographic
algorithm strengths, and a choice of whether the Encapsulating
Security Payload (ESP) is to provide both confidentiality and
integrity or integrity only. The suite names are based on the
Advanced Encryption Standard [AES] mode and AES key length specified
for ESP.
IPsec implementations that use these UI suites MUST use the suite
names listed here. IPsec implementations SHOULD NOT use names
different than those listed here for the suites that are described,
and MUST NOT use the names listed here for suites that do not match
these values. These requirements are necessary for interoperability.
3.1. Suite "Suite-B-GCM-128"
This suite provides ESP integrity protection and confidentiality
using 128-bit AES-GCM (see [RFC4106]). This suite or the following
suite should be used when ESP integrity protection and encryption are
both needed.
ESP:
Encryption AES with 128-bit keys and 16-octet Integrity
Check Value (ICV) in GCM mode [RFC4106]
Integrity NULL
IKEv2:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Integrity HMAC-SHA-256-128 [RFC4868]
Diffie-Hellman group 256-bit random ECP group [RFC5903]
3.2. Suite "Suite-B-GCM-256"
This suite provides ESP integrity protection and confidentiality
using 256-bit AES-GCM (see [RFC4106]). This suite or the preceding
suite should be used when ESP integrity protection and encryption are
both needed.
ESP:
Encryption AES with 256-bit keys and 16-octet ICV in GCM mode
[RFC4106]
Integrity NULL
IKEv2:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Integrity HMAC-SHA-384-192 [RFC4868]
Diffie-Hellman group 384-bit random ECP group [RFC5903]
3.3. Suite "Suite-B-GMAC-128"
This suite provides ESP integrity protection using 128-bit AES-GMAC
(see [RFC4543]) but does not provide confidentiality. This suite or
the following suite should be used only when there is no need for ESP
encryption.
ESP:
Encryption NULL
Integrity AES with 128-bit keys in GMAC mode [RFC4543]
IKEv2:
Encryption AES with 128-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-256 [RFC4868]
Integrity HMAC-SHA-256-128 [RFC4868]
Diffie-Hellman group 256-bit random ECP group [RFC5903]
3.4. Suite "Suite-B-GMAC-256"
This suite provides ESP integrity protection using 256-bit AES-GMAC
(see [RFC4543]) but does not provide confidentiality. This suite or
the preceding suite should be used only when there is no need for ESP
encryption.
ESP:
Encryption NULL
Integrity AES with 256-bit keys in GMAC mode [RFC4543]
IKEv2:
Encryption AES with 256-bit keys in CBC mode
[RFC3602]
Pseudo-random function HMAC-SHA-384 [RFC4868]
Integrity HMAC-SHA-384-192 [RFC4868]
Diffie-Hellman group 384-bit random ECP group [RFC5903]
4. Security Considerations
This document inherits all of the security considerations of the
IPsec and IKEv2 documents.
Some of the security options specified in these suites may be found
in the future to have properties significantly weaker than those that
were believed at the time this document was produced.
5. IANA Considerations
IANA maintains a registry called "Cryptographic Suites for IKEv1,
IKEv2, and IPsec" (see [IANA-Suites]). The registry consists of a
text string and an RFC number that lists the associated transforms.
The four suites in this document have been listed with this document
as the RFC reference. These entries will be updated upon approval of
this document.
The updated values for the registry are:
Identifier Defined in
Suite-B-GCM-128 RFC 6379
Suite-B-GCM-256 RFC 6379
Suite-B-GMAC-128 RFC 6379
Suite-B-GMAC-256 RFC 6379
6. Changes from RFC 4869
The changes from [RFC4869] are:
1. Removed definitions of the suites for IKEv1.
2. Removed IKE authentication methods from the suite definitions.
These now appear in [RFC6380].
3. Removed the requirements on rekeying in IKEv2.
7. References
7.1. Normative References
[IANA-Suites] Internet Assigned Numbers Authority, "Cryptographic
Suites for IKEv1, IKEv2, and IPsec",
<http://www.iana.org/assignments/crypto-suites>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
Cipher Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter
Mode (GCM) in IPsec Encapsulating Security Payload
(ESP)", RFC 4106, June 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC
4308, December 2005.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC
4543, May 2006.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-
SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May
2007.
[RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites
for IPsec", RFC 4869, May 2007.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June
2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010.
7.2. Informative References
[AES] U.S. Department of Commerce/National Institute of
Standards and Technology, "Advanced Encryption Standard
(AES)", FIPS PUB 197, November 2001,
<http://csrc.nist.gov/publications/fips/index.html>.
[RFC6380] Burgin, K. and M. Peck, "Suite B Profile for Internet
Protocol Security (IPsec)", RFC 6380, October 2011.
[SuiteB] U.S. National Security Agency, "NSA Suite B
Cryptography", January 2009, <http://www.nsa.gov/
ia/programs/suiteb_cryptography/>.
Authors' Addresses
Laurie E. Law
National Security Agency
EMail: lelaw@orion.ncsc.mil
Jerome A. Solinas
National Security Agency
EMail: jasolin@orion.ncsc.mil
ISO Plain Language
On this page
§1What a UI Suite Is
RFC 4308 proposes two optional cryptographic user interface suites for IPsec. The two suites, VPN-A and VPN-B, represent commonly used present-day corporate VPN security choices and anticipated future choices respectively. RFC 4869 proposed four new suites based on implementations of the United States National Security Agency's Suite B algorithms.
As with the VPN suites, the Suite B suites are simply collections of values for some options in IPsec. Using a UI suite does not change the IPsec protocols in any way. This document narrows the scope of the suites in RFC 4869 while keeping the original suite names, and it lists the changes it made.
The memo also sets a naming rule, because the names are what two peers use to agree. An implementation that uses these suites must use the names given here, should not use different names for the suites that are described, and must not use these names for suites that do not match these values. The memo says these requirements are necessary for interoperability.
A UI suite is a shortcut for a list of options. It changes nothing about how IPsec works; it only saves both ends from having to spell out every cipher and hash. The names matter, because the two ends use them to check they have picked the same thing.
§3The Four Suite B Suites
Each suite gives choices for ESP, described in RFC 4303, and for IKEv2, described in RFC 5996. The four are told apart by two things: the strength of the cryptographic algorithms, and whether ESP provides both confidentiality and integrity or integrity only. The names are built from the AES mode and the AES key length that ESP uses.
The two GCM suites, Suite-B-GCM-128 and Suite-B-GCM-256, give ESP both integrity protection and confidentiality, using AES-GCM with a 16-octet integrity check value. The memo says either of them should be used when ESP integrity protection and encryption are both needed. The two GMAC suites, Suite-B-GMAC-128 and Suite-B-GMAC-256, give ESP integrity protection only, using AES-GMAC, and provide no confidentiality at all. The memo says either of them should be used only when there is no need for ESP encryption.
Two of the bundles encrypt as well as check the traffic. Two only check it. Within each pair, one uses 128-bit keys and the other 256-bit.
- GCM suitesESP provides both confidentiality and integrity, using AES-GCM with a 16-octet integrity check value.
- GMAC suitesESP provides integrity only, using AES-GMAC. There is no encryption.
- 128-bit suitesAES with 128-bit keys, HMAC-SHA-256, and the 256-bit random ECP group.
- 256-bit suitesAES with 256-bit keys, HMAC-SHA-384, and the 384-bit random ECP group.
§3.1ESP and IKEv2 Choices in Each Suite
Suite-B-GCM-128 uses ESP encryption of AES with 128-bit keys and a 16-octet integrity check value in GCM mode, with the separate ESP integrity field set to NULL. For IKEv2 it uses AES with 128-bit keys in CBC mode, the pseudo-random function HMAC-SHA-256, the integrity algorithm HMAC-SHA-256-128, and the 256-bit random ECP group for Diffie-Hellman. Suite-B-GCM-256 is the same with 256-bit keys and a 16-octet integrity check value, HMAC-SHA-384, HMAC-SHA-384-192, and the 384-bit random ECP group.
The GMAC suites differ in the ESP direction. Suite-B-GMAC-128 sets ESP encryption to NULL and ESP integrity to AES with 128-bit keys in GMAC mode, and its IKEv2 choices are the same as those of the GCM-128 suite: AES with 128-bit keys in CBC mode, HMAC-SHA-256, HMAC-SHA-256-128 and the 256-bit random ECP group. Suite-B-GMAC-256 sets ESP encryption to NULL and ESP integrity to AES with 256-bit keys in GMAC mode, with AES-256 CBC, HMAC-SHA-384, HMAC-SHA-384-192 and the 384-bit random ECP group on the IKEv2 side.
Each bundle fixes the cipher for the protected traffic, the algorithm that checks the key exchange, and the curve used to agree the key. The 128-bit bundles use AES-128, HMAC-SHA-256 and the P-256 group; the 256-bit bundles use AES-256, HMAC-SHA-384 and the P-384 group.
| Suite | ESP encryption | ESP integrity | IKEv2 integrity | Diffie-Hellman group |
|---|---|---|---|---|
| Suite-B-GCM-128 | AES-128 GCM, 16-octet ICV | NULL | HMAC-SHA-256-128 | 256-bit random ECP |
| Suite-B-GCM-256 | AES-256 GCM, 16-octet ICV | NULL | HMAC-SHA-384-192 | 384-bit random ECP |
| Suite-B-GMAC-128 | NULL | AES-128 GMAC | HMAC-SHA-256-128 | 256-bit random ECP |
| Suite-B-GMAC-256 | NULL | AES-256 GMAC | HMAC-SHA-384-192 | 384-bit random ECP |
§4Security Considerations
The document inherits all of the security considerations of the IPsec and IKEv2 documents it points at.
It adds one warning. Some of the security options specified in these suites may be found in the future to have properties significantly weaker than those that were believed at the time the document was produced. In other words, the memo treats the choices it fixes as a snapshot of what was considered strong enough then, and says that a later reading of those algorithms may change that judgement.
The security reasoning is inherited from the IPsec and key exchange documents. The memo also warns that an algorithm judged strong when the suites were written may not be judged so later.
§5The IANA Registry
IANA maintains a registry called Cryptographic Suites for IKEv1, IKEv2, and IPsec. The registry consists of a text string and the RFC number that lists the associated transforms. The four suites in this document have been listed with this document as the reference, and the entries will be updated on approval.
The updated values for the registry are Suite-B-GCM-128, Suite-B-GCM-256, Suite-B-GMAC-128 and Suite-B-GMAC-256, each defined in RFC 6379.
The four names are recorded in the IANA registry of cryptographic suites, so that a product can look up what a name means.
§6Changes from RFC 4869
The memo lists three changes from the document it replaces. The definitions of the suites for IKEv1 were removed. The IKE authentication methods were removed from the suite definitions, and now appear in RFC 6380. The requirements on rekeying in IKEv2 were removed.
The effect of these changes is the narrowing the memo describes: the suites now cover IKEv2 and ESP only, the authentication methods live in their own document, and the rekeying requirements were dropped.
The earlier version of these suites covered the older key exchange protocol as well, and carried authentication and rekeying rules inside them. This version drops all three, leaving only the ESP and IKEv2 algorithm choices.