Re: Auth method negotiation

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

Yes they are valid sequences.
Julo

Steve Senum <ssenum@cisco.com> 06/22/2002 06:36 PM Please respond to Steve Senum

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

Hi Julian,

Just to make sure, please confirm that the following are
(still) valid login sequences, especially the T bit.

1. CHAP Authentication of iSCSI Initiator by iSCSI Target:

I-> Login (CSG,NSG=0,1 T=1)
    InitiatorName=<InitiatorName>
    TargetName=<TargetName>
    AuthMethod=CHAP,None
T-> Login (CSG,NSG=0,0 T=0)
    AuthMethod=CHAP
I-> Login (CSG,NSG=0,0 T=0)
    CHAP_A=<A>
T-> Login (CSG,NSG=0,0 T=0)
    CHAP_A=<A>
    CHAP_I=<I>
    CHAP_C=<C>
I-> Login (CSG,NSG=0,1 T=1)
    CHAP_N=<N>
    CHAP_R=<R>
T-> Login (CSG,NSG=0,1 T=1)
I-> ...
T-> ...

2. No Authentication of iSCSI Initiator by iSCSI Target:

I-> Login (CSG,NSG=0,1 T=1)
    InitiatorName=<InitiatorName>
    TargetName=<TargetName>
    AuthMethod=CHAP,None
T-> Login (CSG,NSG=0,1 T=1)
    AuthMethod=None
I-> ...
T-> ...

Thanks,
Steve Senum

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