I like Rainer's proposal. I had forgotten about the IESG desire for an
out of box acceptable security. I find this mechanism a bit dubious, but
specifying a reasonably secure default configuration as a separate policy
section could work. How about a structure like this:
In the protocol section, since this is TLS and TLS is certificate
oriented, we have the following requirements:
- The TLS negotiation SHALL be configurable to verify certificates based
on the following rules:
- The local side shall negotiate based on a local certificate store.
The local certificate store contains a list of certificate/server pairs.
- The local side shall verify the remote side matches certificates
found in one of three stores:
- Specific certs where Certificate X is accepted for remote X.
(This is oriented toward self-signed certs)
- (optional) Signing certs, where Remote Y is accepted if its cert
was signed by Certificate Y. No chain of trust.
- (optional) Signing certs, where Remote Z is accepted if its cert
was signed by Certificate Z. Chain of trust is accepted.
Implementations may add other additional rules for other situations where
connections are accepted, but these shall not be the default
configuration.
I made the use of signed certs optional because it pulls in all the other
issues around revocation, etc. I'm not too worried about having a server
manage CRLs, updates, etc. but it could be a problem demanding that all
clients also manage that. I do worry about all the issues that come up in
terms of preserving syslog function during serious network disruptions. I
do not want to see my problem reporting facility (syslog) fail just
because I lost the PKI servers. I'm think of cases where those servers
had been physically destroyed, but 80% of the network still exists, e.g.,
Katrina.
In the policy section,
- By default, if verification fails then the connection will be refused.
- Other rules may be added, but shall not be the out of box default.
- There shall be a maintenance method to create a self-signed cert.
There shall be a maintenance method to import a self cert into any of the
cert stores.
- There may be a maintenance method for adding and removing certs in the
other two kinds of cert stores.
- There may be other authentication and authorization methods.
This then enables a reasonably useful default behavior. With proper
instructions a skilled home user could follow these rules. It also
enables direct implementation of many enterprise rules, although not all
of them. It can encourage developers to split their implementation so
that new policy structures do not cause problems with the underlying
protocol implementation.
The default home user scenario expectation is the following:
- Installing a server:
- Home user generates a self-signed certificate for the server, files
it into the server local certificate store, and saves it for making copies
for clients. The corresponding private key lives somewhere in local
configuration files and the user can be instructed that they should never
ever give that information to other people.
- Installing a client:
- Home user generates a self-signed certificate for the client, files
it into the client local certificate store, and saves it for making copies
for servers. Again, private key remains secret in configuration files
somewhere.
- Home user copies the client self-signed certificate into the server's
specific certs for remotes.
- Home user copies the server self-signed certificate into the client's
specific certs for remotes.
This default does not scale to the large enterprise. Adding the two kinds
of signed cert stores extends the default configuration to support many,
but not all, enterprise policies. There will be other enterprise oriented
methods.
This default does meet the needs of a small enterprise or skilled home
user. By making the default the use of self-signed certificates you avoid
all the problems resulting from the absence of syslog oriented PKI
infrastructures. Even when there are suitable PKI infrastructures for
identity management, these are not generally suitable for applications
authentication management. Introducing a PKI dependency will effectively
delay the use of syslog-tls for many more years.
Using self-signed certificates leaves the home user with the need to copy
around these certificates. Moving files from here to there is something
that can be handled by media, web aps, etc. This is simplified by the
lack of security requirements. All you need is fingerprint display if you
have reason to question the copying. It will overwhelm the unskilled home
user, but they probably won't be configuring syslog. Someone who is
setting up syslog can probably handle instructions for copying
certificates from place to place. Self-signed certs may take a few
minutes to generate, but they are something that is not overly burdensome
for syslog maintenance programs.
This also scales to the needs of many service providers. If a service
provider is installing thousands of dumb remote systems to unsupported
locations (i.e., unskilled home user systems), they can preconfigure the
dumb remote with self-signed certificates. Since the rules only require
matching, the service provider does not need to try to match hostnames, IP
addresses, etc. I would base the cert on the device serial number. This
would not be perfect security. I could break into the dumb remote and
steal the private key. But it is a huge improvement over the current
situation. It does force me to break in, and none of the PKI structures
protect against that. Revocation is a bigger administrative problem but
you can manage revocation of self-signed certificates for simple
situations like this even at the service provider scale.
Kind Regards,
Robert Horn | Agfa HealthCare
Research Scientist | HE/Technology Office
T +1 978 897 4860
Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ,
07660-2199, United States
http://www.agfa.com/healthcare/
Click on link to read important disclaimer:
http://www.agfa.com/healthcare/maildisclaimer
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
