Lots of these folks looked forward to blue skies and clear sailing after the patent expired, but this was not to be. New patent problems and subsequent licensing issues have plagued the security industry with a vengeance, especially regarding cryptography. This time, IPR (Intellectual Property Rights) is confusing work in both dual-mode operation (encrypt and authenticate in the same operation) and strong password modes. Unfortunately, IPR can -- and is -- halting standards development, resulting in limited or suboptimal solutions.
If today's IPR worries were as simple as the old RSA patents were, we might be able to move ahead with uniformed licensing so IPR-related technologies could be used in standards. However, these IPR issues make the RSA patent look like grade-school grammar. IPR involves multiple patents that claim rights in both dual-mode operation and strong password modes. Sadly, no clear licensing is available, fueling the fear that if a vendor licenses with one patent holder, another patent holder might win a large, bankruptcy-causing court settlement.
Strong password fields are of particular concern because they are needed in so many applications. There's been considerable deployment of SRP (Secure Remote Password, RFC 2945) in Unix, and Stanford University, which has a patent on SRP, has made the technology freely available. As such, SRP has been proposed in a number of IETF standards. However, all this time concern has been brewing over whether Lucent Technologies' EKE (Encrypted Key Exchange) patent trumps the SRP patent. Standards groups have made several attempts to induce Lucent to talk about its EKE patent -- to no avail. Even with Lucent's silence on the topic, few vendors have been willing to use SRP. To further cloud the situation, there's been a new patent issued claiming that it too covers SRP. In the U.S. patent field, the surfacing of a patent that predates an existing patent is not unheard of. This turn of events may well stop all strong password technology because few vendors are willing to risk a patent suit.
Where does all this leave strong passwords? You can set up an SSL/TLS (Transport Layer Security) connection and send your passwords through it. Yes it's overkill, but it works. But wait, that creates more patent confusion: SSL was patented by Netscape with the intention of protecting Dr. El Gamal's contribution and ensuring its open availability. Hmmm. Here's another fix: Public keys can be used directly, like with SSH (Secure Shell). Then again, isn't there a patent for that, too?
Don't Forget About Dual Mode
We're also losing another opportunity with dual-mode operation. One could argue it's not needed: Systems could always encrypt first then authenticate on a second pass, which is exactly what IPsec (IP security) and S/MIME do today. But dual-mode operations would be a relief for limited CPU systems, like PDAs and cell phones, as well as for very large S/MIME files. But with three patent holders in this arena, vendors will continue on their merry ways and throw more hardware at the performance problems rather than working toward better algorithms.
People and companies that contribute to our technology should be recognized and should receive reasonable compensation for their inventions and ideas. But no one benefits from restrictive licensing and a profusion of patent disputes. Unfortunately, given the nature of the patent world, it's highly unlikely that we will free ourselves from this tangled web. It's quite likely, however, that opportunities will be lost as less-than-best solutions are used to avoid legal and financial risks.
Robert Moskowitz is a senior technical director at TruSecure Corp. Send your comments on this column to him at firstname.lastname@example.org.