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.
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.
In a word... no.
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.
...and misread it as "does your company use a PK solution?" ...yeah, I wish they would... some PKing around the office might not be a bad thing.
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.
I think the University of Virginia uses something like this for authentication. You can go to the IT department website to try and find out. There are contact numbers listed, too. www.itc.virginia.edu
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?
For some internal (non user-facing) things I have used a self signed cert; for example when prototyping cosign (web single sign on).
In the past we have rolled out a CA signed by CREN. This was a pretty small rollout and used for just Shibboleth, S/MIME, Web Auth, and some limited classroom work using handheld devices. At this point we are using mostly Thawte Freemail for S/MIME and CACERT for S/MIME, PDF signing, 802.1x, and a odd series of other tests/work.
This is less than ideal since we end up beholden to corporate groups, but there is something good on the horizon, USHER Usher is a higher ED CA being put together by Internet2 which will be cross certified with the Federal CA bridge. Basically what CREN was supposed to be, only with more backing and interest.
The nice thing about it is that we will get a signing cert to use at will rather than paying someone like Verisign per certificate which is not gonna happen with 138,000 users, especially if we wish to do any kind of PKI-LITE setup (where short term "junk certs" are issued on demand eliminating the need for a CRL which nobody has figured out how to do right yet).
I did a fairly extensive pilot of this at my previous company, with the assistance of Microsoft. We demonstrated everything you mentioned successfully and did scalability tests that indicated that with careful planning, we could scale it to serve our needs (~100,000 users). We used the Active Directory integration, which made issuing and revoking certs seemless for the Windows users (most of the desktops). The primary application was WLAN security, but we demonstrated everything from SSL certs to application signing. We also used the Safenet CA3 hardware root key device as well. There is a *lot* of planning required to make this work well, but it does work.
My company believed that we had a private key infrastructure, but it seems that our moss green frog hide-a-key was a layer of deception far too easily pierced by even the most novice criminal mind...
we now use a terra-cotta sleeping bunny key safe and feel much more secure.
That would be a protected infrastructure.
BTW, the "Images" shown at the bottom of the screen are completely irrelevant to the bunny picture.
Our passwords are so bad that John Q. Public could have root in about four minutes.
Does that count?
Quantum materiae materietur marmota monax si marmota monax materiam possit materiari?
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
Slightly off subject, but what about BlueSocket? It passes your authentication info to a RADIUS/IAS server then sets up AES encryption. I'm fuzzy on details but this is primarily a wireless solution. With VLANS and using their "Clientless" client loaded on the machine you could authenticate and encrypt non-wireless traffic. They get away with calling it clientless because their client piece simply configures a windows xp VPN setup with no fuss. You could in theory accomplish it with a registry hack and only xp tools.
They charge a pretty penny and this is mostly for wireless applications.
I have used OpenSSL to set up Certificate Authorities for military testbeds prior to, and coinciding with, their own PKI rollout. There is no cost associated with its use and once you learn how to use it, it is very easy to use. OpenSSL creates and signs standard X.509 certificates that work with any browser, webserver, or email program that utilize such certificates. You can set up CRLs and such easily as well.
OpenSSL is very powerful and useful. I have used it for many of its encryption routines (such as locking up my pr0n collection while I am in the Middle East!).
strike
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
But I know if we were to implement some sort of security solution we'd go straight to Microsoft for a fairly priced product from a company with a proven track record of putting security first.
How long did the OP suck Bill Gates' nuts before deciding this was a valid question to be asked outside of the campus????
US DOD is probably the single largest user of PKI in the world.
We (Navy via NMCI) use multi-factor identification. Most commands have CAC cards (basically just smart cards) that store multiple keys (one for email, one for web pages, one for digital sigs). To access any data on the cards (including certs) you also need a PIN. Furthermore, most systems have an additional (strong) login uname/pass after your cert is accepted. The result is password overload but fairly decent security.
You minimally have dual authentication factors (physical card access and PIN) and is most cases triple authentication.
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?
What, exactly, were you trying to do? What were you trying to protect, from who and did this really do it? When you saw WLAN, is that wide area network or wireless local area network? If it's wireless, why is it you have to worry about that? How much did all of this cost and how many users did it cover?
I've got big doubts whenever someone puts Microsoft and security together. What good is an authenticated user when the OS underneath gets rooted and keylogged by an email or webpage view?
Friends don't help friends install M$ junk.
I do security work for a Fortune 100 company, and while we've got the usual SSL certs on some of our web servers, we haven't yet had a compelling business case that would justify the huge expense to do PKI right. Coupled with the belief that PKI done wrong is worse than not doing PKI at all, we've stuck with point solutions for our encryption needs thus far.
I believe that we're moving forward with certs in the ActiveDirectory to facilitate EAP-TLS on our wireless, and that will probably go farther towards "universal" certificates for our end users, but since rolling out smart card readers to tens of thousands of users will be a significant investment, using certs for regular auth to the AD just isn't cost justified yet.
In the mean time, we've got self-signed certs for signing internal applications, and use some commercial, GPG-like software for desktop/email encryption :-) SSH works quite well for shell access, although the onesie-twosie management of the RSA keys is a major bitch.
In reality, I doubt that we'll ever go for a full-blown PKI done right. Every time we look at it, we figure out that the servers, admins, training, and physical security improvements will cost $6 million, and it won't really buy that much. For important authentication things, especially remote access, using those random-number tokens works really well, and doesn't have nearly the costs associated with them that PKI does.
noooooo... its all about http://pki.com/!
"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,
A lot of good this will do you when the employee without admin priviledges plays a Sony DRM CD on thier computer. Windows still isn't secure, never has been. Ask the NSA how they do it with SELinux. Ask slashdot my ass.
At work I have a soft cert (pkcs12) and a "smart card" hard cert. Neither is really much of a PITA once you get used to using them. Browsing signed emails is s-l-o-w, at least with exchange. Maybe OCSP fixes that, I'm not sure.
I think the cost for a cert is between $50 and $120 or so. But issuing and managing can be a headache. I'll bet my office of about 3000 people has had *at least* a 50% password failure rate. The smart cards only give you 4 failures then they commit suicide and have to be reactivated manually.
It is based on the Netscape Certificate Server product (which is in use at the DoD as part of a huge certificate infrastructure) but has numerous additional features including a smartcard/token management system that enables two factor authentication out of the box.
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.
I am the administrator of a large network with just under 1,000 servers (1.5 million active users in the main environment) and I must agree with the parent. Creating a certificate takes exactly 15 seconds on my slowest server and deploying it for use takes only slightly longer. Users can generate their own certificates for e-mail clients and the certificates are replicated through the tree so if one certificate server goes down there are still at least two other servers ready to dish them out. I had no idea the pain people in my company's MS-side of the company had when it came to issuing certificates (though they said it is easy compared to using third-party certificates in the same system) until I was asked for help the other day. I showed them how I created a certificate and threw it on an LDAP server just to demo it and the whole thing took just over a minute and a half (from start of process to authentication via LDAPS). The windows admin just applied for the opening on our side of the shop. I've used OpenSSL a few times on my test systems and that works but PKI in Novell's environment is just too easy to pass up.
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 HSPD12PKI and other names for encryption like encryption, lock etc. are stupid names. What should be done to advance its adoption is to have a put in envelope button and an open envelope button. This way it hammers the point that email is a post card and if you have something you don't want the world to see, you put it in an envelope. It is a paradigm that translates well from the real world and makes much more sense than lock and unlock or encrypt and decrypt.
just my 2 cents.
The war with islam is a war on the beast
The war on terror is a war for peace
Seriously, at one time or another - I've used every imaginable sericve over simple ssh port forwards and reverse port-forwards. Also, using public key auth, it's one of the few services I trust to be open on the internet. (I always turn off root though and /sbin/nologin unrequired accounts) There are even file browsers that work over ssh, it is intuitive simple, and I've herd that it can be used over for ldap for centralized key managment. (though I've never done it)
I honestly think that, after 20 years of PKI "about-to-take-off" that the tipping point isn't going to come from corporations: It's is going to come from customers, most likely of Paypal or Ebay or CitiBank or Bank of America or Walmart or CVS or Postal Service or whomever (RadioShack?).
What will drive this will be developing and promoting a decent public PKI system. "Stop by the Customer Service Counter with enough ID and someone (with a bit of training) will certify you for a "Trusted Customer Card & Code" today!"
Then all of the good things that folks promise about PKI can be told/sold to J. Random Customer, and it'll be cheaper then a toaster and as valuable as their customer affinity card.
As a marketing tool it'll be high profile, moderately high contact, and likely with enormous retention. Sure there's an educational aspect but the press can handle that, every article will just bring that much more brand-awareness. Wanna verify my online whatever? I use Brand A!
Roll out a free plugin for the top 5 email clients and the lead will be impressive. It's techie, it's "smart", it'll be like recycling without having to deal with material objects.
Sorry, I know it all seems implausable, but when public PKI gets going I think it'll be bigger then "search" & "portals" and a lot "stickier".
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
You 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
Yeah, they chained all of them down with those coated cables.
This was allegedly to prevent people from "borrowing" them, but everyone knows that it was because Dan the sales-guy (moron) tried to smash the keyboard over the monitor because he couldn't figure out that the printer was out of paper.
Dan nearly put out a VP's good eye with his backswing.
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.
we use a Psycho Kinetic Interface on all our hardware. It has serious improved productivity, and the games are out this world.
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.
And don't forget you should only go 50 MPH on that spare tire, which of course is referring to making sure the security staff is given donuts every friday.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
I am looking for a product that simplifies the process of handling multiple key pairs. The minimum should be dual key pairs, one for encryption, another for signing/non-repudiation. This is for keeping the former active after an employee leaves so we can access the files he created for the company. The other key should never be used again.
Any experience in this area? How about external parties recognizing the use of dual key pairs in communication? I can evangelize to a couple of customers about this technology, but not the entire world.
Take a look at PHPki on Sourceforge. It may not be robust enough for your needs, but it works well as a basic PKI/certificate factory in a CLOSED environment with simple needs. One caveat, is that it stores private keys on the same server with the certificates. That's obviously not PURE best practice, but it's not out of line with what many are already doing with OpenSSL at the shell prompt, and it is likely acceptable in many environments. It certainly has appropriate applications. The online demo can be a bit flaky depending on how overloaded Sourceforge is at the time.
My company's idea of security is to require all authentication between internal systems to pass over SSL HTTP links using self-signed certs, and open trouble tickets against systems found not to be using them.
:)
And you've done business with us, baby.
uses a worldwide PKI infrastructure to access sensitive content
Take a look at the OpenCA project http://www.openca.org/ or http://sf.net/projects/openca/
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
United States Air Force was one of the early adopters of PKI.
Some days I get the sinking feeling Orwell was an optimist.
Switch port authentication? You don't need a certificate to authenticate someone plugging into your switch port. Just look at the dude and see you recognize him.
Although I guess we could pin our public keys on our shirts like nametags and walk around that way.
As evidenced by this page, it looks like Slackware's web site has been compromised. Everyone who downloaded Slackware recently should probably check their MD5 and PGP sigs to make sure they didn't get anything tainted.
I'm just glad LSU doesn't bare that yeasty badge of dishonor any more!
Please help me develop a security system. I intend for my victim to use for something really secret and important (launch codes, financial information, medical records and the like). It has to be based on a platform that is constantly found to be completely insecure and which is widely believed to be unfixable. Also, to make things really interesting I thought I'd get a bunch who've been known to issue certs to people posing as employees of their customers.
Next week I'll be looking at turning water into wine...
Microsoft, VeriSign Warn of Security Hole
Actually we just switched AWAY from MS cert services to an outsourced CA. I did this because we primarily used the MS CA for smartcard logins, and I was able to get one of the FREE online CA's to support the required configurations.
Because they have passed their webtrust compativle security audit, they will soon have major browser inclusion. Thus we will soon have a single cert that can be used for email encryption, IM encryption using certs using Simp ( http://www.secway.com/ ), and SmartCard logon to the network.
1. I installed PHPki and used it as a CA,
2. Generated oodles of certificates for our entire staff (SMIME certs, so they work with Outlook 2K and 2K3)
3. Published each of their certificates to the Global Address List
4. Had everyone set the option in Outlook to include their public cert as an attachment to signed/encrypted emails
5. Had everyone install the CA's root cert on their machine
Now they can send eachother signed and encrypted emails, all WITHOUT any kind of Microsoft CA or server. It's important in our environment that the private certs NOT be stored where the email/Exchange admins have access to them, so while it takes a little manual labor, it's FREE and works very very well.
With the first link, the chain is forged.
Yes, the company I work for does have a large PKI implimentation. Unfortunately, I work for a charter Bank in Canada, so I can't tell you anything about it, else the security people will swoop down and kill me.
I'm from cincinnati, and where i'm from PKI stands for Paramont's Kings Island, and if thats the case, then yes! i've been to a company picnic at PKI!
Ya know a lot of people have been extremely helpful to this kid, and it's not like he didn't do his hw, look at his other posts, it sounds like he justs needs a little help sorting through the mess of half ass standards, and getting some other perspective on a not so common technology.
Wally to Pointy-Haired-Boss: I don't understand how the new reorganization will help us "focus on our core business." Did our core business change? Or are you saying that every reorg prior to this was a misdirected failure?
Pointy-Haired-Boss: Wally, when a car gets a flat tire, what do you do?
Wally: Well, if I'm you, I rotate the tires and drive home.
Among the most popular, the windows one rates probably highest.. but it really has quite a significant ease of use factor... unfortunately...
Also the various verisign services, onsite, etc.
But the one i liked the most personally was the sun/iplanet implementation, which they decided to kill which was a real shame cause it was easy to administer and caused very frew problems...
If both the client and the server are in your company, you can generate your own certificates (using Windows 2003 Certificate Services). When you purchase a certificate from CA (Certificate Authority, e.g. Verisign), you are paying for the trust. When the client and server belong to different enties, the CA acts as a 3rd party that everybody trusts. Also, most web browser automaticly trust the major CAs.
mathematically proving that noone that can't factor huge primes can get your secrets
I think you'll find that factoring large prime numbers is rather easy.
I think you mean to say, "find the prime factors of large integers."
So MS's PKI design is PKINIT/Kerberos.
... I wouldn't want to trust MS never broke it with a security update.
:-P
... Make something better please. :-p.
It is easy to deploy and resonably secure if everyone is in the same forest.
Pros.
+ SSO works "out of box"
+ Easy.
Con.
- Session highjacking via a Man-in-Middle attack during initial login.
- Doesn't work across areas of different trust well. Direct use of
Certificates is much more flexiable. Trust is basically slightly better
than all or nothing.
- Same CA typicial sign machines and people.
- Can't tell KDC to trust one CA for people only or machines only.
- KDC compromise is potentially devestating. Undermines not only
all Authentication, but all Encryption as well.
- Elminiating Cross Realm attacks, or impersonation is probably
possible, but I haven't tried it and if I got a configuration to work
- No OCSP support.
- CRL are aggressively cached and not checked for freshness if you use an
external CA.
That said there are not as many options as I'd like.
Entrust makes something. So does Novell. They work ok.
Novell basically uses password based kerberos tickets and
can randomize a users password basically making it a
short term shared secret. The plus is it allows untrusted
Realms/forest to interact without trusted each other. But, its
not trilling either.
I would look at the pGina stuff. Its not there yet but there are
some interesting things. SSH gina plugin for instance
There is an LDAP plugin but it does not support clientside certs
or smartcards. (I really wish it did!)
Globus particalurly the GSI stuff is really neat, but smartcard
support is not fully there. Windows support (at least login) I
don't think is there either with a the pure certificate based system.
So the summary is they all suck
MS solution works _very_ well for small companies. It does not
work well for organizations that have distributted IT departments
because ultimately those guys usually have and want and deserve to
keep full control over their domain.
The problem is much worse when different "companies" need to
collaborate. IMO that is the point at which MS solution
fails completely, but Novell's solution might still work.
Garick
We need PKI at my company, but there's a big problem.
The people who would be responsible for keys, can just barely handle email.
I know I'm not alone, and I know I'm not the only lone admin who would have to be responsible for put such a system in place, and have to hold hands & train users.
I have researched my eyes out.
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.
:-)
;-) instead they just plug in the damn thing and enter a number. Thus you not only minimize the risks introduced by the human factor, but you also get two-factor authentication for free.
Well, unfortunately killing every human is not an option
But you can minimize that effect. A number of banks from my country uses a tool called RSA Cryptographic Provider to store the certificates on smart cards or tokens. Now, the person only has to remember a PIN code, which is not a big deal (today PINs are on credit cards, mobiles, office-locks, etc), so remembering one is simple.
All you have to do is make sure they don't use '11111' or something just as weak. Now, people don't even realize that they use a certificate
Then there's this other thing - the certificate is NOT stored on the computer, so you can use it from wherever you are, without leaving traces. A friend of mine got his certificate compromised back a few days; Windows stored them in its repository, and my friend made regularly snapshots of his system partition. Somebody got hold of one of those images, restored them on a different box and used his certificate to do some nasty stuff. Shit like this happens, so you gotta be careful.
That's what I felt like writing...
so, is anyone using openCA ?
How does it compare to other solutions metioned here?
- Microsoft PKI
- RH Certification System
- tyneCA
- phpCA
Don't forget to check out the PKI infrastructure on Novell EDir, its easy (much easier than on MS boxes in my opinion) and is essentially a no brainer in a Novell environment.
With all this talk of PKI and such, has anyone actually started planning for the collapse of RSA, Diffie-Hellman, and other forms of public-key crypto? We've never had a security proof of these systems (information-theoretic or even computational security), and, since the publication of Shor's algorithm, we now know they can be broken with a quantum computer. Perhaps there's also a classical algorithm for breaking them, but let's assume not. Quantum computers are probably a minimum of ten years away (more like twenty five years, but let's consider the realistic worst case of ten).
I'm guessing many of you have forward security requirements of longer than ten years. Medical records, financial data, and lots of other things probably need to stay secret for longer than that. That means that you need to start now on preparing for the collapse of public-key crypto. Has anyone in IT actually started doing this? Anyone even thought about it?
Disclaimer: IAAQCR (I am a quantum computing researcher).
IDX-PKI is an Open Source (GPL) implementation of a Public Key Infrastructure which aims to be IETF compliant for PKIX recommendations. IDX-PKI is already used by companies and public agencies.
http://idx-pki.idealx.org/index.en.html
new version is expected RSN.
Out-of-the-box solutions are extremely expensive, and will nearly always require you to do months or years of extremely expensive customization.
Also, any solution which claims to use CRLs of any type is radioactive. It's fundamentally broken, in a very obvious way. The intelligent way to handle cert revocation, expiry, etc is by leveraging an existing sitewide directory, be it AD, LDAP, any X.500-based infrastructure, etc. Store x.509 cert objects in directory entries.
If you have people that know the stuff or can figure it out, building your own (either from the ground up or using OpenSSL) is, counterintuitively, likely to be in the long run the cheaper, easier, and more well-implemented option.
This will likely change in a couple years' time, as the Feds finally have a working PKI in production, and will begin requiring remote sites to implement PKI and join bridges/federation/buzzwordbuzzword for grant processing and the like. After twenty years it's about to gain traction, and I'd suspect in about three years you will be able to get an out-of-the-box solution that's useful without spending just as much time on it as you would with a roll-your-own.
Thanks to everyone who had some great things to say and some insight for my research that is only possible with views from "many" as opposed to one. Much appreciated. JP
JP
The EEMA did quite a bit of work comparing various PKIs a few years ago, http://www.eema.org/index.cfm?fuseaction=focus.con tent&cmid=148&CFID=1697220&CFTOKEN=d0c7818f40accdc 1-D3A2DEB2-A87D-1574-A4D652C7C7397481
Final Report [pdf]
http://www.eema.org/downloads/security_finished_pa pers/pkiC_final_report.pdf