RE: Auth method negotiation

["Robert D. Russell" <rdr@io.iol.unh.edu>]

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

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.


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