The IESG has approved publishing the following Internet-Draft as a Proposed Standard: o iSCSI <draft-ietf-ips-iscsi-20.txt> This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary The Small Computer Systems Interface (SCSI) is a family of protocols for communicating with I/O devices, especially storage devices. SCSI is a client-server architecture. The SCSI protocol has been mapped over various transports, including Parallel SCSI, IPI, IEEE-1394 (firewire) and Fibre Channel. These transports are I/O specific and have limited distance capabilities. The iSCSI protocol defined in draft-ietf-ips-iscsi describes a means of transporting of the SCSI packets over TCP/IP, providing for an interoperable solution which can take advantage of existing Internet infrastructure, Internet management facilities and address distance limitations. Mapping over TCP ensures that the high volume storage transfers use congestion control. Working Group Summary Special care was taken by the working group in a number of areas: string comparison (based on Internet stringprep); strong risk analysis and security; and the SCSI standards. Balance was needed on each of these and the chairs and working group took time to get the right details. Protocol Quality The protocol was reviewed for the IESG by Allison Mankin, David Black, Elizabeth Rodriguez and Bernard Aboba. There are numerous implementations reported to the Area Directors, including the security features. RFC Editor Note: Dear RFC Editor, Please make the following changes to draft-ietf-ips-iscsi-20.txt - (1) In Section 8.2.1, replace the following old text at the end of the section: A single CHAP secret MAY be used for authentication of an individual initiator to multiple targets. Likewise, a single CHAP secret MAY be used for authentication of an individual target to multiple initiators. with the following new text: When an iSCSI initiator or target authenticates itself to counterparts in multiple administrative domains, it SHOULD use a different CHAP secret for each administrative domain to avoid propagating security compromises across domains. Within a single administrative domain: - A single CHAP secret MAY be used for authentication of an initiator to multiple targets. - A single CHAP secret MAY be used for an authentication of a target to multiple initiators when the initiators use an external server (e.g., RADIUS) to verify the target's CHAP responses and do not know the target's CHAP secret. If an external response verification server (e.g., RADIUS) is not used, employing a single CHAP secret for authentication of a target to multiple initiators requires that all such initiators know that target secret. Any of these initiators can impersonate the target to any other such initiator, and compromise of such an initiator enables an attacker to impersonate the target to all such initiators. Targets SHOULD use separate CHAP secrets for authentication to each initiator when such risks are of concern; in this situation it may be useful to configure a separate logical iSCSI target with its own iSCSI Node Name for each initiator or group of initiators among which such separation is desired. (2) In both Section 6.5 and 10.14.5, remove the following text near the end of each section: UA for the next command on the I_T nexus in cases a), b), and c) so that the resulting parenthesized comment reads: (e.g., queued commands and ACA, etc.) and also add the following sentence to the end of the same paragraph: In cases a), b), and c), after the tasks are terminated, the target MUST report a unit attention condition on the next command processed for each affected I_T_L nexus regardless of the connection to which that command is allegiant. These changes are to be made to both Section 6.5 and 10.14.5.
