Re: iSCSI: Option Preference (was Login Proposal)

[Sandeep Joshi <[e-mail]>]

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 
 

Steve Senum wrote:
> 
> 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: [phone]
> > fax: [phone]
> > email: [e-mail]
> >
> > > -----Original Message-----
> > > From: Wheat, Stephen R [mailto:[e-mail]]
> > > 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:[e-mail]]
> > > 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: [phone]
> > > fax: [phone]
> > > email: [e-mail]
> > >
> > > > -----Original Message-----
> > > > From: Rod Harrison [mailto:[e-mail]]
> > > > 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
> > > >
> > >
> > >