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