Slashdot Mirror
Does Your Company Use a PKI Solution?
punkrokk asks: "I am doing an Independent study of the feasibility of a Microsoft Certificate Services PKI in a distributed company. So far, it appears from my research that MS has the best supported implementation of a X.509 based PKI solution, for the Windows environment. While there are a few major weaknesses in a X.509 Public Key Infrastructure, one of which being Certificate Revocation Lists, using one is better than nothing. You do get a tangible security benefit, in addition to doing switch port authentication, and VPN quarantines. The problem is the cost of implementation is pretty steep, from the planning side. What do you guys do for dual factor authentication? Has anyone had Verisign sign their Certificate Authority? If you have implemented a MS Certificate Service infrastructure, I would appreciate your comments."
If you're going to expose your encryption method using a public key, you're about as safe as a CTU agent travelling with Jack Bauer and Tony Almeida. In other words, just think of yourself as Ensign Johnson beaming down to the planet with Kirk and McCoy.
Security is good, but only as good as the weakest link in the chain. If you have humans working for you, they are the weakest link. It's a lot like a car with a flat tire. You should change to the spare, but realistically, the spare is probably a small tire that isn't really designed to be run on for long distances and will cause you to lose control if you rely on it too much.
Hi, I am going through Microsoft's 'Step-by-Step Guide for Setting Up Secure Wireless Access in a Test Lab' now, and the solution does not seem very simple. To setup 802.1x you need: - Active Directory (usually, but you could use standalone IAS) - IAS service (MS's RADIUS server) - Access policy on IAS setup for 802.1x - Certificate server, with computer certificate issued to the IAS server - AP and wireless client that supports WPA Enterprise. - Patches on the client to give operating system support (e.g post sp2 patch to support WPA2). Then, when you configure the client, and connect it seems kind of clunky with popup's for entering credentials and others to verify certificates. Do third party solutions make it simpler, or just outsource the Certificate Services part?
Dunno if this will get modded out of AC-land, but here goes:
For the newbs, CRLs or Certificate Revocation Lists are nothing more than lists of which certs have been revoked. If you're going to deal in non-physical access tokens (as opposed to, say, metal keys and RFID badges) you're eventually going to want to deal with the eventuality that people's lifespans are generally longer than the amount of time that they have access to your stuff. PKI is excellent for mathematically proving that noone that can't factor huge primes can get your secrets just by looking at bits on the wire, but you can't really demand that your recently fired employees surrender their keys since they could very well have made copies in advance. Now that I think about it I suppose the same is true of keys, so consider CRLs the digital equivalent of changing locks.
A CRL is a list of all they key IDs of keys that have been revoked. If you get terminated, you go on the list, and when you subsequently try to use your key, even though mathematically it works great, if you're on the CRL you get a 403 (or big guys with guns or whatever your model for Access Denied happens to be).
CRLs are as dead end as it gets. Especially if you're working with a lot of end-devices or end-users, your CRL situation is going to get fantastically out of control very quickly. Picture, if you will, the DoD. How many people do you think had keys last year who aren't entitled to them now? Sure, the really old keys expire, but the new keys that were revoked all have to be downloaded *every time* a user makes a query, or else you risk race conditions of varying severity. (One could easily imagine the race to get home and log in over the VPN to copy the Secret Plans after being fired; the amount of time a user would need to do this is about the longest you'd want to go between CRL updates. If a CRL was many megabytes large and if the authenticating device got many hundreds of requests per second you might have a problem.
OCSP , or Online Certificate Status Protocol, is a huge step in the right direction; instead of downloading the entire CRL to the authenticating device, the device instead makes a quick call to a OCSP responder, querying the status of the cert. The OCSP has a store of CRLs which it obtains from the CA/VA, and can create a signed response containing the status of the certificate: good or revoked (or, I suppose, unrecognized or otherwise munged). Now you only have to distribute CRLs to one/several devices, instead of every one in the infrastructure.
Some groups (Corestreet, among others) have created distributed versions of OCSP which use precomputed proof lists in order to avoid the problem of distributing private keys to a network of distributed OCSP responders for use in signing OCSP responses. This D-OCSP is vastly more powerful and flexible than CRLs (and proportionally expensive).
PKI is a pretty daunting challenge to implement correctly, and its even harder to make the other links in the chain nearly as strong as the crypto. Best of luck.
vvj
Disclosure: I'm the Principal Engineer for Red Hat Certificate System. (Previously known as Netscape Certificate Management System).
Our product is fairly widely deployed. For example, every single one of the 18+ million Certificates issued from the US Dept of Defense CAC (smartcard) deployment use our Certificate Authority. There are many other deployments within the Federal government also.
In addition, someone mentioned Geotrust. Geotrust built their certificate issuance service on top our certificate authority, so of course I think very highly of them.
Our product is an enterprise-class (meaning hugely scalable, and fault tolerant), full featured, mature product, written by engineers with many years experience in the PKI field.
But, I would like to turn the question around - If you haven't deployed a PKI yet, what is stopping you?
As an example, one of the deployment-blockers we found in the past few years was the poor integration PKI management systems (Certificate Authorities) had with Smartcard Management Systems. So, we engineered a smartcard management system, and bundled into the Certificate System at no extra cost.
What applications would people like to see PKI-enabled that aren't already?
And since I'm a Red Hat employee now, I am constantly thinking about integration with Red Hat Enterprise Linux and Fedora - so, what changes would you want to see happen?
Fashioning it in Windows is quite simple, as Windows domain participants will automatically enroll for the types of certificates that you want, for example, allowing the machines to authenticate into the domain silently. I've written several detailed implementation how-tos on these subjects (kafkaATtelusDOTnet, if you're interested).
As soon as you leave the Windows world, then all these things become a bit trickier. No longer can you simply let the the Windows Certificate Services generate your certificates silently, since you'll need to intercede to generate the type of certificates that want. Controlling how these certificates are constructed becomes somewhat difficult (not impossible, just tricky). How and what you want will totally depend on the applications that you're using. You're probably far better off getting a PKI solution based on OpenSSL in that case, especially if you need to interoperate with non-Windows applications and devices (such as CISCO routers). If you don't have time to write any code, look into RSA Security. They're wayyyy cheaper than Verisign, and you don't have to deal with the hassle of outsourcing.
Another poster recommended using OCSP - thats fine, but I don't believe there is a native OCSP client built in to Windows. You either have to roll your own, or obtain one (RSA, for example, has one. As well as Computer Associates OCSPro). In fact, there is no reason why you can't implement both redundantly. Use both the CRL distributionpoints (CRLdP) extension *and* the AIA extension to get this done.
Another citation, I believe, referred to Peter Guttmans (very old) document on various PKI implementations, X.509 Style Guide. This document is horrendously outdated, as the tools and apps are far more widespread than they were wayyyy back in 2000.
Anyways, for what its worth, if you know what you're doing PKI has distinct advantages to add to your electronic security (although a blind reliance on it won't help you at all).
If you don't know what you're doing, then you'd better go with a vendor that will support you.