Subject: RE: iSCSI: Option Preference (was Login Proposal)

From: "Wheat, Stephen R" <[email-masked]>
Date: Wed, 22 Aug 2001 14:48:45 -0700

This raises an interesting point.  Why would an initiator or target offer
something it was not willing to accept?  I.e., perhaps this should be
addressed in the spec.  Some statement like:

  The sender of a key=<v1>,<v2>,<v3> MUST not offer a Vx that it is
  unwilling for the recipient to choose.

Otherwise, it seems kind of like:
   I->T "pick curtain 1, curtain 2, or curtain 3"
   T->I "I pick curtain 2"
   I->T "Ooops, you lose.  Good bye."

Stephen

-----Original Message-----
From: Steve Senum [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 2:22 PM
To: ietf-ips
Subject: Re: iSCSI: Option Preference (was Login Proposal)

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: [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: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 22 Aug 2001 19:08:30 -0400

That really makes the most sense to me.  IMO, having the initiator "request"
authmethods is kind of a waste of bits.  The model I have in mind is that a
target basicly has one AuthMethod and all initiators that want to access it
either MUST use that AuthMethod (external "storage service provider" model)
or may either use that AuthMethod or none.  I'm having a hard time imagining
poor little targets implementing multiple authMethods in the same box and
actually allowing initiators with different authMethods to access it
simultaneously.  In any case, seems like there's little value in having the
initiator offer a list of AuthMethods.  Makes more sense for the initiator
to request login, and the target to return the required AuthMethod.  If the
initiator can't handle it, it terminates the exchange.  That's my
understanding of how client-server auth relationships usually work.
Actually, typically the client is simply expected to know the required
AuthMethod (thru configuration) and begins the exchange by requesting
authorization.

Marj

> Sent: Wednesday, August 22, 2001 3:24 PM
> To: ietf-ips
> 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
> 
>

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 22 Aug 2001 19:42:56 -0400

> In any case, seems like there's little value in having the
> initiator offer a list of AuthMethods.  Makes more sense for 
> the initiator to request login, and the target to return the required 
> AuthMethod. 

On second thought, the value in the initiator offering it's list of
supported AuthMethods is that the target can immediately terminate the
exchange if it's required AuthMethod is not offered, without an additional
exchange of text params.  Don't you love it when I disagree with myself ;-)

Marj

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 23 Aug 2001 09:50:23 +0300

Marjorie,

If you'll take the time and go through all the scenarios (I know that your
time is precious :-))
you'll find that the order of "exposing" preferences in a negotiation does
not matter if the negotiation is symmetric (and it is).
As we are bound to a certain order of things by the main function (command
processing) we start all exchanges at initiator.
Having the initiator send an empty request only because you think that in
most cases the target dictates authentication
seems a vaste of bits (and time) - contrary to your assertion. This is why
we never gave any example involving it.
But it is certainly a legal sequence in the current draft.  To force
everybody to use it - BAD IDEA.
I assume that as storage gets more decoupled from systems the need for
mutual authentication will increase (why would you believe that
the volume given to you over the net is where you wrote your precious data
last time?).

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>@ece.cmu.edu
on 23-08-2001 02:08:30

Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
      <[email-masked]>

Sent by:  [email-masked]

To:   ietf-ips <[email-masked]>
cc:
Subject:  RE: iSCSI: Option Preference (was Login Proposal)

That really makes the most sense to me.  IMO, having the initiator
"request"
or may either use that AuthMethod or none.  I'm having a hard time
imagining

Marj

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Thu, 23 Aug 2001 12:39:46 -0400

Agreed, I've already disagreed with myself in a subsequent email :-)  Good
point regarding mutual authentication, the possibilities for malicious
behavior are miriad (masquerading as a target to intercept your precious
data).

Marj

> From: Julian Satran [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 11:50 PM
> To: [email-masked]
> the initiator