"Rainer Gerhards" <[EMAIL PROTECTED]> wrote on 05/14/2008 02:48:25 PM:
> > > > So I go buy a Linksys or Netgear router or other consumer gear. > > > > I slip the CD into the drive and run software to install the > > > > management GUI on my PC. > > > > That software is used to perform an initial configuration of the > > > > device, such as enabling DHCP, setting WEP keys, and so on. > > > > This same software can presumably generate a key and "copy the > > > > fingerprint" to the device, right? > > > > Clueless operator needs not be involved. The Internet is secure. > > > > > > > > right? > > > > > > Mostly ;) What the clueless user still needs to do is > > > > > > 1) copy the server's fingerprint to the client > > > 2) configure the server to accept the client's fingerprint > > > > > > [Robert] > > Another minor correction. The dumb gear sends its certificate to the > > server, and gets its certificate from the server. (I would > > suggest by a > > reasonably secure means, such as https.) You then use the > > fingerprints to > > make sure that the right certificates were copied. > > > > R Horn > > [Rainer] > But that, of course, requires that we specify a protocol for > certificate/fingerprint exchange. The current draft does not provide > this. And, to be honest, I find that is way too much "just" to get TLS > protected syslog... > [rjh] In practice, I do use http or https. My Linksys router speaks http. My firewall speaks http and https. Configuration micro-server and micro-browser applications are very commonplace. The dumb device micro-servers are not flexible full function servers. They are highly restricted and just for configuration purposes. At the syslog server level, you have full function browsers. I do think that we will always have people involved, but can keep the configuration simple. For the low end device I can see two viable common approaches for server configuration: 1) The operator at the server uses their browser to go to the device and copy the client certificate into a local store on the server. This can be very heavily automated by the server software or very lightly automated. I would leave the details out of this protocol level document. The dumb device can have documentation that says where the certificate will be found, and it can be described for human finding on the micro-server. The certificates can be public information and they are reasonably small. I've found it quite practical to copy them around using minimal browser and server software. All the browsers include certificate examination tools, so I use them to check certificates if I think it is justified. In most cases I don't bother because I have other reasons to believe that I've used the right certificates. The operator also copies their syslog deamon certificate to the dumb device using a browser. Again, the micro-server on the dumb device has an upload capability on the appropriate web page. The operator just clicks it, gets their local browser file selection interface, navigates to the right directory, picks their server certificate, and sends it. If you want more automation, javascript technology, ajax, etc. are quite capable of taking the same underlying "move around certificates" and presenting a very sophisticated interface. The major enabler for this would be a separate RFC that specifies the locations for the certificates. E.g., if we said there will be an "http://stupid.device.IP/syslog/my-certificate"; for the device certificate, and a "http://smarter.server.IP/syslog/list-of-clients/certificate-OID"; where client certificates were stored, then you could fully automate this. I do not think that the operational environment and policy ramifications are sufficiently well understood to write such an RFC at this time. I think it is reasonable to say "you will be able to copy in and out certificates". For a while we have more operator involvement, but it is just at the level of copying files to and from documented locations, perhaps with the aid of a browser and basic web pages for configuration. 2) The server just trusts everyone, and uses the certificate information or certificate to notice any changes. This can be strengthened by having a user switch for "trust only clients on the list" and "trust everyone". You start in trust only the list, get the new dumb device set up, switch to trust everyone, send a syslog message, and switch back to trust only the list. If you got more than one new client during that trust everyone period I would flag this as a problem, remove the new clients from the list, and say to the operator "try again, there were two new client attempts, not just the one." The TLS and existing client list lets you do this without interfering with traffic for the already configured clients. The decision between 1) and 2) are a policy tradeoff between installation operator cost and likelihood of failure. Option 1) also allows me to consider things like pre-configuration. In large networks we have pre-configuration servers (using LDAP and other mechanisms) where the network designer pre-configures all the equipment. Then when the physical equipment arrives, the operator just downloads the configuration. Pre-configuration is an enterprise only solution. I don't see home users or small users finding it feasible. It does do nicely for the very dumb devices that are deployed by service provider enterprises. Then the "how to install process" for the home user is actually downloading the preconfigured information and uploading relevant information. Again, this kind of high automation will make sense for enterprises, not home users, and doesn't belong in a protocol specification. I personally prefer 1), but this is on a policy basis. The protocol document should enable the implementation of either policy. R Horn > If we do not specify a protocol for certificate copying, I can not > envison how the low end device will copy certificates to e.g. syslog-ng, > MonitorWare, Kiwi, rsyslog, msyslog, WinSyslog, ... They all have quite > different concepts. So my conlusion is that the operator must do it - at > least for the forseable future... > > Even if the copy *could* happen (and it can't), you still need a GUI > frontend for the syslog to display and accept it. Such a GUI is uncommon > for *nix syslogds. > > Rainer > > > > > Rainer > > > > > > > > David Harrington > > > > [EMAIL PROTECTED] > > > > [EMAIL PROTECTED] > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > > > Syslog mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
