On Tue, 2007-10-16 at 09:59 -0400, seth vidal wrote: > On Mon, 2007-10-15 at 18:14 -0400, Karl MacMillan wrote: > > On Mon, 2007-10-15 at 16:07 -0400, seth vidal wrote: > > > On Mon, 2007-10-15 at 16:01 -0400, Karl MacMillan wrote: > > > > If you plan to use this cert infrastructure more broadly then my > > > > concerns about the weaknesses grow quite a bit. > > > > > > We can use the cert signing portion of the infrastructure for whatever > > > needs help communicating with certificates as auth. > > > > > > examples: > > > - yum can use the certs to talk to mod_auth_cert on apache to have > > > authenticated access to repositories > > > > > > - nagios can use it as a transport mechanism to do system checks and to > > > send alerts > > > > > > - cacti can use it as a better-authenticated way to gather system stats > > > > > > - puppet can use the certs as it does currently. > > > > > > > I certainly agree that cert infrastructure is useful and important. I > > would argue a few things: > > > > * It would be nice to abstract this kind of authentication / encryption > > where possible to allow the use of other methods (using things like > > SASL). I know you don't like kerberos, but it has many nice properties. > > Sometimes kerberos is better and sometimes certs are better - allowing > > admins to choose is probably best. > > > > * Putting this all on a distribution mechanism that appears to be > > vulnerable to man-in-the-middle attacks is only providing false > > security. > > Your answer to how to avoid the mitm attacks was, ultimately: "that's > what a signed rpms are for". [If you want to skip the bickering back and forth, please skip to the bottom where I have a suggestion that might make all of us happy] Well that was one option. Any mutual authentication scheme - including something as simple as ssh - can give you better security. > You realize that signed rpms have to have a > key to check them. That key is NOT checked during an anaconda install. > So you have to have a source for the rpms you implicitly trust, since > checking once they are already installed is pointless. > Not if you install from DVD or are on a separate, trusted network. And anaconda should be checking for that key since there is should be no danger in distributing it with the boot media (and yes, of course, that media is sometimes insecure, but that doesn't mean that anaconda should just globally punt on checking the signatures). > Trusting that a specific source for your rpms has not been spoofed or > exploited is just as dangerous, if not more so, than what we've set up. > Only for the initial install - from that point forward package signing works fairly well. > So, during any install you're already counting on that an http/ftp/nfs > server is not being spoofed on your network. B/c if it is, anaconda will > happily install compromised packages and even push in an exploiters > gpgkeys. The problem is you have to start your trust somewhere. > In one scenario! How often do we see applications used outside of their original purpose with disastrous security results? > Now, if we want to increase the security then we could just make > certmaster an ssl'd xmlrpc server and have the funcd process (when it > first connects to certmaster) pop up a 'is this the CN of your > certmaster' dialog. That means, of course, that we'll have to allow > automating that process so that people can kickstart their boxes > properly. > That is one solution, though of course those dialogs hardly help. I'm more suggesting that you should consider using other, secure communication channels if they are available. > > * I know that you want very low infrastructure, but I think that you are > > quickly going to want a little more than you currently have if you > > succeed in getting certs widely distributed. Most obvious to me is > > revocation and automated renewal. > > revocation doesn't have any meaning b/c you have to propagate OUT the > revoked keys. Which is why having a real CA is nice. > In this way we're acting like ssh. How do you revoke ankey > ssh key? You don't. You just remove it from the systems in both priv and > pub forms and that's it. > Well - that is one of the main weaknesses of ssh keys and why people want things like kerberos or real certificate infrastructure. And what will you do about key renewal? > > > We are working on similar things as part of freeipa.org. I'd appreciate > > it if you took a look at that and provided some feedback about how that > > doesn't meet your needs. > > b/c the size of the overhead to run it is too large. Setting it up is > more than: yum install func; /etc/init.d/certmaster > start; /etc/init.d/funcd start > > That's one of the points. Simple things get used immediately, > complicated things only get used after hours of meetings and planning. > And how complex do you think freeipa is to set up? It should be one additional step - that requires a realm name and some passwords (and some dns changes if you want auto-discovery to work). Now, I'm not suggesting that there isn't additional overhead because there is. But it is not that much. Here's a suggestion. We were going to propose an F9 feature to continue work on some conventions for cert storage / management. Perhaps what we should have instead is something like the xdg tools for cert management that will present the same interface regardless of the distribution mechanism. It can offer initial distribution of keys, renewal, and revocation. It would also, by default, use cert storage in /etc/pki. I would also like it to work for kerberos keytabs. Thoughts? Would you guys be interested in working with us on that type of feature? Karl
