|
|
|
|
|
|
IETF RFC 4869
Suite B Cryptographic Suites for IPsec
Last modified on Wednesday, May 2nd, 2007
 Permanent link to RFC 4869
 Search GitHub Wiki for RFC 4869
 Show other RFCs mentioning RFC 4869
Network Working Group L. Law
Request for Comments: 4869 J. Solinas
Category: Informational NSA
May 2007
Suite B Cryptographic Suites for IPsec
 Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright © The IETF Trust (2007).
Abstract
This document proposes four optional cryptographic user interface
suites ("UI suites") for 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.
Table of Contents
1. Introduction ....................................................2
2. Requirements Terminology ........................................2
3. New UI Suites ...................................................2
3.1. Suite "Suite-B-GCM-128" ....................................2
3.2. Suite "Suite-B-GCM-256" ....................................3
3.3. Suite "Suite-B-GMAC-128" ...................................4
3.4. Suite "Suite-B-GMAC-256" ...................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................7
Law & Solinas Informational PAGE 1 
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
1. Introduction
[RFC 4308] 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. This document proposes
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.
2. Requirements Terminology
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as described in [RFC 2119].
3. New UI Suites
Each of the following UI suites provides choices for ESP (see
[RFC 4303]) and for IKEv1 and IKEv2 (see [RFC 2409] and [RFC 4306]).
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 SHOULD 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 [RFC 4106]). 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 [RFC 4106]
Integrity NULL
Law & Solinas Informational PAGE 2
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
IKEv1:
Encryption AES with 128-bit keys in CBC mode
[RFC 3602]
Pseudo-random function HMAC-SHA-256 [RFC 4868]
Hash SHA-256 [FIPS-180-2] [RFC 4634]
Diffie-Hellman group 256-bit random ECP group [RFC 4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST
support pre-shared key authentication [RFC 2409] for interoperability.
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC 2409] or ECDSA-256 [RFC 4754].
IKEv2:
Encryption AES with 128-bit keys in CBC mode
[RFC 3602]
Pseudo-random function HMAC-SHA-256 [RFC 4868]
Integrity HMAC-SHA-256-128 [RFC 4868]
Diffie-Hellman group 256-bit random ECP group [RFC 4753]
Authentication ECDSA-256 [RFC 4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
MUST be supported by both parties in this suite.
3.2. Suite "Suite-B-GCM-256"
This suite provides ESP integrity protection and confidentiality
using 256-bit AES-GCM (see [RFC 4106]). 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
[RFC 4106]
Integrity NULL
IKEv1:
Encryption AES with 256-bit keys in CBC mode
[RFC 3602]
Pseudo-random function HMAC-SHA-384 [RFC 4868]
Hash SHA-384 [FIPS-180-2] [RFC 4634]
Diffie-Hellman group 384-bit random ECP group [RFC 4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST
support pre-shared key authentication [RFC 2409] for interoperability.
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC 2409] or ECDSA-384 [RFC 4754].
Law & Solinas Informational PAGE 3
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
IKEv2:
Encryption AES with 256-bit keys in CBC mode
[RFC 3602]
Pseudo-random function HMAC-SHA-384 [RFC 4868]
Integrity HMAC-SHA-384-192 [RFC 4868]
Diffie-Hellman group 384-bit random ECP group [RFC 4753]
Authentication ECDSA-384 [RFC 4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
MUST be supported by both parties in this suite.
3.3. Suite "Suite-B-GMAC-128"
This suite provides ESP integrity protection using 128-bit AES-GMAC
(see [RFC 4543]) 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 [RFC 4543]
IKEv1:
Encryption AES with 128-bit keys in CBC mode
[RFC 3602]
Pseudo-random function HMAC-SHA-256 [RFC 4868]
Hash SHA-256 [FIPS-180-2] [RFC 4634]
Diffie-Hellman group 256-bit random ECP group [RFC 4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST
support pre-shared key authentication [RFC 2409] for interoperability.
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC 2409] or ECDSA-256 [RFC 4754].
IKEv2:
Encryption AES with 128-bit keys in CBC mode
[RFC 3602]
Pseudo-random function HMAC-SHA-256 [RFC 4868]
Integrity HMAC-SHA-256-128 [RFC 4868]
Diffie-Hellman group 256-bit random ECP group [RFC 4753]
Authentication ECDSA-256 [RFC 4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
MUST be supported by both parties in this suite.
Law & Solinas Informational PAGE 4
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
3.4. Suite "Suite-B-GMAC-256"
This suite provides ESP integrity protection using 256-bit AES-GMAC
(see [RFC 4543]) 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 [RFC 4543]
IKEv1:
Encryption AES with 256-bit keys in CBC mode
[RFC 3602]
Pseudo-random function HMAC-SHA-384 [RFC 4868]
Hash SHA-384 [FIPS-180-2] [RFC 4634]
Diffie-Hellman group 384-bit random ECP group [RFC 4753]
Group Type ECP
For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST
support pre-shared key authentication [RFC 2409] for interoperability.
The authentication method used with IKEv1 MAY be either pre-shared
key [RFC 2409] or ECDSA-384 [RFC 4754].
IKEv2:
Encryption AES with 256-bit keys in CBC mode
[RFC 3602]
Pseudo-random function HMAC-SHA-384 [RFC 4868]
Integrity HMAC-SHA-384-192 [RFC 4868]
Diffie-Hellman group 384-bit random ECP group [RFC 4753]
Authentication ECDSA-384 [RFC 4754]
Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
MUST be supported by both parties in this suite.
4. Security Considerations
This document inherits all of the security considerations of the
IPsec, IKEv1, and IKEv2 documents. See [CNSSP-15] for guidance on
the use of AES in these suites for the protection of U.S. Government
information.
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.
Law & Solinas Informational PAGE 5
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
5. IANA Considerations
IANA has created and will maintain 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 new suites in this document have
been added to this registry after approval by an expert designated by
the IESG.
The new values for the registry are:
Identifier Defined in
Suite-B-GCM-128 RFC 4869
Suite-B-GCM-256 RFC 4869
Suite-B-GMAC-128 RFC 4869
Suite-B-GMAC-256 RFC 4869
6. References
6.1. Normative References
[FIPS-180-2] FIPS 180-2 with change notice, "Secure Hash Standard",
National Institute of Standards and Technology,
February 2004.
[IANA-Suites] Internet Assigned Numbers Authority, "Cryptographic
Suites for IKEv1, IKEv2, and IPsec",
<http://www.iana.org/assignments/crypto-suites>.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC 3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
Cipher Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[RFC 4106] Viega, J. and D. McGrew, "The Use of Galois/Counter
Mode (GCM) in IPsec Encapsulating Security Payload
(ESP)", RFC 4106, June 2005.
[RFC 4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC 4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
Law & Solinas Informational PAGE 6
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
[RFC 4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC
4308, December 2005.
[RFC 4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC
4543, May 2006.
[RFC 4753] Fu, D. and J. Solinas, "ECP Groups for IKE and IKEv2",
RFC 4753, November 2006.
[RFC 4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication
Using ECDSA", RFC 4754, November 2006.
[RFC 4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-
SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May
2007.
6.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>.
[CNSSP-15] Committee on National Security Systems, "National
Policy on the Use of the Advanced Encryption Standard
(AES) to Protect National Security Systems and National
Security Information", June 2003,
<http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf>.
[RFC 4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[SuiteB] U.S. National Security Agency, "Fact Sheet NSA Suite B
Cryptography", July 2005, <http://www.nsa.gov/ia/
industry/crypto_Suite_b.cfm?MenuID=10.2.7>.
Law & Solinas Informational PAGE 7
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
Authors' Addresses
Laurie E. Law
National Information Assurance Research Laboratory
National Security Agency
EMail: lelaw@orion.ncsc.mil
Jerome A. Solinas
National Information Assurance Research Laboratory
National Security Agency
EMail: jasolin@orion.ncsc.mil
Law & Solinas Informational PAGE 8
RFC 4869 Suite B Cryptographic Suites for IPsec May 2007
Full Copyright Statement
Copyright © The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Law & Solinas Informational PAGE 9
Suite B Cryptographic Suites for IPsec
RFC TOTAL SIZE: 17040 bytes
PUBLICATION DATE: Wednesday, May 2nd, 2007
LEGAL RIGHTS: The IETF Trust (see BCP 78)
|
