[Syslog] -transport-tls-12, section 4.2 suggestion

[[e-mail]]

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  [phone]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/syslog