GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7146

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7146.txt · Last modified: 2014/04/04 23:30 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki