SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI extension algorithms (was no subject)



    Nick,
    
    Sorry to be blunt/brusque, but this is an IESG requirement and hot
    button - an implementation that offers only proprietary extension
    algorithm Z without also offering something else is viewed as forcing
    the counterpart to implement Z, and that will not be acceptable to the
    IESG, period.
    
    > I have always seen a big distinction between what is required to
    > be implemented, versus what is offered during negotiation.  We appear
    > to be mandating that a stroage administrator must not be allowed
    > to configure a target to allow authentication Z  (an extension) and
    > no other.  In the future it may be the case that Z is a site standard
    > and no other is acceptable.
    
    The fact that Z may be proprietary is what forces us across this line.
    To achieve the effect you desire, the administrator could configure the
    target to offer Z and CHAP *in that order* (making Z preferred) and
    then configure no CHAP secrets or access to external CHAP verification
    (e.g., RADIUS) into the target.  If the site you envision is properly
    configured, the initiators all accept Z and everything is fine.  An
    initiator that makes the mistake of accepting CHAP fails to authenticate
    as the target is configured so that all CHAP authentications fail.
    
    Note that this requirement is being imposed *only* on non-standard
    authentication methods.
    
    Sorry,
    --David
    ----------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 176 South St., Hopkinton, MA  01748
    +1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
    black_david@emc.com        Mobile: +1 (978) 394-7754
    ----------------------------------------------------
    
    -----Original Message-----
    From: Martin, Nick (Server Storage) [mailto:Nick.Martin@hp.com]
    Sent: Wednesday, January 08, 2003 1:21 PM
    To: Julian Satran; Steve Bellovin; Black_David@emc.com
    Cc: ips@ece.cmu.edu
    Subject: RE: iSCSI extension algorithms (was no subject)
    
    
    Julian and All,
     
    The "MUST also be offered" is the part I have a problem with.  
     
    I have always seen a big distinction between what is required to be
    implemented, versus what is offered during negotiation.  We appear to be
    mandating that a stroage administrator must not be allowed to configure a
    target to allow authentication Z  (an extension) and no other.  In the
    future it may be the case that Z is a site standard and no other is
    acceptable.  
     
    If I understand correctly, the intention is that one can not claim iSCSI
    compliance without implementing (at least one of) the currently specified
    methods.
    I think this is a poor way to state/enforce that intention.
     
    The administrator of the target should select the preferred and/or
    acceptable authentication methods (from the list implemented by his vendor)
    to be offered (allowed to be selected during negotiation) by each target
    under his administration.  The same for initiators.  
     
    We say other algorithms may be implemented and negotiated.  However, we are
    now saying that an administrator may not decide to offer (allow) neither of
    the current authentication methods in favor of something else.  I think we
    are also implying targets and initiators must enforce this.
     
    The iSCSI spec has to this point avoided prescribing such restrictions on
    administration.
     
    Thanks,
    Nick
     
    -----Original Message-----
    From: Julian Satran [mailto:Julian_Satran@il.ibm.com] 
    Sent: Wednesday, January 08, 2003 5:18 AM
    To: Steve Bellovin; Black_David@emc.com
    Cc: ips@ece.cmu.edu
    Subject: 
    
    
    
    The intent of the "offending" statement in 11.1 was to have a strong player
    with a new method forcing everybody into it by not offering anything else. 
    I guess the phrasing was bad.  Simply removing None will not do it since
    None may still remain a valid option if both parties agree: 
    
    I would suggest the new phrasing to be: 
    
    Private or public extension algorithms MAY also be negotiated for
    authentication methods. Whenever a private or public extension algorithm is
    offered, at least one of the authentication methods defined in this document
    MUST also be offered as an option. 
    
    Julo 
    


Home

Last updated: Thu Jan 09 16:18:59 2003
12153 messages in chronological order