Burton Group Weblogs\Jamie Lewis : Opinions from Burton Group's CEO and Research Chair
Updated: 3/10/2003; 2:01:40 PM.



Subscribe to "Burton Group Weblogs\Jamie Lewis" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.


Sunday, March 09, 2003

As I indicated in an earlier, post, we're getting Weblogs up and running on the Burton Group site, and this blog was an early experimentation leading up to that. I've been posting here to keep things going, but am in the process of moving my blog to www.burtongroup.com/weblogs/jamielewis. It may take a few days to get the kinks out, so please bear with use while we get that going, but things should be working early next week. See you there.

12:42:40 PM    

Saturday, March 08, 2003

Doc Searles has a great overview in Linux Journal of the players and issues involved in SCO's recently filed suit against IBM.

11:50:15 AM    

Friday, March 07, 2003


11:12:57 AM    

Thursday, March 06, 2003

I've been playing around with Titles and Links in Radio, as well as trunacting the RSS feed, so forgive me while I tweak this a bit . . .

1:36:12 PM    

If you haven't read "True Names" yet . . .

People have been talking about Vernor Vinge’s novella “True Names” for quite a while. It’s particularly relevant to the digital identity and identity management discussion because Vinge, well before folks like William Gibson, not only anticipated cyberspace, but the potential benefits and dangers of digital identity in cyberspace. That Vinge wrote it in 1981 makes it all the more remarkable.


I bring this up only because I recently read True Names: And the Opening of the Cyberspace Frontier. This book couples the novella with essays written by a wide variety of interesting folks, many from technology circles, who comment on how Vinge’s story relates to the evolution of the Internet to date, and its future. It’s all the more interesting because many of the essays pre-date the bursting of the technology market bubble. (The book was published in 1999.) To see how things have changed and how some folks were still thinking clearly back then (and some folks weren’t) is quite interesting. In particular, the essays by Timothy Mays ("True Nyms and Crypto Anarchy") and Alex Wexelblat ("How is the NII Like a Prison?") will give anyone contemplating the implications of digital identity a lot to chew on. The many references to Bruce Sterling’s “four horseman of the modern apocalypse” (terrorists, pornographers, drug dealers, and the Mafia) are eerily resonant today.


I’ll have to admit that I don’t like the way the book was organized; it puts Vinge’s novella at the end. After first attempting to read it in the order the editor intended, I cheated, skipping to the back and reading “True Names” and then reading the commentary. Made the essays—and the references to the novella they contain—much more meaningful.


Still, it’s highly recommended reading.

12:08:25 PM    

US Federal Government Supports Liberty

The Liberty Alliance announced that the General Services Administration (GSA) and the US Department of Defense (DoD) have joined the organization. When you combine these obviously important government agencies with the large number of corporations that have joined the Alliance, it’s clear that Liberty has critical mass.


The GSA’s and DoD’s decision to join the Alliance has a couple of important implications. First, the government’s involvement can help speed the development of the legal and technical infrastructure necessary to enable federation, increasing the legitimacy of whole effort. The US federal government has been working on many identity fronts, whether it’s the Federal PKI project, a variety of smart card deployment projects, as well as the more recent eAuthentication initiative. (Phil Becker makes these same points on the Digital ID World blog.) Things will move forward if the government, building on the Liberty spec, establishes a means by which companies doing business with the government can federate identity with the government. As these government agencies establish legal and technical frameworks for federation on which they rely, many businesses will feel more comfortable in moving ahead, relying on some of those same legal and technical frameworks.


Second, the federal government’s involvement in Liberty could, at least in theory, lead to a stronger push toward international federation agreements. As Craig Mundie, Microsoft’s CTO, pointed out in his speech at Digital ID World last year, we haven’t even really begun to define how governments, which typically feel they have sovereign rights to manage identity within their borders, will federate identity internationally. Mundie has been working with folks like Lawrence Lessig and Esther Dyson under the auspices of the Center for Strategic and Internal Studies to generate recommendations to the world’s governments on how to federate digital identity in cyberspace. But governments have to get their toe in the federation waters before things move, so maybe this will start to catalyze those efforts.


Liberty’s building momentum is also good news for the Security Assertion Markup Language (SAML), which Liberty based its spec on. SAML continues to show strong momentum, providing a starting point for federated identity. Microsoft and IBM are promising a WS-Federation specification, and Microsoft continues to push XrML as a more robust assertion model. But SAML, precisely because it was narrowly scoped, was completed quickly and vendors are implementing it. If the government moves to implement the Liberty spec in its own identity efforts, it will further strengthen the case for SAML.


We’ll be releasing a report on Liberty and where the organization is headed next week.

10:15:03 AM    

Wednesday, March 05, 2003

A classic case of privacy vs. security . . . and hope for a better way?

In identity management circles, arguments inevitably come down to the inherent conflict between security and privacy. Well-intentioned privacy advocates want complete anonymity, because that eliminates any privacy problem. Well-intentioned security people -- who are likely to get the blame when and if the next terrorist attack happens -- want verifiable identity. The flap over Delta Airlines' decision to test the CAPPS II security system, which will run credit checks on airline passengers and assign a security rating to each, is just the latest example of what will be many skirmishes on the border between privacy and security. But perhaps something like this--which at least has the potential to provide a better approach--gives us a better balance. Time will tell.

11:41:35 AM    

Reinventing PKI: Federated Identity and the Path to Practical Public Key Security

Identity management discussions often lead to a discussion of public key infrastructure (PKI) and its long-term prospects. In theory, X.509 PKI—as defined by the IETF PKIX working group—was supposed to address the identity problem many years ago, providing authorities to certify identity, and a means for authenticating and verifying identity through cryptographic techniques. Indeed, there were even proposals for attribute certificates, which attempted to address the authorization and privilege management side of the equation with an integrated PKI.


In practice, however, X.509 PKI fell well below expectations. The list of problems is, by now, familiar to any security professional. PKI is expensive and hard to manage, even harder to use for the average human, and implementations lack the broad interoperability the standards promised. Consequently, it’s much more popular to talk about federation and the loosely coupled Web services model, and it’s become somewhat fashionable to poke fun at PKI.


I’m a strong advocate of the federated security model. Instead of everyone agreeing on one security system, the federated model allows enterprises to use different security mechanisms, such as username/password pairs, Kerberos, or security tokens. Federation standards create a mechanism by which these different systems can exchange security information, without in-depth knowledge of the security services on each side of the agreement. For example, the Securities Assertion Markup Language (SAML) defines authentication and authorization assertions. As long security systems can consume and produce the standard assertion format, they can interoperate in a federated model for Web-based single sign-on.


While this more loosely coupled model has obvious advantages, however, federation ultimately brings us back to some of the same hard problems we faced with PKI. Using a new, hip term like “federation” doesn’t solve the tough problem of creating trust models that allow enterprises to exchange and rely on assertions, for example. And if enterprises are going to use assertions for high-value transactions, then they’ll need to verify both the source and integrity of the assertion, which means we need digital signatures. In fact, many PKI diehards will look at authorization assertions as defined by SAML, XrML, and other specifications and call them attribute certificates. And from one perspective, they’re right.


So What’s Different?


Does this mean we’re right back where we started with PKI? Well, yes and no. While some of the same hard problems remain, we’re now on a more pragmatic path toward solving those problems. Web services and XML have the potential to re-invent PKI as we’ve known it, creating a more usable public key security model.


The first step on that path is to separate the concept of public key security from the implementation of that concept known as X.509 PKI. Public key cryptography provides an elegant method of supporting authentication, confidentiality, and integrity in a distributed system. It remains a fundamental element of distributed security. As an implementation of public key security, X.509 PKI, as defined by PKIX, provided some valuable lessons, both good and bad. We need to apply those lessons as we re-think security and create practical ways to use public key security.


In addition, a workable security model must be well-aligned with a workable application development model. PKI developer toolkits and application interfaces have typically been vendor-specific. The infrastructure itself was heavy-weight and completely orthogonal to the applications use every day. Developing PKI-enabled applications was too hard, and was never well-aligned with the way most developers build applications. The complexities of ASN.1 encoding and certificate path processing are far beyond the basic Web programmer, for example. We need to relieve client-side and browser-based applications of as much complexity as possible through better abstractions, ensuring that developers can easily leverage public key security within a familiar and usable development framework.


Web Services and Federation


The Web services framework and the notion of federated identity management

are addressing these needs. Consider how the SAML assertion model relates to PKI as we’ve known it. Under the PKIX model, before companies could have interoperable security, every user would have at least two key-pairs and certificates, one for signing and one for encryption. Companies then faced the difficult prospect of cross-certification or joining a hierarchical trust model that made interoperability difficult. And given the different grades of signatures one could may have to provide, it was likely that each user would have more than two key-pairs and associated certificates, which leads to the management nightmare that most organizations faced with enterprise-wide PKI.


Under the assertion model, enterprises can get started with security interoperability by using existing authentication systems. Instead of each user having a bunch of keys (and certificates) for signing, the company signs the assertions. Users log in to the systems they use every day. So-called “assertion authorities” within the organization sign outgoing authentication assertions. The authority could even assign different grades to assertions (by using different key pairs), depending on the strength of the underlying authentication systems. Logins from user ID/password pairs over HTTP may get a grade of one (out of ten), for example, while an authentication against a Kerberos server may get a seven.


Because such interoperability will usually start where business affinities already exist, enterprises can use contracts with suppliers, partners, and other business constituents to define the trust environment, building on existing relationships. They can define the liabilities they’re assuming—and what they are in fact asserting—for each grade of assertion they issue. So instead of certificate populations that quickly reach the tens of thousands, the enterprise may need only a handful of signing keys and certificates to run the assertion system. Instead of having to deploy enterprise-wide PKI in order to interoperate, the assertion model allows them to get started with public key security in a small, but important way. Those enterprises that wish to deploy PKI for smartcard authentication systems or other purposes can still do so, but it’s not a pre-requisite for participating in a global identity environment.


Liberty and Circles of Trust


From there, it’s only a small leap to the “circle of trust” model that the Liberty Alliance has defined in its version 1.1 specification. Circles of trust are federations between identity domains with business relationships based on Liberty Alliance architecture and operational agreements. Within such an arrangement, identity domains keep a list of authorized “identity providers” from whom they’ll accept identity assertions, and a list of authorized “service providers” to whom they’ll send assertions. The format of this configuration is a local matter and could be represented as lists of names or as sets of X.509 certificates of other circle-of-trust members (recommended). The certificates and associated keys are used to validate the assertions that members of the circle of trust send to each other. (Somewhere, Phil Zimmerman of PGP fame is saying “I told you so”.)


Instead of inventing a global trust hierarchy that we all have to agree on, Liberty wisely leveraged SAML to create a more organic model, one that fits the way companies to business today. For example, the Liberty specification will add key services that make SAML more useful, including:


·        Account, or profile linking across different applications in the same company, or different companies

·        Permission-based attribute sharing (in an upcoming specification)

·        Authentication metadata that will allow security systems or applications to determine the quality of user authentication a federated service uses


The point here is that SAML, Liberty, and federated identity efforts are starting to define the real-world use cases for trust and authentication, something that X.509 PKI never really delivered. Without this kind of meat on the bones, PKI was a non-starter. In one sense, then, federation is an application that can leverage public key security for trust. But federation as conceived by Liberty and SAML does not require “in your face” PKI. Rather, it embeds public key security in the infrastructure, making it more usable. Other applications and infrastructure—such as transaction systems and VPNs—can also leverage embedded public key security. There is no grand “PKI in the sky”, just sensible incremental use of public key security, which will remain a vital enabling capability.


The Application Development Issue


The assertion model is also more firmly rooted in the application model that a large number of developers are embracing: XML and Web services. SAML is an XML-based standard, for example, and leverages the XML Digital Signature (XML-Dsig) and XML Encryption standards. Within an application environment that relies on standards such as XML, SOAP, and WSDL, SAML fits right in. Again, public key security is more embedded in the infrastructure, not some ugly bolt-on that bears little or no relationship to the application infrastructure.


Assessing Reality


It’s important to note here that we’re none of the standards I’ve outlined here completely solve the trust problem and all of the complicated issues involved in federating identity. Web services and federated identity standards are immature and incomplete today, and we face a significant transition period over the next few years. We also need business models for federation, which is why Liberty’s focus on the business framework is so useful. It’s also why efforts like PingID’s attempt to build a federated identity network for business are so interesting.


But as the examples I’ve used here illustrate, cautious optimism is warranted. By more closely aligning security models with the way companies do business, the federated model has a stronger foundation. We’re also taking more incremental steps forward. Instead of trying to invent a top-down model that everyone agrees on up front, the model is growing more organically, based on the evolution of the underlying infrastructure and the experience gained in implementation. And because the federation model is firmly rooted in the Web services development framework, public key security should play an important role in Web services and federation. These steps should reinvent PKI as we’ve known it, enabling a more practical way of using public key security in the process.

11:27:27 AM    

Tuesday, February 25, 2003

And I haven't even had a chance to clean up yet 

Geez, now Doc's pointed at me too. I was really hoping to get the place cleaned up before folks started dropping by, but what the heck.

10:13:01 AM    

Monday, February 24, 2003

So much for flying under the radar . . .

I saw today that Dave Winer “outed” me, providing a link to my blog in Scripting News. First, thanks Dave. Second, if you followed the link from Scripting News over, I’m sure your first comment was, gee, he hasn’t posted in a long time. True enough. We’ve been experimenting with blogs at Burton Group for a few months, working under the radar, thinking about how best to use them. Funny thing is, Dave’s discovery of my blog coincides with some of that work, and we’ll be doing something more soon on burtongroup.com. But since Dave’s already noticed this blog, I’ll keep posting here until we do and then let anyone who’s interested know what’s going on. Guess I’m committed now.


3:52:32 PM    

© Copyright 2003 Jamie Lewis.

Click here to visit the Radio UserLand website.


March 2003
Sun Mon Tue Wed Thu Fri Sat
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Feb   Apr