[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI authentication requirements

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


Last updated: Fri Mar 29 14:18:18 2002
9382 messages in chronological order