From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4869.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc4869.txt (limited to 'doc/rfc/rfc4869.txt') diff --git a/doc/rfc/rfc4869.txt b/doc/rfc/rfc4869.txt new file mode 100644 index 0000000..0a98175 --- /dev/null +++ b/doc/rfc/rfc4869.txt @@ -0,0 +1,507 @@ + + + + + + +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 (C) 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 + + [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. 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 [RFC2119]. + +3. New UI Suites + + Each of the following UI suites provides choices for ESP (see + [RFC4303]) and for IKEv1 and IKEv2 (see [RFC2409] and [RFC4306]). + 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 [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 + + + + + +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 + [RFC3602] + Pseudo-random function HMAC-SHA-256 [RFC4868] + Hash SHA-256 [FIPS-180-2] [RFC4634] + Diffie-Hellman group 256-bit random ECP group [RFC4753] + Group Type ECP + + For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST + support pre-shared key authentication [RFC2409] for interoperability. + The authentication method used with IKEv1 MAY be either pre-shared + key [RFC2409] or ECDSA-256 [RFC4754]. + + 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 [RFC4753] + Authentication ECDSA-256 [RFC4754] + + 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 [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 + + IKEv1: + Encryption AES with 256-bit keys in CBC mode + [RFC3602] + Pseudo-random function HMAC-SHA-384 [RFC4868] + Hash SHA-384 [FIPS-180-2] [RFC4634] + Diffie-Hellman group 384-bit random ECP group [RFC4753] + Group Type ECP + + For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST + support pre-shared key authentication [RFC2409] for interoperability. + The authentication method used with IKEv1 MAY be either pre-shared + key [RFC2409] or ECDSA-384 [RFC4754]. + + + +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 + [RFC3602] + Pseudo-random function HMAC-SHA-384 [RFC4868] + Integrity HMAC-SHA-384-192 [RFC4868] + Diffie-Hellman group 384-bit random ECP group [RFC4753] + Authentication ECDSA-384 [RFC4754] + + 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 [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] + + IKEv1: + Encryption AES with 128-bit keys in CBC mode + [RFC3602] + Pseudo-random function HMAC-SHA-256 [RFC4868] + Hash SHA-256 [FIPS-180-2] [RFC4634] + Diffie-Hellman group 256-bit random ECP group [RFC4753] + Group Type ECP + + For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST + support pre-shared key authentication [RFC2409] for interoperability. + The authentication method used with IKEv1 MAY be either pre-shared + key [RFC2409] or ECDSA-256 [RFC4754]. + + 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 [RFC4753] + Authentication ECDSA-256 [RFC4754] + + 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 [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] + + IKEv1: + Encryption AES with 256-bit keys in CBC mode + [RFC3602] + Pseudo-random function HMAC-SHA-384 [RFC4868] + Hash SHA-384 [FIPS-180-2] [RFC4634] + Diffie-Hellman group 384-bit random ECP group [RFC4753] + Group Type ECP + + For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST + support pre-shared key authentication [RFC2409] for interoperability. + The authentication method used with IKEv1 MAY be either pre-shared + key [RFC2409] or ECDSA-384 [RFC4754]. + + 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 [RFC4753] + Authentication ECDSA-384 [RFC4754] + + 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", + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + [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. + + [RFC4306] 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 + + + [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. + + [RFC4753] Fu, D. and J. Solinas, "ECP Groups for IKE and IKEv2", + RFC 4753, November 2006. + + [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication + Using ECDSA", RFC 4754, November 2006. + + [RFC4868] 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, + . + + [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, + . + + [RFC4634] 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, . + + + + + + + + + + + + + + + +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 (C) 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] + -- cgit v1.2.3