[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 RFC 6380

Network Working Group                                        K.W. Burgin
Internet Draft                                  National Security Agency
Intended Status: Informational                                 M.A. Peck
Expires: January 12, 2012                          The MITRE Corporation
                                                           July 11, 2011


         Suite B Profile for Internet Protocol Security (IPsec)
                  draft-burgin-ipsec-suiteb-profile-01


Abstract

   The United States Government has published guidelines for "NSA
   Suite B Cryptography" dated July, 2005, which defines cryptographic
   algorithm policy for national security applications.  This document
   specifies the conventions for using Suite B cryptography in IP
   Security (IPsec).

   Since many of the Suite B algorithms enjoy uses in other environments
   as well, the majority of the conventions needed for the Suite B
   algorithms are already specified in other documents.  This document
   references the source of these conventions, with some relevant
   details repeated to aid developers that choose to support Suite B.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 12, 2012.

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



Burgin & Peck           Expires January 12, 2012                [Page 1]

Internet-Draft         Suite B Profile for IPsec           July 11, 2011


   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this Document  . . . . . . . . . . . . . .  3
   3.  Suite B Requirements . . . . . . . . . . . . . . . . . . . . .  4
   4.  Minimum Levels of Security (minLOS)  . . . . . . . . . . . . .  4
     4.1.  Non-signature Primitives . . . . . . . . . . . . . . . . .  4
     4.2.  Suite B IPsec Cryptographic Suites . . . . . . . . . . . .  5
     4.3.  Suite B IKEv2 Authentication . . . . . . . . . . . . . . .  5
     4.4.  Digital Signatures and Certificates  . . . . . . . . . . .  6
   5.  Suite B Security Associations (SAs) for IKEv2 and IPsec  . . .  6
   6.  The Key Exchange Payload in the IKE_SA_INIT Exchange . . . . .  7
   7.  Generating Keying Material for the IKE SA  . . . . . . . . . .  7
   8.  Additional Requirements  . . . . . . . . . . . . . . . . . . .  8
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   10.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  9
   11.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     11.1  Normative References . . . . . . . . . . . . . . . . . . .  9
     11.2  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10










Burgin & Peck           Expires January 12, 2012                [Page 2]

Internet-Draft         Suite B Profile for IPsec           July 11, 2011


1.  Introduction

   The Fact Sheet on National Security Agency (NSA) Suite B Cryptography
   [NSA] states:

      A Cryptographic Interoperability Strategy (CIS) was developed to
      find ways to increase assured rapid sharing of information both
      within the U.S. and between the U.S. and her partners through the
      use of a common suite of public standards, protocols, algorithms
      and modes referred to as the "Secure Sharing Suite" or S.3 The
      implementation of CIS will facilitate the development of a broader
      range of secure cryptographic products which will be available to
      a wide customer base.  The use of selected public cryptographic
      standards and protocols and Suite B is the core of CIS.

      In 2005, NSA announced Suite B Cryptography which built upon the
      National Policy on the use of the Advanced Encryption Standard
      (AES) to Protect National Security Systems and National Security
      Information.  In addition to the AES algorithm, Suite B includes
      cryptographic algorithms for key exchanges, digital signatures and
      hashing.  Suite B cryptography has been selected from cryptography
      that has been approved by NIST for use by the U.S. Government and
      specified in NIST standards or recommendations.

   IP Security (IPsec) provides confidentiality, data integrity, access
   control and data source authentication to IP datagrams.  The Internet
   Key Exchange (IKE) provides an automated key management for IPsec,
   performing mutual authentication between two parties and establishing
   security associations (SAs) that protects both IKE and IPsec
   communications.  Suite B compliant implementations for IPsec MUST use
   IKEv2 [RFC5996].

   [RFC4869bis] defines a set of four cryptographic user interface
   suites for IPsec that are comprised of Suite B algorithms.  The four
   suites specify options for IKEv2 and for the IP Encapsulating
   Security Payload (ESP), [RFC4303].  Suite B compliant implementations
   for IPsec MUST use one of these four suites depending upon the
   desired security level and security services.

2.  Conventions used in this Document

   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].







Burgin & Peck           Expires January 12, 2012                [Page 3]

Internet-Draft         Suite B Profile for IPsec           July 11, 2011


3.  Suite B Requirements

   Suite B requires that key establishment and signature algorithms be
   based upon Elliptic Curve Cryptography and that the encryption
   algorithm be AES [FIPS197].  Suite B includes [NSA]:

   Encryption:           Advanced Encryption Standard (AES) (key sizes
                         of 128 and 256 bits)

   Digital Signature     Elliptic Curve Digital Signature Algorithm
                         (ECDSA) [FIPS186-3] (using the curves with 256-
                         and 384-bit prime moduli)

   Key Exchange          Elliptic Curve Diffie-Hellman (ECDH)
                         [SP800-56A], (using the curves with 256- and
                         384-bit prime moduli)

   Hashes                SHA-256 and SHA-384 [FIPS180-3]

   The two elliptic curves used in Suite B appear in the literature
   under two different names.  For sake of clarity, we list both names
   below:

      Curve        NIST name       SECG name   IANA assigned DH group #
      -----------------------------------------------------------------
      P-256        nistp256        secp256r1               19
      P-384        nistp384        secp384r1               20

   IANA has already registered these DH groups in [IKEV2IANA].

4.  Minimum Levels of Security (minLOS)

   Suite B provides for two levels of cryptographic security, namely a
   128-bit minimum level of security (minLOS_128) and a 192-bit minimum
   level of security (minLOS_192).  Each level defines a minimum
   strength that all cryptographic algorithms must provide.

4.1.  Non-signature Primitives

   We divide the Suite B non-signature primitives into two columns as
   shown in Table 1.










Burgin & Peck           Expires January 12, 2012                [Page 4]

Internet-Draft         Suite B Profile for IPsec           July 11, 2011


                                  Column 1            Column 2
                             +-------------------+------------------+
            Encryption       |    AES-128        |    AES-256       |
                             +-------------------+------------------+
            Key Agreement    |    ECDH on P-256  |    ECDH on P-384 |
                             +-------------------+------------------+
            Hash for PRF/MAC |    SHA256         |    SHA384        |
                             +-------------------+------------------+
             Table 1: Suite B Cryptographic Non-Signature Primitives

   At the 128-bit minimum level of security:

      - the non-signature primitives MUST either come exclusively from
        Column 1 or exclusively from Column 2.

   At the 192-bit minimum level of security:

      - the non-signature primitives MUST come exclusively from
        Column 2.

4.2.  Suite B IPsec Cryptographic Suites

   Each system MUST specify a security level of a minimum of 128 bits or
   192 bits.  The security level determines which suites from
   [RFC4869bis] are allowed.

   The four Suite B cryptographic user interface (UI) suites,
   [RFC4869bis], Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256 or
   Suite-B-GMAC-256, satisfy the requirements of section 3.

   At the 128-bit minimum level of security:

      - one of Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256 or
        Suite-B-GMAC-256 MUST be used by Suite B IPsec compliant
        implementations [RFC4869bis].

   At the 192-bit minimum level of security:

      - one of Suite-B-GCM-256 or Suite-B-GMAC-256 MUST be used by
        Suite B IPsec compliant implementations [RFC4869bis].

4.3.  Suite B IKEv2 Authentication

   Digital signatures using ECDSA MUST be used for authentication by
   Suite B compliant implementations.  [RFC4754] defines two digital
   signature algorithms: ECDSA-256 and ECDSA-384.  Following the
   direction of RFC 4754, ECDSA-256 represents an instantiation of the
   ECDSA algorithm using the P-256 curve and the SHA-256 hash function.



Burgin & Peck           Expires January 12, 2012                [Page 5]

Internet-Draft         Suite B Profile for IPsec           July 11, 2011


   ECDSA-384 represents an instantiation of the ECDSA algorithm using
   the P-384 curve and the SHA-384 hash function.

   If configured at a minimum level of security of 128 bits, a system
   MUST use either ECDSA-256 or ECDSA-384 for IKE authentication.  It is
   allowable for one party to authenticate with ECDSA-256 and the other
   party to authenticate with ECDSA-384.  This flexibility will allow
   interoperability between an initiator and a responder that have
   different sizes of ECDSA authentication keys.

   Initiators and responders in a system configured at a minimum level
   of security of 128 bits MUST be able to verify ECDSA-256 signatures
   and SHOULD be able to verify ECDSA-384 signatures.

   If configured at a minimum level of security of 192 bits, ECDSA-384
   MUST be used by both parties for IKEv2 authentication.

   Initiators and responders in a system configured at a minimum level
   of security of 192 bits MUST be able to verify ECDSA-384 signatures.

   Authentication methods other than ECDSA-256 and ECDSA-384 MUST NOT be
   used for IKEv2 authentication.  If a relying party receives a message
   signed with any other authentication method, it MUST return an
   AUTHENTICATION_FAILED notification and stop processing the message.

4.4.  Digital Signatures and Certificates

   The initiator and responder, at both minimum levels of security, MUST
   each have an X.509 certificate that complies with the "Suite B
   Certificate and Certificate Revocation List (CRL) Profile" [RFC5759]
   and that contains an elliptic curve public key with the key usage bit
   set for digital signature.

5.  Suite B Security Associations (SAs) for IKEv2 and IPsec

   The four suites in [RFC4869bis] specify options for ESP, [RFC4303],
   and IKEv2, [RFC5996].  The four suites are differentiated by
   cryptographic algorithm strength 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 upon the AES mode ("GCM" or "GMAC") and the AES key length
   specified for ESP ("128" or "256").  Suites with "GCM" in their name
   MUST be used when ESP integrity protection and encryption are both
   needed. Suites with "GMAC" in their name MUST be used only when there
   is no need for ESP encryption.

   An initiator in a system configured at a minimum level of security of
   128 bits MUST offer one or more of the four suites: Suite-B-GCM-128,



Burgin & Peck           Expires January 12, 2012                [Page 6]

Internet-Draft         Suite B Profile for IPsec           July 11, 2011


   Suite-B-GMAC-128, Suite-B-GCM-256 or Suite-B-GMAC-256 [RFC4869bis].
   Suite-B-GCM-128 and Suite-B-GMAC-128, if offered, MUST appear in the
   IKEv2 and IPsec SA payloads before any offerings of Suite-B-GCM-256
   and Suite-B-GMAC-256.

   A responder in a system configured at a minimum level of security of
   128 bits MUST support one or both of the two suites Suite-B-GCM-128
   or Suite-B-GMAC-128 and SHOULD support one or both of the two suites
   Suite-B-GCM-256 or Suite-B-GMAC-256.  The responder SHOULD accept the
   first Suite B UI suite offered by the initiator that it can
   accommodate.  If none of the four suites are offered, the responder
   MUST return a Notify payload with the error "NO_PROPOSAL_CHOSEN".

   An initiator in a system configured at a minimum level of security of
   192 bits MUST offer either one or both suites: Suite-B-GCM-256 or
   Suite-B-GMAC-256.

   A responder configured in a system at a minimum level of security of
   192 bits MUST choose one of Suite-B-GCM-256 or Suite-B-GMAC-256. If
   neither suite is offered, the responder MUST return a Notify payload
   with the error "NO_PROPOSAL_CHOSEN".

6.  The Key Exchange Payload in the IKE_SA_INIT Exchange

   A Suite B IPsec compliant initiator and responder MUST each generate
   an ephemeral elliptic curve key pair to be used in the elliptic curve
   Diffie-Hellman (ECDH) key exchange.  If the 256-bit random ECP group
   for Transform Type 4 is selected, each side MUST generate an EC key
   pair using the P-256 elliptic curve, [SP800-57]. If the 384-bit
   random ECP group for Transform Type 4 is selected, each side MUST
   generate an EC key pair using the P-384 elliptic curve, [SP800-57].
   The ephemeral public keys MUST be stored in the key exchange payload
   as in [RFC5903].

7.  Generating Keying Material for the IKE SA

   The elliptic curve Diffie-Hellman shared secret established during
   the key exchange consists of the x value of the elliptic curve
   Diffie-Hellman common value [RFC5903].  The x value is 256 or 384
   bits when using the P-256 or P-384 curve, respectively.

   IKEv2, [RFC5996], allows for the reuse of Diffie-Hellman ephemeral
   keys. Section 5.6.4.3 of NIST SP800-56A states that an ephemeral
   private key MUST be used in exactly one key establishment transaction
   and MUST be zeroized after its use.  Section 5.8 of SP800-56A states
   that the Diffie-Hellman shared secret MUST be zeroized immediately
   after its use.  Suite B compliant IPsec systems MUST follow the
   mandates in SP800-56A.



Burgin & Peck           Expires January 12, 2012                [Page 7]

Internet-Draft         Suite B Profile for IPsec           July 11, 2011


   If using PRF-HMAC-SHA-256, SKEYSEED, SK_d, SK_pi and SK_pr MUST each
   be generated to be 256 bits long per [RFC5996, section 2.14]. If
   using PRF-HMAC-SHA-384, SKEYSEED, SK_d, SK_pi and SK_pr MUST each be
   generated to be 384 bits long.  SK_ai and SK_ar MUST be 256 or 384
   bits long if using HMAC-SHA-256-128 or HMAC-SHA-384-192,
   respectively. SK_ei and SK_er MUST be 128 or 256 bits long if the key
   length attribute for AES_ENC_CBC is set to 128 or 256, respectively.

8.  Additional Requirements

   AH is not supported in Suite B compliant implementations.

   Per [RFC5996], although ESP does not directly include a
   Diffie-Hellman exchange, a Diffie-Hellman group MAY be negotiated for
   the Child SA.  This allows the peers to employ Diffie-Hellman in the
   CREATE_CHILD SA exchange.  If a transform Type 4 is specified for an
   SA for ESP, the value of the transform MUST match that of the
   transform used by the IKE SA.

   Per RFC 5996, if a CREATE_CHILD_SA exchange includes a KEi payload,
   at least one of the SA offers MUST include the Diffie-Hellman group
   of the KEi.  For Suite B IPsec compliant implementations, the
   Diffie-Hellman group of the KEi MUST use the same random ECP group
   used in the IKE_INIT_SA.

   For IKEv2, rekeying of the CREATE_CHILD_SA MUST be supported by both
   parties.  The initiator of this exchange MAY include a new
   Diffie-Hellman key; if it is included, it MUST use the same random
   ECP group used in the IKE_INIT_SA.  It the initiator of the exchange
   includes a Diffie-Hellman key, the responder MUST include a
   Diffie-Hellman key, and it MUST use the same random ECP group.

   Suite B IPsec compliant systems MUST support IKEv2 and MUST NOT use
   IKEv1 between a Suite B compliant initiator and responder.  To
   accommodate backward compatibility, a Suite B IPsec compliant system
   can be configured to use IKEv1 so long as only IKEv2 is used between
   a Suite B compliant initiator and responder.  However, when IKEv1 is
   being used, the system is not being operated in a Suite B compliant
   mode.

   IKEv2 does not specify how Identification Payloads (IDi and IDr) in
   the IKE_AUTH exchanges are used for policy lookup.  The IKEv2
   authentication method MUST NOT use the Identification Payloads for
   policy lookup.  Instead, the authentication method MUST use an
   end-entity found in the end-entity certificate provided by the
   authenticating party.

   The administrative user interface, (UI), for a system that conforms



Burgin & Peck           Expires January 12, 2012                [Page 8]

Internet-Draft         Suite B Profile for IPsec           July 11, 2011


   to this profile MUST allow the operator to specify a single suite.
   If only one suite is specified in the administrative UI, the IKEv2
   implementation MUST only offer algorithms for that one suite.

   The administrative UI MAY allow the operator to specify more than one
   suite; if it allows this, it MUST allow the operator to specify a
   preferred order for the suites that are to be offered or accepted.
   The preferred order MUST follow the direction provided in section 4.
   If more than one suite is specified in the administrative UI, the
   IKEv2 implementation MUST only offer algorithms for those suites.

9.  Security Considerations

   This document discusses security requirements throughout, and it
   inherits the security considerations of [RFC4303], [RFC4754],
   [RFC5759], and [RFC5996].

10.  IANA Considerations

   None.

11.  References

11.1  Normative References

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4303]     Kent, S., "IP Encapsulating Security Payload (ESP)",
                 RFC 4303, December 2005.

   [RFC4754]     Fu, D. and J. Solinas, "IKE and IKEv2 Authentication
                 Using the Elliptic Curve Digital Signature Algorithm
                 (ECDSA)", RFC 4754, January 2007.


   [RFC4869bis]  Law, L. and J. Solinas, "Suite B Cryptographic Suites
                 for IPsec", draft-law-rfc4869bis-01, February 2011.

   [RFC5759]     Solinas, J. and L. Zieglar, "Suite B Certificate and
                 Certificate Revocation List (CRL) Profile", RFC 5759,
                 January 2010.

   [RFC5996]     Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
                 "Internet Key Exchange Protocol Version 2 (IKEv2)",
                 RFC 5996, September 2010.





Burgin & Peck           Expires January 12, 2012                [Page 9]

Internet-Draft         Suite B Profile for IPsec           July 11, 2011


   [FIPS180-3]   National Institute of Standards and Technology, "Secure
                 Hash Standard", FIPS PUB 180-3, October 2008.

   [FIPS186-3]   National Institute of Standards and Technology,
                 "Digital Signature Standard (DSS)", FIPS PUB 186-3,
                 June 2009.

   [FIPS197]     National Institute of Standards and Technology,
                 "Advanced Encryption Standard (AES)", FIPS PUB 197,
                 November 2001.

11.2  Informative References

   [IKEV2IANA]   "Internet Key Exchange Version 2 (IKEv2) Parameters",
                 <http://www.iana.org>.

   [NSA]         U.S. National Security Agency, "Fact Sheet NSA Suite B
                 Cryptography", January 2009,
                 [http://www.nsa.gov/ia/programs/suiteb_cryptography/].

   [RFC5903]     Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
                 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June
                 2010.

   [SP800-56A]   National Institute of Standards and Technology,
                 "Recommendation for Pair-wise Key Establishment Schemes
                 Using Discrete Logarithm Cryptography", NIST Special
                 Publication 800-56A, March 2007.

   [SP800-57]    National Institute of Standards and Technology,
                 "Recommendation for Key Management - Part 1", NIST
                 Special Publication 800-57, March 2007.

Authors' Addresses

   Kelley W. Burgin
   National Security Agency

   EMail: kwburgi@tycho.ncsc.mil

   Michael A. Peck
   The MITRE Corporation

   EMail: mpeck@mitre.org







Burgin & Peck           Expires January 12, 2012               [Page 10]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/