| Storage Maintenance (storm) | D. Black |
| Internet-Draft | EMC |
| Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if approved) | P. Koning |
| Intended status: Standards Track | Dell |
| Expires: April 24, 2014 | October 21, 2013 |
Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3
draft-ietf-storm-ipsec-ips-update-04
RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., RDMAP. This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published.
[RFC Editor: The "Updates:" list above has been truncated by xml2rfc. The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if approved) ]
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 April 24, 2014.
Copyright (c) 2013 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 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.
RFC 3723 [RFC3723] specifies IPsec requirements for block storage protocols over IP (e.g., iSCSI [RFC3720]) based on IPsec v2 (RFC 2401 [RFC2401] and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., RDMAP [RFC5040]. This document updates RFC 3723's IPsec requirements to IPsec v3 ([RFC4301] and related RFCs) to reflect developments since RFC 3723 was published.
For brevity, this document uses the term "block storage protocols" to refer to all protocols to which RFC 3723's requirements apply, see Section 1.3 for details.
In addition to the IPsec v2 requirements in RFC 3723, IPsec v3, as specified in [RFC4301] and related RFCs (e.g., IKEv2 [RFC5996]), SHOULD be implemented for block storage protocols. Retention of the mandatory requirement for IPsec v2 provides interoperability with existing implementations, and the strong recommendation for IPsec v3 encourages implementers to move forward to that newer version of IPsec.
Cryptographic developments since the publication of RFC 3723 necessitate changes to the encryption transform requirements for IPsec v2, as explained further in Section 2.2; these updated requirements also apply to IPsec v3.
Block storage protocols can be expected to operate at high data rates (multiple Gigabits/second). The cryptographic requirements in this document are strongly influenced by that expectation; an important example is that 3DES CBC is no longer recommended for block storage protocols due to the frequent rekeying impacts of 3DES's 64-bit block size at high data rates.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This document makes the following changes to RFC 3723:
RFC 3723's IPsec requirements have been applied to a number of protocols. For that reason, in addition to updating RFC 3723's IPsec requirements, this document also updates the IPsec requirements for each protocol that uses RFC 3723, i.e., the following RFCs are updated - in each case, the update is solely to the IPsec requirements:
[RFC3721] and [RFC5387] are not updated by this document, as their usage of RFC 3723 does not encompass its IPsec requirements.
In addition, this document's updated IPsec requirements apply to the new specifications for iSCSI ([I-D.ietf-storm-iscsi-cons]) and iSER ( [I-D.ietf-storm-iser]).
This document uses the term "block storage protocols" to refer to the protocols (listed above) to which RFC 3723's requirements (as updated by the requirements in this document) apply.
RFC 3723 requires that implementations MUST support IPsec ESPv2 [RFC2406] in tunnel mode as part of IPsec v2 to provide security for both control packets and data packets, and that when ESPv2 is utilized, per-packet data origin authentication, integrity and replay protection MUST be provided.
This document modifies RFC 3723 to require that implementations SHOULD also support IPsec ESPv3 [RFC4303] in tunnel mode as part of IPsec v3 to provide security for both control packets and data packets; per-packet data origin authentication, integrity and replay protection MUST be provided when ESPv3 is utilized.
At the high speeds at which block storage protocols are expected to operate, a single IPsec SA could rapidly exhaust the ESP 32-bit sequence number space, requiring frequent rekeying of the SA, as rollover of the ESP sequence number within a single SA is prohibited for both ESPv2 [RFC2406] and ESPv3 [RFC4303] . In order to provide the means to avoid this potentially undesirable frequent rekeying, implementations that are capable of operating at speeds of 1 gigabit/second or higher MUST implement extended (64-bit) sequence numbers for ESPv2 (and ESPv3 if supported) and SHOULD use extended sequence numbers for all block storage protocol traffic. Extended sequence number negotiation as part of security association establishment is specified in [RFC4304] for IKEv1 and [RFC5996] for IKEv2.
RFC 3723 requires that:
This document clarifies RFC 3723's key size requirements for implementations of AES CBC MAC with XCBC extensions; 128-bit keys MUST be supported, and other key sizes MAY also be supported.
This document also adds a requirement for IPsec v3:
The rationale for the added requirement is that GMAC is more amenable to hardware implementations that may be preferable for the high data rates at which block storage protocols can be expected to operate.
RFC 3723 requires that:
The 3DES CBC and AES CTR requirements are replaced by requirements that both MAY be implemented. The NULL encryption requirement is not changed by this document. The 3DES CBC requirement matched the basic encryption interoperability requirement for IPsec v2. At the time of RFC 3723's publication, AES Counter mode was the encryption transform that was most amenable to hardware implementation, as hardware implementation may be preferable for the high data rates at which block storage protocols can be expected to operate. This document changes both of these requirements based on cryptographic developments since the publication of RFC 3723.
The requirement for 3DES CBC has become problematic due to 3DES's 64-bit block size, i.e., the core cipher encrypts or decrypts 64 bits at a time. Security weaknesses in encryption start to appear as the amount of data encrypted under a single key approaches the birthday bound of 32GiB for a cipher with a 64-bit block size, see Appendix A and [triple-des-birthday]. It is prudent to rekey well before that bound is reached, and 32GiB or some significant fraction thereof is less than the amount of data that a block storage protocol may transfer in a single session. This may require frequent rekeying, e.g., to obtain an order of magnitude (10x) safety margin by rekeying after 3GiB on a multi-gigabit/sec link. In contrast, AES has a 128 bit block size, which results in a much larger birthday bound (2^68 bytes), see Appendix A. AES CBC [RFC3602] is the primary mandatory-to-implement encryption transform for interoperability, and hence is the appropriate mandatory-to-implement transform replacement for 3DES CBC.
AES Counter mode (AES CTR) is no longer the encryption transform that is most amenable to hardware implementation. That characterization now applies to AES Galois Counter Mode (GCM) [RFC4106], which provides both encryption and integrity protection in a single cryptographic mechanism (in contrast, neither HMAC-SHA1 nor AES CBC MAC with XCBC extensions is well suited for hardware implementation, as both transforms do not pipeline well). AES GCM is also capable of providing confidentiality protection for the IKEv2 key exchange protocol, but not the IKEv1 protocol [RFC5282], and therefore the new AES GCM "SHOULD" requirement is based on presence of support for IKEv2.
For the reasons described in the preceding paragraphs, the confidentiality transform requirements in RFC 3723 are replaced by the following:
The requirement for support of NULL encryption enables use of SAs that provide data origin authentication and data integrity, but not confidentiality.
Other transforms MAY be implemented in addition to those listed above.
Note: to avoid ambiguity, the original IKE protocol [RFC2409] is referred to as "IKEv1" in this document.
This document adds requirements for IKEv2 usage with block Storage protocols and makes the following two changes to the IKEv1 requirements in RFC 3723 (the new D-H group requirement also applies to IKEv2):
There are no other changes to RFC 3723's IKEv1 requirements, but many of them are restated in this document in order to provide context for the new IKEv2 requirements.
RFC 3723 requires that IKEv1 [RFC2409] be supported for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [RFC2407], and further requires that manual keying not be used since it does not provide the rekeying support necessary for operation at high data rates. This document adds a requirement that IKEv2 [RFC5996] SHOULD be supported for peer authentication, negotiation of security associations, and key management. The manual keying prohibition in RFC 3723 is extended to IKEv2; manual keying MUST NOT be used with any version of IPsec for protocols to which the requirements in this document apply.
RFC 3723's requirements for IKEv1 mode implementation and usage are unchanged; this document does not extend those requirements to IKEv2 because IKEv2 does not have modes.
When IPsec is used, the receipt of an IKEv1 Phase 2 delete message or an IKEv2 INFORMATIONAL exchange that deletes the SA SHOULD NOT be interpreted as a reason for tearing down the block storage protocol connection (e.g., TCP-based). If additional traffic is sent, a new SA will be created to protect that traffic.
The method used to determine whether a block storage protocol connection should be established using IPsec is regarded as an issue of IPsec policy administration, and thus is not defined in this document. The method used by an implementation that supports both IPsec v2 and v3 to determine which versions of IPsec are supported by the a block storage protocol peer is also regarded as an issue of IPsec policy administration, and thus is also not defined in this document. If both IPsec v2 and v3 are supported by both endpoints of a block storage protocol connection, use of IPsec v3 is RECOMMENDED.
The authentication requirements for IKEv1 are unchanged by this document, but are restated here for context along with the authentication requirements for IKEv2:
The reasons for the identification requirements in items e and f above are:
This document does not change the support requirements for Diffe-Hellman (D-H) groups and Pseudo-Random Functions (PRFs). See [RFC4109] for IKEv1 requirements and [RFC4307] for IKEv2 requirements. Implementors are advised to check for subsequent RFCs that update either of these RFCs, as such updates may change these requirements.
When DH groups are used, a DH group of at least 2048 bits SHOULD be offered as a part of all proposals to create IPsec Security Associations for both IKEv1 and IKEv2.
RFC 3723 requires that the IKEv1 Quick Mode key exchange that provides perfect forward secrecy MUST be implemented. This document extends that requirement to IKEv2; the CREATE_CHILD_SA key exchange that provides perfect forward secrecy MUST be implemented for use of IPsec with block storage protocols.
This document includes no request to IANA.
This entire document is about security.
The security considerations sections of all of the referenced RFCs apply, and particular note should be taken of the security considerations for the encryption transforms whose requirement levels are changed by this RFC:
Of particular interest are the security considerations concerning the use of AES GCM[RFC4106] and AES GMAC[RFC4543]; both modes are vulnerable to catastrophic forgery attacks if a nonce is ever repeated with a given key.
The requirement level for 3DES CBC has been reduced based on considerations for high speed implementations; 3DES CBC remains an optional encryption transform that may be suitable for implementations limited to operating at lower speeds where the required rekeying frequency for 3DES is acceptable.
The requirement level for AES CTR has been reduced based solely on hardware implementation considerations that favor AES GCM, as opposed to changes in AES CTR's security properties. AES CTR remains an optional security transform that is suitable for use in general as it does not share 3DES CBC's requirement for frequent rekeying when operating at high data rates.
Key sizes with comparable strength SHOULD be used for the cryptographic algorithms and transforms for any individual IPsec security association. See Section 5.6 of [SP800-57] for further discussion.
| [RFC3721] | Bakke, M., Hafner, J., Hufferd, J., Voruganti, K. and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004. |
| [RFC4806] | Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007. |
| [RFC5045] | Bestler, C. and L. Coene, "Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)", RFC 5045, October 2007. |
| [RFC5047] | Chadalapaka, M., Hufferd, J., Satran, J. and H. Shah, "DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI)", RFC 5047, October 2007. |
| [RFC5387] | Touch, J., Black, D. and Y. Wang, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", RFC 5387, November 2008. |
This Appendix provides the birthday bounds for the 3DES and AES ciphers based on [triple-des-birthday], which states: "Theory advises against using a w-bit block cipher to encrypt more than 2^(w/2) blocks with a single key; this is known as the birthday bound."
For a cipher with a 64-bit block size (e.g., 3DES), w=64, so the birthday bound is 2^32 blocks. As each block contains 8 (2^3) bytes, the birthday bound is 2^35 bytes = 2^5 gibibytes, i.e., 32 GiB, where 1 gibibyte (GiB) = 2^30 bytes. Note that a gigabyte (decimal quantity) is not the same as a gibibyte (binary quantity), 1 gigabyte (GB) = 10^6 bytes.
For a cipher with a 128-bit block size (e.g., AES), w=128, so the birthday bound is 2^64 blocks. As each block contains 16 (2^4) bytes, the birthday bound is 2^68 bytes = 2^8 exbibytes, i.e., 256 EiB, where 1 exbibyte (EiB) = 2^60 bytes. Note that an exabyte (decimal quantity) is not the same as an exbibyte (binary quantity), 1 exabyte (EB) = 10^9 bytes.
David McGrew's observations about the birthday bound implications of 3DES's 64-bit block size on the ipsec@ietf.org mailing list lead to changing from 3DES CBC to AES CBC as the mandatory to implement encryption algorithm based on the birthday bound discussion in Appendix A.
The original authors of RFC 3723 were: Bernard Aboba, Joshua Tseng, Jesse Walker, Venkat Rangan and Franco Travostino. Comments from Francis Dupont, Yaron Sheffer, Tom Talpey, Sean Turner and Tom Yu have improved this document and are gratefully acknowledged.
This section should be removed before this document is published as an RFC
Changes from -00 to -01:
Changes from -01 to -02.
Changes from -02 to -03
Changes from -03 to -04