Wednesday, October 3, 2007

Beyond Passwords: Implementing The Vision

In Part 1 of Beyond Passwords, we explained the problem and showed why organizations are interested in improving on password authentication. In part two, we examine the solution.

Organizations that want to implement stronger authentication have a dizzying array of alternatives and products to choose from. To get started, let's break the alternatives down into categories and identify a few products in each category.

1. Digital Certificates
Digital certificates are based on Public Keys, a cryptographic system whereby pairs of keys are generated with a unique mathematical property: anything encrypted by one key can only be decrypted by the other key. In each pair, one key must be safeguarded and known only to the legitimate user—this is the Private Key. The other key is given freely to everyone who wants to authenticate the private key holder—this is the Public Key. If you encrypt a known value with your Private Key, anyone else can decrypt that value with your Public Key and compare those two values. If they match, you are considered authentic because you demonstrated that you hold the Private Key.

For authentication, your identity must be somehow tied to your key pair. This is the purpose of Digital Certificates. A certificate binds a public key to a named entity and some information about that entity (like company, state, and country). Although this binding could be supplied to each correspondent out-of-band, that would not scale well or let strangers authenticate each other. To solve this, certificates are issued by Certificate Authorities (CAs): trusted third parties that generate and "sign" certificates using their own private keys. In this way, everyone can know the public keys of a few trusted "root" CAs and accept as valid any certificate those CAs generate.

Digital certificates are the basis for the SSL server authentication widely used by e-commerce sites. Every web browser is installed with a list of well-known root CAs. For example, Thawte's certificate is included in Internet Explorer's trusted root list (below).

Click to view larger imageOrganizations may purchase certificates from these root operators, or they can install in-house CAs to generate, distribute, and revoke their own digital certificates. MSSPs that provide Managed PKI services generally use their own CA(s) to generate certificates for use by their customers.

For example, an MSSP might issue an "intermediate" CA certificate to YourCorp, and sign all of YourCorp's user certificates with that CA's private key. YourCorp must install that trusted CA certificate in every system. When a YourCorp user wants to authenticate, she presents her certificate, signed by YourCorp's CA, and a value (thumbprint) encrypted with her own private key. The recipient uses the CA's public key to verify the certificate is valid. He then extracts the subject name and public key from the certificate to authenticate the user.

Even from this brief description, we can see that Public Key Infrastructure can be complex. And we haven't even discussed the most challenging aspects of deployment, like expiring, renewing, and revoking certificates, publishing certificate revocation lists, and creating a business process for generating key pairs and certificates and making sure they are distributed securely to legitimate users. Larger enterprises often have the IT staff and security expertise to deploy a PKI, if they choose to do so. But many SMBs do not—and this is where MSSPs can step in to help to fill the gap. To roll your own CA, start with a PKI platform, available from many sources, including:

* Computer Associates
* Cybertrust/Betrusted
* Digi-Sign
* Entrust
* Kyberpass
* Microsoft
* OpenCA Project
* Netscape/RedHat
* Verisign

To learn more about Digital Certificates and deploying a PKI, consult these vendors' websites and third-party sites like this PKI Page. Today, digital certificates are widely used for server authentication—for example, site-to-site VPN gateway authentication. They can also provide strong user authentication—for example, in wireless LANs using 802.1X with EAP-TLS.

However, many organizations have been scared off by PKI complexity and cost. To date, most companies have pursued other options for stronger-than-password user authentication.



http://www.isp-planet.com/technology/2005/beyond_passwords_2a.html