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."
The University of Wisconsin - Madison has deployed a campuswide PKI solution based on GeoTrust.
. asp
More information, with presentations and descriptions of our deployment:
http://doit.wisc.edu/middleware/pki/
UW/GeoTrust/EDUCAUSE joint press release:
http://doit.wisc.edu/middleware/pki/geotrustuwpki
For more information about UW-Madison's PKI deployment, contact Nick Davis
We have been using MS' Certificate Services for a couple of years - primarily for WPA-RADIUS authentication. It has worked fine. You can set group policy to automatically request user and machine certificates so there isn't a lot of touches to the desktop. Only thing I haven't figured out is how to get our company's root CA to be a trusted root certificate within the WPA config.
We use Certalert for managing our digital certificate lifecycle and CRL's. This is a nice add on solution to MSFT PKI. This does not do anything on the 2 factor authentication side however, so we are still looking for a solution there. For my money the Certalert guys really provide a great solution for managing your server side certificate environment. http://www.certalertsoftware.com/ ,if your interested.
Don't forget to look at OpenSSL (you'll have to write some scripts and use a RDBMS with this), Entrust, and RSA.
Also, don't hardcode your CRL URL into your certificates. If that web server goes down, your entire PKI could break. It is better to leave revocation out of certificates and get all of your important PKI clients to use OSPF.
For the root node of your PKI:
Take a laptop, scratch off all networking-type thingks (modem jack, ethernet jack), generated your root CA key, use it to sign your intermediate CA certificates, then lock the laptop in a safe.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Entrust wrote the first commercially available PKI back in 1994, and have only improved on it since then. It's scalable to millions of users, and is used by many governments on financial institutions. Worth a look if you are looking for a large enterprise PKI solution.
Life is like a web application. Sometime you need cookies just to get by.
I strongly recommend you research Novell's PKI solution -- it's integrated directly into Client32 (the network client software) for Windows, and the key, certificate, etc., are all stored in the Directory (formerly known as NDS {Novell Directory Services}, it was renamed to "eDirectory" quite a few years ago).
"NICI" and "Directory Services" and "NetWare" are the keywords which will be most helpful in your search for additional information on this subject.
The Lumber Cartel, local 42 (Canadian branch)
British Columbia, Canada
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
Regarding the use of the CRL distribution point extension, a URI that points to a DNS alias can help alleviate the risk.
"OSPF" was likely a botched reference to OCSP (Online Certificate Status Protocol), defined in RFC 2560.
Finally, read the PKIX spec on certificate management, RFC 3280. It will give you a much more detailed understanding of how PKI should work than any vendor docs. This level of understanding is critical if you start playing the role of CA.
If you do your homework, and understand how things work, OpenSSL is an adequate tool.
Although MS may have a bastardized implementation of PKI, it has some primary flaws. For starters, MS will only allow their domain controller certs to be constructed in some specific fashion. If you are a small firm and it is inexpensive to gut your PKI quickly, then play with MS implementations.
Stick with standards compliance for larger implementations. You never know how someone is going to need to use your infrastructure, and it is a REAL PAIN to adjust (bigger = exponentially harder). For example, one day you might need to do something with hardware cards or trusted peers. If your chosen version doesn't play that way, you could be screwed. Just find another job, fast.
If all you want is single sign on with a piece of plastic, buy a SSO solution and be done with it. But if you want a root CA, subordinate CAs which issue hardware, software, server, and mcs credentials, then that's a real PKI.
If you don't have the facilities to handle physical security needed for a PKI, then find a vendor.
The first part of PKI is Policy (read - legal junk that gives your Base64 blobs some sort of validity). You need a CP and a CPS and that requires a lot of typing. Once you get that down, then you can survey offerings and find what you need. Some hints at decent products are from Novell and a section of RedHat that was formerly known as NSS.
I'm not stricly MS bashing, but some will see 2 linux vendors and say "oh, he just hates Windows". Fact is there are plenty of PKI standards and Microsoft doesn't do it correctly - why should they when everyone uses Windows to sign in.
I sure hope you are not working on HSPD12You seem to be asking several questions, or confusing several solutions, or both.
.1X schtuff up.
If you're looking for port-level authentication on your networks, wired or wireless, then IEEE 802.1X is the answer.
(dot)1X uses EAP (Extensible Authentication Protocol) Methods. MS gives you two big methods out of the box w/ the XP client: PEAP-MS-CHAPv2 (think: login/passwd) and EAP-TLS (think: digital certs), and provides the server level support in the form of certificate services, IAS (internet authentication server) and integration of both into the AD. Other methods are around, typically from other vendors (at additional cost). To impliment one not supported by MS out of the box, you need client-side and server side support.
IF (BIG IF) you have an MS infrastructure, your client machine logins are probably hanging off the domain controller, and use one of the above methods, or, can easily (and transparently to your users) move to one.
NOW, once either one is in place, implimenting port level auth is straightforward.... unless you do not have 100% XP clients. Nobody does in my experience (think: Printservers, other headless network clients). Then you get to get REALLY inventive with firewalls, vlans, switches, etc. and you can "get there". Taint gonna be easy....
There are open solutions on the client side, even in an MS infrastructure. Google for "wpa_supplicant".
NOW, back to your question: The MS PKI will prolly scale as well as AD itself. No better, worse.
This answer is deceptively simple. You have to overlay it on YOUR network, YOUR security policy, YOUR needs, YOUR level of expertise, etc.
MS does eat their own dawgf00d in this area, and I personally know some of the architects and implementors.
I AM NOT A MS FAN. That being said, they have (mostly) gotten this right.
There is a book from MS Press: Deploying Secure 802.11 Wireless Networks with Microsoft® Windows, ISBN: 0-7356-1939-5, which is obviously oriented on wireless nets, but which steps you through setting all of the
Recommended....
I sincerely hope this helps..
-RED
The University of Michigan rolled out Kerberos some time before 1993. I forget when. There have since been many other projects which tie into it like cosign for example.
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.
When you need to do authentication with parties outside of your organization you probable need to use a commercial CA such Verisign, but for internal use within your organization there is no need to do so. Personaly, for internal authentication I prefer to use a CA generated on one of our servers. It makes it easier to secure a VPN, for instance, if you own the the CA that signs the certificates that authenticate connections. The OpenVPN package provides a very comprehensive set of openssl tools that allows one to generate various certificates on Linux, Unix or Windows systems.
The real problem you will come across when using server side certificates only is that the wireless link will be enables first after logon.
This might seem like a small problem, but remember that you will not have a IP-address at the logon and therefore the client computer will not load logonscripts and Group polices. To get around this with a enterprise WPA solution you will have to issue two certificates, one for the user and one for the computer.
I have been working with various PKI implementations since 2000, and I have two bits of advice for any new PKI deployment:
- PKI is not an end in itself, it is just a tool: before designing a PKI solution, you really need to know exactly what end solution you're trying to put in place: Windows Logon? VPN Access? Device authentication in your infrastructure? Email encryption/signature ? Web authentication? Once you know the requirements of your end solution, the choice of a PKI as a security layer for that solution will be far easier.
- The technical solution is the easy part: as can be seen on the other posts, there are plenty of Certificate Authorities around, all with their technical strenghts and weaknesses. What they do not address is the process part around PKI - the CP/CPS and others -, in other words how the PKI shall be used, who is allowed to do what, how the various components shall be protected, procedures defined to address various scenarios (administrator run over by a bus, role separation, administration procedures, key ceremony, key escrow, revocation policy, etc.). This is really the tricky part because it is what will make your PKI a really strong solution or just a gimmick...
As a conclusion, in some cases the Microsoft CA will be fine (say you mainly want to do smart card logon on a 'standard' Windows network), in other cases other solutions will be more suitable, but in every case, the hardest part (as in 'the most expensive part') will be the creation of the policies revolving around your PKI. If after analysis you find out a strong PKI policy does not seem that important in your particular case, chances are you don't really need a PKI but another form of strong authentication. For instance, 2 factor Auth based on one time password tokens or similar, which are much lighter to put in place from an admin point of view, though not quite as strong as PKI, of course...
Just my 2 cents,
Edouard