--------------245BCAB4CF6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Well, at least it's truth-in-advertising; this is how I think and what I
reacted to from last week...
Please feel free to contact me if you have any questions or concerns.
Thanks,
Rohit Khare
--- Rohit Khare -- World Wide Web Consortium -- Technical Staff w: 617/253-5884 -- f: 617/258-5999 -- h: 617/491-5030 NE43-344, MIT LCS, 545 Tech Square, Cambridge, MA 02139
Rohit Khare, March 24-28 1997, khare@alumni.caltech.edu
As I bounced from interview to interview this past Friday, it slowly dawned on me that I actually do have a role to play in defining the Teledesic Network. Sure, I've always been impressed by the individual team members I have met… and the audacious goals… and the plan. It never seemed like I needed to be here, though. Now, I do, and I want to explain at length why I feel the way I do. Part of it, a very large part of it, is the potential of the technology itself. A well-tempered security architecture at the base could improve wide range of services. The other part is the thrill of working with a very high-performance team. Common cause and total team dedication are what brought me to the Web Consortium and attracts me to the graduate research labs I'm considering.
In asking for your collective attention with this memo, I'd like to capture what I've been rolling around in my head furiously for the last few days with my closest friends, colleagues, and family. At the technical level, I've been speculating extensively about the role security technology will play in the Teledesic Network. I've also been reminded that I historically do a much more thorough job of providing recruiting background information, and I may not have highlighted my relevant qualifications to each interviewer. Finally, I've reexamined my motivations and future plans for signs of a decisive interest in Teledesic. Hopefully these three kinds of information can help you better define a potential role, and argue why I might fill it.
[I apologize that this is coming in right before the 4/28 hiring meeting, and that I've been out of communication for the week. As the first 'tenured' staff member to potentially resign W3C, I've attracted a lot of very long therapeutic meetings…]
As many of you have heard, I first seriously examined the Teledesic concept when I met Mark Lundstrom and debated whether he should join Teledesic (though he seemed 100% certain without my advice, to be sure… :-). My major concern was, and is, that Teledesic could be radically affected by software evolution on the ground. I have more to say about that scenario later. For now, though, I'll just extract the concern that Teledesic will have to track and implement many open Internet standards with one hand tied behind its back: there are no upgrade kits in low Earth orbit. While Teledesic's service model may be unperturbed by radical application-layer innovations, security is a prime example of continuously evolving link-layer technology which will intimately affect satellite and ground equipment.
[Apologies for the rambling and potentially simplistic treatment which follows.]
The Teledesic Network initially comprises 840 satellites in 22 orbital planes, each with 1 Gbps capacity to the ground. Each satellite is also a powerful data switch, since packets are delivered across the constellation. Approximated as a torus mesh router, the maximum path length implies approximately 20Gbps bandwidth across a satellite, initially. Ground stations advertise data-channel services from 16kbits to 2Mbps and special-purpose 1Gbps links. Up to 1800 ground stations could be visible per scan cycle (which is about 500Hz). The underlying communications channels are divided into 64-byte cells in an ATM-like model.
Teledesic apparently intends to sell fixed-capacity data pipes, closely modeled on the fiber service model. The key security distinction is that terrestrial fiber users have a presumption of physical security: it should be expensive and traceable to tap into the actual bitstream -- regardless of whether end-to-end security is protecting that traffic. To encourage confidence in the Teledesic Network, it seems sufficient to provide channel security services. Later, I will argue that richer security services can effectively increase the range of service models Teledesic can resell. Closer integration with application-layer security and internal adoption of open Internet standards could facilitate more available-bit-rate users and encourage application-specific Teledesic deployment.
The fundamental issue in security architecture analysis is isolating where the trust lies, in what roles. This step can be deceptively difficult, since so many cipheranalysis and security products all emphasize the mathematical. Trust is a business/social issue, not a technical one. Of course, this is more acute in the context of e-mail, authentication, and other application-layer services, but it applies to hardware, too. In this case, we have it easy: our initial attempt only establishes trust between terminals and satellites in order to provide internal channel security. Of course, we may need to establish trust in the terminals themselves, by using secure coprocessors to authorize end-users and entrust the main hardware (and this could, in turn, be on a smart card…). Satellites, we'd assume, should trust each other, but are we sure? Should our threat model address rogue satellites, given the international (political) security influence of the Teledesic Network? When a device goes haywire, do we revoke its certificate while diagnosing it?
Some of these are decidedly open questions for an open-systems environment, but we can control the standards throughout the Teledesic Network. We can also simplify the problem a bit from the general case. So far, we haven't had to consider anything pesky like authorizing (human) users. Nevertheless, just in a client-server world, we already have accounting and billing issues which could require authentication and systemwide checks (can an account access the net from two locations simultaneously?). We also have to consider collective trust issues: even if an individual terminal can present adequate credentials, can it trust the others not to greedily subvert multiple-access contention schemes?
We also have performance constraints which affect the security architecture, namely the need to loft very-long-lifetime, very-high-performance switching gear. Indeed, the zero-th order solution is to keep the constellation traffic in the clear, pushing security to the endpoints. The tradeoff is a global key-distribution problem which challenges each terminal to cache and validate the identity of every other terminal or terminal-group (see discussion below of broadcast and anycast services). Of course, dropping a cheap PC Card hard drive into each ground terminal could be cheap enough to handle this.
At the other extreme, we could use strict link-by-link encryption which fixes the potential addresses to the set of satellites. Each terminal communicates with its current uplink using its flash ROM tables; each link is encrypted between constellation members; and each downlink is batched and enciphered on its own.
That last comment highlights the performance-sensitivity of this approach. On the uplink, decrypting scattered cells interleaved from all the visible terminals could be possible at 1Gbps, but not for millions of constantly-changing keys. If we assume that uplink signals cannot be intercepted from the ground it makes sense to use a common encryption key. The entire cell can see the downlink traffic, though. Now we could leverage the 500 Hz system heartbeat to presort and batch each terminal's traffic through a pipelined key-setup and encryption phase to uniquely protect each terminal's traffic.
I have to admit, even I first latched upon the latter scenario, drawing up charts of the interconnect latency, performance of known stream ciphers, and key-change rates. Security hackers love to over-secure, too. There is an altogether separate knack for security architects: to decide what makes the most sense systemwide.
As I intimated by my earlier PC Card comment, I believe that we're best off defining away active intra-constellation threats and thunking the problem to the ground. Now we're out of "telecom" mode, and closer to "Internet" thinking; perhaps we could even directly adapt IPSec and IPv6 over our 64-byte cell layer. Again, we have magnified our key-distribution challenges, but we have reduced the investment in space to simply checking if terminal certificates have been properly validated by the Teledesic Certification Authority or its delegated resellers.
This allows us to ride the COTS curve, too. No matter how perplexing millions-to-millions key management seems, it will be a shadow of the problems facing the terrestrial Internet. Nevertheless, there are Teledesic-specific issues, too. Multicast and anycast group addressing (without relying on re-encryption by intermediate routers) implies prearranging shared group keys which expands the key database and could weaken operational security (because of the number of devices sharing secret keys). These are not exceptional applications, either: real-time multimedia and digital package delivery will be popular drivers. Another unique scenario is a global partner ISP which "teleports" packets to/from the terrestrial Internet from many locations around the globe. When the destination is not a Teledesic-connected terminal user, traffic can be downlinked to any convenient gateway -- all of which would have to share a single private key.
Outer space is a pretty good approximation of physical vacuum, but politics abhors one even more deeply than Mother Nature. The Teledesic Network is going to affect and be affected by a wide range of policy issues, not the least of which turn on citizen's right to secure communications. Export control on the ground may be weakened by the next decade, but probably at the cost of moving more of the 'government control' burden into the network itself. This drags the satellite hardware back into the picture: how will we protect connection data, terminal locations, transmission contents, and so on from attackers but perhaps leave back doors for governments?
Even without political pressure, there is good commercial reason to consider these requirements. Teledesic has its own audit and diagnostic access rights. Clients can rightfully demand integration with key-escrow services. Resellers can battle over who owns a customer; who authenticates a user with a roaming-access smart card? Policy flexibility -- negotiation -- in the software architecture becomes critical. We are asking to predict social and technological security policies fifteen years into the future…
There are other requirements arising within the Teledesic Network. Once it was put as, "We can't be having high-school kids deorbiting satellites on a lark, eh?" The ground control systems and intraconstellation control systems must be protected quite separately from user security services. Here, we can consult existing military and corporate experience within a closed system. We have to certify these systems will remain secure in theory and in practice (predicted factoring attack evolution) for their entire operational lifetime.
At the next network layer, there are other juicy targets for denial-of-service attacks. The address, location, and routing tables are all vulnerable targets. DNS and routing security is even now just emerging on the Internet, so we could face a steep learning curve here. This information can not only be used to interfere with the network, but also could compromise user privacy. Directory services, billing, and key distribution are user-management services which must be handled well too -- who can see these bits, and why, and from where? Finally, resource reservation is an example of an upper-layer network service to be protected; it's the essence of a service guarantee our business model might dictate.
Of course, it's always fair to ask why systems ship with as little security as they do. In large measure, it's because it doesn't make enough of an impact on the immediate bottom line. In this case, the Devil's advocate should demand, "Why secure Teledesic Network traffic at all?" -- we sell rope, let users hang what they may…
We need to provide security at three levels for three reasons:
The Teledesic Network offers unique challenges for its security architecture. A primary requirement is to keep the evolution and processing burden on the ground, not in the core of your network 400 miles up. The second is to be flexible, to cope with the rapidly evolving threat board and social/technical expectations for security. Only third is to be compatible, to look-and-feel like a fiber IP network. It's last but not least -- Teledesic's long-term ace in the hole will be drop-in compatibility with tomorrow's Internet. To meet these goals, Teledesic needs a security team with skills in traditional analysis and design, but also a healthy dollop of visionary outreach to engage the user community.
I was a bit taken aback when I realized the quick one-page resume I dashed off two weeks ago ended up as some interviewers' complete background dossier. No, it's complete, and I fully stand by it, but I realized how much I changed from the callow undergraduate who mailed off 1/2" binders for graduate applications. Now that I've got a clearer picture of what Teledesic is looking for, I'd like to highlight a few aspects of my background:
I began working at W3C in the thick of the Web security wars (SSL vs. S-HTTP). I became a voracious student of cryptographic protocols and the industry structure. I organized primers, meetings, proposals, and more. I expanded our charter from HTTP security to considering the security of mobile code, content labels, HTML form design, and so many more aspects. The highlight of my first year was SEA, the Security Extension Architecture. As that project grew, I refined the first element of Signature-Encryption-Authentication into the Digital Signature Initiative, which I wrote an top-level and SigLabel architecture documents for: and. Along the way, I organized workshops and spoke at dozens of events on the general topic of Web Security and trust.
I also developed the underlying technology into a full-blown HTTP extension protocol. This led me into other areas, like electronic payment negotiation, intellectual property rights, and demographic analysis. I've also been personally active in academic conferences about the economics and administrative structure of the Internet.
My web site says more about my professional background, including a 1995-7 vita update. To summarize the impact of all the last two years' experience, it's that I've learned how innovation spreads outside the cubicle: how to develop strategy, align forces, ride the public standards process, and leverage a clean architecture.
Here at the Consortium, one of the senior managers confronted me by asking, "When do you expect to make your mark? I thought you'd want to make it here…" To speak with the brash authority of youth, I had to explain I'm aiming at something even more ambitious. Web technology? Been there, done that, about to get the T-Shirt. That's why the book projects I mentioned to some of you are so important to me: to capture what I/W3C have learned about Principles of Information Architecture and Web Design.
Looking further out, though, I want to drive the deconstruction of the Internet. I think there are fundamental organizational paradoxes at the heart of the Internet infrastructure. There's a lot of hidden centralization and single-network-image thinking underneath the covers which I don't believe respects the biological model of peer-to-peer autonomy. In the very long-term, I think third-generation wireless systems, with every-cellphone-a-router, will upset this order (is that an evocative term? It's from the satellite network literature I researched this weekend).
Teledesic is not that network. Of course not. I'm ready to say it could be the next stepping stone, mutually beneficial for us both. Security and identity are the dual critical issues I can best address for Teledesic and my future vision, so I believe this could be a good fit. Last, but not least, I want the experience of working with this team. I've learned from many of my mentors how rare, and how gratifying, it is to really click into a high-performance single-minded team.
As much enthusiasm as I share for Teledesic's prospects and my potential role there, I also realize we've only addressed the tip of the iceberg. I'm sure you can understand I'm trying to juggle many options for 1997. The primary forcing function for me is UC Irvine's April 15 deadline and secondary pressure from W3C to define my scope of action. In an ideal world, I'd like to hear back from Teledesic next week.
I am back in Los Angeles tonight (3/28) through Tuesday night. I will be in San Francisco April 3-13. Longer-term, I'm planning on traveling the world during May, in order to resettle somewhere June 1.