RE: iSCSI: Login Proposal

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

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
> > 
>  
>