RE: iSCSI: Option Preference (was Login Proposal)

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

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

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, August 22, 2001 11:50 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: Option Preference (was Login Proposal)
> 
> 
> 
> 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)" 
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 23-08-2001 02:08:30
> 
> Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>       <marjorie_krueger@hp.com>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   ietf-ips <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI: Option Preference (was Login Proposal)
> 
> 
> 
> 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
> 
> > -----Original Message-----
> > From: Steve Senum [mailto:ssenum@cisco.com]
> > Sent: Wednesday, August 22, 2001 3:24 PM
> > To: ietf-ips
> > Subject: Re: iSCSI: Option Preference (was Login Proposal)
> >
> >
> > 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
> >
> >
> 
> 
>