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)



    Bill,
    
    > On Thu, 16 Jan 2003 Black_David@emc.com wrote:
    > 
    > > It is also the case that in the absence of explicit administrative
    > > action, an implementation MUST NOT default to extension
    > > algorithms or to extension algorithms plus "None", and that in
    > > the absence of explicit administrative action, CHAP SHOULD be
    > > offered if an extension algorithm is offered.
    > 
    > But without administrative action (either to add CHAP names and
    > passphrases or to configure a RADIUS server), how can we offer CHAP?
    > 
    > To paraphrase Julian's other message, are we trying to make interoperable
    > implementations, or interoperable administators? If the adminsitrator
    > won't be interoperable, what should we do?
    
    As long as the administrator has made explicit choices that lead to
    lack of interoperability, the results are her own fault.  The issue
    is ensuring that implementations don't default to lack of interoperation.
     
    > My concern is that the text we're talking about would make our
    > implementation not compliant.
    > 
    > The way we do security is you tie an authentication entry (which matches
    > an AUTH_MIB entry) describing an initiator to a target; that permits an
    > initiator (or initiators) with a matching name to use the target, if
    > security succeeds. The list of security methods the target will accept is
    > the union of security credentials in the auth entry. If there's a CHAP
    > entry, the target will do CHAP. If there's a None entry, we'll skip
    > security. If there's a Kerberos entry, we'll do Kerberos. If X-com.bar.foo
    > gets added and there's a X-com.bar.foo entry, we'll do X-com.bar.foo. We
    > of course then look at what the initiator wants to do, and we go with the
    > first one the initiator wants that is acceptable to us.
    >  
    > The point is that we won't do any form of security, neither ones listed in
    > the iSCSI draft nor ones added later, unless the administrator
    > specifically told us to.
    
    That sounds like "explicit administrative action" to me.
     
    > So what do we do if the only credential in the entry is for X-com.bar.foo?
    > If it's there, it's there because the administrator put it there. If
    > nothing else is there, then the admin chose not to add anything else. We
    > can't do CHAP or anything else, since we don't have the credentials.
    > 
    > Would we be violating the spec if we didn't do CHAP in that case?
    
    I believe that would be ok.  Let's assume the implementation ships with
    no secrets - in the absence of administrative action, it only offers
    "None", and treats the configuration of secrets as a explicit
    administrative actions that enable the corresponding algorithms to be
    offered.  The default of "None" is fine, as no extension algorithm
    is offered, so the "SHOULD offer CHAP" requirement does not apply.
    An extension algorithm can only be offered in this situation based
    on the "explicit administrative action" of configuring a secret for
    it, and hence there's no requirement to offer anything else.
    
    Now, if someone took that implementation and configured only an
    X-com.bar.foo secret as an example account and shipped the result as
    product, that would be a problem because the result defaults to
    the extension algorithm.  This is avoidable by configuring both
    an X-com.bar.foo secret and a CHAP secret for the example account.
    
    And to head off the next question, if the advocates of X-com.bar.foo
    authentication want to get out from under the requirement in the
    previous paragraph, they make the effort to have the IETF standardize
    that authentication method.  If that succeeds, and the algorithm is
    assigned something other than an X- key, none of this discussion
    applies to it at that point.
    
    Thanks,
    --David
    ----------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 176 South St., Hopkinton, MA  01748
    +1 (508) 293-7953             FAX: +1 (508) 293-7786
    black_david@emc.com        Mobile: +1 (978) 394-7754
    ----------------------------------------------------
    


Home

Last updated: Thu Jan 16 19:19:05 2003
12198 messages in chronological order