doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc7146.txt b/doc/rfc/rfc7146.txt
new file mode 100644
index 0000000..e956a22
--- /dev/null
+++ b/doc/rfc/rfc7146.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          D. Black
+Request for Comments: 7146                                           EMC
+Updates: 3720, 3723, 3821, 3822, 4018, 4172,                   P. Koning
+         4173, 4174, 5040, 5041, 5042, 5043,                        Dell
+         5044, 5045, 5046, 5047, 5048                         April 2014
+Category: Standards Track
+ISSN: 2070-1721
+
+
+               Securing Block Storage Protocols over IP:
+               RFC 3723 Requirements Update for IPsec v3
+
+Abstract
+
+   RFC 3723 specifies IPsec requirements for block storage protocols
+   over IP (e.g., Internet Small Computer System Interface (iSCSI))
+   based on IPsec v2 (RFC 2401 and related RFCs); those requirements
+   have subsequently been applied to remote direct data placement
+   protocols, e.g., the Remote Direct Memory Access Protocol (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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7146.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Black & Koning               Standards Track                    [Page 1]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Requirements Language ......................................3
+      1.2. Summary of Changes to RFC 3723 .............................4
+      1.3. Other Updated RFCs .........................................4
+   2. ESP Requirements ................................................6
+      2.1. Data Origin Authentication and Data Integrity Transforms ...6
+      2.2. Confidentiality Transform Requirements .....................7
+   3. IKEv1 and IKEv2 Requirements ....................................8
+      3.1. Authentication Requirements ...............................10
+      3.2. DH Group and PRF Requirements .............................11
+   4. Security Considerations ........................................11
+   5. References .....................................................12
+      5.1. Normative References ......................................12
+      5.2. Informative References ....................................16
+   Appendix A. Block Cipher Birthday Bounds ..........................17
+   Appendix B. Contributors ..........................................17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Black & Koning               Standards Track                    [Page 2]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+1.  Introduction
+
+   [RFC3723] specifies IPsec requirements for block storage protocols
+   over IP (e.g., iSCSI [RFC3720]) based on IPsec v2 ([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 Triple Data Encryption Standard Cipher Block Chaining
+   (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.
+
+1.1.  Requirements Language
+
+   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
+   [RFC2119].
+
+
+
+
+
+
+
+
+
+
+Black & Koning               Standards Track                    [Page 3]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+1.2.  Summary of Changes to RFC 3723
+
+   This document makes the following changes to RFC 3723:
+
+   o  Adds requirements that IPsec v3 SHOULD be implemented
+      (Encapsulating Security Payload (ESPv3) and IKEv2) in addition to
+      IPsec v2 (see Section 1).
+
+   o  Requires extended sequence numbers for both ESPv2 and ESPv3 (see
+      Section 2).
+
+   o  Clarifies key-size requirements for AES CBC MAC with XCBC
+      extensions (MUST implement 128-bit keys; see Section 2.1).
+
+   o  Adds IPsec v3 requirements for AES Galois Message Authentication
+      Code (GMAC) and Galois/Counter Mode (GCM) (SHOULD implement when
+      IKEv2 is supported; see Sections 2.1 and 2.2).
+
+   o  Removes implementation requirements for 3DES CBC and AES in
+      Counter mode (AES CTR) (changes requirements for both to "MAY
+      implement").  Adds a "MUST implement" requirement for AES CBC (see
+      Section 2.2).
+
+   o  Adds specific IKEv2 implementation requirements (see Section 3).
+
+   o  Removes the requirement that IKEv1 use UDP port 500 (see
+      Section 3).
+
+   o  Allows the use of the Online Certificate Status Protocol (OCSP) in
+      addition to Certificate Revocation Lists (CRLs) to check
+      certificates, and changes the Diffie-Hellman group size
+      recommendation to a minimum of 2048 bits (see Section 3).
+
+1.3.  Other Updated RFCs
+
+   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; that is, the following RFCs are
+   updated -- in each case, the update is solely to the IPsec
+   requirements:
+
+   o  [RFC3720] "Internet Small Computer Systems Interface (iSCSI)"
+
+   o  [RFC3821] "Fibre Channel Over TCP/IP (FCIP)"
+
+   o  [RFC3822] "Finding Fibre Channel over TCP/IP (FCIP) Entities Using
+      Service Location Protocol version 2 (SLPv2)"
+
+
+
+Black & Koning               Standards Track                    [Page 4]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+   o  [RFC4018] "Finding Internet Small Computer Systems Interface
+      (iSCSI) Targets and Name Servers by Using Service Location
+      Protocol version 2 (SLPv2)"
+
+   o  [RFC4172] "iFCP - A Protocol for Internet Fibre Channel Storage
+      Networking"
+
+   o  [RFC4173] "Bootstrapping Clients using the Internet Small Computer
+      System Interface (iSCSI) Protocol"
+
+   o  [RFC4174] "The IPv4 Dynamic Host Configuration Protocol (DHCP)
+      Option for the Internet Storage Name Service"
+
+   o  [RFC5040] "A Remote Direct Memory Access Protocol Specification"
+
+   o  [RFC5041] "Direct Data Placement over Reliable Transports"
+
+   o  [RFC5042] "Direct Data Placement Protocol (DDP) / Remote Direct
+      Memory Access Protocol (RDMAP) Security"
+
+   o  [RFC5043] "Stream Control Transmission Protocol (SCTP) Direct Data
+      Placement (DDP) Adaptation"
+
+   o  [RFC5044] "Marker PDU Aligned Framing for TCP Specification"
+
+   o  [RFC5045] "Applicability of Remote Direct Memory Access Protocol
+      (RDMA) and Direct Data Placement (DDP)"
+
+   o  [RFC5046] "Internet Small Computer System Interface (iSCSI)
+      Extensions for Remote Direct Memory Access (RDMA)"
+
+   o  [RFC5047] "DA: Datamover Architecture for the Internet Small
+      Computer System Interface (iSCSI)"
+
+   o  [RFC5048] "Internet Small Computer System Interface (iSCSI)
+      Corrections and Clarifications"
+
+   [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 [RFC7143] and iSCSI Extensions for RDMA
+   (iSER) [RFC7145].
+
+   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.
+
+
+
+
+Black & Koning               Standards Track                    [Page 5]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+2.  ESP Requirements
+
+   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 security association (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.
+
+2.1.  Data Origin Authentication and Data Integrity Transforms
+
+   RFC 3723 requires that:
+
+   o  HMAC-SHA1 MUST be implemented in the form of HMAC-SHA-1-96
+      [RFC2404].
+
+   o  AES CBC MAC with XCBC extensions SHOULD be implemented [RFC3566].
+
+   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:
+
+   o  Implementations that support IKEv2 [RFC5996] SHOULD also implement
+      AES GMAC [RFC4543].  AES GMAC implementations MUST support 128-bit
+      keys and MAY support other key sizes.
+
+
+
+
+
+Black & Koning               Standards Track                    [Page 6]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+   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.
+
+2.2.  Confidentiality Transform Requirements
+
+   RFC 3723 requires that:
+
+   o  3DES in CBC mode (3DES CBC) [RFC2451] [triple-des-spec] MUST be
+      supported.
+
+   o  AES in Counter mode (AES CTR) [RFC3686] SHOULD be supported.
+
+   o  NULL encryption [RFC2410] MUST be supported.
+
+   The above requirements from RFC 3723 regarding 3DES CBC and AES CTR
+   are replaced in this document by requirements that both 3DES CBC and
+   AES CTR 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 in 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 32 GiB (gibibytes) 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 32 GiB 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 3 GiB 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 in Counter mode (AES CTR) is no longer the encryption transform
+   that is most amenable to hardware implementation.  That
+   characterization now applies to AES GCM [RFC4106], which provides
+   both encryption and integrity protection in a single cryptographic
+
+
+
+Black & Koning               Standards Track                    [Page 7]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+   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 the 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:
+
+   o  3DES in CBC mode MAY be implemented (replaces RFC 3723's "MUST
+      implement" requirement).
+
+   o  AES in Counter mode (AES CTR) MAY be implemented (replaces
+      RFC 3723's "SHOULD implement" requirement).
+
+   o  AES in CBC mode MUST be implemented.  AES CBC implementations MUST
+      support 128-bit keys and MAY support other key sizes.
+
+   o  Implementations that support IKEv2 SHOULD also implement AES GCM.
+      AES GCM implementations MUST support 128-bit keys and MAY support
+      other key sizes.
+
+   o  NULL encryption [RFC2410] MUST be supported.
+
+   The requirement for support of NULL encryption enables the 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.
+
+3.  IKEv1 and IKEv2 Requirements
+
+   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 Diffie-Hellman (DH) group
+   requirement also applies to IKEv2):
+
+   o  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.  The recommendation for the use of 1024-bit DH
+
+
+
+
+Black & Koning               Standards Track                    [Page 8]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+      groups with 3DES CBC and HMAC-SHA1 has been removed; the use of
+      1024-bit DH groups is NOT RECOMMENDED, and
+
+   o  The requirement to use UDP port 500 is removed in order to allow
+      NAT traversal [RFC3947].
+
+   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 domain of interpretation (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 prohibition of manual keying
+   as stated 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
+   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, the use of IPsec v3 is RECOMMENDED.
+
+
+
+
+
+
+
+
+
+
+Black & Koning               Standards Track                    [Page 9]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+3.1.  Authentication Requirements
+
+   The authentication requirements for IKEv1 are unchanged by this
+   document but are restated here for context, along with the
+   authentication requirements for IKEv2:
+
+   a.  Peer authentication using a pre-shared cryptographic key MUST be
+       supported.  Certificate-based peer authentication using digital
+       signatures MAY be supported.  For IKEv1 [RFC2409], peer
+       authentication using the public key encryption methods specified
+       in Sections 5.2 and 5.3 of [RFC2409] SHOULD NOT be used.
+
+   b.  When digital signatures are used for authentication, all IKEv1
+       and IKEv2 negotiators SHOULD use Certificate Request Payload(s)
+       to specify the certificate authority and SHOULD check the
+       certificate validity via the pertinent Certificate Revocation
+       List (CRL) or the use of the Online Certificate Status Protocol
+       (OCSP) [RFC6960] before accepting a PKI certificate for use in
+       authentication.  OCSP support within the IKEv2 protocol is
+       specified in [RFC4806].
+
+   c.  IKEv1 implementations MUST support Main Mode and SHOULD support
+       Aggressive Mode.  Main Mode with the pre-shared key
+       authentication method SHOULD NOT be used when either the
+       initiator or the target uses dynamically assigned IP addresses.
+       While in many cases pre-shared keys offer good security,
+       situations in which dynamically assigned addresses are used force
+       the use of a group pre-shared key, which creates vulnerability to
+       a man-in-the-middle attack.  These requirements do not apply to
+       IKEv2 because it has no modes.
+
+   d.  In the IKEv1 Phase 2 Quick Mode, in exchanges for creating the
+       Phase 2 SA, the Identification Payload MUST be present.  This
+       requirement does not apply to IKEv2 because it has no modes.
+
+   e.  The following identification type requirements apply to IKEv1.
+       ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6),
+       and ID_FQDN Identification Types MUST be supported; ID_USER_FQDN
+       SHOULD be supported.  The IP Subnet, IP Address Range,
+       ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types SHOULD
+       NOT be used.  The ID_KEY_ID Identification Type MUST NOT be used.
+
+   f.  When IKEv2 is supported, the following identification
+       requirements apply.  ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol
+       stack supports IPv6), and ID_FQDN Identification Types MUST be
+       supported; ID_RFC822_ADDR SHOULD be supported.  The
+       ID_DER_ASN1_DN and ID_DER_ASN1_GN Identification Types SHOULD NOT
+       be used.  The ID_KEY_ID Identification Type MUST NOT be used.
+
+
+
+Black & Koning               Standards Track                   [Page 10]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+   The reasons for the identification requirements in items e and f
+   above are as follows:
+
+   o  IP Subnet and IP Address Range are too broad to usefully identify
+      an iSCSI endpoint.
+
+   o  The _DN and _GN types are X.500 identities; it is usually better
+      to use an identity from subjectAltName in a PKI certificate.
+
+   o  ID_KEY_ID is an opaque identifier that is not interoperable among
+      different IPsec implementations as specified.  Heterogeneity in
+      some block storage protocol implementations can be expected (e.g.,
+      iSCSI initiator vs. iSCSI target implementations), and hence
+      heterogeneity among IPsec implementations is important.
+
+3.2.  DH Group and PRF Requirements
+
+   This document does not change the support requirements for Diffie-
+   Hellman (DH) groups and Pseudo-Random Functions (PRFs).  See
+   [RFC4109] for IKEv1 requirements and [RFC4307] for IKEv2
+   requirements.  Implementers 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 support for perfect forward secrecy in the
+   IKEv1 Quick Mode key exchange MUST be implemented.  This document
+   extends that requirement to IKEv2; support for perfect forward
+   secrecy in the CREATE_CHILD_SA key exchange MUST be implemented for
+   the use of IPsec with block storage protocols.
+
+4.  Security Considerations
+
+   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:
+
+   o  AES GMAC [RFC4543] (new requirement -- SHOULD be supported when
+      IKEv2 is supported),
+
+   o  3DES CBC [RFC2451] (changed from "MUST be supported" to "MAY be
+      supported"),
+
+
+
+Black & Koning               Standards Track                   [Page 11]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+   o  AES CTR [RFC3686] (changed from "SHOULD be supported" to "MAY be
+      supported"),
+
+   o  AES CBC [RFC3602] (new requirement -- MUST be supported), and
+
+   o  AES GCM [RFC4106] (new requirement -- SHOULD be supported when
+      IKEv2 is supported).
+
+   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.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
+              Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
+              ESP and AH", RFC 2404, November 1998.
+
+   [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
+              Payload (ESP)", RFC 2406, November 1998.
+
+
+
+
+
+Black & Koning               Standards Track                   [Page 12]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+   [RFC2407]  Piper, D., "The Internet IP Security Domain of
+              Interpretation for ISAKMP", RFC 2407, November 1998.
+
+   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
+              (IKE)", RFC 2409, November 1998.
+
+   [RFC2410]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
+              Its Use With IPsec", RFC 2410, November 1998.
+
+   [RFC2451]  Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
+              Algorithms", RFC 2451, November 1998.
+
+   [RFC3566]  Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
+              and Its Use With IPsec", RFC 3566, September 2003.
+
+   [RFC3602]  Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
+              Algorithm and Its Use with IPsec", RFC 3602,
+              September 2003.
+
+   [RFC3686]  Housley, R., "Using Advanced Encryption Standard (AES)
+              Counter Mode With IPsec Encapsulating Security Payload
+              (ESP)", RFC 3686, January 2004.
+
+   [RFC3720]  Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
+              and E. Zeidner, "Internet Small Computer Systems Interface
+              (iSCSI)", RFC 3720, April 2004.
+
+   [RFC3723]  Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
+              Travostino, "Securing Block Storage Protocols over IP",
+              RFC 3723, April 2004.
+
+   [RFC3821]  Rajagopal, M., Rodriguez, E., and R. Weber, "Fibre Channel
+              Over TCP/IP (FCIP)", RFC 3821, July 2004.
+
+   [RFC3822]  Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP)
+              Entities Using Service Location Protocol version 2
+              (SLPv2)", RFC 3822, July 2004.
+
+   [RFC3947]  Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
+              "Negotiation of NAT-Traversal in the IKE", RFC 3947,
+              January 2005.
+
+   [RFC4018]  Bakke, M., Hufferd, J., Voruganti, K., Krueger, M., and T.
+              Sperry, "Finding Internet Small Computer Systems Interface
+              (iSCSI) Targets and Name Servers by Using Service Location
+              Protocol version 2 (SLPv2)", RFC 4018, April 2005.
+
+
+
+
+
+Black & Koning               Standards Track                   [Page 13]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
+              (GCM) in IPsec Encapsulating Security Payload (ESP)",
+              RFC 4106, June 2005.
+
+   [RFC4109]  Hoffman, P., "Algorithms for Internet Key Exchange
+              version 1 (IKEv1)", RFC 4109, May 2005.
+
+   [RFC4172]  Monia, C., Mullendore, R., Travostino, F., Jeong, W., and
+              M. Edwards, "iFCP - A Protocol for Internet Fibre Channel
+              Storage Networking", RFC 4172, September 2005.
+
+   [RFC4173]  Sarkar, P., Missimer, D., and C. Sapuntzakis,
+              "Bootstrapping Clients using the Internet Small Computer
+              System Interface (iSCSI) Protocol", RFC 4173,
+              September 2005.
+
+   [RFC4174]  Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic
+              Host Configuration Protocol (DHCP) Option for the Internet
+              Storage Name Service", RFC 4174, September 2005.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
+              RFC 4303, December 2005.
+
+   [RFC4304]  Kent, S., "Extended Sequence Number (ESN) Addendum to
+              IPsec Domain of Interpretation (DOI) for Internet Security
+              Association and Key Management Protocol (ISAKMP)",
+              RFC 4304, December 2005.
+
+   [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the
+              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
+              December 2005.
+
+   [RFC4543]  McGrew, D. and J. Viega, "The Use of Galois Message
+              Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
+              May 2006.
+
+   [RFC5040]  Recio, R., Metzler, B., Culley, P., Hilland, J., and D.
+              Garcia, "A Remote Direct Memory Access Protocol
+              Specification", RFC 5040, October 2007.
+
+   [RFC5041]  Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct
+              Data Placement over Reliable Transports", RFC 5041,
+              October 2007.
+
+
+
+
+
+Black & Koning               Standards Track                   [Page 14]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+   [RFC5042]  Pinkerton, J. and E. Deleganes, "Direct Data Placement
+              Protocol (DDP) / Remote Direct Memory Access Protocol
+              (RDMAP) Security", RFC 5042, October 2007.
+
+   [RFC5043]  Bestler, C. and R. Stewart, "Stream Control Transmission
+              Protocol (SCTP) Direct Data Placement (DDP) Adaptation",
+              RFC 5043, October 2007.
+
+   [RFC5044]  Culley, P., Elzur, U., Recio, R., Bailey, S., and J.
+              Carrier, "Marker PDU Aligned Framing for TCP
+              Specification", RFC 5044, October 2007.
+
+   [RFC5046]  Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H.,
+              and P. Thaler, "Internet Small Computer System Interface
+              (iSCSI) Extensions for Remote Direct Memory Access
+              (RDMA)", RFC 5046, October 2007.
+
+   [RFC5048]  Chadalapaka, M., "Internet Small Computer System Interface
+              (iSCSI) Corrections and Clarifications", RFC 5048,
+              October 2007.
+
+   [RFC5282]  Black, D. and D. McGrew, "Using Authenticated Encryption
+              Algorithms with the Encrypted Payload of the Internet Key
+              Exchange version 2 (IKEv2) Protocol", RFC 5282,
+              August 2008.
+
+   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
+              "Internet Key Exchange Protocol Version 2 (IKEv2)",
+              RFC 5996, September 2010.
+
+   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
+              Galperin, S., and C. Adams, "X.509 Internet Public Key
+              Infrastructure Online Certificate Status Protocol - OCSP",
+              RFC 6960, June 2013.
+
+   [RFC7143]  Chadalapaka, M., Satran, J., Meth, K., and D. Black,
+              "Internet Small Computer System Interface (iSCSI) Protocol
+              (Consolidated)", RFC 7143, April 2014.
+
+   [RFC7145]  Ko, M. and A. Nezhinsky, "Internet Small Computer System
+              Interface (iSCSI) Extensions for the Remote Direct Memory
+              Access (RDMA) Specification", RFC 7145, April 2014.
+
+   [SP800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
+              "NIST Special Publication 800-57: Recommendation for Key
+              Management - Part 1: General (Revision 3)", July 2012,
+              <http://csrc.nist.gov/publications/nistpubs/800-57/
+              sp800-57_part1_rev3_general.pdf>.
+
+
+
+Black & Koning               Standards Track                   [Page 15]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+   [triple-des-birthday]
+              McGrew, D., "Impossible plaintext cryptanalysis and
+              probable-plaintext collision attacks of 64-bit block
+              cipher modes (Cryptology ePrint Archive: Report 2012/
+              623)", November 2012, <http://eprint.iacr.org/2012/623>.
+
+   [triple-des-spec]
+              American Bankers Association (ABA), "American National
+              Standard for Financial Services X9.52-1998 - Triple Data
+              Encryption Algorithm Modes of Operation", July 1998.
+
+5.2.  Informative References
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Black & Koning               Standards Track                   [Page 16]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+Appendix A.  Block Cipher Birthday Bounds
+
+   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.
+
+Appendix B.  Contributors
+
+   David McGrew's observations about the birthday bound implications of
+   3DES's 64-bit block size on the ipsec@ietf.org mailing list led 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Black & Koning               Standards Track                   [Page 17]
+
+RFC 7146            RFC 3723 Reqs Update for IPsec v3         April 2014
+
+
+Authors' Addresses
+
+   David L. Black
+   EMC Corporation
+   176 South St.
+   Hopkinton, MA  01748
+   USA
+
+   Phone: +1 508 293-7953
+   EMail: david.black@emc.com
+
+
+   Paul Koning
+   Dell
+   300 Innovative Way
+   Nashua, NH  03062
+   USA
+
+   Phone: +1 603 249-7703
+   EMail: paul_koning@Dell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Black & Koning               Standards Track                   [Page 18]
+