On Thursday 15 March 2007 16:46, Jorj Bauer wrote: > 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.
That's really great. Thanks for your efforts! :-) Landon, at this point, as far as I am concerned, you can proceed with adding the code. Also, if Jorj has other points (bugs), please don't hesitate to address them keeping me informed of you plans. Thanks, Kern PS: Jorj, please let me know when the FLA is sent. That helps me track it. Thanks. ------------------------------------------------------------------------- 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
