Burton Group Identity Blog

ActivIdentity acquires CoreStreet

Blogger: Mark Diodati

You may have seen that ActivIdentity Corporation will acquire CoreStreet Ltd. Since its de-emphasis of its enterprise single sign-on business (primarily the result of the Protocom acquisition in 2005), ActivIdentity has focused on strong authentication. While ActivIdentity has one-time password solutions, its technological crown jewels are its smart card offerings. Its smart card management system and smart card middleware products have a significant footprint in the US Federal Government.

CoreStreet’s products complement ActivIdentity’s smart card solution. CoreStreet provides a PKI certificate validation solution, which is arguably a requirement for large-scale smart card deployments. CoreStreet also has a handheld device that enables the authentication of Federal agency personal via their PIV smart cards. The device is handy in scenarios where emergency first responders arrive at a disaster site. Finally, CoreStreet offers a solution which enables the PIV card to be used in an unmodified physical access control systems (PACS). It is pure conjecture on my part, but I am guessing that the solution involves hashing or truncating the PIV card’s Card Holder Unique Identifier (CHUID) to make it compatible with Wiegand-based PACS. CoreStreet’s products are aligned with the Federal Government smart card market, which co-incidentally is ActivIdentity’s primary focus. The certificate validation solution is appropriate for large smart card deployments in the enterprise, too.

Overall, the acquisition is a good move for ActivIdentity; it will enable ActivIdentity to market a broader smart card solution to the Federal Government. For customers of both companies, the acquisition provides a single vendor relationship. For more information on PACS and Federal Government smart card initiatives, please see our research documents “Let’s Get Logical: The Convergence of Physical Access Control and Identity Systems” and "U.S. Federal Authentication Programs Making Progress, but Much Work Remains" (subscription required).

Hopes and concerns for identity

Blogger: Ian Glazer

A friend in the industry recently asked me for my thoughts on OpenID, InfoCards, and the US federal government's work to consume non-government issued credentials. Letting the question rattle around in my head for a while, here's what I've got so far.

My hope is that the overall ICAM initiative is successful—not because I have been eagerly waiting to interact with the federal government using some form of authenticated credential—but because we (citizens, enterprises and government) are at a pivotal moment in the history of the web. With the US government working with both the OpenID and InfoCard Foundations, there exists an opportunity to change how individuals interact with large organizations, both public and private. For the first time, individuals would be able to (even encouraged to) interact with a large organization (such as the US federal government) using an identity asserted, not by the large organization, but by the individual. In this case, the State is no longer the sole provider of identity. This breaks the monopoly that the State has had on credentials and is indicative of the future to come.

But there is a long road to walk before getting there. There are numerous concerns with these plans. Among these are notable security concerns, especially with OpenID, that the identity community is not blind to. These are not my primary concerns.

My primary concern is with the establishment of standard user behavior that could prolong existing problems. Today, after decades of enterprise training and a decade of consumer training, people naturally expect to see two text boxes on web sites. One is for their username and the one with the little stars is for their password. This behavior is ingrained. Changing this behavior is no small feat - just ask the OpenID and InfoCard groups. But it is a change that must occur to normalize people using something stronger than username and passwords to authenticate themselves.

My concern is that the behavior that is being established as a norm - the use of either an identity selector or some other user interface means - will become the username/password for the next generation. This isn't a hypothetical problem; the writing is already on the wall. Currently, OpenID will only be accepted for low-value transactions with the government known as Level of Assurance 1 (LOA1). Activities like filing tax returns requires a far greater assurance that the person is who they claim to be and thus require a Level of Assurance 3 identifier. And there is problem. The way people use an LOA3 credential may be very different than how they do so with an LOA1 credential.

If we, as an industry, normalize user behavior that meets LOA1 needs but not LOA3, we are training in behavior that has to get untrained in a near future. What the government and its partners are on the path to doing is effecting real cultural change. This kind of change doesn't happen often and is hard to do, and especially hard to undo.

I definitely want a future in which I can assert my own identity without validation from the State, but I am very willing to wait for that future to assure that the behavior the industry normalizes is one that will work for generations to come.

RSA, VeriSign, Cloud, OTPs, and Token Necklaces

Blogger: Mark Diodati

Today, RSA and VeriSign announced a partnership where VeriSign can resell SecurID OTP tokens via its VIP managed authentication service. RSA can also resell the VIP authentication service.

The press release implies that the relationship between RSA and VeriSign has been co-operative and amicable. Don’t be fooled. In early 2005, VeriSign was the primary driver for the OATH industry group, expressly created to take on RSA’s “cash cow”–its SecurID OTP business. Since that time, VeriSign aggressively pursued RSA’s SecurID customers and competes against RSA in the consumer authentication space.

As applications move to the cloud (e.g., SaaS), it is essential that users are not required to carry more than one OTP to access SaaS applications from different providers. This scenario is very similar to what we’ve seen in the enterprise—the “token necklace”. Users carried multiple authenticators around their neck because the authentication domains did not speak to each other.  RSA and VeriSign launched managed authentication services (the aforementioned VIP service and RSA’s Go ID service) which can overcome the token necklace issue by enabling many organizations to leverage a single token for authentication. Now that RSA can resell the VIP service, is this the end (or more likely, the de-emphasis) of RSA’s Go ID service?

This agreement provides VeriSign with some powerful capabilities. The VIP service will now work with both VeriSign (OATH-based) and RSA SecurID tokens. It’s likely that customers can mix and match token types based upon their application support and price requirements. Because VeriSign can bundle SecurID into its managed service, I believe it got the better part of the deal.

RSA derives two benefits from the partnership. Presumably, RSA will sell more SecurID tokens. Also, RSA’s ability to resell the VeriSign managed service gives broader entry into the managed authentication services market and with it the ability to better address the emergence of cloud applications (which enables RSA to sell more tokens).

Over time, the OTP form factor of choice for cloud-based applications will be the software token installed on the user’s mobile phone. We discuss this in our research document “More, More, More: The Challenge of Extended Enterprise Authentication Mobility” (subscription required).

Symark Acquires BeyondTrust

Blogger: Mark Diodati

You may have heard about Symark’s acquisition of BeyondTrust. Symark is best known for its UNIX security product- PowerBroker. BeyondTrust’s primary product is Privilege Manager. Privilege Manager provides authorization (specifically, privilege delegation) for the Windows platform. The product provides Windows Group Policy templates, which enable more granular privilege delegation.

Symark has taken the BeyondTrust corporate name. It’s likely that BeyondTrust will rename Privilege Manager to PowerBroker for Windows. The Privilege Manager acquisition enables BeyondTrust to leapfrog most of its UNIX security product competitors into the Windows access control market. Only CA has a companion product for Windows. Centrify, IBM, Novell, and Quest have roadmapped Windows authorization capabilities for next year (for most of the vendors). It’s interesting that the UNIX security market leaders – CA and BeyondTrust – now possess Windows security products.

I have been skeptical for many years about necessity of a Windows product that is analogous to the classic UNIX security product. Microsoft Windows already provides the functionality that the UNIX security products provide, including centralized IdM, privilege delegation, event auditing, and finer-grained discretionary access control lists (as compared with the standard UNIX model). Windows systems clearly have a different security model and policy enforcement points (PEPs) as compared with UNIX systems. The different PEP model results in distinctive policy sets within the UNIX security product.

Still, “I want (fill in the blank with your favorite UNIX security product) for Windows” is a common utterance from customers; I have heard it, and I know that the UNIX security vendors have heard it, too. When the conversation goes a little deeper, product requirements become more ambiguous.

Ultimately, I think that customers are looking for common activity and forensic auditing, and a single place to analyze the access rights of privileged users. It remains to be seen if a Windows PEP or if privilege restriction capabilities are required.

We’re living in interesting times. Either by acquisition or development, the AD Bridge, UNIX security, privileged account management, and Windows authorization vendors are beginning to cross over into different product classes. Burton Group will be discussing this trend in our September TeleBriefing on September 29/30 – “Markets Colliding: UNIX Security, Active Directory Bridge, Privileged Account Management, and Windows Authorization” (subscription required).

For more information on UNIX security products, please see the IdPS report “Providing a Strong Foundation: The Resurgence of UNIX Security Products” (subscription required).

US Government Identity News

Blogger: Bob Blakley

9/9/9 was a day of announcements.  You’ve already undoubtedly heard about the 64GB iPod touch, and if you’ve also heard about the new Leica M9 you know what to get me for Christmas this year.

But the identity world had its own big news today; the news is that the US Government has teamed up with the OpenID Foundation, the Information Card Foundation, the Kantara Initiative, and InCommon in creating the Open Identity Initiative. 

This is a really big deal, for two reasons.

First, as a condition of playing with the government in this game, OIDF and ICF have had to address the longest-standing and most serious defect in the open identity ecosystem: the lack of a trust infrastructure.  “What’s a trust infrastructure”, I hear you cry...

When you receive an X.509 certificate from a PKI provider, you can go to the provider’s site and read its Certification Practice Statement.  This statement provides three critical pieces of information:

1. What the provider does to ensure that the person who sent you the certificate is who he says he is.
2. What the provider does to ensure that its own systems aren’t compromised in a way that would allow people to create fraudulent certificates or steal private keys.
3. What obligations the provider undertakes and what remedies it will provide to its customers (i.e. YOU) if it breaches those obligations.

There’s never been any equivalent of a Certification Practice Statement for open identity providers.  Today’s announcement changes that.  The Open Identity Initiative has created a Trust Framework Provider Adoption Process which will allow organizations to set themselves up as roots of trust for open identity.  Organizations which serve as trust roots will assess the practices and guarantees of identity providers, and they will establish registries of providers and “score” them against a set of identity assurance criteria aligned with the Liberty Alliance Identity Assurance Framework and the OMB M-04-04 and NIST SP 800-63 guidelines.

So, if a few serious organizations sign up to become Trust Framework Providers, we’ll finally have a trust infrastructure for open identity.

The second reason today’s announcement is a really big deal is that, after years of government attempts to create identities and assign them to citizens (via such bad ideas as the UK National ID scheme and the US REAL-ID act), a government has finally recognized that individuals already HAVE identities, and that it’s a better idea, for most purposes, to use these identities than to establish a new government bureaucracy to create new identities – especially if they’re identities people don’t want.

If this initiative succeeds, and I hope it does, it’s almost certain to be a much cheaper route to government consumption of reliable digital identities of citizens than something like REAL-ID would be.  And it will preserve consumer choice at the same time as encouraging innovation in commercial identity technology.

So three cheers for Vivek Kundra and the boards of the OpenID Foundation, the Information Card Foundation, the Kantara Initiative, and InCommon.  And while we’re at it, let’s not forget to congratulate OSIS and the Internet Identity Workshop, where many of the technologies behind today’s announcement were developed and more of the ideas were born, and the Liberty Alliance, whose work on the Identity Assurance Framework is the keystone of the trust infrastructure we are finally about to see.

Kerberos interop event hosted by Microsoft!

Blogger: Gerry Gebel

At Burton Group we are big fans of interoperability events so it was great to see that the MIT Kerberos Consortium announced it will host an interoperability event this March 30 to April 3 at Microsoft's offices in Redmond. Kerberos is a key element to many organizations' single sign-on strategy, providing standards-based mechanisms that are supported by many platforms and applications. It will be very interesting to see who participates, what the testing scenarios are, and how the results turn out.

New Year’s Resolution: Let’s Talk More about SPML

Blogger: Mark Diodati

Jackson Shaw and James McGovern have been blogging recently about one of my favorite topics: Service Provisioning Markup Language (SPML).  I’d like to contribute to the discussion.  You can find Jackson’s blog entry from December 20 here, and James McGovern’s blog entry from January 5 here.

One thing that organizations using SPML should do is to secure the service from an authentication, authorization, and encryption perspective.  In most instances, because the number of SPML requestors and providers (this is terminology specific to SPML) are small, most organizations are opting to manually configure the requesting authority and the provisioning service provider with static passwords or certificate lists to establish trust between the provisioning services components.  These authentication techniques don’t provide authorization services in any meaningful sense.  A large SPML implementation requires authorization services to determine the rights of the requesting authority to manage the specific user on the respective provisioning service target.  In our opinion, the multi-tenancy (call it cloud-based if you like) use case is an example of a large SPML implementation – one must build the requisite authorization and authentication services to support the provisioning service.

SPML’s lack of authentication and authorization capabilities highlights the broader issues we see with the emergence of identity services.  An authorization service requires authentication services in order to have any utility whatsoever.  The authorization and authentication services may be consolidated (one big authorization and authentication service) or discrete (two separate services).  One example of a discrete authorization service is a XACML authorization service that leverages the user’s SiteMinder SMSESSION ticket for authentication.

As for federation and federated provisioning, the lack of provisioning capabilities remains an operational impediment.  Several years ago, a Liberty Alliance Technical Expert Group began working on a way to “harmonize” SPML and SAML.  While the services would remain separate “pipes”, the TEG was working on a way to harmonize the user attribute schema across the two services.

James’ blog entry discusses the inter-enterprise standardization of roles.  From talking to my colleague Kevin Kampman, there's been little if any traction to date.  It really highlights the fact that a role is a representation of responsibilities coupled to a relationship, and getting common agreement on this is problematic.

If you are interested in more detail, we published a research document on SPML.  The document discusses the v2 specification in depth, as well as the differences between the v2 specification and the v1 specification.  It also discusses the barriers to the ubiquitous use of SPML.  You can find the document at http://www.burtongroup.com/Client/Research/Document.aspx?cid=848 (client subscription required).

Dear Santa

Blogger: Mark Diodati

Hey, Santa, I want OTP support for Microsoft workstation – whaddya say?

You may be aware of the IETF Kerberos Working Group’s efforts to bring standardized one-time password (OTP) support to Kerberos.  The latest draft of the specification (dated December 5, 2008) is here.  The primary author of the specification is Gareth Richards at RSA/EMC, and the specification supports OATH-based OTPs as well as SecurID OTPs.  Larry Zhu from Microsoft co-chairs the working group, and provided extensive and constructive comments on the specification.

The draft specifies extending the Kerberos pre-authentication phase to support OTPs (pre-authentication is the phase where Kerberos can be extended to support additional authentication types).  Kerberos was extended to support PKI authentication (i.e., PKINIT) in the pre-authentication phase.  PKINIT is the basis for Microsoft’s support for smart card authentication at the workstation. 

Our recent authentication contextual research revealed that customers struggle with Microsoft’s lack of third party strong authentication interoperability at the workstation.  Only two authentication mechanisms are supported at the workstation: password, and smart card with certificate.  Customers are specifically looking for native OTP support at the workstation, as it is the pre-dominant strong authenticator in the enterprise.  Today, any OTP authentication at the workstation is achieved by replaying the user’s Active Directory password.

Let’s tie this up in a pretty bow.  The work required at the workstation and in Active Directory would be substantial.  Microsoft’s product lifecycles are understandably long.  Even if Microsoft started working immediately, it would be a minimum of three years before we see it.

Still, I take hope where I can get it.

Microsoft and the SAML protocol come together in Geneva

Blogger: Gerry Gebel

At the PDC conference this week, Microsoft announced support for the SAML 2.0 protocol as part of a broader announcement regarding the beta release of the Geneva platform. Don Schmidt and Mike Jones of Microsoft also posted comments on the announcement. Geneva is the successor to the Active Directory Federation Services (ADFS) product and the Zermatt developer framework announced over the summer and has a broad scope as Microsoft’s “claims based access platform.”

Geneva includes the runtime server apparatus to support claims based applications, a developer framework for building those applications, and an enhanced Geneva CardSpace client. This is another positive step for Microsoft as this announcement addresses one of the main pain points for its customers that want to operate in many federation scenarios without imposing a specific protocol on partner organizations. Geneva, according to the announcement, contains support for WS-Federation, SAML 2.0 IDP lite and SP lite profiles, the GSA profile used by the U.S. federal government, WS-Trust and information cards. Finally, Microsoft customers will be able to interoperate in a heterogeneous federation environment using Microsoft tools exclusively. Some early interop testing has already occurred with Internet 2 Shibboleth, IBM’s Tivoli Federated Identity Manager, and Ping Identity PingFederate. 

Microsoft’s Geneva announcement moves applications toward a cleaner architecture that rely on shared services for authentication as well as authorization information. The next step we’re waiting to hear about is entitlement management and policy enforcement. Today, that is still handled by the developer within the business application. Will Microsoft also externalize that function a la entitlement management tools?

Now for the bad news… Can you wait until late 2009 or 2010 for Geneva? Yes, I know you’ve asked for this for at least three years now. Yes, I know that managing SharePoint access and federation is very painful but you’ll have to wait for some unspecified period of time before SharePoint - and other Microsoft applications – utilize the Geneva platform. Additional prerequisites, such as migrating to Windows Server 2008 and Windows 7, will likely be necessary to realize all the promised enhancements. Bottom line: you can continue waiting for Geneva (final composition of features subject to change – you know the drill), implement unsatisfactory workarounds, build some custom code, or look to the third party market for tools that provide enhanced functionality.

Static KBA: Lipstick on the Weak-Authentication Pig

Blogger: Mark Diodati

You may have read that vice presidential candidate Sarah Palin’s Yahoo! email account was hacked via a self-service password reset application.  The hacker gained access to the account by knowing three pieces of information about Sarah: her date of birth, her zip code, and where she met her husband.  This incident illustrates one of the KBA’s vulnerabilities: the targeted attack. The Chicago Tribune has a great summary of the attack here.  The self-service application is an example of using static knowledge-based authentication (KBA) as an identity proofing process.  Static KBA systems utilize a non-changing set of easily-guessed or self-selected questions to prove a user’s identity at specific authentication lifecycle milestones, when the primary authentication method (in this case, the user’s password) cannot be used.  Situations where KBA is utilized include account origination and account unlock.

We’ve expressed our concerns about static KBA in the past in several of our research documents, and also on our blog (here and here).  Static KBA is not acceptable for use with higher identity assurance applications or stronger authentication devices.  It is safe to assume that the email account had higher identity assurance requirements, especially because it appears that the email account was used to conduct government business.  Many consumer-facing organizations – not just Yahoo! – utilize KBA because it is perceived as less expensive than other identity proofing methods like dynamic KBA and out-of-band identity proofing (our blog entries here and here discuss these techniques).  Also, many enterprises use static KBA for their employees.

There are some indications that Federal financial regulatory agencies are beginning to acknowledge the risk of static KBA, and potentially exclude its use when access to money or private information is possible.  Let’s hope that happens soon.  Fraudsters are several easy questions away from accessing consumers’ email, money, and confidential information – at will.  Shouldn’t consumer-facing organizations stop putting lipstick on a pig, and go with better identity proofing processes?