All:
Pointers to articles:
http://www.crn.com/nl/crndailynews/showArticle.jhtml?articleId=180204041
http://www.microsoft.com/windowsserversystem/CLM/overview.mspx
Kobielus kommentary:
The headline of this piece isn’t news, nor is its substance. Everybody knows passwords aren’t enough for strong authentication. And anybody who’s been paying attention knows that Microsoft has been beefing up Windows’ smartcard and certificate lifecycle management tools. Microsoft acquired Alacris last year and has been integrating its credential management workflow and provisioning tools into Windows Vista and “Longhorn.”
But it’s clear that Microsoft, with Certificate Lifecycle Manager (CLM), isn’t implementing any functionality different from entrenched card/credential management vendors, such as GemPlus, Schlumberger, and Siemens. Yes, card/credential management integration with the InfoCard feature of Vista/Longhorn is news, until you realize that InfoCard is just another type of soft token in which PKI and other credentials will be stored—Microsoft’s not an innovator in that regard either.
Let’s not confuse a Bill Gates marketing-ish announcement with an actual vision of anything new--from a PKI, IdM, or trust management perspective—coming out of Microsoft. It would have been more interesting if Microsoft had let Kim Cameron discuss identity metasystem from the stage at RSA Security. But that would be a PR no-go for Microsoft. Only IdM wonks like myself would have paid attention. Also, Kim is a semi-autonomous vision guy, not someone that Microsoft would ever consider as a heavy-hitting marketing mouthpiece.
Gates is Microsoft’s marketeer-in-chief. And you can’t ask for a better one. He’s iconic, smart, current, in-depth, articulate. However, he’s not usually someone who communicates anything that you haven’t heard before, expressed more memorably by others.
In this instance, I find Gates’ statements on the issue of authentication factors--passwords vs. smartcards/certs--a tad stale, and off the mark.
First off, he focuses on the need to simplify smartcard/certificate issuance, renewal, and revocation, rather than the need to increase assurance (hence trust) surrounding these critical lifecycle processes. “Having the revocation and issuance work as easily as passwords do today is a critical element here,” says Gates. Wait just a second, Bill. The primary purpose of smartcards/certs is to enable stronger authentication than you can get with plain ID/passwords. And strong authentication demands strong assurance implemented acrosss the entire lifeycle of smartcard/cert enrollment, approval, proofing, provisioning, management, and validation. It all comes down to trusted workflows and trusted roles implemented across a company’s smartcard/cert/credential management process. If somebody can impersonate me and get a smartcard/cert in my name without undergoing the necessary administrative approvals and in-person proofing necessary to prove that they’re me, then what’s being gained? Just a new way to steal my identity and “authenticate” as me and gain “authorized” access to my world. Simplifying the smartcard/credential management process often means gutting whatever assurance the provisioned tokens/certs might otherwise have had.
Second, he says that most companies can and should (implication: they will) move away from password authentication toward smartcard/cert authentication by the end of this decade. Of course, that prediction is predicated on Microsoft and other smartcard/cert/credential management vendors making greater headway in customer acceptance than they have in the past. It’s still not clear that Microsoft’s CLM will appreciably simplify the complex PKI workflow and technical infrastructure needed to make this happen (ignoring, for the sake of discussion, the negative impact that such “simplification” might have on smartcard/certificate assurance levels).
If you want authentication simplicity, you can’t beat passwords. For authentication assurance, though, passwords are almost always the weak link in the trust chain, owing to boundless opportunities to hack, guess, and steal passwords, and also to the fact that users are rarely proofed in-person prior to issuance of passwords.
Consequently, the password being presented in an authentication session may or may not be presented by the identity that purports to be presenting it. You have no strong assurance that it’s not being presented by an impostor.
But then again, without an enrollment, approval, proofing, and provisioning workflow that ensures strong binding of the smartcard/cert to a particular human being, you have no strong assurance with multifactor authentication either. And without a trust web and certificate validation infrastructure, you have no assurance that a cert being presented is still valid. How often do people rely on someone else’s PKI cert without checking to see whether it’s been revoked, or simply expired? Without that validity check, how secure is that cert?
CLM assurance (implemented through infrastructure and workflow) is the “x-factor” in multifactor authentication. Without that x-factor, digital certs aren’t appreciably more secure than passwords. Under most circumstances (and these aren’t likely to change by the end of this decade, regardless of what Gates claims), digital certs are more costly, complex, and cumbersome than passwords. Yes, the smartcard/PKI industry needs to embed their infrastructure in platforms (e.g., Windows) and needs to expand the opportunities for user self-service in enrollment, renewal, revocation, and other lifecycle functions.
But, inherently, strong credentials assurance can’t rely on user self-service alone. Users must run the gantlet of company approvers, background vetters, in-person proofers, and other trusted “administrators” in order to obtain their trusted certs. And to renew them. And to ensure that, when other people’s certs are revoked, that the appropriate certificate revocation lists are kept up to date.
Yes, passwords aren’t enough. But smartcards and certs without a strong-assurance-enabling infrastructure aren’t enough either.
Jim
