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

    Re: iSCSI authentication requirements

    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
    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.
    >Make no mistake.  Patents have their costs.  If you want your protocol
    >to be widely deployed across the Internet, use of patented technology
    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.


Last updated: Sat Mar 30 18:18:20 2002
9397 messages in chronological order