idnits 2.17.00 (12 Aug 2021) /tmp/idnits19247/draft-black-ips-iscsi-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC-2945], [RFC-2119], [RFC-2406]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ISCSI-IPSEC' is mentioned on line 107, but not defined == Missing Reference: 'RFC 2663' is mentioned on line 636, but not defined == Unused Reference: 'RFC-2663' is defined on line 820, but no explicit reference was found in the text == Outdated reference: draft-ietf-ips-iscsi has been published as RFC 3720 == Outdated reference: draft-ietf-ips-iscsi-name-disc has been published as RFC 3721 ** Downref: Normative reference to an Informational draft: draft-ietf-ips-iscsi-name-disc (ref. 'ISCSI-NAME-DISC') == Outdated reference: draft-ietf-ips-iscsi-reqmts has been published as RFC 3347 == Outdated reference: draft-ietf-l2tpext-security has been published as RFC 3193 == Outdated reference: draft-ietf-ipsec-nat-reqts has been published as RFC 3715 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-nat-reqts (ref. 'NAT-REQTS') ** Downref: Normative reference to an Informational RFC: RFC 2104 ** 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 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2663 Summary: 16 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Storage WG D. Black, EMC 3 Internet Draft 4 Document: draft-black-ips-iscsi-security-01.txt August, 2001 6 iSCSI Security Requirements and SRP-based ESP Keys 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. Internet-Drafts are working documents of 12 the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet-Drafts as 19 reference material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/1id-abstracts.html 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html 27 Discussion and suggestions for improvement are requested. This 28 draft will expire before February 2002. Distribution of this draft 29 is unlimited. 31 Abstract 33 This draft describes security requirements, status of security 34 specification, operating environment characteristics, and related 35 considerations for iSCSI. It also outlines an SRP-based [RFC-2945] 36 mechanism to derive ESP [RFC-2406] keying material and associated 37 rekeying mechanisms. These topics are combined in this draft for 38 convenience; the security requirements, status and operating 39 environment are generic to iSCSI, whereas the use of SRP to obtain 40 ESP keys is an independent proposal and is not the only way to meet 41 iSCSI's security requirements. The keying description focuses on 42 the overall approach and structure, further details will be added if 43 this proposal is pursued. 45 This draft is unlikely to become an RFC in its current form; its 46 primary purpose is to capture a set of ideas as a basis for further 47 discussions. Portions of this draft may be incorporated into other 48 drafts that are intended to become RFCs. Caution should be 49 exercised in drawing inferences from the fact that the author of 50 this draft is one of the chairs of the IP Storage WG. This draft is 51 an individual submission that the IP Storage WG is free to adopt, 52 modify, reject, fold, spindle, and/or mutilate as it sees fit. 54 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 60 this document are to be interpreted as described in [RFC-2119]. 62 Table of Contents 64 1. Context and Purposes............................................2 65 2. iSCSI Overview..................................................3 66 3. Approach to Security Specification..............................3 67 4. Security Functionality Requirements.............................4 68 4.1 Negotiation of Security Functionality..........................4 69 4.2 Authentication.................................................4 70 4.2.1 Multiple Authentication Considerations.......................5 71 4.3 Cryptographic Integrity and Data Origin Authentication.........5 72 4.4 Confidentiality................................................6 73 4.5 Rekeying.......................................................6 74 5. iSCSI Implementation Characterization...........................6 75 5.1 Implementation Classes and Resource Availability...............6 76 5.2 Implementation Scaling.........................................7 77 5.3 Other Implementation Environment Concerns......................8 78 6. SRP Keying of ESP...............................................9 79 6.1 Overall structure..............................................9 80 6.2 Negotiation...................................................10 81 6.3 Key Derivation................................................11 82 6.4 ESP Startup...................................................11 83 6.5 Rekeying......................................................13 84 6.5.1 Rekeying Mechanism 1: No New Key Exchange...................14 85 6.5.2 Rekeying Mechanism 2: New Key Exchange......................14 86 7. Security Considerations........................................14 87 8. Changes from û00 Version.......................................14 88 9. References.....................................................15 89 10. Acknowledgments...............................................16 90 11. Author's Address..............................................16 92 1. Context and Purposes 94 As specification of iSCSI security mechanisms progresses, it seems 95 useful to gather security requirements and reasonable security- 96 relevant assumptions about iSCSI operating environments in an 97 accessible form; that is the purpose of Sections 2 through 5 of this 98 draft. The IP Storage WG has recently completed work on iSCSI 99 requirements [ISCSI-REQTS], which should be consulted for further 100 information on iSCSI requirements in other areas. Section 6 of this 101 draft describes an SRP-based mechanism for keying ESP based on 102 concepts discussed at the IP Storage WG's Nashua interim meeting 103 (April 30 and May 1, 2001). Section 6 is included in this draft 104 primarily for convenience and to ensure that these ideas are not 105 lost. While this mechanism appears to satisfy iSCSI's security 106 requirements, it is not the only mechanism that satisfies them; IKE 107 is another possibility, see [ISCSI-IPSEC]. 109 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 111 As is the case for all Internet-Drafts, the contents of this draft 112 are subject to discussion and revision. All material in this draft 113 concerning status or content of specification efforts in the IP 114 Storage WG is as of mid-August 2001 as understood by the author. It 115 is hoped that this closely approximates reality, but no absolute 116 assurances can be offered, and all WG decisions are potentially 117 subject to change as work on the iSCSI specification(s) moves 118 forward. 120 2. iSCSI Overview 122 iSCSI [ISCSI] is a TCP/IP encapsulation of the SCSI protocols used 123 to access disk, tape and other devices. iSCSI is a client-server 124 protocol in which clients (Initiators) open connections to servers 125 (Targets). This draft uses the SCSI terms Initiator and Target for 126 clarity and to avoid the common assumption that clients have 127 considerably less computational and memory resources than servers; 128 the reverse is often the case for SCSI, as Targets are commonly 129 dedicated devices of some form. 131 iSCSI Initiators and Targets are layer 5 entities that are 132 independent of TCP ports and IP addresses. An Initiator or Target 133 may use multiple communication endpoints ( 134 pair), and such endpoints may be shared by multiple Initiators or 135 Targets. The common case for sharing will be that the sharing 136 entities are all of the same type (i.e., all Initiators or all 137 Targets). iSCSI entities have names that are independent of 138 communication endpoints, and iSCSI defines its own naming syntax for 139 such entities (i.e., Initiators and Targets), see [ISCSI-NAME-DISC]. 141 The iSCSI protocol has a text based negotiation mechanism as part of 142 its initial (Login) procedure. The mechanism is extensible in what 143 can be negotiated (new text keys and values can be defined) and also 144 in the number of negotiation rounds (e.g., to accommodate 145 functionality such as challenge-response authentication). 147 3. Approach to Security Specification 149 The IP Storage WG is currently pursuing an approach of selecting 150 subsets of IETF security specifications for iSCSI. This requires 151 that good engineering judgement be used and that the result be sound 152 from a security standpoint. Motivations for this subset selection 153 approach include: 155 - Avoiding specification of requirements that have little current 156 justification, (e.g., AH). 157 - Matching the chosen subset more closely to iSCSI's security 158 requirements (e.g., iSCSI does not require both transport and 159 tunnel mode IPsec encapsulation). 160 - Matching implementation requirements more closely to iSCSI's 161 expected operating environments, particularly resource-limited 162 embedded systems. 164 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 166 In addition to the above examples, this approach may be applicable 167 to areas such as IKE/ISAKMP [RFC-2407, RFC-2408, RFC-2409] (e.g., 168 subset of IKE modes and ISAKMP-negotiable items/values) and ESP 169 algorithms (e.g., believe it or not, DES is still REQUIRED by ESP in 170 Section 5 of [RFC-2406]). 172 4. Security Functionality Requirements 174 This section summarizes iSCSI security requirements and status. 176 4.1 Negotiation of Security Functionality 178 The current status is that iSCSI's negotiation mechanism is capable 179 of negotiating away any and all security functionality in 180 environments where it is not needed (as determined by local policy). 181 For example, a security administrator could determine that a 182 physically isolated and physically secure network used only for 183 iSCSI requires no additional iSCSI security beyond authentication. 184 Another example is that a security administrator could determine 185 that operation of iSCSI over a secure VPN requires no security 186 beyond authentication because the VPN provides adequate defense 187 against the relevant classes of threats. 189 Two caveats apply to the previous paragraph: 190 - Both of the examples above use authentication. Use of 191 authentication should be RECOMMENDED by the iSCSI specification. 192 - The acronym SAN has sometimes been used to refer to environments 193 in which iSCSI requires less security than is needed on a public 194 network. Such usage is misleading, as it incorrectly implies that 195 SANs have little to no need for communication protocol security. 197 ISCSI's inband negotiation mechanism has no intrinsic security 198 because it is performed in the clear as far as iSCSI is concerned. 199 If such a negotiation is conducted over an otherwise unsecured 200 connection, man-in-the-middle attacks on security negotiation have 201 to be considered. The usual admonition to not offer security 202 mechanisms that are weaker than acceptable applies. 204 4.2 Authentication 206 Bi-directional authentication (Initiator to Target) and vice-versa 207 is REQUIRED. This authentication is logically between the iSCSI 208 Initiator and the iSCSI Target (as opposed to between the TCP/IP 209 communication endpoints). There is no requirement that the 210 identities used in authentication be kept confidential (e.g., from a 211 passive eavesdropper). The intent of the iSCSI design is that the 212 Initiator and Target represent the systems (e.g., host and disk 213 array or tape system) participating in the communication, as opposed 214 to network communication interfaces or endpoints. 216 The current status is that the Secure Remote Password protocol 218 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 220 (SRP) [RFC-2945] will be REQUIRED of all implementations based on 221 iSCSIÆs text-based multi-round negotiation mechanism noted above. A 222 number of additional authentication protocols have also been 223 specified in the current iSCSI draft. Negotiation between Initiator 224 and Target is used to determine which authentication algorithm to 225 use (or whether to use one at all); the connection closes if either 226 side requires authentication and no mutually acceptable algorithm 227 can be agreed upon. 229 4.2.1 Multiple Authentication Considerations 231 If a secure communication channel (e.g., an IPsec Security 232 Association) is used below iSCSI, authentication may occur both in 233 setting up that channel and as part of iSCSI login. If these 234 authentications employ different identities, the security properties 235 of the channel may not be constrained to the iSCSI authenticated 236 identity (e.g., it may be possible for multiple iSCSI sessions with 237 different authentication identities to use the same IPsec Security 238 Association). This is particularly true when a machine identity is 239 used for IPsec authentication, but a user identity is used for iSCSI 240 authentication (the user identity may be that of some application 241 rather than an actual human user). An analogous situation 242 arises in the interaction of PPP and IPsec authentication when IPsec 243 provides a secure communication channel for PPP encapsulated in 244 L2TP, and most of the discussion of in see Section 5.1.1 of [L2TP- 245 SECURITY] is applicable to this iSCSI situation, as it involves a 246 mix of user authentication (PPP) and machine authentication (IPsec). 248 Any multiple authentication approach for iSCSI MUST include some 249 means of checking that the identities used in the two 250 authentications for each connection correspond in some acceptable 251 fashion, and these checks MUST be automatic because they may occur 252 as part of a system boot procedure. A possible means of supporting 253 such checks is to include both identities and communication 254 endpoints as part of iSCSI access control and discovery information 255 provided that the mechanisms for distributing and/or configuring 256 such information are suitably secured. 258 4.3 Cryptographic Integrity and Data Origin Authentication 260 Cryptographic integrity of all iSCSI communications after the login 261 phase must be implemented, and this integrity mechanism MUST be 262 keyed to provide data origin authentication for all received data. 263 The key MUST be derived from or otherwise securely linked to the 264 appropriate authentication; among the purposes of this is to prevent 265 a TCP hijack attack from succeeding because the hijacker does not 266 know the key required to generate the correct cryptographic 267 integrity checks. This is a significantly stronger integrity 268 requirement than the usual data integrity requirements for storage 269 traffic; the integrity check MUST resist malicious tampering, and 270 MUST be authenticated in a fashion that prevents an adversary from 271 regenerating it. For example, an XOR-keyed CRC (CRC xor key) is not 273 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 275 a sufficient check because it has inadequate strength to resist 276 tampering. An adversary who does not know the key can easily 277 determine which bits to flip in a keyed CRC to offset bits flipped 278 in the data covered by the CRC. Use of a cryptographic integrity 279 mechanism in iSCSI is negotiable - see Section 4.1. 281 The current status is that ESP [RFC-2406] with NULL encryption has 282 been chosen as the implementation approach to meet this requirement, 283 but the Authentication Algorithm (MAC, e.g., HMAC-SHA1) has not been 284 selected. While iSCSI is clearly a "host" rather than a "security 285 gateway" (see Section 3 of [RFC-2401]), ESP is likely to be used 286 only in tunnel mode for reasons that include: 288 (1) Only one IPsec encapsulation mode (transport or tunnel) is 289 needed by a protocol like iSCSI. 290 (2) Tunnel mode better accommodates NATs because the encapsulated IP 291 and TCP checksums are correct in tunnel mode, whereas they are 292 incorrect in transport mode. See [NAT-REQTS] for details. 293 (3) Tunnel mode may allow the use of external IPsec gateways and 294 related implementation structures, transport mode does not. 296 This is an example of the subset approach to security specification 297 discussed in Section 3. 299 4.4 Confidentiality 301 A confidentiality mechanism MUST be implemented, but any such 302 mechanism is OPTIONAL to use. The current status is also that ESP 303 has been chosen as the implementation approach, but no preferred ESP 304 transform (i.e., encryption algorithm) has been selected. 306 4.5 Rekeying 308 A manual keying mechanism uses a pre-configured key without key 309 exchanges or rekeying. This is insufficient because iSCSI will 310 support long-lived connections that exchange enough traffic to cause 311 ESP's 32-bit sequence number to rollover, exposing the connection to 312 replay attacks. Other considerations may dictate or recommend 313 rekeying considerably earlier than required solely to avoid rollover 314 (e.g., to limit the amount of data encrypted or signed with the same 315 session key). For these reasons, an interoperable automatic 316 rekeying mechanism MUST be specified as part of iSCSI and will be 317 REQUIRED of all conforming implementations. 319 5. iSCSI Implementation Characterization 321 5.1 Implementation Classes and Resource Availability 323 iSCSI will be implemented on a variety of systems ranging from large 324 servers running general purpose operating systems to embedded host 325 bus adapters (HBAs). Host Bus Adapter is a generic term for a SCSI 326 interface to other device(s); it's roughly analogous to the term 328 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 330 Network Interface Card (NIC) for a TCP/IP network interface, except 331 that HBAs generally have on-board SCSI implementations, whereas most 332 NICs do not implement TCP, UDP, or IP. In general, a host bus 333 adapter is the most constrained iSCSI implementation environment, 334 although an HBA may draw upon the resources of the system to which 335 it is attached in some cases (e.g., authentication computations 336 required for connection setup). More resources should be available 337 to iSCSI implementations for embedded and general purpose operating 338 systems. The following guidelines indicate the approximate level of 339 resources that authentication, keying, and rekeying functionality 340 can reasonably expect to draw upon: 342 - Low power processors with small word size are generally not used, 343 as power is usually not a constraining factor, with the possible 344 exception of HBAs, which can draw upon the computational resources 345 of the system into which they are inserted). Computational 346 horsepower should be available to perform a reasonable amount of 347 exponentiation as part of authentication and key derivation for 348 connection setup. The same is true of rekeying, although the 349 ability to avoid exponentiation for rekeying may be desirable (but 350 is not an absolute requirement). 352 - RAM and/or flash resources tend to be constrained in embedded 353 implementations. 8-10 MB of code and data for authentication, 354 keying, and rekeying is clearly excessive, 800-1000 KB is clearly 355 larger than desirable, but tolerable if there is no other 356 alternative and 80-100 KB should be acceptable. These sizes are 357 intended as rough order of magnitude guidance, and should not be 358 taken as hard targets or limits (e.g., smaller code sizes are 359 always better). Software implementations for general purpose 360 operating systems may have more leeway. 362 In summary, the primary resource concern for implementation of 363 authentication and keying mechanisms is code size, as iSCSI assumes 364 that the computational horsepower to do exponentiations (e.g., those 365 required by SRP) will be available (SRP implementation is currently 366 REQUIRED by iSCSI). 368 5.2 Implementation Scaling 370 There is no dominant iSCSI usage scenario - the scenarios range from 371 a single connection constrained only by media bandwidth to hundreds 372 of Initiator connections to a single Target or communication 373 endpoint. SCSI sessions and hence the connections they use tend to 374 be relatively long lived; for disk storage, a host typically opens a 375 SCSI connection on boot and closes it on shutdown. Tape session 376 length tends to be measured in hours or fractions thereof (i.e., 377 rapid fire sharing of the same tape device among different 378 Initiators is unusual), although tape robot control sessions can be 379 short when the robot is shared among tape drives. On the other 380 hand, tape will not see a large number of Initiator connections to a 381 single Target or communication endpoint, as each tape drive is 383 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 385 dedicated to a single use at a single time, and a dozen tape drives 386 is a large tape device. 388 Given current networking technology, security solutions must work 389 well at 1 Gbit/sec in terms of CPU overhead and/or availability of 390 suitable hardware implementations. Solutions that scale up to 10 391 Gbits/sec are desirable but are not an absolute requirement as there 392 are issues with a number of technologies at 10 Gbits/sec. This is 393 of particular concern for HMAC [RFC-2104], which is the basis for 394 the only MACs (cryptographic data integrity and data origin 395 authentication) currently standardized for use with ESP. HMAC 396 implementations are commercially available at 1 Gbit/sec (often 397 based on hardware assistance of some form), but HMAC's computational 398 structure and overhead raise serious concerns about scaling to 10 399 Gbits/sec. 401 5.3 Other Implementation Environment Concerns 403 This section gathers up several questions and answers on other iSCSI 404 implementation environment topics. 406 Q: Will IPsec generally be present on systems supporting iSCSI 407 due to other traffic requiring IPsec security? 408 A: No, especially for Targets, as they may have no important 409 functionality other than iSCSI. 411 Q: What are the persistence requirements for security state across 412 power off or loss of TCP connections? 413 A: Essentially none; most SCSI state does not survive power loss or 414 system crash events with a few exceptions such as persistent 415 reservations. Security state for open TCP connections need not 416 survive the loss of those connections; any new connection will 417 have to re-authenticate. 419 Q: What about load-balancing or fail-over middleboxes? 420 A: Discussions of iSCSI-aware middleboxes have usually assumed that 421 such boxes serve as an endpoint for the iSCSI sessions on both 422 sides of them. For example, this is why iSCSI specifies separate 423 CRCs for its header and data. The author has not seen any 424 major objections in the IP Storage WG to the fashion in which 425 IPsec can interact with such boxes (e.g., TCP header is 426 encrypted, making it impossible to classify traffic based on TCP 427 port number). 429 Q: What about NATs? 430 A: The IP Storage WG charter indicates that the ability to operate 431 through NATs is important, but not an absolute requirement. Work 432 is underway in the ipsec WG to specify transparent operation 433 through NATs via UDP encapsulation. 435 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 437 6. SRP Keying of ESP 439 This section describes a mechanism to provide keying material for 440 ESP based on SRP inband authentication for iSCSI. This is a single- 441 layer authentication approach that places all other security 442 mechanism (i.e., ESP) below TCP. ESP is linked to the SRP 443 authentication by deriving ESP's keys from the SRP authentication. 444 ESP's position below TCP causes TCP retransmission to be invoked 445 whenever ESP discards a packet due to a failed security check. If 446 the failed check is due to data corruption, the result is TCP 447 retransmission rather than an iSCSI or SCSI retry. This increases 448 the integrity assurance of data delivered by TCP based on the more 449 powerful integrity check in ESP MACs by comparison to TCP/IP 450 checksums. 452 This approach to ESP keying requires an interface between iSCSI and 453 the ESP implementation to transfer keying material from SRP to ESP; 454 such an interface may make use of external IPsec gateways with iSCSI 455 more difficult or impossible (e.g., software development may be 456 required to securely transfer keys and related configuration 457 information from iSCSI to the external IPsec gateway). 459 This section does not contain complete details; the major goal is to 460 show how this mechanism works to enable it to be evaluated for use 461 in iSCSI. The mechanism is currently described for SRP only, but 462 appears to be extensible to any iSCSI inband authentication approach 463 that provides good keying material. 465 6.1 Overall structure 467 The overall structure of this keying mechanism consists of the 468 following components: 470 - SRP inband iSCSI authentication (see [ISCSI]). 471 - iSCSI Negotiation of ESP SA parameters (Section 6.2) 472 - ESP session key derivation from SRP results (Section 6.3) 473 - ESP startup for an iSCSI TCP connection (Section 6.4) 474 - Rekeying (Section 6.5) 476 In summary, SRP is used as inband authentication for iSCSI, and 477 iSCSI negotiates additional parameters for ESP Security 478 Associations. Keys for these associations are derived from the 479 results of the SRP authentication and used to initiate ESP security 480 processing beneath an existing iSCSI TCP connection. The SAs used 481 for such processing are tightly bound to the corresponding TCP 482 connection and cannot be reused for other connections or traffic. 483 Rekeying is handled by one of two methods described in Section 6.5. 485 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 487 6.2 Negotiation 489 In addition to the SRP authentication conducted as part of iSCSI 490 negotiation, the following additional parameters need to be 491 negotiated by iSCSI: 493 - ESP authentication algorithm (MAC, e.g., HMAC-SHA-1) or "none" 494 - ESP encryption algorithm (e.g., AES) or "none" 495 - SPI value sets for both Initiator and Target 497 The scope of negotiation is a single TCP connection; every iSCSI TCP 498 connection that uses this keying mechanism MUST perform SRP 499 authentication and negotiate these parameters. The result will be 500 different ESP keys for each TCP connection. 502 iSCSI should limit the supported ESP encryption and authentication 503 algorithms to a small number that all implementations are REQUIRED 504 to support, except that implementations may choose not to support 505 any encryption algorithms. As indicated previously, these 506 algorithms have yet to be chosen as of the date this draft was 507 written. 509 The Initiator and Target independently announce SPI value ranges via 510 iSCSI negotiation. The Initiator tells the Target what SPI values 511 to apply to traffic sent to the Initiator, and the Target likewise 512 informs the Initiator what SPI values the Initiator to apply to 513 traffic sent to the Target. To avoid having to renegotiate SPI 514 values when rekeying, ranges of SPI values are announced. The two 515 Least Significant Bits of the announced SPI values MUST be zero; the 516 four SPI values obtained from all possible values for the two LSBs. 517 The initial SPI values used when ESP security processing is 518 initiated MUST have their two LSBs set to zero. Rekeying will cycle 519 through each set of four SPI values (see Section 6.5). A range of 520 four values is negotiated because two is too small for effective 521 rekey signaling (see section 6.5) and eight seems excessive. 523 This negotiation is completely in the clear, and hence is vulnerable 524 to man-in-the-middle tampering, but over a small number of 525 possibilities. A single negotiation may not be particularly 526 vulnerable to this tampering provided that care is taken in 527 configuring the minimum levels of security protection offered and 528 accepted (e.g., an Initiator who offers "none" for ESP 529 authentication and encryption algorithms deserves the absence of 530 security that may result). If this is insufficient, additional 531 measures may be needed, such as requiring the exchange of security 532 parameter offers and negotiated results (and/or hashes thereof) over 533 the secure channel after ESP security processing is initiated. 535 Negotiation retries with weaker security than initially offered are 536 dangerous and MUST NOT be performed. Consider an adversary who 537 changes the ESP authentication algorithm parameter to "none" on 538 iSCSI negotiation messages when neither party offered "none". If 540 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 542 both parties are prepared to offer and accept "none" on a 543 negotiation retry, the man-in-the-middle can cause "none" to be the 544 agreed value, even though it was not included in the initial 545 negotiation. 547 6.3 Key Derivation 549 The same session keys are used for traffic in both directions on a 550 single TCP connection used by iSCSI. In IPsec terminology this 551 means that the two Security Associations which carry the 552 connection's TCP traffic (one in each direction) share session keys. 554 SRP produces 320 bits of session keying material (K) as part of its 555 authentication. These 320 bits of material are the result of a 556 secure hash after the Diffie-Hellman exchange embedded in SRP. The 557 ESP keying material is then derived from K as follows: 559 (1) Set the 160 most significant bits of K aside as K_SAVE. This is 560 for use in rekeying. 562 (2) Apply the SHA_Interleave function from Section 3.1 of RFC 2945 563 to the 160 least significant bits of K to yield K2. 565 (3) The ESP encryption keying material is the 160 most significant 566 bits of K2, and the ESP authentication keying material is the 160 567 least significant bits of K2. Use of this keying material is 568 defined by the specifications for the encryption and authentication 569 algorithms; any algorithm requiring less than 160 bits of keying 570 material MUST use the most significant bits of the appropriate 571 keying material. 573 It's easy enough to generate different keying material for each SA 574 by following IKE's approach of incorporating the SPI value for each 575 direction into the hashes (see the definition of KEYMAT in section 576 5.5 of [RFC-2407]). At (2) above, the SPI for the SA would be 577 appended to the 160 least significant bits of K2 before applying 578 SHA_Interleave. The definition of SHA_Interleave generalizes to 579 arbitrary length inputs. The most obvious benefit of this is 580 lengthening rekeying intervals when rekeying is based on the amount 581 of data for which a key is used. The SPI values are publicly known, 582 but this is also the case for IKE and does not appear to cause a 583 security issue there. 585 6.4 ESP Startup 587 At the completion of security negotiation, all communication MUST 588 switch to using ESP with the negotiated algorithms, SPI numbers, and 589 associated keys. This means that all traffic sent by an Initiator 590 or Target after the iSCSI PDU containing SecurityContextComplete=Yes 591 must be processed by ESP. This switch MUST occur at the end of the 592 PDU containing this security completion indication. iSCSI requires 593 that both sides send the security completion indication before 595 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 597 switching into full feature mode; access to SCSI data can only occur 598 in full feature mode. 600 This approach of starting ESP processing during of an active 601 connection may raise security monitoring/enforcement and 602 implementation concerns. There is no meaningful security for 603 traffic prior to the point at which ESP processing is initiated as 604 described in the previous paragraph. Firewalls and network traffic 605 monitoring systems may have difficulty verifying that iSCSI switches 606 to use of ESP prior to entering full feature mode. Implementation 607 concerns have also been raised in that some IPsec implementations 608 may have difficulty in switching security processing from "off" to 609 "on" underneath an existing TCP connection. All of these concerns 610 are in need of further discussion, exploration and explanation. 612 There are at least three alternatives for initiating ESP security 613 processing of iSCSI traffic after negotiation: 615 (1) Just start ESP security processing under TCP as described in the 616 first paragraph of this section. Traffic on the wire changes 617 from "TCP in IP" to "TCP in IP in ESP in IP". The "TCP in IP" 618 portion may not be visible in the latter format if encryption is 619 in use. 621 (2) Encapsulate all traffic prior to the start of security 622 processing in tunnel mode ESP, but use an SPI value of zero 623 and omit the authentication data prior to the start of ESP 624 security processing. 626 (3) Employ a specified universal SPI value, universal key and 627 universal authentication algorithm for use prior to starting 628 security processing. All traffic on any iSCSI connection will 629 be authenticated with this key and algorithm prior to initiation 630 of ESP security processing. 632 Alternative (1) is an honest reflection of what is actually 633 happening. It is also the best fit with iSCSI's ability to 634 negotiate "none" for both ESP security algorithms (in which case ESP 635 is not used). On the other hand, it does not work through Network 636 Address Port Translation (see Section 4.1.2 of [RFC 2663]) because 637 adding ESP disables the port translation in the network without 638 providing sufficient information to the destination to enable it to 639 be reconstructed (i.e., the TCP port number will change as part of 640 the change from ôTCP in IPö to ôTCP in ESP in IPö. Alternative (2) 641 is not consistent with [RFC-2406] because it amounts to ESP with 642 NULL authentication and NULL encryption prior to initiation of 643 security processing. Alternative (3) provides a potentially false 644 indication of security, as any serious adversary can be assumed to 645 know the universal key, but it may provide some protection against 646 less capable adversaries. 648 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 650 If this SRP/ESP keying mechanism is employed, one of the above 651 choices must be selected and REQUIRED for all iSCSI TCP connections. 653 6.5 Rekeying 655 Rekeying only needs to provide new keys; it is not necessary to 656 renegotiate any SA parameters in order to rekey. The Initiator or 657 Target may initiate rekeying, and the results are applied to the h 658 ESP SAs in both directions. This avoids negotiating key lifetimes 659 (both initially and as part of rekeying), as either party to a 660 connection can initiate rekeying when it determines that a key needs 661 to be replaced. Section 6.2 describes the means used to negotiate a 662 range of four SPI values in each direction; rekeying causes the two 663 least significant bits of the SPI value in each direction to be 664 incremented, modulo 4 (i.e., incrementing 11 yields 00). 666 A range of four SPI values in each direction is negotiated to avoid 667 confusion that could occur if only two values were negotiated. ESP 668 may receive reordered IP packets, causing a packet with an 669 unincremented SPI value to arrive after packets with incremented SPI 670 values, even though the unincremented packet was sent first. If 671 only two SPI values are available in each direction, it's not 672 possible to determine a priori whether such a packet is a rekeying 673 signal and needs to be processed with new keys versus a packet prior 674 to the last rekeying event that needs to be processed with old keys. 675 This is primarily a performance issue as there is only one correct 676 set of keys for any packet. A range of four SPI values eliminates 677 this confusion, and specifying sufficient minimum rekeying intervals 678 should eliminate any need for larger ranges. 680 Rekeying MUST NOT be initiated until the initiating party receives 681 confirmation that the other party has completed any previous 682 rekeying event (i.e., packets arrive with the SPI value from that 683 rekeying event and are verified to have been processed with the 684 associated keys). Spurious rekeying is prevented by checking that 685 an inbound IP packet is correctly processed with the corresponding 686 keys before initiating rekeying in response to its reception. If 687 ESP authentication is in use, the Authentication Data in the ESP 688 trailer (see [RFC-2406]) MUST be verified before initiating 689 rekeying. If only Encryption is in use, the Next Header, Pad Length 690 and Padding fields in the ESP trailer (see [RFC-2406]) MUST be 691 verified before initiating rekeying. Receipt of stale packets based 692 on keys from a prior use of an SPI value will not pass these tests, 693 and hence will not cause spurious rekeying. 695 Two different rekeying mechanisms are proposed depending on whether 696 a new key exchange is desired to decouple the new session keys from 697 past keying material. Minimum time and/or amount of data 698 transmitted between rekeying events SHOULD be specified to avoid 699 excessive rekeying, and these times should be sufficient so that at 700 the time of rekeying event N+1, no packets with keys from event N-1 701 are expected to be alive in the network. The initial SRP 703 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 705 authentication on an iSCSI TCP connection is considered to be 706 rekeying event 0, and hence the minimum rekeying specifications 707 apply to the time and/or amount of data until the first rekeying 708 event. If this keying mechanism is employed, further discussion 709 will be needed to decide whether to specify one or both rekeying 710 mechanisms. Specifying both mechanisms will entail also specifying 711 a means of preventing the Initiator and Target from concurrently 712 initiating both rekeying mechanisms. For this reason, it may be 713 better to only specify one rekeying mechanism. 715 6.5.1 Rekeying Mechanism 1: No New Key Exchange 717 The new keying material is obtained by applying SHA_Interleave to 718 the keying material K_SAVE saved by step (1) in Section 6.3, and 719 using the resulting 320 bit value as the input to steps (1) to (3) 720 in Section 6.3 to yield new keying material and a new K_SAVE. 721 Either communicating party may initiate rekeying by calculating new 722 keys, incrementing the two least significant bits of the SPI value 723 used to send data (increment of 11 yields 00), and immediately using 724 the new keys to send data using the new SPI value. 726 A party who receives an incremented SPI value MUST process the data 727 using the new keys (which it can calculate by itself) and MUST 728 commence using the new keys and corresponding incremented SPI value 729 to send data. This rekeying and transition to use of new keys and 730 SPI value to send data MUST be completed before sending any iSCSI 731 PDU that depends on the PDU whose arriving IP packet contained the 732 incremented SPI value. Implementations MAY precalculate keys for 733 future rekeying events in order to avoid delays caused by a need to 734 perform rekeying calculations when a new SPI value is received. 736 6.5.2 Rekeying Mechanism 2: New Key Exchange 738 This rekeying mechanism repeats the SRP authentication in order to 739 generate new keys based on the key exchange embedded in SRP. An 740 iSCSI Initiator may initiate rekeying by using iSCSI Text PDUs to 741 initiate a new SRP authentication. The keys derived from that 742 authentication are then used with incremented (mod 4) SPI values for 743 ESP processing. An iSCSI Target may initiate rekeying by sending an 744 iSCSI Asynchronous Message PDU to the Initiator to make this 745 request; a new iSCSI Asynchronous Message code would need to be 746 defined for this purpose. 748 7. Security Considerations 750 This entire draft is about security. 752 8. Changes from û00 Version 754 Added statement that there is no requirement to keep authentication 755 identities confidential. 757 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 759 Removed discussion of IKE text from authentication requirements 760 section to remove any implication that IKE is required. Added short 761 discussion of multiple authentications and pointer to L2TP security 762 draft. 764 Updated confidentiality section to indicate that confidentiality is 765 now "MUST implement" but "OPTIONAL to use". 767 Added note that starting ESP on an active TCP connection will not 768 work correctly when TCP port translation is in use. 770 Added statement that SAs used with the proposed key management are 771 tightly bound to iSCSI TCP connections and hence not reusable to key 772 management description. 774 9. References 776 [ISCSI] Satran, J., et.al., "iSCSI", draft-ietf-ips-iscsi-07.txt, 777 Work in Progress, July, 2001. 779 [ISCSI-IPSEC} Aboba, B., et.al., "Securing iSCSI with IPsec", draft- 780 aboba-ips-iscsi-security-00.txt, Work in Progress, August 2001. 782 [ISCSI-NAME-DISC] Bakke, M., et.al., "iSCSI Naming and Discovery", 783 draft-ietf-ips-iscsi-name-disc-02.txt, Work in Progress, August 784 2001. 786 [ISCSI-REQTS] Krueger, M., et.al., "iSCSI Requirements and Design 787 Considerations", draft-ietf-ips-iscsi-reqmts-05.txt, Work in 788 Progress, July 2001. 790 [L2TP-SECURITY] Patel, B., et.al., "Securing L2TP using IPsec", 791 draft-ietf-l2tpext-security-04.txt, Work in Progress, July 2001. 793 [NAT-REQTS] Aboba, B., "IPsec-NAT Compatibility Requirements", 794 draft-ietf-ipsec-nat-reqts-00.txt, Work in Progress, June 2001. 796 [RFC-2104] Krawczyk, H., M. Bellare, and R. Canetti, "HMAC: Keyed- 797 Hashing for Message Authentication", RFC 2104, February 1997. 799 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", RFC 2119, March 1997. 802 [RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the 803 Internet Protocol", RFC 2401, November 1998. 805 [RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 806 Payload (ESP)", RFC 2406, November 1998. 808 [RFC-2407] Piper, D., "The Internet IP Security Domain of 809 Interpretation for ISAKMP", RFC 2407, November 1998. 811 iSCSI Security Requirements and SRP-based ESP Keys Aug 2001 813 [RFC-2408] Maughan, D., M. Schertler, M. Schneider, and J. Turner, 814 "Internet Security Association and Key Management Protocol 815 (ISAKMP)", RFC 2408, November 1998. 817 [RFC-2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 818 (IKE)", RFC 2409, November 1998. 820 [RFC-2663] Srisuresh, P. and M. Holdrege, "IP Network Address 821 Translator (NAT) Terminology and Considerations", RFC 2663, August 822 1999. 824 [RFC-2945] Wu, T., "The SRP Authentication and Key Exchange System", 825 RFC 2945, September 2000. 827 10. Acknowledgments 829 This draft expands on topics originally discussed during the May 830 1st, 2001 interim meeting of the IP Storage WG. Ted Ts'o and 831 Bernard Aboba have made significant contributions to these topics 832 since that meeting. A number of other people have contributed via 833 discussions and email exchanges. All contributions, discussions and 834 comments are gratefully appreciated and hereby acknowledged. This 835 draft will expire before March 2002. 837 11. Author's Address 839 David L. Black 840 EMC Corporation 841 42 South Street 842 Hopkinton, MA 01748 843 Phone: +1 (508) 435-1000 x75140 844 Email: black_david@emc.com