Subject: Re: [Syslog] syslog/tls policies and use cases

From: "David Harrington" <[email-masked]>
Date: Wed, 14 May 2008 08:07:24 -0400

Hi,

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?

David Harrington
[email-masked]
[email-masked]
[email-masked]

_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 14 May 2008 18:29:44 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of David Harrington
> Sent: Wednesday, May 14, 2008 2:07 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Syslog] syslog/tls policies and use cases
> 
> Hi,
> 

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

Rainer

---

From: [email-masked]
Date: Wed, 14 May 2008 14:30:52 -0400

> 2) configure the server to accept the client's fingerprint

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 14 May 2008 20:48:25 +0200

> [Robert] 

[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...

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

---

From: [email-masked]
Date: Wed, 14 May 2008 16:02:24 -0400

"Rainer Gerhards" <[email-masked]> wrote on 05/14/2008 02:48:25 

> this. And, to be honest, I find that is way too much "just" to get TLS

[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

---

From: "tom.petch" <[email-masked]>
Date: Fri, 16 May 2008 09:29:46 +0200

Rainer

I do not think that Robert or David is suggesting that we standardise this, just
that this is close to what already happens when I customise an entry level box,
using proprietary tools.  (I have even used SNMP to do something like this, it
happened to be the protocol that the manufacturer provided).

So yes, I do see this as a viable way forward (but would not want to see more
than a passing reference to it, or an overview, in section 5 of the I-D).

If such a mechanism is to be standardised, then it should IMO be a pkix-like
group, or a non-IETF one focussed on configuration.

Tom Petch