|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI authentication requirementsTed, 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
Home Last updated: Fri Mar 29 14:18:18 2002 9382 messages in chronological order |