idnits 2.17.1 draft-ietf-storm-ipsec-ips-update-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4018, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3720, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5040, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3723, but the abstract doesn't seem to directly say this. It does mention RFC3723 though, so this could be OK. -- The draft header indicates that this document updates RFC4172, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4173, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3821, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4174, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3822, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3720, updated by this document, for RFC5378 checks: 2000-11-06) (Using the creation date from RFC3821, updated by this document, for RFC5378 checks: 2000-10-31) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 07, 2013) is 3976 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-storm-iscsi-cons-08 == Outdated reference: A later version (-15) exists of draft-ietf-storm-iser-14 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 3720 (Obsoleted by RFC 7143) ** Obsolete normative reference: RFC 4307 (Obsoleted by RFC 8247) ** Obsolete normative reference: RFC 5048 (Obsoleted by RFC 7143) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 5046 (Obsoleted by RFC 7145) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Storage Maintenance (storm) D. Black 3 Internet-Draft EMC 4 Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, P. Koning 5 Intended status: Standards Track Dell 6 Expires: December 09, 2013 June 07, 2013 8 IP Storage: IPsec Requirements Update for IPsec v3 9 draft-ietf-storm-ipsec-ips-update-01 11 Abstract 13 RFC 3723 includes requirements for IPsec usage with IP Storage 14 protocols (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related 15 RFCs). This document updates those requirements to IPsec v3 (RFC 16 4301 and related RFCs) and updates implementation requirements to 17 reflect developments in cryptography since RFC 3723 was published. 19 [RFC Editor: The "Updates:" list above has been truncated by xml2rfc. 20 The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, 21 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if 22 approved) ] 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 09, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 1.2. Updated RFCs . . . . . . . . . . . . . . . . . . . . . . 3 61 2. ESP Requirements . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Data Origin Authentication and Data Integrity Transforms 4 63 2.2. Confidentiality Transform Requirements . . . . . . . . . 5 64 3. IKEv1 and IKEv2 Requirements . . . . . . . . . . . . . . . . 6 65 3.1. Authentication Requirements . . . . . . . . . . . . . . . 7 66 3.2. D-H Group and PRF Requirements . . . . . . . . . . . . . 9 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 6.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 RFC 3723 [RFC3723] includes requirements for use of IPsec with IP 77 Storage protocols (e.g., iSCSI) based on IPsec v2 (RFC 2401 [RFC2401] 78 and related RFCs). This document updates those requirements to 79 include IPsec v3 (RFC 4301[RFC4301] and related RFCs) to reflect 80 developments since RFC 3723 was published. IP storage protocols can 81 be expected to operate at high data rates (multiple Gigabits/second); 82 the requirements in this document are strongly influenced by that 83 expectation, and hence may not be appropriate for use of IPsec with 84 other protocols that do not operate at high data rates. 86 In addition to the IPsec v2 requirements in RFC 3723, IPsec v3, as 87 specified in [RFC4301] and related RFCs (e.g., IKEv2 [RFC5996]), 88 SHOULD be implemented for use of IPsec with IP storage protocols. 89 Retention of the mandatory requirement for IPsec v2 provides 90 interoperability with existing implementations, and the strong 91 recommendation for IPsec v3 encourages implementers to move forward 92 to that newer version of IPsec. 94 Cryptographic developments since the publication of RFC 3723 95 necessitate changes to the encryption transform requirements for 96 IPsec v2, as explained further in Section 2.2; these updated 97 requirements also apply to IPsec v3. 99 1.1. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 1.2. Updated RFCs 107 The requirements for IPsec usage with IP storage in RFC 3723 are used 108 by a number of protocols. For that reason, beyond updating RFC 3723, 109 this document also updates the IPsec requirements for each protocol 110 specification that uses RFC 3723, i.e., the following RFCs in 111 addition to RFC 3723: 113 o [RFC3720] "Internet Small Computer Systems Interface (iSCSI)" 115 o [RFC3821] "Fibre Channel Over TCP/IP (FCIP)" 117 o [RFC3822] "Finding Fibre Channel over TCP/IP (FCIP) Entities Using 118 Service Location Protocol version 2 (SLPv2)" 120 o [RFC4018] "Finding Internet Small Computer Systems Interface 121 (iSCSI) Targets and Name Servers by Using Service Location 122 Protocol version 2 (SLPv2)" 124 o [RFC4172] "iFCP - A Protocol for Internet Fibre Channel Storage 125 Networking" 127 o [RFC4173] "Bootstrapping Clients using the Internet Small Computer 128 System Interface (iSCSI) Protocol" 130 o [RFC4174] "The IPv4 Dynamic Host Configuration Protocol (DHCP) 131 Option for the Internet Storage Name Service" 133 o [RFC5040] "A Remote Direct Memory Access Protocol Specification" 135 o [RFC5041] "Direct Data Placement over Reliable Transports" 137 o [RFC5042] "Direct Data Placement Protocol (DDP) / Remote Direct 138 Memory Access Protocol (RDMAP) Security" 140 o [RFC5043] "Stream Control Transmission Protocol (SCTP) Direct Data 141 Placement (DDP) Adaptation" 143 o [RFC5044] "Marker PDU Aligned Framing for TCP Specification" 145 o [RFC5045] "Applicability of Remote Direct Memory Access Protocol 146 (RDMA) and Direct Data Placement (DDP)" 148 o [RFC5046] "Internet Small Computer System Interface (iSCSI) 149 Extensions for Remote Direct Memory Access (RDMA)" 151 o [RFC5047] "DA: Datamover Architecture for the Internet Small 152 Computer System Interface (iSCSI)" 154 o [RFC5048] "Internet Small Computer System Interface (iSCSI) 155 Corrections and Clarifications" 157 [RFC3721] and [RFC5387] are not updated by this document, as their 158 usage of RFC 3723 does not encompass its IPsec requirements. 160 In addition, these updated requirements apply to the new 161 specifications for iSCSI ([I-D.ietf-storm-iscsi-cons]) and iSER ( 162 [I-D.ietf-storm-iser]). 164 2. ESP Requirements 166 RFC 3723 requires that implementations MUST support IPsec ESPv2 167 [RFC2406] in tunnel mode as part of IPsec v2 to provide security for 168 both control packets and data packets, and that when ESPv2 is 169 utilized, per-packet data origin authentication, integrity and replay 170 protection MUST be provided. 172 This document modifies RFC 3723 to require that implementations 173 SHOULD also support IPsec ESPv3 [RFC4303] in tunnel mode as part of 174 IPsec v3 to provide security for both control packets and data 175 packets; per-packet data origin authentication, integrity and replay 176 protection MUST be provided when ESPv3 is utilized. 178 In addition, at the high speeds at which IP storage protocols are 179 expected to operate, a single IPsec SA could rapidly cycle through 180 the ESP 32-bit sequence number space. In view of this, 181 implementations that are capable of operating at speeds of 1 gigabit/ 182 second or higher and that implements both IKEv2 [RFC5996] and ESPv3 183 [RFC4303] MUST also implement extended (64-bit) sequence numbers for 184 ESPv3 and SHOULD use ESPv3 extended sequence numbers for all security 185 associations that protect IP storage protocol connections. 187 2.1. Data Origin Authentication and Data Integrity Transforms 189 RFC 3723 requires that: 191 o HMAC-SHA1 MUST be implemented [RFC2404], and 193 o AES CBC MAC with XCBC extensions SHOULD be implemented [RFC3566]. 195 This document clarifies key sizes for the AES CBC MAC with XCBC 196 extensions; 128-bit AES keys MUST be supported, and other key sizes 197 MAY be supported. This document also adds a requirement for IPsec 198 v3: 200 o Implementations that support IKEv2 [RFC5996] SHOULD also implement 201 AES GMAC [RFC4543] with 128-bit AES keys; other AES key sizes MAY 202 be supported. 204 The rationale for the added requirement is that GMAC is more amenable 205 to hardware implementations that may be preferable for the high data 206 rates at which IP storage protocols can be expected to operate. 208 2.2. Confidentiality Transform Requirements 210 RFC 3723 requires that: 212 o 3DES in CBC mode [RFC2451], [triple-des-spec] MUST be supported, 213 and 215 o AES in Counter mode [RFC3686], SHOULD be supported. 217 The 3DES-CBC requirement matched the basic encryption 218 interoperability requirement for IPsec v2. At the time of RFC 3723's 219 publication, AES Counter mode was the encryption transform that was 220 most amenable to hardware implementation, as hardware implementation 221 may be preferable for the high data rates at which IP storage 222 protocols can be expected to operate. 224 This document changes both of these requirements based on 225 cryptographic developments since the publication of RFC 3723. The 226 requirement for 3DES CBC has become problematic due to 3DES's 64 bit 227 block size, i.e., the core cipher encrypts or decrypts 64 bits at a 228 time. Security weaknesses in encryption start to appear as the 229 amount of data encrypted under a single key approaches the birthday 230 bound of 32GB (gigabytes) for a cipher with a 64-bit block size 231 [triple-des-birthday]. It is prudent to rekey well before that bound 232 is reached, and 32GB or some significant fraction thereof is less 233 than the amount of data that an IP Storage protocol may transfer in a 234 single session. This may entail rather frequent rekeying, e.g., to 235 obtain an order of magnitude (10x) safety margin by rekeying after 236 3GB on a multi-gigabit/sec link. In contrast, AES has a 128 bit 237 block size, which results in an astronomical birthdaya bound (2^69 238 bytes). AES CBC is the primary mandatory-to-implement cryptographic 239 transform for interoperability, and hence is the appropriate 240 replacement for 3DES CBC. 242 AES Counter mode is no longer the encryption transform that is most 243 amenable to hardware implementation. That characterization now 244 applies to AES Galois Counter Mode (GCM) [RFC4106], which provides 245 both encryption and integrity protection in a single cryptographic 246 mechanism (in contrast, neither of the RFC 3723 integrity transforms 247 are well suited for hardware implementation, as they do not pipeline 248 well). AES GCM is also capable of providing confidentiality 249 protection for the IKEv2 key exchange protocol, but not the IKEv1 250 protocol [RFC5282], and therefore the new AES GCM "SHOULD" 251 requirement is based on presence of support for IKEv2. 253 For the reasons described in the preceding paragraphs, the 254 confidentiality transform requirements in RFC 3723 are replaced by 255 the following: 257 o 3DES in CBC mode MAY be implemented, 259 o AES in Counter mode MAY be implemented, 261 o AES in CBC mode MUST be implemented with 128-bit keys; other key 262 sizes MAY be supported, and 264 o Implementations that support IKEv2 SHOULD also implement AES GCM 265 with 128-bit keys; other key sizes may be supported. 267 In addition, NULL encryption [RFC2410] MUST be implemented to enable 268 use of SAs that provide data origin authentication and data 269 integrity, but not confidentiality. Other transforms MAY be 270 implemented in addition to those listed above. 272 3. IKEv1 and IKEv2 Requirements 274 Note: to avoid ambiguity, the original IKE protocol [RFC2409] is 275 referred to as "IKEv1" in this document. 277 This document adds requirements for IKEv2 usage with IP Storage 278 protocols and makes the following two changes to the IKEv1 279 requirements in RFC 3723: 281 o When DH groups are used, a DH group of at least 2048 bits SHOULD 282 be offered as a part of all proposals to create IPsec Security 283 Associations. Use of 1024 bit DH groups with 3DES CBC and HMAC- 284 SHA1 is no longer recommended. 286 o The requirement to use UDP port 500 is removed in order to allow 287 NAT traversal [RFC3947]. 289 There are no other changes to RFC 3723's IKEv1 requirements, but many 290 of them are restated in this document in order to provide context for 291 the new IKEv2 requirements. 293 RFC 3723 requires that IKEv1 [RFC2409] be supported for peer 294 authentication, negotiation of security associations, and key 295 management, using the IPsec DOI [RFC2407], and further requires that 296 manual keying not be used since it does not provide the rekeying 297 support necessary for operation at high data rates. This document 298 adds a requirement that IKEv2 [RFC5996] SHOULD be supported for peer 299 authentication, negotiation of security associations, and key 300 management. The manual keying prohibition in RFC 3723 is extended to 301 IKEv2; manual keying MUST NOT be used with any version of IPsec for 302 use with IP storage protocols. 304 RFC 3723's requirements for IKEv1 mode implementation and usage are 305 unchanged; this document does not extend those requirements to IKEv2 306 because IKEv2 does not have modes. 308 When IPsec is used, the receipt of an IKEv1 Phase 2 delete message or 309 an IKEv2 INFORMATIONAL exchange that deletes the SA SHOULD NOT be 310 interpreted as a reason for tearing down the IP storage connection 311 (e.g., TCP-based). If additional traffic is sent, a new SA will be 312 created to protect that traffic. 314 The method used to determine whether an IP storage protocol 315 connection should be established using IPsec is regarded as an issue 316 of IPsec policy administration, and thus is not defined in this 317 document. The method used by an implementation that supports both 318 IPsec v2 and v3 to determine which versions of IPsec are supported by 319 the an IP storage peer is also regarded as an issue of IPsec policy 320 administration, and thus is also not defined in this document. If 321 both IPsec v2 and v3 are supported by both endpoints of an IP storage 322 connection, use of IPsec v3 is recommended. 324 3.1. Authentication Requirements 326 The authentication requirements for IKEv1 are unchanged by this 327 document, but are restated here for context along with the 328 authentication requirements for IKEv2: 330 a. Peer authentication using a pre-shared cryptographic key MUST be 331 supported. Certificate-based peer authentication using digital 332 signatures MAY be supported. For IKEv1 ([RFC2409]), peer 333 authentication using the public key encryption methods outlined 334 in sections 5.2 and 5.3 of [RFC2409] SHOULD NOT be used. 336 b. When digital signatures are used for authentication, all IKEv1 337 and IKEv2 negotiators SHOULD use Certificate Request Payload(s) 338 to specify the certificate authority, and SHOULD check the 339 pertinent Certificate Revocation List (CRL) before accepting a 340 PKI certificate for use in authentication. 342 c. IKEv1 implementations MUST support Main Mode and SHOULD support 343 Aggressive Mode. Main Mode with pre-shared key authentication 344 method SHOULD NOT be used when either the initiator or the target 345 uses dynamically assigned IP addresses. While in many cases pre- 346 shared keys offer good security, situations in which dynamically 347 assigned addresses are used force the use of a group pre-shared 348 key, which creates vulnerability to a man-in-the-middle attack. 349 These requirements do not apply to IKEv2 because it has no modes. 351 d. In the IKEv1 Phase 2 Quick Mode, exchanges for creating the Phase 352 2 SA, the Identification Payload MUST be present. This 353 requirement does not apply to IKEv2 because it has no modes. 355 e. The following identification type requirements apply to IKEv1. 356 ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6) 357 and ID_FQDN Identification Types MUST be supported; ID_USER_FQDN 358 SHOULD be supported. The IP Subnet, IP Address Range, 359 ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types SHOULD 360 NOT be used. The ID_KEY_ID Identification Type MUST NOT be used. 362 f. If IKEv2 is supported, the following identification requirements 363 apply. ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack 364 supports IPv6) and ID_FQDN Identification Types MUST be 365 supported; ID_RFC822_ADDR SHOULD be supported. The 366 ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Types SHOULD 367 NOT be used. The ID_KEY_ID Identification Type MUST NOT be used. 369 The reasons for the identification requirements in items e and f 370 above are: 372 o IP Subnet and IP Address Range are too broad to usefully identify 373 an iSCSI endpoint. 375 o The _DN and _GN types are X.500 identities; it is usually better 376 to use an identity from subjectAltName in a PKI certificate. 378 o ID_KEY_ID is an opaque identifier that is not interoperable among 379 different IPsec implementations as specified. Heterogeneity in 380 some IP storage implementations can be expected (e.g., iSCSI 381 initiator vs. iSCSI target implementations), and hence 382 heterogeneity among IPsec implementations for IP storage is 383 important. 385 3.2. D-H Group and PRF Requirements 387 This document does not change the support requirements for Diffe- 388 Hellman (D-H) groups and Pseudo-Random Functions (PRFs). See 389 [RFC4109] for IKEv1 requirements and [RFC4307] for IKEv2 390 requirements. Implementors are advised to check for subsequent RFCs 391 that update either of these RFCs, as such updates may change these 392 requirements. 394 When DH groups are used, a DH group of at least 2048 bits SHOULD be 395 offered as a part of all proposals to create IPsec Security 396 Associations for both IKEv1 and IKEv2. 398 RFC 3723 requires that that the IKEv1 Quick Mode key exchange that 399 provides perfect forward secrecy MUST be implemented. This document 400 extends that requirement to IKEv2; the CREATE_CHILD_SA key exchange 401 that provides perfect forward secrecy MUST be implemented for use of 402 IPsec with IP Storage protocols. 404 4. IANA Considerations 406 This document includes no request to IANA. 408 5. Security Considerations 410 This entire document is about security. 412 6. References 414 6.1. Normative References 416 [I-D.ietf-storm-iscsi-cons] 417 Chadalapaka, M., Satran, J., Meth, K., and D. Black, 418 "iSCSI Protocol (Consolidated)", draft-ietf-storm-iscsi- 419 cons-08 (work in progress), January 2013. 421 [I-D.ietf-storm-iser] 422 Ko, M. and A. Nezhinsky, "iSCSI Extensions for RDMA 423 Specification", draft-ietf-storm-iser-14 (work in 424 progress), June 2013. 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 430 Internet Protocol", RFC 2401, November 1998. 432 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 433 ESP and AH", RFC 2404, November 1998. 435 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 436 Payload (ESP)", RFC 2406, November 1998. 438 [RFC2407] Piper, D., "The Internet IP Security Domain of 439 Interpretation for ISAKMP", RFC 2407, November 1998. 441 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 442 (IKE)", RFC 2409, November 1998. 444 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 445 Its Use With IPsec", RFC 2410, November 1998. 447 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 448 Algorithms", RFC 2451, November 1998. 450 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 451 and Its Use With IPsec", RFC 3566, September 2003. 453 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 454 Counter Mode With IPsec Encapsulating Security Payload 455 (ESP)", RFC 3686, January 2004. 457 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., 458 and E. Zeidner, "Internet Small Computer Systems Interface 459 (iSCSI)", RFC 3720, April 2004. 461 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. 462 Travostino, "Securing Block Storage Protocols over IP", 463 RFC 3723, April 2004. 465 [RFC3821] Rajagopal, M., Rodriguez, E., and R. Weber, "Fibre Channel 466 Over TCP/IP (FCIP)", RFC 3821, July 2004. 468 [RFC3822] Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) 469 Entities Using Service Location Protocol version 2 470 (SLPv2)", RFC 3822, July 2004. 472 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 473 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 474 January 2005. 476 [RFC4018] Bakke, M., Hufferd, J., Voruganti, K., Krueger, M., and T. 477 Sperry, "Finding Internet Small Computer Systems Interface 478 (iSCSI) Targets and Name Servers by Using Service Location 479 Protocol version 2 (SLPv2)", RFC 4018, April 2005. 481 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 482 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 483 4106, June 2005. 485 [RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version 486 1 (IKEv1)", RFC 4109, May 2005. 488 [RFC4172] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and 489 M. Edwards, "iFCP - A Protocol for Internet Fibre Channel 490 Storage Networking", RFC 4172, September 2005. 492 [RFC4173] Sarkar, P., Missimer, D., and C. Sapuntzakis, 493 "Bootstrapping Clients using the Internet Small Computer 494 System Interface (iSCSI) Protocol", RFC 4173, September 495 2005. 497 [RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic 498 Host Configuration Protocol (DHCP) Option for the Internet 499 Storage Name Service", RFC 4174, September 2005. 501 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 502 Internet Protocol", RFC 4301, December 2005. 504 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 505 4303, December 2005. 507 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 508 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 509 December 2005. 511 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 512 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 513 May 2006. 515 [RFC5040] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. 516 Garcia, "A Remote Direct Memory Access Protocol 517 Specification", RFC 5040, October 2007. 519 [RFC5041] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct 520 Data Placement over Reliable Transports", RFC 5041, 521 October 2007. 523 [RFC5042] Pinkerton, J. and E. Deleganes, "Direct Data Placement 524 Protocol (DDP) / Remote Direct Memory Access Protocol 525 (RDMAP) Security", RFC 5042, October 2007. 527 [RFC5043] Bestler, C. and R. Stewart, "Stream Control Transmission 528 Protocol (SCTP) Direct Data Placement (DDP) Adaptation", 529 RFC 5043, October 2007. 531 [RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. 532 Carrier, "Marker PDU Aligned Framing for TCP 533 Specification", RFC 5044, October 2007. 535 [RFC5048] Chadalapaka, M., "Internet Small Computer System Interface 536 (iSCSI) Corrections and Clarifications", RFC 5048, October 537 2007. 539 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 540 Algorithms with the Encrypted Payload of the Internet Key 541 Exchange version 2 (IKEv2) Protocol", RFC 5282, August 542 2008. 544 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 545 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 546 5996, September 2010. 548 [triple-des-birthday] 549 McGrew, D., "Impossible plaintext cryptanalysis and 550 probable-plaintext collision attacks of 64-bit block 551 cipher modes (Cryptology ePrint Archive: Report 2012/ 552 623)", November 2012, . 554 [triple-des-spec] 555 American Bankers Association, ., "American National 556 Standard for Financial Services X9.52-1998 - Triple Data 557 Encryption Algorithm Modes of Operation", July 1998. 559 6.2. Informative References 561 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. 562 Krueger, "Internet Small Computer Systems Interface 563 (iSCSI) Naming and Discovery", RFC 3721, April 2004. 565 [RFC5045] Bestler, C. and L. Coene, "Applicability of Remote Direct 566 Memory Access Protocol (RDMA) and Direct Data Placement 567 (DDP)", RFC 5045, October 2007. 569 [RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., 570 and P. Thaler, "Internet Small Computer System Interface 571 (iSCSI) Extensions for Remote Direct Memory Access 572 (RDMA)", RFC 5046, October 2007. 574 [RFC5047] Chadalapaka, M., Hufferd, J., Satran, J., and H. Shah, 575 "DA: Datamover Architecture for the Internet Small 576 Computer System Interface (iSCSI)", RFC 5047, October 577 2007. 579 [RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and 580 Applicability Statement for Better-Than-Nothing Security 581 (BTNS)", RFC 5387, November 2008. 583 Appendix A. Contributors 585 The original authors of RFC 3723 were: Bernard Aboba, Joshua Tseng, 586 Jesse Walker, Venkat Rangan and Franco Travostino. Comments from 587 Yaron Sheffer have improved this document and are gratefully 588 acknowledged. 590 Appendix B. Change Log 592 This section should be removed before this document is published as 593 an RFC 595 Changes from -00 to -01: 597 o Make it clearer that RFC 3723's encryption transform 598 implementation requirements are being changed. 600 o State that D-H group and PRF implementation requirements are 601 unchanged and provide references to RFCs where they can be found 602 (new section 3.2). 604 o Add requirements for perfect forward secrecy implementation (also 605 in 3.2). 607 o Use the correct GMAC reference. 609 o Many other editorial changes. 611 Authors' Addresses 612 David Black 613 EMC 614 176 South Street 615 Hopkinton, MA 01748 616 US 618 Phone: +1 508 293-7953 619 Email: david.black@emc.com 621 Paul Koning 622 Dell 623 300 Innovative Way 624 Nashua, NH 03062 625 US 627 Phone: +1 603 249-7703 628 Email: paul_koning@Dell.com