RFC 6380

Suite B Profile for Internet Protocol Security (IPsec)

📅 published October 2011, from ietf

RFC 6380: Suite B Profile for Internet Protocol Security (IPsec) 💖

Okay bestie, let's get into it 🎀 This is RFC 6380, an Informational doc (ISSN 2070-1721) written by K. Burgin from the National Security Agency and M. Peck from The MITRE Corporation. It came out in October 2011. It's not a Standards Track spec, and its title block doesn't list anything it obsoletes or updates, so it's just doing its own thing 🌸

Abstract ✨

The US Government put out guidelines called "NSA Suite B Cryptography," dated July, 2005, and they set the cryptographic algorithm policy for national security applications 🔐 This doc is the rulebook for using Suite B crypto in IP Security (IPsec) 💅

A lot of the Suite B algorithms show up in other environments too, so most of the conventions you need are already written up elsewhere 📚 This doc points you to the source for each one and repeats some of the important details, so devs who want to support Suite B have a handy cheat sheet 🧚

Status of This Memo 🦋

This doc is not an Internet Standards Track specification. It's published for informational purposes 💜

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓

Info about the current status, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6380 ✨

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🫶

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc. Code Components pulled out of this doc must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 📜

This doc may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸

Table of Contents 💅

1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Suite B Requirements ............................................3
4. Minimum Levels of Security (minLOS) .............................4
4.1. Non-Signature Primitives ...................................4
4.2. Suite B IPsec Cryptographic Suites .........................4
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 .........................................7
9. Security Considerations .........................................8
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ...................................10

1. Introduction 🎀

This doc lays out the rules for using NSA Suite B Cryptography [SuiteB] in IP Security (IPsec) 🔐

IPsec gives IP datagrams confidentiality, data integrity, access control, and data source authentication. The Internet Key Exchange (IKE) handles automated key management for IPsec. It does mutual authentication between two parties and sets up security associations (SAs) that protect both IKE and IPsec traffic. Suite B compliant implementations for IPsec MUST use IKEv2 [RFC5996] 💜

[RFC6379] defines four cryptographic user interface suites for IPsec, all made from Suite B algorithms. Those four suites cover options for IKEv2 and for the IP Encapsulating Security Payload (ESP), [RFC4303] 🦋 Depending on the security level and security services you want, Suite B compliant implementations for IPsec MUST use one of these four suites ✨

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 doc are to be read as described in [RFC2119] 🫶

3. Suite B Requirements 🌸

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

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 show up in the literature under two different names. For clarity, here are both names 👀

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 two levels of cryptographic security: 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 🧚

The non-signature primitives get split into two columns, as shown in Table 1 ✨

                              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. That security level decides which suites from [RFC6379] are allowed 🦋

The four Suite B cryptographic user interface suites ("UI suites") [RFC6379] are Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256, and Suite-B-GMAC-256. They 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 [RFC6379].

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

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 is an instantiation of the ECDSA algorithm using the P-256 curve and the SHA-256 hash function. ECDSA-384 is an instantiation of the ECDSA algorithm using the P-384 curve and the SHA-384 hash function ✨

If it's configured at a minimum level of security of 128 bits, a system MUST use either ECDSA-256 or ECDSA-384 for IKE authentication. It's allowed for one party to authenticate with ECDSA-256 and the other party to authenticate with ECDSA-384. That flexibility lets an initiator and a responder with different sizes of ECDSA authentication keys still interoperate 🌈

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 it's 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 🙈

For Suite B compliant systems, authentication methods other than ECDSA-256 and ECDSA-384 MUST NOT be used for IKEv2 authentication. If a relying party gets 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 use an X.509 certificate that complies with the "Suite B Certificate and Certificate Revocation List (CRL) Profile" [RFC5759]. That certificate has to contain an elliptic curve public key with the key usage bit set for digital signature 👑

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

okay so the four suites in [RFC6379] are the options for ESP [RFC4303] and IKEv2 [RFC5996] 💖 they're told apart by how strong the crypto is and by whether ESP gives you confidentiality plus integrity or integrity only 🔐 the names come from the AES mode ("GCM" or "GMAC") and the AES key length set for ESP ("128" or "256"). bestie, the rule is simple: suites with GCM in the name MUST be used when ESP needs both integrity protection and encryption, and suites with GMAC in the name MUST be used only when there's no need for ESP encryption 🫶

an initiator in a system set to a minimum level of security of 128 bits MUST offer one or more of the four suites: Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256, or Suite-B-GMAC-256 [RFC6379] 🦋 and if it offers Suite-B-GCM-128 or Suite-B-GMAC-128, those MUST show up in the IKEv2 and IPsec SA payloads before any Suite-B-GCM-256 or Suite-B-GMAC-256 offers 🌸

a responder at that same 128-bit minimum MUST support one or both of Suite-B-GCM-128 or Suite-B-GMAC-128, and SHOULD support one or both of Suite-B-GCM-256 or Suite-B-GMAC-256 ✨ it MUST accept one of the Suite B UI suites. if none of the four suites show up in the offer, the responder MUST return a Notify payload with the error NO_PROPOSAL_CHOSEN when it's running in Suite B compliant mode 🙈

now the 192-bit minimum 👑 an initiator at 192 bits MUST offer either one or both of Suite-B-GCM-256 or Suite-B-GMAC-256 💅 and a responder configured for 192 bits MUST choose one of those two. if neither one 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 for the elliptic curve Diffie-Hellman (ECDH) key exchange 🔑 if the 256-bit random ECP group for Transform Type 4 is picked, 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 picked, 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 ECDH shared secret from the key exchange is the x value of the ECDH common value [RFC5903] 🦋 that x value is 256 or 384 bits, depending on whether you're using P-256 or P-384 💖

okay, this part is lowkey important. IKEv2 [RFC5996] lets you reuse Diffie-Hellman ephemeral keys 👀 but Section 5.6.4.3 of NIST SP800-56A says 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 says the Diffie-Hellman shared secret MUST be zeroized immediately after its use 🧼 so Suite B compliant IPsec systems MUST follow the mandates in SP800-56A. no exceptions, periodt 💅

now the lengths 📏 if you're using PRF-HMAC-SHA-256, SKEYSEED, SK_d, SK_pi, and SK_pr MUST each be generated to be 256 bits long per RFC 5996 ([RFC5996], Section 2.14). if you're 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 you're using HMAC-SHA-256-128 or HMAC-SHA-384-192, respectively. and 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 🚫 no AH for us, bestie 🙅‍♀️

per [RFC5996], even though ESP doesn't directly include a Diffie-Hellman exchange, a Diffie-Hellman group MAY be negotiated for the Child SA 🌸 that lets the peers use 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 the transform used by the IKE SA 🫶

also 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 that was 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 does, it MUST use the same random ECP group used in the IKE_INIT_SA. and if the initiator includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key too, 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 🙅‍♀️ for backward compatibility, a Suite B IPsec compliant system can be configured to use IKEv1 as long as only IKEv2 is used between a Suite B compliant initiator and responder. BUT when IKEv1 is being used, the system is not operating in a Suite B compliant mode 😭

IKEv2 doesn't specify how Identification Payloads (IDi and IDr) in the IKE_AUTH exchanges are used for policy lookup 🤷‍♀️ so for Suite B compliant systems, 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 to this profile MUST allow the operator to specify a single suite 👑 and 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 does, it MUST allow the operator to specify a preferred order for the suites that are to be offered or accepted, and that 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]. bestie, it's a whole lot of security, so don't skip those referenced docs 😭💀

10. References 📚

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

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

[RFC6379]     Law, L. and J. Solinas, "Suite B Cryptographic Suites
              for IPsec", RFC 6379, October 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.

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

10.2. Informative References

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

[SuiteB]      U.S. National Security Agency, "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.

Authors' Addresses 🎀

Kelley W. Burgin
National Security Agency

EMail: kwburgi@tycho.ncsc.mil


Michael A. Peck
The MITRE Corporation

EMail: mpeck@mitre.org
📦 where this page comes from