< draft-ietf-storm-ipsec-ips-update-03.txt   draft-ietf-storm-ipsec-ips-update-04.txt >
Storage Maintenance (storm) D. Black Storage Maintenance (storm) D. Black
Internet-Draft EMC Internet-Draft EMC
Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, P. Koning Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, P. Koning
Intended status: Standards Track Dell Intended status: Standards Track Dell
Expires: January 10, 2014 July 09, 2013 Expires: April 23, 2014 October 20, 2013
Securing Block Storage Protocols over IP: RFC 3723 Requirements Update Securing Block Storage Protocols over IP: RFC 3723 Requirements Update
for IPsec v3 for IPsec v3
draft-ietf-storm-ipsec-ips-update-03 draft-ietf-storm-ipsec-ips-update-04
Abstract Abstract
RFC 3723 specifies IPsec requirements for block storage protocols RFC 3723 specifies IPsec requirements for block storage protocols
over IP (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related RFCs); over IP (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related RFCs);
those requirements have subsequently been applied to remote direct those requirements have subsequently been applied to remote direct
data placement protocols, e.g., RDMAP. This document updates RFC data placement protocols, e.g., RDMAP. This document updates RFC
3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and
makes some changes to required algorithms based on developments in makes some changes to required algorithms based on developments in
cryptography since RFC 3723 was published. cryptography since RFC 3723 was published.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2014. This Internet-Draft will expire on April 23, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Summary of Changes to RFC 3723 . . . . . . . . . . . . . 3 1.2. Summary of Changes to RFC 3723 . . . . . . . . . . . . . 3
1.3. Other Updated RFCs . . . . . . . . . . . . . . . . . . . 4 1.3. Other Updated RFCs . . . . . . . . . . . . . . . . . . . 4
2. ESP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 2. ESP Requirements . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Data Origin Authentication and Data Integrity Transforms 6 2.1. Data Origin Authentication and Data Integrity Transforms 6
2.2. Confidentiality Transform Requirements . . . . . . . . . 6 2.2. Confidentiality Transform Requirements . . . . . . . . . 6
3. IKEv1 and IKEv2 Requirements . . . . . . . . . . . . . . . . 8 3. IKEv1 and IKEv2 Requirements . . . . . . . . . . . . . . . . 8
3.1. Authentication Requirements . . . . . . . . . . . . . . . 9 3.1. Authentication Requirements . . . . . . . . . . . . . . . 9
3.2. D-H Group and PRF Requirements . . . . . . . . . . . . . 10 3.2. D-H Group and PRF Requirements . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
RFC 3723 [RFC3723] specifies IPsec requirements for block storage RFC 3723 [RFC3723] specifies IPsec requirements for block storage
protocols over IP (e.g., iSCSI [RFC3720]) based on IPsec v2 (RFC 2401 protocols over IP (e.g., iSCSI [RFC3720]) based on IPsec v2 (RFC 2401
[RFC2401] and related RFCs); those requirements have subsequently [RFC2401] and related RFCs); those requirements have subsequently
been applied to remote direct data placement protocols, e.g., RDMAP been applied to remote direct data placement protocols, e.g., RDMAP
[RFC5040]. This document updates RFC 3723's IPsec requirements to [RFC5040]. This document updates RFC 3723's IPsec requirements to
IPsec v3 ([RFC4301] and related RFCs) to reflect developments since IPsec v3 ([RFC4301] and related RFCs) to reflect developments since
RFC 3723 was published. RFC 3723 was published.
skipping to change at page 3, line 28 skipping to change at page 3, line 28
Block storage protocols can be expected to operate at high data rates Block storage protocols can be expected to operate at high data rates
(multiple Gigabits/second). The cryptographic requirements in this (multiple Gigabits/second). The cryptographic requirements in this
document are strongly influenced by that expectation; an important document are strongly influenced by that expectation; an important
example is that 3DES CBC is no longer recommended for block storage 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 protocols due to the frequent rekeying impacts of 3DES's 64-bit block
size at high data rates. size at high data rates.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
1.2. Summary of Changes to RFC 3723 1.2. Summary of Changes to RFC 3723
This document makes the following changes to RFC 3723: This document makes the following changes to RFC 3723:
o Adds requirements that IPsec v3 SHOULD be implemented (ESPv3 and o Adds requirements that IPsec v3 SHOULD be implemented (ESPv3 and
IKEv2) in addition to IPsec v2, (see Section 1). The ESPv3 IKEv2) in addition to IPsec v2, (see Section 1).
implementation requirement includes extended sequence numbers, see
o Requires extended sequence numbers for both ESPv2 and ESPv3, see
Section 2. Section 2.
o Clarifies key size requirements for AES CBC MAC with XCBC o Clarifies key size requirements for AES CBC MAC with XCBC
extensions (MUST implement 128 bit keys, see Section 2.1). extensions (MUST implement 128 bit keys, see Section 2.1).
o Adds IPsec v3 requirements for AES GMAC and GCM (SHOULD implement o Adds IPsec v3 requirements for AES GMAC and GCM (SHOULD implement
when IKEv2 is supported, see Section 2.1 and Section 2.2). when IKEv2 is supported, see Section 2.1 and Section 2.2).
o Removes implementation requirements for 3DES CBC and AES CTR o Removes implementation requirements for 3DES CBC and AES CTR
(changes requirements for both to "MAY implement"). Adds a "MUST (changes requirements for both to "MAY implement"). Adds a "MUST
implement" requirement for AES CBC (see Section 2.2). implement" requirement for AES CBC (see Section 2.2).
o Adds specific IKEv2 implementation requirements (see Section 3). o Adds specific IKEv2 implementation requirements (see Section 3).
o Removes the requirement that IKEv1 use UDP port 500, and changes o Removes the requirement that IKEv1 use UDP port 500 (see
the Diffie-Hellman group size recommendation to a minimum of 2048 Section 3).
bits (see Section 3).
o Allows use of OCSP in addition to 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 1.3. Other Updated RFCs
RFC 3723's IPsec requirements have been applied to a number of RFC 3723's IPsec requirements have been applied to a number of
protocols. For that reason, in addition to updating RFC 3723's IPsec protocols. For that reason, in addition to updating RFC 3723's IPsec
requirements, this document also updates the IPsec requirements for requirements, this document also updates the IPsec requirements for
each protocol that uses RFC 3723, i.e., the following RFCs are each protocol that uses RFC 3723, i.e., the following RFCs are
updated - in each case, the update is solely to the IPsec updated - in each case, the update is solely to the IPsec
requirements: requirements:
skipping to change at page 5, line 40 skipping to change at page 6, line 6
utilized, per-packet data origin authentication, integrity and replay utilized, per-packet data origin authentication, integrity and replay
protection MUST be provided. protection MUST be provided.
This document modifies RFC 3723 to require that implementations This document modifies RFC 3723 to require that implementations
SHOULD also support IPsec ESPv3 [RFC4303] in tunnel mode as part of SHOULD also support IPsec ESPv3 [RFC4303] in tunnel mode as part of
IPsec v3 to provide security for both control packets and data IPsec v3 to provide security for both control packets and data
packets; per-packet data origin authentication, integrity and replay packets; per-packet data origin authentication, integrity and replay
protection MUST be provided when ESPv3 is utilized. protection MUST be provided when ESPv3 is utilized.
At the high speeds at which block storage protocols are expected to At the high speeds at which block storage protocols are expected to
operate, a single IPsec SA could rapidly cycle through the ESP 32-bit operate, a single IPsec SA could rapidly exhaust the ESP 32-bit
sequence number space. In view of this, implementations that are sequence number space, requiring frequent rekeying of the SA, as
capable of operating at speeds of 1 gigabit/second or higher and that rollover of the ESP sequence number within a single SA is prohibited
implement both IKEv2 [RFC5996] and ESPv3 [RFC4303] MUST also for both ESPv2 [RFC2406] and ESPv3 [RFC4303] . In order to provide
implement extended (64-bit) sequence numbers for ESPv3 and SHOULD use the means to avoid this potentially undesirable frequent rekeying,
ESPv3 extended sequence numbers for all block storage protocol implementations that are capable of operating at speeds of 1 gigabit/
traffic. 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 2.1. Data Origin Authentication and Data Integrity Transforms
RFC 3723 requires that: RFC 3723 requires that:
o HMAC-SHA1 MUST be implemented in the form of HMAC-SHA-1-96 o HMAC-SHA1 MUST be implemented in the form of HMAC-SHA-1-96
[RFC2404]. [RFC2404].
o AES CBC MAC with XCBC extensions SHOULD be implemented [RFC3566]. o AES CBC MAC with XCBC extensions SHOULD be implemented [RFC3566].
skipping to change at page 7, line 13 skipping to change at page 7, line 28
at a time. Security weaknesses in encryption start to appear as the at a time. Security weaknesses in encryption start to appear as the
amount of data encrypted under a single key approaches the birthday 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 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 and [triple-des-birthday]. It is prudent to rekey well before that
bound is reached, and 32GiB or some significant fraction thereof is bound is reached, and 32GiB or some significant fraction thereof is
less than the amount of data that a block storage protocol may less than the amount of data that a block storage protocol may
transfer in a single session. This may require frequent rekeying, transfer in a single session. This may require frequent rekeying,
e.g., to obtain an order of magnitude (10x) safety margin by 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 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 bit block size, which results in a much larger birthday bound (2^68
bytes), see Appendix A. AES CBC is the primary mandatory-to-implement bytes), see Appendix A. AES CBC [RFC3602] is the primary mandatory-
encryption transform for interoperability, and hence is the to-implement encryption transform for interoperability, and hence is
appropriate mandatory-to-implement transform replacement for 3DES the appropriate mandatory-to-implement transform replacement for 3DES
CBC. CBC.
AES Counter mode is no longer the encryption transform that is most AES Counter mode (AES CTR) is no longer the encryption transform that
amenable to hardware implementation. That characterization now is most amenable to hardware implementation. That characterization
applies to AES Galois Counter Mode (GCM) [RFC4106], which provides now applies to AES Galois Counter Mode (GCM) [RFC4106], which
both encryption and integrity protection in a single cryptographic provides both encryption and integrity protection in a single
mechanism (in contrast, neither HMAC-SHA1 nor AES CBC MAC with XCBC cryptographic mechanism (in contrast, neither HMAC-SHA1 nor AES CBC
extensions is well suited for hardware implementation, as both MAC with XCBC extensions is well suited for hardware implementation,
transforms do not pipeline well). AES GCM is also capable of as both transforms do not pipeline well). AES GCM is also capable of
providing confidentiality protection for the IKEv2 key exchange providing confidentiality protection for the IKEv2 key exchange
protocol, but not the IKEv1 protocol [RFC5282], and therefore the new protocol, but not the IKEv1 protocol [RFC5282], and therefore the new
AES GCM "SHOULD" requirement is based on presence of support for AES GCM "SHOULD" requirement is based on presence of support for
IKEv2. IKEv2.
For the reasons described in the preceding paragraphs, the For the reasons described in the preceding paragraphs, the
confidentiality transform requirements in RFC 3723 are replaced by confidentiality transform requirements in RFC 3723 are replaced by
the following: the following:
o 3DES in CBC mode MAY be implemented (replaces RFC 3723's "MUST o 3DES in CBC mode MAY be implemented (replaces RFC 3723's "MUST
implement" requirement) . implement" requirement).
o AES in Counter mode MAY be implemented (replaces RFC 3723's o AES in Counter mode (AES CTR) MAY be implemented (replaces RFC
"SHOULD implement" requirement). 3723's "SHOULD implement" requirement).
o AES in CBC mode MUST be implemented. AES CBC implementations MUST o AES in CBC mode MUST be implemented. AES CBC implementations MUST
support 128-bit keys and MAY support other key sizes. support 128-bit keys and MAY support other key sizes.
o Implementations that support IKEv2 SHOULD also implement AES GCM. o Implementations that support IKEv2 SHOULD also implement AES GCM.
AES GCM implementations MUST support 128-bit keys, and MAY support AES GCM implementations MUST support 128-bit keys, and MAY support
other key sizes. other key sizes.
o NULL encryption [RFC2410] MUST be supported. o NULL encryption [RFC2410] MUST be supported.
skipping to change at page 8, line 20 skipping to change at page 8, line 36
Note: to avoid ambiguity, the original IKE protocol [RFC2409] is Note: to avoid ambiguity, the original IKE protocol [RFC2409] is
referred to as "IKEv1" in this document. referred to as "IKEv1" in this document.
This document adds requirements for IKEv2 usage with block Storage This document adds requirements for IKEv2 usage with block Storage
protocols and makes the following two changes to the IKEv1 protocols and makes the following two changes to the IKEv1
requirements in RFC 3723 (the new D-H group requirement also applies requirements in RFC 3723 (the new D-H group requirement also applies
to IKEv2): to IKEv2):
o When D-H groups are used, a D-H group of at least 2048 bits SHOULD o When D-H groups are used, a D-H group of at least 2048 bits SHOULD
be offered as a part of all proposals to create IPsec Security be offered as a part of all proposals to create IPsec Security
Associations. Use of 1024 bit D-H groups with 3DES CBC and HMAC- Associations. The recommendation for use of 1024 bit D-H groups
SHA1 is no longer recommended, and with 3DES CBC and HMAC-SHA1 has been removed; use of 1024 bit D-H
groups is NOT RECOMMENDED, and
o The requirement to use UDP port 500 is removed in order to allow o The requirement to use UDP port 500 is removed in order to allow
NAT traversal [RFC3947]. NAT traversal [RFC3947].
There are no other changes to RFC 3723's IKEv1 requirements, but many 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 of them are restated in this document in order to provide context for
the new IKEv2 requirements. the new IKEv2 requirements.
RFC 3723 requires that IKEv1 [RFC2409] be supported for peer RFC 3723 requires that IKEv1 [RFC2409] be supported for peer
authentication, negotiation of security associations, and key authentication, negotiation of security associations, and key
skipping to change at page 9, line 10 skipping to change at page 9, line 27
SA will be created to protect that traffic. SA will be created to protect that traffic.
The method used to determine whether a block storage protocol The method used to determine whether a block storage protocol
connection should be established using IPsec is regarded as an issue connection should be established using IPsec is regarded as an issue
of IPsec policy administration, and thus is not defined in this of IPsec policy administration, and thus is not defined in this
document. The method used by an implementation that supports both document. The method used by an implementation that supports both
IPsec v2 and v3 to determine which versions of IPsec are supported by 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 the a block storage protocol peer is also regarded as an issue of
IPsec policy administration, and thus is also not defined in this IPsec policy administration, and thus is also not defined in this
document. If both IPsec v2 and v3 are supported by both endpoints of document. If both IPsec v2 and v3 are supported by both endpoints of
a block storage protocol connection, use of IPsec v3 is recommended. a block storage protocol connection, use of IPsec v3 is RECOMMENDED.
3.1. Authentication Requirements 3.1. Authentication Requirements
The authentication requirements for IKEv1 are unchanged by this The authentication requirements for IKEv1 are unchanged by this
document, but are restated here for context along with the document, but are restated here for context along with the
authentication requirements for IKEv2: authentication requirements for IKEv2:
a. Peer authentication using a pre-shared cryptographic key MUST be a. Peer authentication using a pre-shared cryptographic key MUST be
supported. Certificate-based peer authentication using digital supported. Certificate-based peer authentication using digital
signatures MAY be supported. For IKEv1 ([RFC2409]), peer signatures MAY be supported. For IKEv1 ([RFC2409]), peer
authentication using the public key encryption methods specified authentication using the public key encryption methods specified
in sections 5.2 and 5.3 of [RFC2409] SHOULD NOT be used. in sections 5.2 and 5.3 of [RFC2409] SHOULD NOT be used.
b. When digital signatures are used for authentication, all IKEv1 b. When digital signatures are used for authentication, all IKEv1
and IKEv2 negotiators SHOULD use Certificate Request Payload(s) and IKEv2 negotiators SHOULD use Certificate Request Payload(s)
to specify the certificate authority, and SHOULD check the to specify the certificate authority, and SHOULD check the
pertinent Certificate Revocation List (CRL) before accepting a cerificate validity via the pertinent Certificate Revocation List
PKI certificate for use in authentication. (CRL) or via 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 c. IKEv1 implementations MUST support Main Mode and SHOULD support
Aggressive Mode. Main Mode with pre-shared key authentication Aggressive Mode. Main Mode with pre-shared key authentication
method SHOULD NOT be used when either the initiator or the target method SHOULD NOT be used when either the initiator or the target
uses dynamically assigned IP addresses. While in many cases pre- uses dynamically assigned IP addresses. While in many cases pre-
shared keys offer good security, situations in which dynamically shared keys offer good security, situations in which dynamically
assigned addresses are used force the use of a group pre-shared assigned addresses are used force the use of a group pre-shared
key, which creates vulnerability to a man-in-the-middle attack. key, which creates vulnerability to a man-in-the-middle attack.
These requirements do not apply to IKEv2 because it has no modes. These requirements do not apply to IKEv2 because it has no modes.
skipping to change at page 11, line 9 skipping to change at page 11, line 23
IPsec with block storage protocols. IPsec with block storage protocols.
4. IANA Considerations 4. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
5. Security Considerations 5. Security Considerations
This entire document is about security. 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"),
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.
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-storm-iscsi-cons] [I-D.ietf-storm-iscsi-cons]
Chadalapaka, M., Satran, J., Meth, K., and D. Black, Chadalapaka, M., Satran, J., Meth, K., and D. Black,
"iSCSI Protocol (Consolidated)", draft-ietf-storm-iscsi- "iSCSI Protocol (Consolidated)", draft-ietf-storm-iscsi-
cons-09 (work in progress), June 2013. cons-10 (work in progress), July 2013.
[I-D.ietf-storm-iser] [I-D.ietf-storm-iser]
Ko, M. and A. Nezhinsky, "iSCSI Extensions for RDMA Ko, M. and A. Nezhinsky, "iSCSI Extensions for RDMA
Specification", draft-ietf-storm-iser-14 (work in Specification", draft-ietf-storm-iser-15 (work in
progress), June 2013. progress), July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
skipping to change at page 11, line 50 skipping to change at page 13, line 11
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998. Its Use With IPsec", RFC 2410, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998. Algorithms", RFC 2451, November 1998.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", RFC 3566, September 2003. 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) [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004. (ESP)", RFC 3686, January 2004.
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
and E. Zeidner, "Internet Small Computer Systems Interface and E. Zeidner, "Internet Small Computer Systems Interface
(iSCSI)", RFC 3720, April 2004. (iSCSI)", RFC 3720, April 2004.
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols over IP", Travostino, "Securing Block Storage Protocols over IP",
skipping to change at page 13, line 8 skipping to change at page 14, line 20
[RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic [RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic
Host Configuration Protocol (DHCP) Option for the Internet Host Configuration Protocol (DHCP) Option for the Internet
Storage Name Service", RFC 4174, September 2005. Storage Name Service", RFC 4174, September 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 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 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307, Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005. December 2005.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
May 2006. May 2006.
[RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. [RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D.
Garcia, "A Remote Direct Memory Access Protocol Garcia, "A Remote Direct Memory Access Protocol
skipping to change at page 14, line 5 skipping to change at page 15, line 23
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282, August Exchange version 2 (IKEv2) Protocol", RFC 5282, August
2008. 2008.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010. 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.
[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>.
[triple-des-birthday] [triple-des-birthday]
McGrew, D., "Impossible plaintext cryptanalysis and McGrew, D., "Impossible plaintext cryptanalysis and
probable-plaintext collision attacks of 64-bit block probable-plaintext collision attacks of 64-bit block
cipher modes (Cryptology ePrint Archive: Report 2012/ cipher modes (Cryptology ePrint Archive: Report 2012/
623)", November 2012, <http://eprint.iacr.org/2012/623>. 623)", November 2012, <http://eprint.iacr.org/2012/623>.
[triple-des-spec] [triple-des-spec]
American Bankers Association, ABA., "American National American Bankers Association, ABA., "American National
Standard for Financial Services X9.52-1998 - Triple Data Standard for Financial Services X9.52-1998 - Triple Data
Encryption Algorithm Modes of Operation", July 1998. Encryption Algorithm Modes of Operation", July 1998.
6.2. Informative References 6.2. Informative References
[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M.
Krueger, "Internet Small Computer Systems Interface Krueger, "Internet Small Computer Systems Interface
(iSCSI) Naming and Discovery", RFC 3721, April 2004. (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 [RFC5045] Bestler, C. and L. Coene, "Applicability of Remote Direct
Memory Access Protocol (RDMA) and Direct Data Placement Memory Access Protocol (RDMA) and Direct Data Placement
(DDP)", RFC 5045, October 2007. (DDP)", RFC 5045, October 2007.
[RFC5047] Chadalapaka, M., Hufferd, J., Satran, J., and H. Shah, [RFC5047] Chadalapaka, M., Hufferd, J., Satran, J., and H. Shah,
"DA: Datamover Architecture for the Internet Small "DA: Datamover Architecture for the Internet Small
Computer System Interface (iSCSI)", RFC 5047, October Computer System Interface (iSCSI)", RFC 5047, October
2007. 2007.
[RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and
skipping to change at page 15, line 12 skipping to change at page 16, line 48
bytes, the birthday bound is 2^68 bytes = 2^8 exbibytes, i.e., 256 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 EiB, where 1 exbibyte (EiB) = 2^60 bytes. Note that an exabyte
(decimal quantity) is not the same as an exbibyte (binary quantity), (decimal quantity) is not the same as an exbibyte (binary quantity),
1 exabyte (EB) = 10^9 bytes. 1 exabyte (EB) = 10^9 bytes.
Appendix B. Contributors Appendix B. Contributors
David McGrew's observations about the birthday bound implications of 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 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 changing from 3DES CBC to AES CBC as the mandatory to implement
encryption algorithm and including the birthday bound material in encryption algorithm based on the birthday bound discussion in
Appendix A. Appendix A.
The original authors of RFC 3723 were: Bernard Aboba, Joshua Tseng, The original authors of RFC 3723 were: Bernard Aboba, Joshua Tseng,
Jesse Walker, Venkat Rangan and Franco Travostino. Comments from Jesse Walker, Venkat Rangan and Franco Travostino. Comments from
Yaron Sheffer and Tom Talpey have improved this document and are Francis Dupont, Yaron Sheffer, Tom Talpey, Sean Turner and Tom Yu
gratefully acknowledged. have improved this document and are gratefully acknowledged.
Appendix C. Change Log Appendix C. Change Log
This section should be removed before this document is published as This section should be removed before this document is published as
an RFC an RFC
Changes from -00 to -01: Changes from -00 to -01:
o Make it clearer that RFC 3723's encryption implementation o Make it clearer that RFC 3723's encryption implementation
requirements are being changed. requirements are being changed.
skipping to change at page 16, line 7 skipping to change at page 17, line 42
o Add appendix on birthday bound calculations. o Add appendix on birthday bound calculations.
o Clean up and tighten requirements text, with a focus on making key o Clean up and tighten requirements text, with a focus on making key
size requirements clearer. size requirements clearer.
o Add summary of changes from RFC 3723. o Add summary of changes from RFC 3723.
o Many other editorial changes. o Many other editorial changes.
Changes from -02 to -03
o Editorial changes
Changes from -03 to -04
o Extend ESN requirement to ESPv2.
o Allow OCSP in addition to CRLs to check certificates.
o Add security considerations text, primarily on changes to
encryption requirements.
o Editorial changes
Authors' Addresses Authors' Addresses
David Black David Black
EMC EMC
176 South Street 176 South Street
Hopkinton, MA 01748 Hopkinton, MA 01748
US USA
Phone: +1 508 293-7953 Phone: +1 508 293-7953
Email: david.black@emc.com Email: david.black@emc.com
Paul Koning Paul Koning
Dell Dell
300 Innovative Way 300 Innovative Way
Nashua, NH 03062 Nashua, NH 03062
US USA
Phone: +1 603 249-7703 Phone: +1 603 249-7703
Email: paul_koning@Dell.com Email: paul_koning@Dell.com
 End of changes. 28 change blocks. 
48 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/