idnits 2.17.1 draft-ietf-storm-ipsec-ips-update-04.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4018, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3720, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5040, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4172, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4173, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3821, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4174, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3822, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3720, updated by this document, for RFC5378 checks: 2000-11-06) (Using the creation date from RFC3821, updated by this document, for RFC5378 checks: 2000-10-31) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 20, 2013) is 3831 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 3720 (Obsoleted by RFC 7143) ** Obsolete normative reference: RFC 4307 (Obsoleted by RFC 8247) ** Obsolete normative reference: RFC 5046 (Obsoleted by RFC 7145) ** Obsolete normative reference: RFC 5048 (Obsoleted by RFC 7143) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-57' Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Storage Maintenance (storm) D. Black 3 Internet-Draft EMC 4 Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, P. Koning 5 Intended status: Standards Track Dell 6 Expires: April 23, 2014 October 20, 2013 8 Securing Block Storage Protocols over IP: RFC 3723 Requirements Update 9 for IPsec v3 10 draft-ietf-storm-ipsec-ips-update-04 12 Abstract 14 RFC 3723 specifies IPsec requirements for block storage protocols 15 over IP (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related RFCs); 16 those requirements have subsequently been applied to remote direct 17 data placement protocols, e.g., RDMAP. This document updates RFC 18 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and 19 makes some changes to required algorithms based on developments in 20 cryptography since RFC 3723 was published. 22 [RFC Editor: The "Updates:" list above has been truncated by xml2rfc. 23 The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, 24 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if 25 approved) ] 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 23, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 1.2. Summary of Changes to RFC 3723 . . . . . . . . . . . . . 3 64 1.3. Other Updated RFCs . . . . . . . . . . . . . . . . . . . 4 65 2. ESP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Data Origin Authentication and Data Integrity Transforms 6 67 2.2. Confidentiality Transform Requirements . . . . . . . . . 6 68 3. IKEv1 and IKEv2 Requirements . . . . . . . . . . . . . . . . 8 69 3.1. Authentication Requirements . . . . . . . . . . . . . . . 9 70 3.2. D-H Group and PRF Requirements . . . . . . . . . . . . . 10 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 6.2. Informative References . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 78 1. Introduction 80 RFC 3723 [RFC3723] specifies IPsec requirements for block storage 81 protocols over IP (e.g., iSCSI [RFC3720]) based on IPsec v2 (RFC 2401 82 [RFC2401] and related RFCs); those requirements have subsequently 83 been applied to remote direct data placement protocols, e.g., RDMAP 84 [RFC5040]. This document updates RFC 3723's IPsec requirements to 85 IPsec v3 ([RFC4301] and related RFCs) to reflect developments since 86 RFC 3723 was published. 88 For brevity, this document uses the term "block storage protocols" to 89 refer to all protocols to which RFC 3723's requirements apply, see 90 Section 1.3 for details. 92 In addition to the IPsec v2 requirements in RFC 3723, IPsec v3, as 93 specified in [RFC4301] and related RFCs (e.g., IKEv2 [RFC5996]), 94 SHOULD be implemented for block storage protocols. Retention of the 95 mandatory requirement for IPsec v2 provides interoperability with 96 existing implementations, and the strong recommendation for IPsec v3 97 encourages implementers to move forward to that newer version of 98 IPsec. 100 Cryptographic developments since the publication of RFC 3723 101 necessitate changes to the encryption transform requirements for 102 IPsec v2, as explained further in Section 2.2; these updated 103 requirements also apply to IPsec v3. 105 Block storage protocols can be expected to operate at high data rates 106 (multiple Gigabits/second). The cryptographic requirements in this 107 document are strongly influenced by that expectation; an important 108 example is that 3DES CBC is no longer recommended for block storage 109 protocols due to the frequent rekeying impacts of 3DES's 64-bit block 110 size at high data rates. 112 1.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in RFC 117 2119 [RFC2119]. 119 1.2. Summary of Changes to RFC 3723 121 This document makes the following changes to RFC 3723: 123 o Adds requirements that IPsec v3 SHOULD be implemented (ESPv3 and 124 IKEv2) in addition to IPsec v2, (see Section 1). 126 o Requires extended sequence numbers for both ESPv2 and ESPv3, see 127 Section 2. 129 o Clarifies key size requirements for AES CBC MAC with XCBC 130 extensions (MUST implement 128 bit keys, see Section 2.1). 132 o Adds IPsec v3 requirements for AES GMAC and GCM (SHOULD implement 133 when IKEv2 is supported, see Section 2.1 and Section 2.2). 135 o Removes implementation requirements for 3DES CBC and AES CTR 136 (changes requirements for both to "MAY implement"). Adds a "MUST 137 implement" requirement for AES CBC (see Section 2.2). 139 o Adds specific IKEv2 implementation requirements (see Section 3). 141 o Removes the requirement that IKEv1 use UDP port 500 (see 142 Section 3). 144 o Allows use of OCSP in addition to CRLs to check certificates, and 145 changes the Diffie-Hellman group size recommendation to a minimum 146 of 2048 bits (see Section 3). 148 1.3. Other Updated RFCs 150 RFC 3723's IPsec requirements have been applied to a number of 151 protocols. For that reason, in addition to updating RFC 3723's IPsec 152 requirements, this document also updates the IPsec requirements for 153 each protocol that uses RFC 3723, i.e., the following RFCs are 154 updated - in each case, the update is solely to the IPsec 155 requirements: 157 o [RFC3720] "Internet Small Computer Systems Interface (iSCSI)" 159 o [RFC3821] "Fibre Channel Over TCP/IP (FCIP)" 161 o [RFC3822] "Finding Fibre Channel over TCP/IP (FCIP) Entities Using 162 Service Location Protocol version 2 (SLPv2)" 164 o [RFC4018] "Finding Internet Small Computer Systems Interface 165 (iSCSI) Targets and Name Servers by Using Service Location 166 Protocol version 2 (SLPv2)" 168 o [RFC4172] "iFCP - A Protocol for Internet Fibre Channel Storage 169 Networking" 171 o [RFC4173] "Bootstrapping Clients using the Internet Small Computer 172 System Interface (iSCSI) Protocol" 174 o [RFC4174] "The IPv4 Dynamic Host Configuration Protocol (DHCP) 175 Option for the Internet Storage Name Service" 177 o [RFC5040] "A Remote Direct Memory Access Protocol Specification" 179 o [RFC5041] "Direct Data Placement over Reliable Transports" 181 o [RFC5042] "Direct Data Placement Protocol (DDP) / Remote Direct 182 Memory Access Protocol (RDMAP) Security" 184 o [RFC5043] "Stream Control Transmission Protocol (SCTP) Direct Data 185 Placement (DDP) Adaptation" 187 o [RFC5044] "Marker PDU Aligned Framing for TCP Specification" 188 o [RFC5045] "Applicability of Remote Direct Memory Access Protocol 189 (RDMA) and Direct Data Placement (DDP)" 191 o [RFC5046] "Internet Small Computer System Interface (iSCSI) 192 Extensions for Remote Direct Memory Access (RDMA)" 194 o [RFC5047] "DA: Datamover Architecture for the Internet Small 195 Computer System Interface (iSCSI)" 197 o [RFC5048] "Internet Small Computer System Interface (iSCSI) 198 Corrections and Clarifications" 200 [RFC3721] and [RFC5387] are not updated by this document, as their 201 usage of RFC 3723 does not encompass its IPsec requirements. 203 In addition, this document's updated IPsec requirements apply to the 204 new specifications for iSCSI ([I-D.ietf-storm-iscsi-cons]) and iSER ( 205 [I-D.ietf-storm-iser]). 207 This document uses the term "block storage protocols" to refer to the 208 protocols (listed above) to which RFC 3723's requirements (as updated 209 by the requirements in this document) apply. 211 2. ESP Requirements 213 RFC 3723 requires that implementations MUST support IPsec ESPv2 214 [RFC2406] in tunnel mode as part of IPsec v2 to provide security for 215 both control packets and data packets, and that when ESPv2 is 216 utilized, per-packet data origin authentication, integrity and replay 217 protection MUST be provided. 219 This document modifies RFC 3723 to require that implementations 220 SHOULD also support IPsec ESPv3 [RFC4303] in tunnel mode as part of 221 IPsec v3 to provide security for both control packets and data 222 packets; per-packet data origin authentication, integrity and replay 223 protection MUST be provided when ESPv3 is utilized. 225 At the high speeds at which block storage protocols are expected to 226 operate, a single IPsec SA could rapidly exhaust the ESP 32-bit 227 sequence number space, requiring frequent rekeying of the SA, as 228 rollover of the ESP sequence number within a single SA is prohibited 229 for both ESPv2 [RFC2406] and ESPv3 [RFC4303] . In order to provide 230 the means to avoid this potentially undesirable frequent rekeying, 231 implementations that are capable of operating at speeds of 1 gigabit/ 232 second or higher MUST implement extended (64-bit) sequence numbers 233 for ESPv2 (and ESPv3 if supported) and SHOULD use extended sequence 234 numbers for all block storage protocol traffic. Extended sequence 235 number negotiation as part of security association establishment is 236 specified in [RFC4304] for IKEv1 and [RFC5996] for IKEv2. 238 2.1. Data Origin Authentication and Data Integrity Transforms 240 RFC 3723 requires that: 242 o HMAC-SHA1 MUST be implemented in the form of HMAC-SHA-1-96 243 [RFC2404]. 245 o AES CBC MAC with XCBC extensions SHOULD be implemented [RFC3566]. 247 This document clarifies RFC 3723's key size requirements for 248 implementations of AES CBC MAC with XCBC extensions; 128-bit keys 249 MUST be supported, and other key sizes MAY also be supported. 251 This document also adds a requirement for IPsec v3: 253 o Implementations that support IKEv2 [RFC5996] SHOULD also implement 254 AES GMAC [RFC4543]. AES GMAC implementations MUST support 128-bit 255 keys, and MAY support other key sizes. 257 The rationale for the added requirement is that GMAC is more amenable 258 to hardware implementations that may be preferable for the high data 259 rates at which block storage protocols can be expected to operate. 261 2.2. Confidentiality Transform Requirements 263 RFC 3723 requires that: 265 o 3DES in CBC mode (3DES CBC) [RFC2451], [triple-des-spec] MUST be 266 supported. 268 o AES in Counter mode (AES CTR) [RFC3686], SHOULD be supported. 270 o NULL encryption [RFC2410] MUST be supported. 272 The 3DES CBC and AES CTR requirements are replaced by requirements 273 that both MAY be implemented. The NULL encryption requirement is not 274 changed by this document. The 3DES CBC requirement matched the basic 275 encryption interoperability requirement for IPsec v2. At the time of 276 RFC 3723's publication, AES Counter mode was the encryption transform 277 that was most amenable to hardware implementation, as hardware 278 implementation may be preferable for the high data rates at which 279 block storage protocols can be expected to operate. This document 280 changes both of these requirements based on cryptographic 281 developments since the publication of RFC 3723. 283 The requirement for 3DES CBC has become problematic due to 3DES's 284 64-bit block size, i.e., the core cipher encrypts or decrypts 64 bits 285 at a time. Security weaknesses in encryption start to appear as the 286 amount of data encrypted under a single key approaches the birthday 287 bound of 32GiB for a cipher with a 64-bit block size, see Appendix A 288 and [triple-des-birthday]. It is prudent to rekey well before that 289 bound is reached, and 32GiB or some significant fraction thereof is 290 less than the amount of data that a block storage protocol may 291 transfer in a single session. This may require frequent rekeying, 292 e.g., to obtain an order of magnitude (10x) safety margin by rekeying 293 after 3GiB on a multi-gigabit/sec link. In contrast, AES has a 128 294 bit block size, which results in a much larger birthday bound (2^68 295 bytes), see Appendix A. AES CBC [RFC3602] is the primary mandatory- 296 to-implement encryption transform for interoperability, and hence is 297 the appropriate mandatory-to-implement transform replacement for 3DES 298 CBC. 300 AES Counter mode (AES CTR) is no longer the encryption transform that 301 is most amenable to hardware implementation. That characterization 302 now applies to AES Galois Counter Mode (GCM) [RFC4106], which 303 provides both encryption and integrity protection in a single 304 cryptographic mechanism (in contrast, neither HMAC-SHA1 nor AES CBC 305 MAC with XCBC extensions is well suited for hardware implementation, 306 as both transforms do not pipeline well). AES GCM is also capable of 307 providing confidentiality protection for the IKEv2 key exchange 308 protocol, but not the IKEv1 protocol [RFC5282], and therefore the new 309 AES GCM "SHOULD" requirement is based on presence of support for 310 IKEv2. 312 For the reasons described in the preceding paragraphs, the 313 confidentiality transform requirements in RFC 3723 are replaced by 314 the following: 316 o 3DES in CBC mode MAY be implemented (replaces RFC 3723's "MUST 317 implement" requirement). 319 o AES in Counter mode (AES CTR) MAY be implemented (replaces RFC 320 3723's "SHOULD implement" requirement). 322 o AES in CBC mode MUST be implemented. AES CBC implementations MUST 323 support 128-bit keys and MAY support other key sizes. 325 o Implementations that support IKEv2 SHOULD also implement AES GCM. 326 AES GCM implementations MUST support 128-bit keys, and MAY support 327 other key sizes. 329 o NULL encryption [RFC2410] MUST be supported. 331 The requirement for support of NULL encryption enables use of SAs 332 that provide data origin authentication and data integrity, but not 333 confidentiality. 335 Other transforms MAY be implemented in addition to those listed 336 above. 338 3. IKEv1 and IKEv2 Requirements 340 Note: to avoid ambiguity, the original IKE protocol [RFC2409] is 341 referred to as "IKEv1" in this document. 343 This document adds requirements for IKEv2 usage with block Storage 344 protocols and makes the following two changes to the IKEv1 345 requirements in RFC 3723 (the new D-H group requirement also applies 346 to IKEv2): 348 o When D-H groups are used, a D-H group of at least 2048 bits SHOULD 349 be offered as a part of all proposals to create IPsec Security 350 Associations. The recommendation for use of 1024 bit D-H groups 351 with 3DES CBC and HMAC-SHA1 has been removed; use of 1024 bit D-H 352 groups is NOT RECOMMENDED, and 354 o The requirement to use UDP port 500 is removed in order to allow 355 NAT traversal [RFC3947]. 357 There are no other changes to RFC 3723's IKEv1 requirements, but many 358 of them are restated in this document in order to provide context for 359 the new IKEv2 requirements. 361 RFC 3723 requires that IKEv1 [RFC2409] be supported for peer 362 authentication, negotiation of security associations, and key 363 management, using the IPsec DOI [RFC2407], and further requires that 364 manual keying not be used since it does not provide the rekeying 365 support necessary for operation at high data rates. This document 366 adds a requirement that IKEv2 [RFC5996] SHOULD be supported for peer 367 authentication, negotiation of security associations, and key 368 management. The manual keying prohibition in RFC 3723 is extended to 369 IKEv2; manual keying MUST NOT be used with any version of IPsec for 370 protocols to which the requirements in this document apply. 372 RFC 3723's requirements for IKEv1 mode implementation and usage are 373 unchanged; this document does not extend those requirements to IKEv2 374 because IKEv2 does not have modes. 376 When IPsec is used, the receipt of an IKEv1 Phase 2 delete message or 377 an IKEv2 INFORMATIONAL exchange that deletes the SA SHOULD NOT be 378 interpreted as a reason for tearing down the block storage protocol 379 connection (e.g., TCP-based). If additional traffic is sent, a new 380 SA will be created to protect that traffic. 382 The method used to determine whether a block storage protocol 383 connection should be established using IPsec is regarded as an issue 384 of IPsec policy administration, and thus is not defined in this 385 document. The method used by an implementation that supports both 386 IPsec v2 and v3 to determine which versions of IPsec are supported by 387 the a block storage protocol peer is also regarded as an issue of 388 IPsec policy administration, and thus is also not defined in this 389 document. If both IPsec v2 and v3 are supported by both endpoints of 390 a block storage protocol connection, use of IPsec v3 is RECOMMENDED. 392 3.1. Authentication Requirements 394 The authentication requirements for IKEv1 are unchanged by this 395 document, but are restated here for context along with the 396 authentication requirements for IKEv2: 398 a. Peer authentication using a pre-shared cryptographic key MUST be 399 supported. Certificate-based peer authentication using digital 400 signatures MAY be supported. For IKEv1 ([RFC2409]), peer 401 authentication using the public key encryption methods specified 402 in sections 5.2 and 5.3 of [RFC2409] SHOULD NOT be used. 404 b. When digital signatures are used for authentication, all IKEv1 405 and IKEv2 negotiators SHOULD use Certificate Request Payload(s) 406 to specify the certificate authority, and SHOULD check the 407 cerificate validity via the pertinent Certificate Revocation List 408 (CRL) or via use of the Online Certificate Status Protocol (OCSP) 409 [RFC6960] before accepting a PKI certificate for use in 410 authentication. OCSP support within the IKEv2 protocol is 411 specified in [RFC4806]. 413 c. IKEv1 implementations MUST support Main Mode and SHOULD support 414 Aggressive Mode. Main Mode with pre-shared key authentication 415 method SHOULD NOT be used when either the initiator or the target 416 uses dynamically assigned IP addresses. While in many cases pre- 417 shared keys offer good security, situations in which dynamically 418 assigned addresses are used force the use of a group pre-shared 419 key, which creates vulnerability to a man-in-the-middle attack. 420 These requirements do not apply to IKEv2 because it has no modes. 422 d. In the IKEv1 Phase 2 Quick Mode, exchanges for creating the Phase 423 2 SA, the Identification Payload MUST be present. This 424 requirement does not apply to IKEv2 because it has no modes. 426 e. The following identification type requirements apply to IKEv1. 427 ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6) 428 and ID_FQDN Identification Types MUST be supported; ID_USER_FQDN 429 SHOULD be supported. The IP Subnet, IP Address Range, 430 ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types SHOULD 431 NOT be used. The ID_KEY_ID Identification Type MUST NOT be used. 433 f. When IKEv2 is supported, the following identification 434 requirements apply. ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol 435 stack supports IPv6) and ID_FQDN Identification Types MUST be 436 supported; ID_RFC822_ADDR SHOULD be supported. The 437 ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types SHOULD 438 NOT be used. The ID_KEY_ID Identification Type MUST NOT be used. 440 The reasons for the identification requirements in items e and f 441 above are: 443 o IP Subnet and IP Address Range are too broad to usefully identify 444 an iSCSI endpoint. 446 o The _DN and _GN types are X.500 identities; it is usually better 447 to use an identity from subjectAltName in a PKI certificate. 449 o ID_KEY_ID is an opaque identifier that is not interoperable among 450 different IPsec implementations as specified. Heterogeneity in 451 some block storage protocol implementations can be expected (e.g., 452 iSCSI initiator vs. iSCSI target implementations), and hence 453 heterogeneity among IPsec implementations is important. 455 3.2. D-H Group and PRF Requirements 457 This document does not change the support requirements for Diffe- 458 Hellman (D-H) groups and Pseudo-Random Functions (PRFs). See 459 [RFC4109] for IKEv1 requirements and [RFC4307] for IKEv2 460 requirements. Implementors are advised to check for subsequent RFCs 461 that update either of these RFCs, as such updates may change these 462 requirements. 464 When DH groups are used, a DH group of at least 2048 bits SHOULD be 465 offered as a part of all proposals to create IPsec Security 466 Associations for both IKEv1 and IKEv2. 468 RFC 3723 requires that the IKEv1 Quick Mode key exchange that 469 provides perfect forward secrecy MUST be implemented. This document 470 extends that requirement to IKEv2; the CREATE_CHILD_SA key exchange 471 that provides perfect forward secrecy MUST be implemented for use of 472 IPsec with block storage protocols. 474 4. IANA Considerations 476 This document includes no request to IANA. 478 5. Security Considerations 480 This entire document is about security. 482 The security considerations sections of all of the referenced RFCs 483 apply, and particular note should be taken of the security 484 considerations for the encryption transforms whose requirement levels 485 are changed by this RFC: 487 o AES GMAC [RFC4543] (new requirement - SHOULD be supported when 488 IKEv2 is supported), 490 o 3DES CBC [RFC2451] (changed from "MUST be supported" to "MAY be 491 supported"), 493 o AES CTR [RFC3686] (changed from "SHOULD be supported" to "MAY be 494 supported"), 496 o AES CBC [RFC3602] (new requirement - MUST be supported), and 498 o AES GCM [RFC4106] (new requirement - SHOULD be supported when 499 IKEv2 is supported). 501 Of particular interest are the security considerations concerning the 502 use of AES GCM[RFC4106] and AES GMAC[RFC4543]; both modes are 503 vulnerable to catastrophic forgery attacks if a nonce is ever 504 repeated with a given key. 506 The requirement level for 3DES CBC has been reduced based on 507 considerations for high speed implementations; 3DES CBC remains an 508 optional encryption transform that may be suitable for 509 implementations limited to operating at lower speeds where the 510 required rekeying frequency for 3DES is acceptable. 512 The requirement level for AES CTR has been reduced based solely on 513 hardware implementation considerations that favor AES GCM, as opposed 514 to changes in AES CTR's security properties. AES CTR remains an 515 optional security transform that is suitable for use in general as it 516 does not share 3DES CBC's requirement for frequent rekeying when 517 operating at high data rates. 519 Key sizes with comparable strength SHOULD be used for the 520 cryptographic algorithms and transforms for any individual IPsec 521 security association. See Section 5.6 of [SP800-57] for further 522 discussion. 524 6. References 526 6.1. Normative References 528 [I-D.ietf-storm-iscsi-cons] 529 Chadalapaka, M., Satran, J., Meth, K., and D. Black, 530 "iSCSI Protocol (Consolidated)", draft-ietf-storm-iscsi- 531 cons-10 (work in progress), July 2013. 533 [I-D.ietf-storm-iser] 534 Ko, M. and A. Nezhinsky, "iSCSI Extensions for RDMA 535 Specification", draft-ietf-storm-iser-15 (work in 536 progress), July 2013. 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, March 1997. 541 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 542 Internet Protocol", RFC 2401, November 1998. 544 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 545 ESP and AH", RFC 2404, November 1998. 547 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 548 Payload (ESP)", RFC 2406, November 1998. 550 [RFC2407] Piper, D., "The Internet IP Security Domain of 551 Interpretation for ISAKMP", RFC 2407, November 1998. 553 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 554 (IKE)", RFC 2409, November 1998. 556 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 557 Its Use With IPsec", RFC 2410, November 1998. 559 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 560 Algorithms", RFC 2451, November 1998. 562 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 563 and Its Use With IPsec", RFC 3566, September 2003. 565 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 566 Algorithm and Its Use with IPsec", RFC 3602, September 567 2003. 569 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 570 Counter Mode With IPsec Encapsulating Security Payload 571 (ESP)", RFC 3686, January 2004. 573 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., 574 and E. Zeidner, "Internet Small Computer Systems Interface 575 (iSCSI)", RFC 3720, April 2004. 577 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. 578 Travostino, "Securing Block Storage Protocols over IP", 579 RFC 3723, April 2004. 581 [RFC3821] Rajagopal, M., Rodriguez, E., and R. Weber, "Fibre Channel 582 Over TCP/IP (FCIP)", RFC 3821, July 2004. 584 [RFC3822] Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) 585 Entities Using Service Location Protocol version 2 586 (SLPv2)", RFC 3822, July 2004. 588 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 589 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 590 January 2005. 592 [RFC4018] Bakke, M., Hufferd, J., Voruganti, K., Krueger, M., and T. 593 Sperry, "Finding Internet Small Computer Systems Interface 594 (iSCSI) Targets and Name Servers by Using Service Location 595 Protocol version 2 (SLPv2)", RFC 4018, April 2005. 597 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 598 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 599 4106, June 2005. 601 [RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version 602 1 (IKEv1)", RFC 4109, May 2005. 604 [RFC4172] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and 605 M. Edwards, "iFCP - A Protocol for Internet Fibre Channel 606 Storage Networking", RFC 4172, September 2005. 608 [RFC4173] Sarkar, P., Missimer, D., and C. Sapuntzakis, 609 "Bootstrapping Clients using the Internet Small Computer 610 System Interface (iSCSI) Protocol", RFC 4173, September 611 2005. 613 [RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic 614 Host Configuration Protocol (DHCP) Option for the Internet 615 Storage Name Service", RFC 4174, September 2005. 617 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 618 Internet Protocol", RFC 4301, December 2005. 620 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 621 4303, December 2005. 623 [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to 624 IPsec Domain of Interpretation (DOI) for Internet Security 625 Association and Key Management Protocol (ISAKMP)", RFC 626 4304, December 2005. 628 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 629 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 630 December 2005. 632 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 633 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 634 May 2006. 636 [RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. 637 Garcia, "A Remote Direct Memory Access Protocol 638 Specification", RFC 5040, October 2007. 640 [RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct 641 Data Placement over Reliable Transports", RFC 5041, 642 October 2007. 644 [RFC5042] Pinkerton, J. and E. Deleganes, "Direct Data Placement 645 Protocol (DDP) / Remote Direct Memory Access Protocol 646 (RDMAP) Security", RFC 5042, October 2007. 648 [RFC5043] Bestler, C. and R. Stewart, "Stream Control Transmission 649 Protocol (SCTP) Direct Data Placement (DDP) Adaptation", 650 RFC 5043, October 2007. 652 [RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. 653 Carrier, "Marker PDU Aligned Framing for TCP 654 Specification", RFC 5044, October 2007. 656 [RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., 657 and P. Thaler, "Internet Small Computer System Interface 658 (iSCSI) Extensions for Remote Direct Memory Access 659 (RDMA)", RFC 5046, October 2007. 661 [RFC5048] Chadalapaka, M., "Internet Small Computer System Interface 662 (iSCSI) Corrections and Clarifications", RFC 5048, October 663 2007. 665 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 666 Algorithms with the Encrypted Payload of the Internet Key 667 Exchange version 2 (IKEv2) Protocol", RFC 5282, August 668 2008. 670 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 671 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 672 5996, September 2010. 674 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 675 Galperin, S., and C. Adams, "X.509 Internet Public Key 676 Infrastructure Online Certificate Status Protocol - OCSP", 677 RFC 6960, June 2013. 679 [SP800-57] 680 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 681 "NIST Special Publication 800-57: Recommendation for Key 682 Management - Part 1: General (Revision 3)", July 2012, 683 . 686 [triple-des-birthday] 687 McGrew, D., "Impossible plaintext cryptanalysis and 688 probable-plaintext collision attacks of 64-bit block 689 cipher modes (Cryptology ePrint Archive: Report 2012/ 690 623)", November 2012, . 692 [triple-des-spec] 693 American Bankers Association, ABA., "American National 694 Standard for Financial Services X9.52-1998 - Triple Data 695 Encryption Algorithm Modes of Operation", July 1998. 697 6.2. Informative References 699 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. 700 Krueger, "Internet Small Computer Systems Interface 701 (iSCSI) Naming and Discovery", RFC 3721, April 2004. 703 [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status 704 Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 705 2007. 707 [RFC5045] Bestler, C. and L. Coene, "Applicability of Remote Direct 708 Memory Access Protocol (RDMA) and Direct Data Placement 709 (DDP)", RFC 5045, October 2007. 711 [RFC5047] Chadalapaka, M., Hufferd, J., Satran, J., and H. Shah, 712 "DA: Datamover Architecture for the Internet Small 713 Computer System Interface (iSCSI)", RFC 5047, October 714 2007. 716 [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and 717 Applicability Statement for Better-Than-Nothing Security 718 (BTNS)", RFC 5387, November 2008. 720 Appendix A. Block Cipher Birthday Bounds 722 This Appendix provides the birthday bounds for the 3DES and AES 723 ciphers based on [triple-des-birthday], which states: "Theory advises 724 against using a w-bit block cipher to encrypt more than 2^(w/2) 725 blocks with a single key; this is known as the birthday bound." 727 For a cipher with a 64-bit block size (e.g., 3DES), w=64, so the 728 birthday bound is 2^32 blocks. As each block contains 8 (2^3) bytes, 729 the birthday bound is 2^35 bytes = 2^5 gibibytes, i.e., 32 GiB, where 730 1 gibibyte (GiB) = 2^30 bytes. Note that a gigabyte (decimal 731 quantity) is not the same as a gibibyte (binary quantity), 1 gigabyte 732 (GB) = 10^6 bytes. 734 For a cipher with a 128-bit block size (e.g., AES), w=128, so the 735 birthday bound is 2^64 blocks. As each block contains 16 (2^4) 736 bytes, the birthday bound is 2^68 bytes = 2^8 exbibytes, i.e., 256 737 EiB, where 1 exbibyte (EiB) = 2^60 bytes. Note that an exabyte 738 (decimal quantity) is not the same as an exbibyte (binary quantity), 739 1 exabyte (EB) = 10^9 bytes. 741 Appendix B. Contributors 743 David McGrew's observations about the birthday bound implications of 744 3DES's 64-bit block size on the ipsec@ietf.org mailing list lead to 745 changing from 3DES CBC to AES CBC as the mandatory to implement 746 encryption algorithm based on the birthday bound discussion in 747 Appendix A. 749 The original authors of RFC 3723 were: Bernard Aboba, Joshua Tseng, 750 Jesse Walker, Venkat Rangan and Franco Travostino. Comments from 751 Francis Dupont, Yaron Sheffer, Tom Talpey, Sean Turner and Tom Yu 752 have improved this document and are gratefully acknowledged. 754 Appendix C. Change Log 756 This section should be removed before this document is published as 757 an RFC 759 Changes from -00 to -01: 761 o Make it clearer that RFC 3723's encryption implementation 762 requirements are being changed. 764 o State that D-H group and PRF implementation requirements are 765 unchanged and provide references to RFCs where they can be found 766 (new section 3.2). 768 o Add requirements for perfect forward secrecy implementation (also 769 in 3.2). 771 o Use the correct GMAC reference. 773 o Many other editorial changes. 775 Changes from -01 to -02. 777 o Remove "IP Storage" terminology, use "Block Storage" in title and 778 body, based on RFC 3723. 780 o Add appendix on birthday bound calculations. 782 o Clean up and tighten requirements text, with a focus on making key 783 size requirements clearer. 785 o Add summary of changes from RFC 3723. 787 o Many other editorial changes. 789 Changes from -02 to -03 791 o Editorial changes 793 Changes from -03 to -04 795 o Extend ESN requirement to ESPv2. 797 o Allow OCSP in addition to CRLs to check certificates. 799 o Add security considerations text, primarily on changes to 800 encryption requirements. 802 o Editorial changes 804 Authors' Addresses 806 David Black 807 EMC 808 176 South Street 809 Hopkinton, MA 01748 810 USA 812 Phone: +1 508 293-7953 813 Email: david.black@emc.com 815 Paul Koning 816 Dell 817 300 Innovative Way 818 Nashua, NH 03062 819 USA 821 Phone: +1 603 249-7703 822 Email: paul_koning@Dell.com