Re: iSCSI authentication requirements

[David Jablon <dpj@theworld.com>]

Ted,

Regarding my statement:
>On Wed, Mar 27, 2002 at 03:42:55PM -0500, David Jablon wrote:
>> A primary decision for the WG to consider is whether
>> item (e), preventing "dictionary attack", is important.

Your thoughtful, rather lengthy reply warrants a response.

I feel it is necessary for me to point out where exaggeration
invalidates your argument and is also damaging to the process
of arriving at a consensus on the best all-around solution.
I will clarify these points here.

At 10:57 PM 3/27/02 -0500, Theodore Tso wrote:
>We need to be a bit more nuanced here.  The question is not just
>whether or not a particular scheme is vulnerable to a dictionary
>attack, but under what circumstances is it vulnerable to a dictionary
>attack.  If the attack requires the use of an active attack, where the
>attacker has to be on communications path, *and* the attacker must
>interpose him/herself between the client and the server, *and* the
>attack causes the attempted authentication to fail, such that the
>client knows something might be going on --- how bad is it that under
>these sorts of circumstances, a dictionary attack might be possible?

Ok.  On the one hand, you sure do make that attack sound hard.
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.  Some
might consider that a *bad thing* indeed.

>Also, if we posit that the authentication target has a public key,
>which can be optionally cached by the client (in an ssh-style type
>approach), then the server can sign its challenge with its public key,
>and then even the possibility of an active attack is limited to the
>first time the client talks to a particular server or iSCSI target.

Sure, posit that.  Strong password methods work well for securing
initial connections, or generally in remote retrieval of data when a
local credential cache has been cleared or needs updating.
If this standard used SSH, or proposed such caching, then, I'd argue,
a person should use a strong password method to protect that
initial connection.

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.  A good burglar will try them all, or wait for the
appropriate time, etc.  In contrast, a strong password method closes
all these doors to offline cracking of network messages, forcing the
burglar to try something different.

>Is this as good as an EKE, SPEKE, or PDM-style authentication scheme?
>Nope; but it's close.  And as I articulated during the IETF
>open-plenary, we are an engineering organization, and engineering
>always involves tradeoffs.  Some of these tradeoffs are not
>necessarily strictly technical, but involve real-world
>business/financial issues.

I do love those "real-world" arguments, implying that the opponent
is living on some other planet. So, for the record, I, also an Earthling,
believe that these tradeoffs must be made. Let's start:

        Is it OK for proposal X to allow active attack?

        Is it OK for proposal Y to allows both passive and active
        attack, perhaps in the theory that people or applications that
        use passwords as keys deserve to be hacked?

        Do Z, W, U, and V really work as advertised in preventing both
        active and passive attacks, and if so how much is it worth?

        Are X or Y truly less encumbered than the others, and if so,
        is this fact significant?  For example, has the WG established
        that costs would likely be onerous for anyone who implements
        any of the others?

I have no problem in letting the WG decide these things.

But the IETF *cannot* make proper business/engineering tradeoffs
by political fiat.  As an organization, the IETF cannot investigate pricing
or license policies.  And no decree from on high can take into
consideration the concerns or nuances of each specific application.
This is a job that must be done by individual WG members.
And they should not be discouraged or preempted from doing that job.

>The problem at this point is that the IP situation with respect to all
>of these schemes is cloudy, and that may prevent some companies from
>being able to implement the spec.  ...

No, the IP situation is very clear for several of the patented schemes.

>... Also, if any of these patent claims
>are true, then it certainly will rule out open-source, reference
>implementations from being able to fully implement the specification.
>Such reference implementations have for other working groups been a
>significant force towards helping assure interoperability. ...

That is false.  Open source and reference implementations are
no problem per-se for patented techniques.  Open source at a basic
level relates to copyright protection, not patents. And there are
several examples of open source software for patented methods.

>... (Also,
>consider that as Linux continues to make inroads into the server
>platforms, it would be a real shame if Linux were not able to make
>authenticated connections to iSCSI devices thanks to the patent
>issues; you'd be essentially eliminating part of the iSCSI device
>manufacturers' market thanks to the patent issue.)

Again, this is false.  Even that last requirement can be met.
While it is true that free use and distribution products like Linux
can pose a different problem for a patent holder, it is surmountable.
And finally, as you almost point out, all these interoperability
problems go away when a patented technique is standardized as
a SHOULD implement method.

>How important are these issues?  Well, I will be the first to admit
>that if some patented technology conferred overwhelming advantage over
>all other alternatives (such as back in the bad old days when RSA and
>D-H was the only game in town for doing public-key cryptography), then
>the concerns which I've articulated probably would not outweigh the
>technical advantage conferred by the IP-encumbered technology.  (And
>even in that case, the fact that the technology was encumbered
>probably delayed the wide-spread use of protocols which specified the
>use of public-key technology by close to a decade.)

First, you'll forgive me if I doubt that you'd be the *first* to
stand in line to use anybody's patent.  Let's be honest.
I do appreciate your role here.  Unnecessary encumbrances should be
discouraged.  So, in this case, why not lighten up on the preaching
and exaggeration, state the IETF policy, or, as you see it, the
general-but-unwritten IETF philosophy, and let people determine for
themselves how easy or hard it is to use such methods.  And if a
patented technique is still acceptable to the group, then so be it.

>In this particular case, however, I would submit that the advantage
>confered by using EKE, SPEKE, PDM, or other related technologies is at
>best marginal.  There are other technical solutions, which I've
>outlined above, that provide almost the same amount of protection,
>without having to deal with the headaches of settling with potentially
>two or three patent holders. . . .

Again, why exaggerate?  Anyone who properly investigates this field can
find out that, for several methods, there is exactly one patent holder, and
among these there is a clear and free choice of more than one such holder.
It is also obvious that different people have different views on the
significance of the technical benefits, and this is clearly a factor
in establishing a fair price.

>... We also avoid eliminating at one stroke
>all possibilities of compliant/legal open-source implementations of
>the technology.  Because of both downsides, in this particular case,
>the engineering tradeoffs simply isn't worth it.
>
>                                                        - Ted 

I'll argue the reverse.  With your "one stroke", you might prevent all
possibility of anyone benefitting from an entire class of technology.
THAT seems to be the bigger threat.

 From here on down, I feel compelled to make some philosophical points,
so readers purely focused on iSCSI should feel free to skip to the last
couple paragraphs, if indeed, you've held on this long.


Ted, I have no problem with your concerns, your *personal* philosophy,
or even the longstanding IETF tradition to prefer unpatented technology
to any *equivalent* patented technology.  I also have no problem with
you trying to focus on the need for these methods in specific narrow
times and places (which, incidently, sound like fine bargaining points
to negotiate a lower price).

But here's where I do see some big problems, only some of which are
actually contained in your message:

* I disagree with the somewhat arbitrary line you've drawn between active
and passive attacks.  It seems contrived to fit your agenda.

* I disagree with the concept of making *uninformed* business/engineering
tradeoffs.

* I disagree with idea of retrofitting requirements to fit certain methods,
which I believe that some people are trying to do.

* 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).

* I object to the idea of IETF watchdogs too-closely directing actions of a
working group, or discouraging them, especially using false statements,
from properly investigating relevant technical and business
issues to be able to make the necessary tradeoffs.

* I believe it is wrong for all IETF participants to promote an unwritten
extremist anti-patent agenda onto others in this or any working group.
I think that you, and others, should simply stop encouraging exaggerated
fears in this regard.

Patent infringement is not some criminal thing, like oh, say, a copyright
violation.  You can't go to jail over a patent.  The worst that might
happen is that a truly extreme infringer who gets caught might overpay.
In a majority of day-to-day cases of people using other people's patents,
nobody takes any real action or pays anything.  In this specific field there
is no monopoly position blocking this class of technology.  And if in the
worst case, should some patent holder abuse it's power and position,
the process is ultimately self-correcting as you yourself have argued.

Let's keep this in perspective.

The problem is that actions like yours may prevent people from being
able to obtain the benefits in the first place.  Using IETF standards are
important, and standardization is required for some people to invest in
using a technology.  No standards organization should create a blockade
to the legitimate use of any general class of patented technology.

And, for those people who have an inordinate fear that the mere mention in
an IETF standard of some patented technique will somehow establish a
huge business monopoly of some sort, all I can say is come back to Earth.
These documents don't have *that* much power.  The existence of a
standard doesn't compel any vendor to have to implement every little
thing in it, especially when there are alternatives.
People can always pick and choose what they want to implement,
based on value and price.  There are no standards-compliance
police twisting peoples arms.  It just doesn't work that way.

In the context of this working group, it appears to me that forces have
gathered to try to downgrade a MUST-implement security method to a MAY,
or to do away with it entirely, and in this process are retroactively adjusting
the requirements to fit certain techniques.  That this may be done without
full investigation of the actual cost of the tradeoff from a business
perspective, and with only hasty discussion of the technically equivalent
methods, as well as other non-equivalent tradeoffs, seems wrong to me.

The general practice of *avoiding* patents at any cost is damaging
to patent holders, and to the world at large.  Such a practice is forbidden
in other standards organizations, for these reasons.

Yes, we all know that IETF is a *different kind* of standards body.
I just think that you're promoting a too-extreme position in this regard.

All of this discussion may be premature, as I'm not absolutely sure that
password-based authentication was the real goal here.  I think there's good
evidence that this was indeed the case, after all, if not, then why SRP?
Yet, I believe that some participants may be afraid of the consequences
of speaking up, even to just discuss technical issues, for fear of violating
the default IETF religion. That is not a good thing.

If one of the goals here is to allow people to use passwords to authenticate
the establishment of these device connections, then I think there are many
paths to an optimal engineering solution.

If not a MUST, then why not a SHOULD for some variant of EKE, SPEKE, SRP, 
or an equivalent?

How about asking a vendor to back up their claim of being able to provide
this freely to all, as was suggested in Minneapolis?

Why not ask if people have ever had trouble licensing these schemes on
reasonable terms from any available sources?

I see several paths that can result in wide-scale deployment of optimally
engineered solutions here.  And where there are real (or "real-world")
requirements for strong password methods, I will do my best to get my
company to assist in this process.

-- David