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



    
    ----- Forwarded by Julian Satran/Haifa/IBM on 06/22/2002 01:02 PM -----
                                                                                                                                            
                          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: Sat Jun 22 07:18:40 2002
10940 messages in chronological order