Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h1D0VSc04506
	for ips-outgoing; Wed, 12 Feb 2003 19:31:28 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mxic1.corp.emc.com ([128.222.32.10])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h1D0VPW04497
	for <ips@ece.cmu.edu>; Wed, 12 Feb 2003 19:31:26 -0500 (EST)
Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <1KDYTY2F>; Wed, 12 Feb 2003 19:31:20 -0500
Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C892@corpmx14.us.dg.com>
From: Black_David@emc.com
To: ips@ece.cmu.edu
Subject: iSCSI - RFC editor notes
Date: Wed, 12 Feb 2003 19:29:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

As part of IESG approval of iSCSI, two notes to the RFC Editor
were issued (see below) to do the following to the -20 draft:

(1) Explain the risks of sharing CHAP secrets.
(2) Restore the requirement for Unit Attention on implicit
	task termination.

FYI,
--David

> 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.
