RE: iSCSI: Option Preference (was Login Proposal)

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

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