RE: Auth method negotiation

["Julian Satran" <Julian_Satran@il.ibm.com>]

OK - Julo

"Robert D. Russell" <rdr@io.iol.unh.edu> Sent by: owner-ips@ece.cmu.edu 06/23/2002 02:17 PM Please respond to "Robert D. Russell"

To:        Julian Satran/Haifa/IBM@IBMIL         cc:        ips@ece.cmu.edu         Subject:        RE: Auth method negotiation

Julian:

So now the last sentence of your suggested text reads:

"If the next stage is FullFeaturePhase, the target MUST respond with
 a Login Response with the TSIH and the selected protocol version."

However, I still would like to see the phrase "and the selected
protocol version" removed, because ALL Login Responses sent by the
target must contain the selected protocol version -- there is nothing
special about the Login Response that causes the transition into
FullFeaturePhase with respect to the protocol version information
(i.e., the version-active field), but adding this phrase makes it
sound as if there is.

Thank you for your consideration.
Bob Russell

>
>
> Bob,
>
> Comments in text.
>
> Thanks,
> Julo
>
>
> "Robert D. Russell" <rdr@io.iol.unh.edu>
>
> 06/22/2002 06:25 PM
> Please respond to "Robert D. Russell"
>
>         To:        Julian Satran/Haifa/IBM@IBMIL
>         cc:        ips@ece.cmu.edu
>         Subject:        RE: Auth method negotiation
>
>
>
> Julian:
>
> Just two minor comments -- in the very last sentence of
> your suggested text ends with "and the protocol version".
> Why is this necessary -- doesn't every Login response
> have to carry identical values for version-max and
> version-active?  Is the value in version-active
> what you mean by "protocol version"?  If so, I would just
> omit this phrase (because it raises the question as to
> whether or not previous Login responses need to carry
> version-active).
>
> +++ Version selected - the initiator has version min and max in the Login
> request.
> I should perhaps add selected +++
>
> Second comment -- the term "session id".  Do you mean the TSIH?
> If so, I believe it should say TSIH explicitly.  If not, then
> what do you mean  - the full ISID/TSIH?  If so, then again
> this is misleading because all Login Responses have to carry
> the ISID offered in the first Login Request.
>
> +++ I will replace session ID with TSIH +++
> Thanks,
> Bob Russell
>
>
> On Sat, 22 Jun 2002, Julian Satran wrote:
>
> >
> > How about the following text:
> >
> >           -When the initiator considers that it ready to conclude the
> >             SecurityNegotiation stage it sets the T bit to 1 and the
> NSG to
> >             what it would like the next stage to be. The target will
> then
> >             set the T bit to 1 and set NSG to the next stage in the
> Login
> >             response where it finishes sending its security keys. The
> next
> >             stage selected will be the one the target selected. If the
> next
> >             stage is FullFeaturePhase, the target MUST respond with a
> Login
> >             Response with the Session ID and the protocol version.
> >  Julo
> >
> >
> >
> >                       pat_thaler@agilen
> >                       t.com                    To:
> wrstuden@wasabisystems.com, chirag.wighe@windriver.com
> >                       Sent by:                 cc:
> ips@ece.cmu.edu
> >                       owner-ips@ece.cmu        Subject:  RE: Auth
> method negotiation
> >                       .edu
> >
> >
> >                       06/22/2002 03:01
> >                       AM
> >                       Please respond to
> >                       pat_thaler
> >
> >
> >
> >
> >
> > Bill,
> >
> > I agree that the target made an error in sending T=1 when it chose an
> > authentication method.
> >
> > However, even if it was willing to skip negotiation it must return CHAP
> > when offered AuthMethod=KRB5,SRP,CHAP,None.
> >
> > 4.3.2 says "-The target MUST reply with the first option in the list it
> > supports and is allowed to use for the specific initiator
> > unless it does not support any in which case it MUST answer
> > with "Reject" (see also Section 4.2 Text Mode Negotiation).
> > The parameters are encoded in UTF8 as key=value. For security
> > parameters, see Chapter 10."
> >
> > So if the target supports CHAP and is allowed to use CHAP for an
> initiator
> > it MUST reply with CHAP or an earlier alternative in the list when
> offered
> > CHAP before None for AuthMethod. It cannot reply None. If the initiator
> > would have preferred "None" over "CHAP" it should have placed it before
> > CHAP in the list.
> >
> > I think that the next text in 4.3.2 is a bit confusing:
> > "-The initiator must be aware of the imminent completion of the
> > SecurityNegotiation stage and MUST set the T bit to 1 and the
> > NSG to what it would like the next stage to be. The target
> > will answer with a Login response with the T bit set to 1 and
> > the NSG to what it would like the next stage to be. The next
> > stage selected will be the one the target selected. If the
> > next stage is FullFeaturePhase, the target MUST respond with
> > a Login Response with the Session ID and the protocol version."
> >
> > I think "aware of imminent completion" means that the target has sent
> its
> > last key=value of the security negotiation but it doesn't seem a very
> clear
> > way to say it.
> > Also, the next sentence is not always true. The target might not be
> ready
> > to set the T bit in the answering Login Response. It might have
> required
> > more than one PDU to send its final key(s) of the security negotiation.
> > "The target will then set the T bit to 1 and set NSG to the next stage
> in
> > the Login response where it finishes sending its security keys." would
> be
> > more accurate.
> >
> > Pat
> >
> > -----Original Message-----
> > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
> > Sent: Friday, June 21, 2002 4:19 PM
> > To: Chirag Wighe
> > Cc: ips@ece.cmu.edu
> > Subject: Re: Auth method negotiation
> >
> >
> > On Fri, 21 Jun 2002, Chirag Wighe wrote:
> >
> > > Hi
> > >
> > > I am sorry for the typo but I cut and paste from the spec. In the
> spec on
> > > page 245 for example it says
> > > If the initiator authentication is successful, the target proceeds:
> > > T- Login (CSG,NSG=0,1 T=1)
> > > I- Login (CSG,NSG=1,0 T=0)
> >
> > Oh, if T=0, then NSG is reserved, and should have the value 0.
> >
> > > ... iSCSI parameters
> > > T- Login (CSG,NSG=1,0 T=0)
> > > ... iSCSI parameters
> > >
> > > I did a search and there are several other 1,0 transitions in the
> spec.
> >
> > Were they transitions, i.e. T=1? Or just notifications of continuing
> > operational parameter negotiation? That's what (CSG,NSG=1,0 T=0) is.
> >
> > > Anyway what I meant was what Bill intepreted it to be which was
> > > Login (CSG,NSG=0,1 T=1)
> > > InitiatorName=iqn.1999-07.com.os.hostid.77
> > > TargetName=iqn.1999-07.com.acme.diskarray.sn.88
> > > AuthMethod=KRB5,SRP,CHAP,None
> > >
> > > and the target replying
> > > T- Login-PR (CSG,NSG=0,1 T=1)
> > > AuthMethod=CHAP
> > >
> > > and then my other questions hopefully make more sense.
> >
> > I think the concensus is that the target made an error. If it was
> willing
> > to skip security negotiations (T=1, NSG=1), it shouldn't have chosen
> CHAP.
> >
> > Take care,
> >
> > Bill
> >
> >
> >
> >
>
>
>
>