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)



    On Thu, 16 Jan 2003 Black_David@emc.com wrote:
    
    > > 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.
    
    Ok, that's not quite what I was taking from the text, but what I thought
    we all had in mind.
    
    > > 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.
    
    Ok!
    
    > 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.
    
    Ahhh!!!! Ok, that is a very different interpretation that what I was
    taking away from the text, but a very sensible one.
    
    Then may I suggest we make the "this is the shipped default" aspect of
    this text more prominent (well the "the admin has done nothing" aspect)?
    Because if I got confused on it, I expect others may too.
    
    > 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.
    
    Wouldn't those advocates also have to also make it a MUST?
    
    Because as long as the algorithm in question isn't a MUST, we have this
    issue. The case you describe above for an X- method also applies for a
    device that only ships with Kerberos, SRP, or one of the public key
    methods; since those methods are optional, we have the exact same
    interop-by-default issue.
    
    Take care,
    
    Bill
    
    


Home

Last updated: Thu Jan 16 20:19:06 2003
12202 messages in chronological order