Re: iSCSI: Option Preference (was Login Proposal)

Steve Senum <ssenum@cisco.com> Wed, 22 August 2001 23:08 UTC

Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25956 for <ips-archive@odin.ietf.org>; Wed, 22 Aug 2001 19:08:57 -0400 (EDT)
Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f7MMOUe26486 for ips-outgoing; Wed, 22 Aug 2001 18:24:30 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7MMOTe26482 for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 18:24:29 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA06281 for <ips@ece.cmu.edu>; Wed, 22 Aug 2001 18:24:22 -0400 (EDT)
Message-ID: <3B84310E.C01D7071@cisco.com>
Date: Wed, 22 Aug 2001 17:24:14 -0500
From: Steve Senum <ssenum@cisco.com>
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ips <ips@ece.cmu.edu>
Subject: Re: iSCSI: Option Preference (was Login Proposal)
References: <6BD67FFB937FD411A04F00D0B74FE87802A0925E@xrose06.rose.hp.com> <3B842289.D34268CD@cisco.com> <3B8428A1.B7F0AB5A@research.bell-labs.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Not to try to beat this into the ground anymore
then already has been done, but...

Many months ago, when I first looked over
the iSCSI spec, I remember thinking it was
kind of odd for the side being authenticated
to control the possible options.  Other
protocols I have worked with would have the
side driving the authentication (i.e., the Target)
control this.

If the IPS group wants to stay with the
current target-really-controls-authentication
notion, we might want to go a step further,
and allow only the Target to send the AuthMethod
key out.

Just a thought,
Steve Senum

Sandeep Joshi wrote:
> 
> Steve,
> 
> That would be the initiator's preference...accept a "none"
> or drop the connection.
> 
> Marjorie's point is that conceptually user/IIN authentication
> would be controlled by the target (i.e. the server).
> 
> Once the endpoints are authenticated (e.g. by IPSec), then
> ITN/IIN authentication will be driven by the server (target)
> 
> This is analogous to a RAS scenario in ipsra,
> http://www.ietf.org/internet-drafts/draft-ietf-ipsra-reqmts-03.txt)
> ( umm..please dont extend this analogy too far :-) )
> 
> regards,
> -Sandeep