GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4869

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",
               <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.
 [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,
               <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>.
 [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, <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 (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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4869.txt · Last modified: 2007/05/02 17:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki