On Wednesday 14 March 2007 22:29, Landon Fuller wrote: > On Mar 14, 2007, at 13:41, Jorj Bauer wrote: > > Let's take the DNS security issue off the table for the moment. > > As I mentioned at some point, that's mostly paranoia. As you say, > > you'd > > have to compromise both DNS and one of the root CAs to exploit it. I > > only mentioned it for those that are totally paranoid about securing > > their clients. (I'm sure they're out there.) > > Sure -- this is the point of centralized x509 infrastructure. The > best defense is limiting ones exposure by not trusting a wide array > of CAs. > > In an ideal world, we'd have nice PGP-style web of, and levels, of > trust. > > >> I don't understand your failure case -- the *entire purpose* of a CA > >> is to sign certificates by validating the requesting party. > > > > Okay. Let's look at two features in Bacula. This gets to the heart > > of my > > original problem. > > > > (1) TLS. This requires that a FD be at a particular DNS name > > (specifically, that the FD certificate's CN is the same as the Address > > field in the Director's configuration, and the Address field is > > used as > > the DNS name to look up in order to connect to the FD). > > Either the CN, or the subjectAltName. For mobile clients, without > dynamic DNS, this isn't really workable. > > > (2) The Director's "setip" command. This allows a client to change its > > Address registered with the Director. > > > > If one uses (2) to change the address of the client, then (1) will > > fail. > > The only ways to avoid this are to > > > > (a) issue new certificates every time the address changes; > > > > or > > > > (b) decouple validation from the DNS name by making the director > > more > > flexible (i.e. separate the piece of information embedded in > > the cert > > from the one that's used to connect to the client). > > > > Where (b) can be accomplished in at least two ways. One is to separate > > the cert CN from the information used to connect to the client (the CN > > contains something other than the hostname, and is manually > > validated). > > The other is analogous: have the director keep a second string for the > > address update via setip, and then connect to the alternate string but > > validate the original one. > > > > The latter method doesn't solve a similar problem, though: what if a > > device has to change name for a non-technical reason? For example, an > > office move in an organization where the DNS names are tied to > > geographic location. Using non-DNS information embedded in the > > certificate here provides a significantly greater level of > > flexibility, > > and Bacula already (by and large) has the infrastructure to deal with > > this. > > Supporting arbitrary CN values in Bacula is a cheap and effective way > of decoupling TLS authentication from the hostname, and seems > reasonable. > > If Kern doesn't have any objections, I'd like to merge it into HEAD.
I don't have any objections with the feature enhancement, but at the current time we cannot use the patch supplied because it is copyrighted by the University, and they seem to be unlikely (to the best of my knowledge) to sign or agree to the FLA. Nor do I have problems with "fixing" the bug reported by Jorj (if I remember right) where there is a problem handling wild-card CNs. Best regards, Kern > > -landonf ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
