Jeff’s Blog

In today’s (February 15^th, 2009) New York Times there is an article by John Markoff titled “Do we need a new Internet.” It asks this question because today’s Internet is a security mess. So let me take a crack at an answer…

No

The Internet isn’t the problem. The Internet does just what it is supposed to do, it allows us to route traffic from one place to another as efficiently as possible. It many ways it is just like a highway and road system. Some has posited that the Internet Users are the problem. It is easy to see why one might believe this. People install untrusted software on their computers all the time, they answer “phishing” mail revealing their passwords (and other sensitive information), the list goes on.

Yet, you don’t get to replace the users. People are people and will continue to be so. So what can we do?

The road system gives us some hints…. But let me digress for a second. In my earlier days I took flying lessons (I gave it up for a variety of reasons, not the least of which was the cost, and I was a starving graduate student). To get a pilot’s license you truly have to demonstrate competence. It was interesting to see the contrast with a driver’s license, where quite frankly, you don’t. A driver’s test really only requires a minimum of competence, otherwise too many people would be excluded. Yet, highway accidents and fatalities are at acceptable levels (at least to most people for we don’t see a significant demand for change!). Why is this? Well for one things there are engineering decisions (and regulations that codify them in some cases) built into the road/car ecosystem to make roads safer then they otherwise would be. To go back to flying, impacts that are fatal to a plane are often survivable in a car. Cars have been designed to provide for a safer environment, even when faced with a marginally qualified driving public.

We need to do the same thing to the Internet. And interestingly it isn’t the Internet so much as the computers people use that needs to be changed. Some have called for an “Internet Drivers License.” If you think of that as an identity document, we already have one. It is your password. Yet this is part of the problem, people share their passwords way too much. Imagine for a moment if every person you showed your driver’s license to also received an identical copy that they could then use to impersonate you. You would have the situation we have today with passwords. Every time you use your password you give a copy to someone else (in most cases the server) which can then be compromised.

So what should we do… Well I won’t presume to have all of the answers, but here is a start:

• We need safer computers. Computers that don’t permit the installation trivially of malware and viruses. Apple has been quietly moving in this direction with Mac OS X which as of Leopard has most binaries digitally signed as well as some interesting “sandboxing” technology for Internet facing applications. The iPhone is another good example of a sandboxing platform. Third party applications are quite restricted in what they can do on the iPhone.
• We need to replace passwords with a technology that doesn’t effectively copy your credentials every time you use them. There are several alternatives from X.509 digital certificates to one time password tokens. These technologies are not without their problems, but they can prevent the kind of rampant phishing that we see today.

So how do we start…

OK, so how does a credit card work? Well let’s see. We have a number, which we need to keep secret. If a “bad guy” learns it, they can use it to charge against us… and otherwise impersonate us.

However in order to use it we need to share it with individuals and organizations that we have no fundamental reason to trust! What’s wrong with this picture?

Yet, for years before the Internet boom, this business practice worked fine. Perhaps that was because in the event of fraud, it was easier to track it down as shared numbers couldn’t be zapped across the globe in a matter of seconds. There was “friction” in the transfer of information.

But the Internet has made the friction go away. So now we have attackers breaking into servers and stealing millions of card numbers. We have attacks where numbers are stolen quasi in-flight. There will be more ways card numbers are stolen in the future.

The payment card industry has attempted to address merchant security with its security standards. But these standards have to recognize practical limitations, so they leave holes (and in some cases they require steps that are costly, but add minimal security). The problem is once you have standards such as this, it isn’t about security anymore, but about compliance. You hear of companies who have positions with titles such as “Chief Compliance Officer.” Yet compliance doesn’t ensure security. In fact it can reduce it because it doesn’t value actions that improve security but do not improve compliance!

But let’s get back to the fundamentals. What’s Wrong with this Picture? There is a fundamental disconnect when we have a secret value that we *must* share widely. We need a better solution. And they are out there… but it will require a major change in how credit cards work. So the question is, how much more money needs to be lost and how many more people need to be inconvenienced before the trade-off leans toward solving this fundamental disconnect?

I am a member of the Internet Engineering Task Force (IETF), and have been from very close to “the beginning” having attended over 50 meetings of the group. In the 1990’s the IETF developed what is now known as IPv6, the next generation of the Internet Protocol (the current generation is referred to as IPv4).

As early as 1988 (long before the Internet “boom”) members of the IETF recognized that the IPv4 architecture had fundamental limitations that would cause it to not be able to scale to a global scale network. Around 1991 the IETF started to address this with its Routing and Addressing Group (ROAD Group). The ROAD group went off to define the problem and look at solutions. One of the early papers was entitled “One Question, Three Problems, Seven Solutions” (I have been unable to find a copy of it on-line!). The “One Question” was something [I'm working from memory hear] like “Will the Internet Succeed?” meaning “Do we have to solve the three problems.” The paper answered this question by stating that it didn’t matter if the Internet succeeded or not, we had to solve the three problem, just in case…

The three problems were:

1. Running out of class “B” addresses (don’t worry if you don’t know what this means).
2. The Internet Routing Table was growing too rapidly for technology to keep up.
3. Running out of Internet Addresses in general.

The paper then went on to propose seven ways to address the three questions. Unfortunately there were seven ways, not one. One of the things that I have learned is that technical people (read, the kind of people at the IETF in the early 1990’s) have a hard time selecting between proposals of roughly equal merit. What ensued was an messy process that resulted in some proposals loosing support and other proposals merging until we finally wound up with what would become IPv6.

So how did IPv6 solve the three problems. Well for one thing it expanded the size of IP addresses from 32 bits (not enough for everyone to have one…) to 128 bits (enough to give one to every light switch on earth). It introduced the notion that people would not have their own IP address ranges, but would get a “sub-block” from their Internet Service Provider (ISP). This would keep the routing tables at the core of the Internet reasonably small because they would not have to have a route for every user and institution but instead only for each major ISP. But when an enterprise changed ISP, it would have to assign new addresses to all of its computers. So one of the key goals of IPv6 was to make this process easy (as opposed to be very hard under IPv4). Oh, and to encourage adoption of IPv6, the IETF made the security portions of the standard “mandatory” to implement so that the IPv6 networking world would in theory be more secure then the IPv4 world.

IPv6 was mostly completed by 1996 and made a “DRAFT” standard (which unlike its name implies, is a very stable IETF standard) in 1998. So where are we today…

Well, IPv6 hasn’t really taken off. It has been 9 years since it was declared a DRAFT standard, and yet deployment has been minuscule. Why is that?

There are several reasons:

1. IPv6 is not compatible with IPv4, there is no incremental upgrade path.
2. Other “hacks” have been deployed in the IPv4 network to extend its ability to scale, so there is no strong business driver.
3. To work all end-point computers need to support IPv6.
4. It is just harder to work with for people familiar with IPv4 technology. Some people may scoff at me when I say this…. but one of the problems is that you cannot “talk about” an IPv6 address and you can about an IPv4 address. Just the way we choose to represent addresses when we write them down and when we talk about them matters!

For example an IPv4 address might be 18.7.21.1. Whereas an IPv6 address is something like: fe80::20c:29ff:fe97:d844/64. You can say the former simply as “Eighteen dot seven dot twenty one dot one.” Go ahead, say the IPv6 address out loud!

Another failure has been provider based addressing (getting your addresses as a sub-block of your ISP). Easy re-numbering (say if you want to switch providers) has just never really come about. It is a hard problem! Finally, provider based addressing doesn’t solve the case of an institution connected to multiple ISPs (as is common for many enterprises in the 21^st century Internet).

But perhaps the two biggest reasons are the lack of business driver and the hacks done to preserve IPv4. One of the important properties of the hacks is that they have been incrementally deployable and in general they do not require changes on all of the end-point computers.

So what do we need to do?

Perhaps its is time to admit that IPv6 was too little too early… A new architecture is needed. For one thing we need a new layer of abstraction called “end point identifiers” which are addresses for devices that are independent of the routing layer of the Internet. They would remain constant even when an institution changes ISP. The addresses that would change would be quasi invisible, mapped by a protocol from an end-point identifier. This is not a new idea. Such concepts were discussed back in 1991, but were just too radical to make it into IPv6.

We also need to develop a new protocol that is incrementally deployable on today’s Internet. IPv6 required too much of a “fork lift” upgrade to be successful. Unfortunately I don’t have any easy answers on how to do this. I just know that we need to figure this one out. We need a “bridge” from today’s Internet to the Internet of the future.

Make no mistake, we will have to solve these problems. IPv4’s days are probably numbered (exactly what those numbers are is subject to debate) there will be a day when the hacks run out or fail and no new computers can be connected to the Internet. Will this result in a fork lift upgrade to IPv6… or to something newer and better…

I have been involved in Internet Security for about 20 or so years. One of the holy grails that we have pursued is the global Internet Authentication system. In the 1980’s we developed Kerberos at MIT. Kerberos was one of the first practical cryptographic based authentication systems on the Internet. Prior to the advent of Kerberos you authenticated yourself by providing a user name and a password, in the clear over the network where they could be intercepted by anyone with the wherewithal to eavesdrop on the network. Kerberos permits you to prove who you are without revealing anything to a network eavesdropper that would permit them to impersonate you.

However Kerberos is an enterprise solution. It assumes a common management domain which issues user names and (Kerberos protected) passwords. Although Kerberos supports connections between “realms,” this is setup via bi-lateral arrangements. This works, but it doesn’t scale to the size of the global Internet.

In the early 1990’s when the Netscape browser first became popular, the folks at Netscape realized that the web could not be used for commerce unless there was some way of providing authentication and encryption of sensitive information in flight. The solution was Public Key Encryption. With Public Key Encryption you have two keys, one public and the other private. You can prove who you are by signing a datum with the private key. This “signature” can then be verified using the public key. As long as you know that you have the correct public key, you can validate the signature.

The trick is how you know you have someone’s public key. The idea in the 1990’s is that we would have a global X.509 based “certificate” infrastructure. A certificate is a data item, itself signed, that associates a public key with a person’s identity. Using certificates we can build a hierarchy that permits any browser to validate any server and any web server to validate any web user that has a certificate.

But it didn’t work out that way. In part this was because of greed, policy wonking and lawyers. Add to this technology that was complicated to understand and use and the seeds of failure were well planted.

Greed: Some folks wanted to setup the system so that they would profit from every certificate issued. Imagine the income if every Internet user paid you $25/year!

Policy Wonking and Lawyering: Some folks assumed that getting authentication credentials would be such an important process, that people would put up with significant hassle to obtain credentials (say, visit a notary public, show two forms of ID, mail off a paper application (with your $25 check) and then wait days or weeks for the credential to be issued!

In the end, server certificates succeeded, particularly since the infrastructure evolved so that there was competition in certificate issuers (competition = customer service!). But client certificates, those issued to individuals to prove their identity, have totally flopped.

In the meantime, a global identity system has evolved behind the scenes on the Internet. What is it? Its your e-mail address. Ultimately you prove yourself by demonstrating that you can read e-mail sent to your purported e-mail address. Most websites today that desire authenticating their users have some system where you establish an account on the site and provide your e-mail address. If you forget your password (common on a site you may only use occasionally) the site can mail it (or a new one) to you. So being able to read your e-mail translates into proving your identity. Problem solved, QED.

Why does this work:

• Everyone has an e-mail address, it is universal and ubiquitous.
• Everyone knows how to use e-mail.
• No policy mavens got involved early and made getting an e-mail address hard!
• Ultimately your e-mail address is your unique identifier.

Of course this works because of the domain name system (DNS). The DNS provides for a globally unique way of identifying resources on the Internet and its management has evolved in a reasonable fashion (this may be controversial because people do have issues with ICANN, the organization that in theory is responsible for managing the DNS. However this is beyond the scope of this post. Perhaps I will address it in a future post).

But perhaps the most important point is that e-mail addresses just work. There is no need for sites to enter into bilateral agreements to send mail to people. I.e. If I have an e-mail address at MIT (aka @mit.edu) and I use that to register at frobs.com. There doesn’t need to be any technical arrangement or legal agreement between frobs.com and MIT in order for me to have frobs.com e-mail me a new password!

Which brings me to my final point. Check out http://openid.net. OpenID may well become an important authentication technology on the Internet (if not the authentication on the Internet). Why? Because like using e-mail addresses, there is no need for complicated bilateral technical arrangements nor legal agreements. It just works.

The Internet came to be because of technology that could be deployed and used. The most important property of that technology is that it “just worked.” OpenID just works… check it out.

OK. So this is my first “Journal” entry. Its interesting. I have always considered myself a techno type of person, but this trend of writing a journal on-line is a bit strange to me. But what the heck, here goes!

So whom am I. Well I am a technologist, manager (at times), Network Hacker (I was there when the Internet was born) [and no, Al Gore was not next to me at the time, but he was involved!] on January 1^st 1983, perhaps I will talk about that in another entry). I am a Security guru. For 9 years I was a Security Area Director of the Internet Engineering Task Force (IETF). That meant that I was responsible for reviewing Security standards of the Internet (and managing the working groups creating them) as well as looking over all Internet Standard from a security perspective.

I live with my wife and  young son in the Boston area and work at MIT (http://web.mit.edu). We raise Cavies (a Cavy is a Guinea Pig) and are members of the Essex County Rabbit and Cavy Breeders. (http://www.ecrcba.org). I am currently serving as the president of the association. You can see us at the Topsfield Fair in the Rabbit Barn each fall (http://www.topsfieldfair.org).

Well, that’s enough for now. we’ll see how this thing evolves and I’ll get pictures of my Guinea Pigs up here too. Update: Pictures of my Guinea Pigs can be found on my home page at http://jis.mit.edu.