Protocol Action: iSCSI to Proposed Standard

[The IESG <iesg-secretary@ietf.org>]

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.