On Thu, Mar 15, 2007 at 12:04:00AM +0100, Kern Sibbald wrote: > 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 > 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.
The University has verbally agreed to transfer copyright. I'm working on the paperwork now. -- Jorj ------------------------------------------------------------------------- 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
