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". 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. 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. 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. 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. > * 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. In this way we're acting like ssh. How do you revoke an ssh key? You don't. You just remove it from the systems in both priv and pub forms and that's it. > 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. -sv
