idnits 2.17.1 draft-burgin-ipsec-suiteb-profile-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 12, 2011) is 4638 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K.W. Burgin 3 Internet Draft National Security Agency 4 Intended Status: Informational M.A. Peck 5 Expires: February 13, 2012 The MITRE Corporation 6 August 12, 2011 8 Suite B Profile for Internet Protocol Security (IPsec) 9 draft-burgin-ipsec-suiteb-profile-02 11 Abstract 13 The United States Government has published guidelines for "NSA 14 Suite B Cryptography" dated July, 2005, which defines cryptographic 15 algorithm policy for national security applications. This document 16 specifies the conventions for using Suite B cryptography in IP 17 Security (IPsec). 19 Since many of the Suite B algorithms enjoy uses in other environments 20 as well, the majority of the conventions needed for the Suite B 21 algorithms are already specified in other documents. This document 22 references the source of these conventions, with some relevant 23 details repeated to aid developers that choose to support Suite B. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 13, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Conventions used in this Document . . . . . . . . . . . . . . 3 73 3. Suite B Requirements . . . . . . . . . . . . . . . . . . . . . 4 74 4. Minimum Levels of Security (minLOS) . . . . . . . . . . . . . 4 75 4.1. Non-signature Primitives . . . . . . . . . . . . . . . . . 4 76 4.2. Suite B IPsec Cryptographic Suites . . . . . . . . . . . . 5 77 4.3. Suite B IKEv2 Authentication . . . . . . . . . . . . . . . 5 78 4.4. Digital Signatures and Certificates . . . . . . . . . . . 6 79 5. Suite B Security Associations (SAs) for IKEv2 and IPsec . . . 6 80 6. The Key Exchange Payload in the IKE_SA_INIT Exchange . . . . . 7 81 7. Generating Keying Material for the IKE SA . . . . . . . . . . 7 82 8. Additional Requirements . . . . . . . . . . . . . . . . . . . 8 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 87 11.2. Informative References . . . . . . . . . . . . . . . . . 10 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 The Fact Sheet on National Security Agency (NSA) Suite B Cryptography 93 [NSA] states: 95 A Cryptographic Interoperability Strategy (CIS) was developed to 96 find ways to increase assured rapid sharing of information both 97 within the U.S. and between the U.S. and her partners through the 98 use of a common suite of public standards, protocols, algorithms 99 and modes referred to as the "Secure Sharing Suite" or S.3 The 100 implementation of CIS will facilitate the development of a broader 101 range of secure cryptographic products which will be available to 102 a wide customer base. The use of selected public cryptographic 103 standards and protocols and Suite B is the core of CIS. 105 In 2005, NSA announced Suite B Cryptography which built upon the 106 National Policy on the use of the Advanced Encryption Standard 107 (AES) to Protect National Security Systems and National Security 108 Information. In addition to the AES algorithm, Suite B includes 109 cryptographic algorithms for key exchanges, digital signatures and 110 hashing. Suite B cryptography has been selected from cryptography 111 that has been approved by NIST for use by the U.S. Government and 112 specified in NIST standards or recommendations. 114 IP Security (IPsec) provides confidentiality, data integrity, access 115 control and data source authentication to IP datagrams. The Internet 116 Key Exchange (IKE) provides an automated key management for IPsec, 117 performing mutual authentication between two parties and establishing 118 security associations (SAs) that protects both IKE and IPsec 119 communications. Suite B compliant implementations for IPsec MUST use 120 IKEv2 [RFC5996]. 122 [RFC4869bis] defines a set of four cryptographic user interface 123 suites for IPsec that are comprised of Suite B algorithms. The four 124 suites specify options for IKEv2 and for the IP Encapsulating 125 Security Payload (ESP), [RFC4303]. Suite B compliant implementations 126 for IPsec MUST use one of these four suites depending upon the 127 desired security level and security services. 129 2. Conventions used in this Document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. Suite B Requirements 137 Suite B requires that key establishment and signature algorithms be 138 based upon Elliptic Curve Cryptography and that the encryption 139 algorithm be AES [FIPS197]. Suite B includes [NSA]: 141 Encryption: Advanced Encryption Standard (AES) (key sizes 142 of 128 and 256 bits) 144 Digital Signature Elliptic Curve Digital Signature Algorithm 145 (ECDSA) [FIPS186-3] (using the curves with 256- 146 and 384-bit prime moduli) 148 Key Exchange Elliptic Curve Diffie-Hellman (ECDH) 149 [SP800-56A], (using the curves with 256- and 150 384-bit prime moduli) 152 Hashes SHA-256 and SHA-384 [FIPS180-3] 154 The two elliptic curves used in Suite B appear in the literature 155 under two different names. For sake of clarity, we list both names 156 below: 158 Curve NIST name SECG name IANA assigned DH group # 159 ----------------------------------------------------------------- 160 P-256 nistp256 secp256r1 19 161 P-384 nistp384 secp384r1 20 163 IANA has already registered these DH groups in [IKEV2IANA]. 165 4. Minimum Levels of Security (minLOS) 167 Suite B provides for two levels of cryptographic security, namely a 168 128-bit minimum level of security (minLOS_128) and a 192-bit minimum 169 level of security (minLOS_192). Each level defines a minimum 170 strength that all cryptographic algorithms must provide. 172 4.1. Non-signature Primitives 174 We divide the Suite B non-signature primitives into two columns as 175 shown in Table 1. 177 Column 1 Column 2 178 +-------------------+------------------+ 179 Encryption | AES-128 | AES-256 | 180 +-------------------+------------------+ 181 Key Agreement | ECDH on P-256 | ECDH on P-384 | 182 +-------------------+------------------+ 183 Hash for PRF/MAC | SHA256 | SHA384 | 184 +-------------------+------------------+ 185 Table 1: Suite B Cryptographic Non-Signature Primitives 187 At the 128-bit minimum level of security: 189 - the non-signature primitives MUST either come exclusively from 190 Column 1 or exclusively from Column 2. 192 At the 192-bit minimum level of security: 194 - the non-signature primitives MUST come exclusively from 195 Column 2. 197 4.2. Suite B IPsec Cryptographic Suites 199 Each system MUST specify a security level of a minimum of 128 bits or 200 192 bits. The security level determines which suites from 201 [RFC4869bis] are allowed. 203 The four Suite B cryptographic user interface (UI) suites, 204 [RFC4869bis], Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256 or 205 Suite-B-GMAC-256, satisfy the requirements of section 3. 207 At the 128-bit minimum level of security: 209 - one of Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256 or 210 Suite-B-GMAC-256 MUST be used by Suite B IPsec compliant 211 implementations [RFC4869bis]. 213 At the 192-bit minimum level of security: 215 - one of Suite-B-GCM-256 or Suite-B-GMAC-256 MUST be used by 216 Suite B IPsec compliant implementations [RFC4869bis]. 218 4.3. Suite B IKEv2 Authentication 220 Digital signatures using ECDSA MUST be used for authentication by 221 Suite B compliant implementations. [RFC4754] defines two digital 222 signature algorithms: ECDSA-256 and ECDSA-384. Following the 223 direction of RFC 4754, ECDSA-256 represents an instantiation of the 224 ECDSA algorithm using the P-256 curve and the SHA-256 hash function. 226 ECDSA-384 represents an instantiation of the ECDSA algorithm using 227 the P-384 curve and the SHA-384 hash function. 229 If configured at a minimum level of security of 128 bits, a system 230 MUST use either ECDSA-256 or ECDSA-384 for IKE authentication. It is 231 allowable for one party to authenticate with ECDSA-256 and the other 232 party to authenticate with ECDSA-384. This flexibility will allow 233 interoperability between an initiator and a responder that have 234 different sizes of ECDSA authentication keys. 236 Initiators and responders in a system configured at a minimum level 237 of security of 128 bits MUST be able to verify ECDSA-256 signatures 238 and SHOULD be able to verify ECDSA-384 signatures. 240 If configured at a minimum level of security of 192 bits, ECDSA-384 241 MUST be used by both parties for IKEv2 authentication. 243 Initiators and responders in a system configured at a minimum level 244 of security of 192 bits MUST be able to verify ECDSA-384 signatures. 246 For Suite B compliant systems, authentication methods other than 247 ECDSA-256 and ECDSA-384 MUST NOT be used for IKEv2 authentication. 248 If a relying party receives a message signed with any other 249 authentication method, it MUST return an AUTHENTICATION_FAILED 250 notification and stop processing the message. 252 4.4. Digital Signatures and Certificates 254 The initiator and responder, at both minimum levels of security, MUST 255 each use an X.509 certificate that complies with the "Suite B 256 Certificate and Certificate Revocation List (CRL) Profile" [RFC5759] 257 and that contains an elliptic curve public key with the key usage bit 258 set for digital signature. 260 5. Suite B Security Associations (SAs) for IKEv2 and IPsec 262 The four suites in [RFC4869bis] specify options for ESP, [RFC4303], 263 and IKEv2, [RFC5996]. The four suites are differentiated by 264 cryptographic algorithm strength and a choice of whether the 265 Encapsulating Security Payload (ESP) is to provide both 266 confidentiality and integrity or integrity only. The suite names are 267 based upon the AES mode ("GCM" or "GMAC") and the AES key length 268 specified for ESP ("128" or "256"). Suites with "GCM" in their name 269 MUST be used when ESP integrity protection and encryption are both 270 needed. Suites with "GMAC" in their name MUST be used only when there 271 is no need for ESP encryption. 273 An initiator in a system configured at a minimum level of security of 274 128 bits MUST offer one or more of the four suites: Suite-B-GCM-128, 275 Suite-B-GMAC-128, Suite-B-GCM-256 or Suite-B-GMAC-256 [RFC4869bis]. 276 Suite-B-GCM-128 and Suite-B-GMAC-128, if offered, MUST appear in the 277 IKEv2 and IPsec SA payloads before any offerings of Suite-B-GCM-256 278 and Suite-B-GMAC-256. 280 A responder in a system configured at a minimum level of security of 281 128 bits MUST support one or both of the two suites Suite-B-GCM-128 282 or Suite-B-GMAC-128 and SHOULD support one or both of the two suites 283 Suite-B-GCM-256 or Suite-B-GMAC-256. The responder MUST accept one 284 of the Suite B UI suites. If none of the four suites are offered, 285 the responder MUST return a Notify payload with the error 286 "NO_PROPOSAL_CHOSEN" when operating in Suite B compliant mode. 288 An initiator in a system configured at a minimum level of security of 289 192 bits MUST offer either one or both suites: Suite-B-GCM-256 or 290 Suite-B-GMAC-256. 292 A responder configured in a system at a minimum level of security of 293 192 bits MUST choose one of Suite-B-GCM-256 or Suite-B-GMAC-256. If 294 neither suite is offered, the responder MUST return a Notify payload 295 with the error "NO_PROPOSAL_CHOSEN". 297 6. The Key Exchange Payload in the IKE_SA_INIT Exchange 299 A Suite B IPsec compliant initiator and responder MUST each generate 300 an ephemeral elliptic curve key pair to be used in the elliptic curve 301 Diffie-Hellman (ECDH) key exchange. If the 256-bit random ECP group 302 for Transform Type 4 is selected, each side MUST generate an EC key 303 pair using the P-256 elliptic curve, [SP800-57]. If the 384-bit 304 random ECP group for Transform Type 4 is selected, each side MUST 305 generate an EC key pair using the P-384 elliptic curve, [SP800-57]. 306 The ephemeral public keys MUST be stored in the key exchange payload 307 as in [RFC5903]. 309 7. Generating Keying Material for the IKE SA 311 The elliptic curve Diffie-Hellman shared secret established during 312 the key exchange consists of the x value of the elliptic curve 313 Diffie-Hellman common value [RFC5903]. The x value is 256 or 384 314 bits when using the P-256 or P-384 curve, respectively. 316 IKEv2, [RFC5996], allows for the reuse of Diffie-Hellman ephemeral 317 keys. Section 5.6.4.3 of NIST SP800-56A states that an ephemeral 318 private key MUST be used in exactly one key establishment transaction 319 and MUST be zeroized after its use. Section 5.8 of SP800-56A states 320 that the Diffie-Hellman shared secret MUST be zeroized immediately 321 after its use. Suite B compliant IPsec systems MUST follow the 322 mandates in SP800-56A. 324 If using PRF-HMAC-SHA-256, SKEYSEED, SK_d, SK_pi and SK_pr MUST each 325 be generated to be 256 bits long per [RFC5996, section 2.14]. If 326 using PRF-HMAC-SHA-384, SKEYSEED, SK_d, SK_pi and SK_pr MUST each be 327 generated to be 384 bits long. SK_ai and SK_ar MUST be 256 or 384 328 bits long if using HMAC-SHA-256-128 or HMAC-SHA-384-192, 329 respectively. SK_ei and SK_er MUST be 128 or 256 bits long if the key 330 length attribute for AES_ENC_CBC is set to 128 or 256, respectively. 332 8. Additional Requirements 334 AH is not supported in Suite B compliant implementations. 336 Per [RFC5996], although ESP does not directly include a 337 Diffie-Hellman exchange, a Diffie-Hellman group MAY be negotiated for 338 the Child SA. This allows the peers to employ Diffie-Hellman in the 339 CREATE_CHILD SA exchange. If a transform Type 4 is specified for an 340 SA for ESP, the value of the transform MUST match that of the 341 transform used by the IKE SA. 343 Per RFC 5996, if a CREATE_CHILD_SA exchange includes a KEi payload, 344 at least one of the SA offers MUST include the Diffie-Hellman group 345 of the KEi. For Suite B IPsec compliant implementations, the 346 Diffie-Hellman group of the KEi MUST use the same random ECP group 347 used in the IKE_INIT_SA. 349 For IKEv2, rekeying of the CREATE_CHILD_SA MUST be supported by both 350 parties. The initiator of this exchange MAY include a new 351 Diffie-Hellman key; if it is included, it MUST use the same random 352 ECP group used in the IKE_INIT_SA. It the initiator of the exchange 353 includes a Diffie-Hellman key, the responder MUST include a 354 Diffie-Hellman key, and it MUST use the same random ECP group. 356 Suite B IPsec compliant systems MUST support IKEv2 and MUST NOT use 357 IKEv1 between a Suite B compliant initiator and responder. To 358 accommodate backward compatibility, a Suite B IPsec compliant system 359 can be configured to use IKEv1 so long as only IKEv2 is used between 360 a Suite B compliant initiator and responder. However, when IKEv1 is 361 being used, the system is not being operated in a Suite B compliant 362 mode. 364 IKEv2 does not specify how Identification Payloads (IDi and IDr) in 365 the IKE_AUTH exchanges are used for policy lookup. For Suite B 366 compliant systems, the IKEv2 authentication method MUST NOT use the 367 Identification Payloads for policy lookup. Instead, the 368 authentication method MUST use an end-entity found in the end-entity 369 certificate provided by the authenticating party. 371 The administrative user interface, (UI), for a system that conforms 372 to this profile MUST allow the operator to specify a single suite. 373 If only one suite is specified in the administrative UI, the IKEv2 374 implementation MUST only offer algorithms for that one suite. 376 The administrative UI MAY allow the operator to specify more than one 377 suite; if it allows this, it MUST allow the operator to specify a 378 preferred order for the suites that are to be offered or accepted. 379 The preferred order MUST follow the direction provided in section 4. 380 If more than one suite is specified in the administrative UI, the 381 IKEv2 implementation MUST only offer algorithms for those suites. 383 9. Security Considerations 385 This document discusses security requirements throughout, and it 386 inherits the security considerations of [RFC4303], [RFC4754], 387 [RFC5759], and [RFC5996]. 389 10. IANA Considerations 391 None. 393 11. References 395 11.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 401 RFC 4303, December 2005. 403 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication 404 Using the Elliptic Curve Digital Signature Algorithm 405 (ECDSA)", RFC 4754, January 2007. 407 [RFC4869bis] Law, L. and J. Solinas, "Suite B Cryptographic Suites 408 for IPsec", draft-law-rfc4869bis-01, February 2011. 410 [RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and 411 Certificate Revocation List (CRL) Profile", RFC 5759, 412 January 2010. 414 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 415 "Internet Key Exchange Protocol Version 2 (IKEv2)", 416 RFC 5996, September 2010. 418 [FIPS180-3] National Institute of Standards and Technology, "Secure 419 Hash Standard", FIPS PUB 180-3, October 2008. 421 [FIPS186-3] National Institute of Standards and Technology, 422 "Digital Signature Standard (DSS)", FIPS PUB 186-3, 423 June 2009. 425 [FIPS197] National Institute of Standards and Technology, 426 "Advanced Encryption Standard (AES)", FIPS PUB 197, 427 November 2001. 429 [SP800-56A] National Institute of Standards and Technology, 430 "Recommendation for Pair-wise Key Establishment Schemes 431 Using Discrete Logarithm Cryptography", NIST Special 432 Publication 800-56A, March 2007. 434 [SP800-57] National Institute of Standards and Technology, 435 "Recommendation for Key Management - Part 1", NIST 436 Special Publication 800-57, March 2007. 438 11.2. Informative References 440 [IKEV2IANA] "Internet Key Exchange Version 2 (IKEv2) Parameters", 441 . 443 [NSA] U.S. National Security Agency, "Fact Sheet NSA Suite B 444 Cryptography", January 2009, 445 [http://www.nsa.gov/ia/programs/suiteb_cryptography/]. 447 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 448 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 449 2010. 451 Authors' Addresses 453 Kelley W. Burgin 454 National Security Agency 456 EMail: kwburgi@tycho.ncsc.mil 458 Michael A. Peck 459 The MITRE Corporation 461 EMail: mpeck@mitre.org