Subject: RE: iSCSI: Login Proposal

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 22 Aug 2001 13:14:46 -0700

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: [email-masked] 

> -----Original Message-----
> From: Wheat, Stephen R [mailto:[email-masked]]
> 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:[email-masked]]
> 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: [email-masked] 
> 
> > -----Original Message-----
> > From: Rod Harrison [mailto:[email-masked]]
> > 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
> > 
>  
>

---

From: Sandeep Joshi <[email-masked]>
Date: Wed, 22 Aug 2001 17:48:17 -0400

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

---

From: Steve Senum <[email-masked]>
Date: Wed, 22 Aug 2001 16:22:17 -0500

Steve Senum

---

From: Steve Senum <[email-masked]>
Date: Wed, 22 Aug 2001 17:24:14 -0500

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