SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Home

Last updated: Sun Jun 23 13:18:45 2002
10951 messages in chronological order