Date: Thu, 16 Jan 2003 15:56:20 -0800 (PST)
From: Bill Studenmund <wrstuden@wasabisystems.com>
To: <Black_David@emc.com>
Cc: <ips@ece.cmu.edu>
Subject: RE: iSCSI extension algorithms (was no subject)
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C7A2@corpmx14.us.dg.com>
Message-ID: <Pine.NEB.4.33.0301161530280.499-100000@candlekeep.home-net.internetconnect.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

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