Re: iSCSI: Option Preference (was Login Proposal)

[Steve Senum <ssenum@cisco.com>]

I disagree, at least somewhat.

If the Initiator sends AuthMethod=SRP,CHAP,none and
the Target returns AuthMethod=none, the Initiator
could still choose to abort the connection if
it was configured to require authentication.
I believe either or both sides can dictate the
security environment.

Steve Senum

"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
> 
> I meant only to point out that it's the target that must dictate the
> security environment, not the initiator.  The initiator is only
> communicating a preference.  So yes, I agree with you, but Ron's comment was
> 
> > >     I expect this to be under the control of the sys admin
> > > through some kind of config at the initiator side. I think a
> > > good guide to keep in mind with all this is that it is the
> > > initiator's data, and so it seems reasonable to let the
> > > initiator control connection security and integrity.
> 
> and I'm thinking it's the other way around.  The initiator has a role, but
> it is the requestor of a service, not the "server" hence the target really
> controls security.  Of course, ultimately, the system admin controls
> everything, but we don't get to write his/her "protocol"  :-)
> 
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions Org.
> Hewlett-Packard
> tel: +1 916 785 2656
> fax: +1 916 785 0391
> email: marjorie_krueger@hp.com
> 
> > -----Original Message-----
> > From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com]
> > Sent: Wednesday, August 22, 2001 11:02 AM
> > To: ietf-ips
> > Subject: RE: iSCSI: Login Proposal
> >
> >
> > Marjorie,
> >
> > I agree with your premise that the target must be allowed to
> > not just let
> > anyone in.
> >
> > But why isn't this already covered by the ability of the sys admin to
> > configure the target to only agree to certain offerings?  Quoting from
> > 1.2.4, with my
> > emphasis,
> >    "The responding party answers with the first value from the list it
> > supports and
> >     is **allowed** to use for the specific initiator."
> >
> >
> > For some network interfaces,
> > the sys admin could rely upon physical security and other
> > means inherent to
> > the
> > environment.  In such cases, the admin could configure the
> > target to follow
> > the
> > initiator's preferences, including "none".
> >
> > For other network interfaces where the environment is not inherently
> > trusted,
> > the sysadmin would be motivated to not allow the target to
> > connect without any authentication; so they'd set it up to not accept
> > "none", even
> > though the initiator may prefer "none".
> >
> > Yes?
> >
> > Stephen
> >
> > -----Original Message-----
> > From: KRUEGER,MARJORIE (HP-Roseville,ex1)
> > [mailto:marjorie_krueger@hp.com]
> > Sent: Wednesday, August 22, 2001 10:47 AM
> > To: 'Rod Harrison'; ietf-ips
> > Subject: RE: iSCSI: Login Proposal
> >
> >
> > I'm thinking a little differently regarding which party has
> > priority in
> > chosing security parameters - while it *may* be the
> > initiators data, this
> > can't be established until the initiator is authenticated.
> > Since the target
> > is the "server" side, I think the burden is on the target to
> > ensure that
> > this is the intended initiator.  Therefore, the target must
> > dictate the
> > authentication method used, since it has the security
> > responsibility and the
> > "contact point" for potentially malicious entities.  Consider
> > the example
> > where an initiator was previously authenticated using
> > Kerberos, the session
> > was ended, and a new session is requested by what appears to
> > be the same
> > initiator, but the authmethod requested is now "none".  Looks pretty
> > suspicious to me.  It seems to me like the target has the
> > responsibility of
> > maintaining a consistent authmethod with all initiators that
> > access it,
> > therefore the target MUST force the minimum level
> > authorization it requires
> > or reject the login request.
> >
> > Marjorie Krueger
> > Networked Storage Architecture
> > Networked Storage Solutions Org.
> > Hewlett-Packard
> > tel: +1 916 785 2656
> > fax: +1 916 785 0391
> > email: marjorie_krueger@hp.com
> >
> > > -----Original Message-----
> > > From: Rod Harrison [mailto:rod.harrison@windriver.com]
> > > Sent: Wednesday, August 22, 2001 4:58 AM
> > > To: Wheat, Stephen R; 'Steve Senum'; ietf-ips
> > > Subject: RE: iSCSI: Login Proposal
> > >
> > >
> > >
> > >     I think we should view this as the order indicates the
> > > initiators preference and the target SHOULD pick the first
> > > item from the list it supports. Note that SHOULD allows the
> > > target to do something other than pick the first item it
> > > supports if it has a good reason to do so, e.g. If it would
> > > otherwise terminate the session. The initiator can always
> > > terminate the session if it doesn't like what the target
> > > chooses.
> > >
> > >     So, to extend your example, as an initiator if I didn't
> > > want to do CHAP at all I would send ...
> > >
> > > AuthMethod=none
> > >
> > >     if I preferred not to do CHAP but I could tolerate it I
> > > would send ...
> > >
> > > AuthMethod=none,CHAP
> > >
> > >     and if I would prefer CHAP I would send ...
> > >
> > > AuthMethod=CHAP,none
> > >
> > >     I expect this to be under the control of the sys admin
> > > through some kind of config at the initiator side. I think a
> > > good guide to keep in mind with all this is that it is the
> > > initiator's data, and so it seems reasonable to let the
> > > initiator control connection security and integrity.
> > >
> > >     - Rod
> > >
> >
> >