Re: iSCSI authentication requirements

[David Jablon <dpj@theworld.com>]

Ted, on some relevant points, I think we may be closer to
agreement than you think, for example, I think we could probably
tweak the following into a mutually agreeable form:

1)  A MUST implement CHAP-based method would surely promote
free interoperability for all, with security for some.

2)  A SHOULD implement method in the SRP category would permit 
implementors the opportunity to make an engineering/business tradeoff,
and if desired, to use a method optimally resistant to dictionary attack,
with a chance for widespread interoperability in this regard too.

I think there are clearly ways that the standard can let people
pay "whatever they think it's worth", as you've characterized it,
to use a method like SRP, and still maximize interoperability
among applications that use either that approach or a
guaranteed-free but not-equivalent alternative.

The next job would seem to be to insure that the SRP-like option
is specified in a way that makes a decision to use it as easy
and as inexpensive as possible.

I'll respond below to some points where we have had or may
still have disagreement,

At 07:15 PM 3/28/02 -0500, Theodore Tso wrote:
>On Thu, Mar 28, 2002 at 08:13:42PM -0500, David Jablon wrote:
>> [...] But stated in other words, an attacker can inject just a couple
>> bogus packets, a mere hiccup from the user's view, and then he
>> gets unlimited offline guessing to crack the password [...]
>
>Nope, not that easy.  As I said, [...] This is not necessarily trivial --- it's
>*not* just a matter of "injecting a few bogus packets".

In order for either of us to prove our points, someone has to specify the
exact protocol you've been thinking about. Maybe it's not exactly the
EZ-to-crack thing I was thinking of.  SRP and well-known equivalents
are established protocols that have survived years of public scrutiny.
But I'll be glad to to spend a few minutes looking at the new proposal
when it's ready.  ;-)

>> Furthermore, limiting the attack window to *just* the first time may
>> not significantly decrease the problem.  It depends on other
>> assumptions.  In some cases it may be like locking all but one door
>> of your house.  [...]
>
>Again, nope.  It's like saying that while the house is being built,
>there is a small window when the deadbolt hasn't been installed yet.
>But once the deadbolt has been installed, the burgler can't get in. [...]

That "nope" is not so well supported.  Essentially, I think you've argued
that you know how the application can be built and is likely to be used
in a way that greatly reduces this window of vulnerability, so therefore
everything is A-OK.

But I think the real test is in how applications interpret the standard,
and how people use those applications, and it seems pretty early to
know that, and therefore hard to predict how big that "window" might be.

In getting rid of that window entirely, one reduces the risk of failure
due to unanticipated application and user behavior, which can't be
easily specified.

>> And finally, as you almost point out, all these [freeware] interoperability
>> problems go away when a patented technique is standardized as
>> a SHOULD implement method.
>
>Nope.  Security mechanisms have to be a MUST implement.  If we have a
>non-encumbered MUST implement mechanism, then whether or not we have
>an encumbered SHOULD mechanism at some level is less important. ...

That "Nope" is inappropriate.  I was arguing almost the same point.

One difference is that I think at least a SHOULD for something like SRP
is still important, since before all the IP rumors, people thought it was
a MUST.  Anything less seems like a downgrade.

Yet, another possibility to fit your original point, is for a MUST SRP and
MUST CHAP standard.  Everything that implements the standard is 
interoperable, and it still allows for (somewhat-non-compliant) freeware
implementations that fully interoperate with all standard ones.
(Yes. I know. This is surely politically incorrect.)

But I also wonder if the interoperable freeware debate is based on the
assumption that there are no other IP encumbrances on this standard,
which seems like it might be an open question.  If there are other
encumbrances, discussion about freeware may be irrelevant.

> ... Most
>people will probably depend on the MUST implement for
>interoperability.

I'd rather not debate predictions.  We clearly agree that a MUST
method provides a baseline for interoperability.

>... So then, people will only pay whever are costs (in
>money, legal uncertainty, etc.) for using said encumbered technology
>if said encumbered technology really provides enough value that it's
>worth the cost.

That sounds reasonable to me.  People can pay what they think it's worth.

>> * I think it's up to the working group members to decide what technology is
>> truly equivalent to an optimal case for its purposes, without undue pressure
>> or interference from "outsiders" (including me too of course).
>
>The security area of the IETF, and the security AD's of the IESG are
>not "outsiders".  They are part of the IETF community.  And the IETF
>community *has* made some global decisions for the entire IETF. ...

Ok.  There are definitely legitimate reasons for global decisions to be
made in the IETF.  You cited some great examples involving
governmental entanglements.

My point is that it seems to be a very bad thing for the IETF to start
making global top-down decisions about specific competing technologies
that merely involve business/engineering tradeoffs. I think we're talking
about the difference between a light hand and a heavy hand.

A relevant sentence in RFC2026, 10.3.2:
  "(B)  The IESG disclaims any responsibility for identifying the
      existence of or for evaluating the applicability of any claimed
      copyrights, patents, patent applications, or other rights in the
      fulfilling of the its obligations under (A), and will take no
      position on the validity or scope of any such rights."

In the act of proposing specific alternative technology to avoid
specific patents, there is at least the appearance that the IESG
is indeed taking on this responsibility.  And it certainly seems
to be "taking a position" here.

>PS.
>...
>Make no mistake.  Patents have their costs.  If you want your protocol
>to be widely deployed across the Internet, use of patented technology
>...

P.S.
If by "you" and "your", you mean me and mine, I object to personalizing
the debate. I think we all know that I invented one of the contenders.
Otherwise, if you were just using the "royal you", please don't. Thanks.