Hi Robert, I think this mostly makes sense. Some questions inline below: > > 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. > [Joe] I'm not sure what the different between the last two are. The capability to chain certificates is indicated in the basic constraints extension of a CA certificate and is validated by standard certificate path validation (RFC 5280), is there a reason why this is not sufficient? Perhaps we can collapse the second two into one. > Implementations may add other additional rules for other > situations where connections are accepted, but these shall > not be the default configuration. > [Joe] I believe that the ability to match a Subject name field should be at least RECOMMENDED.
> 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. [Joe] I think having just one mandatory option is fine. > > 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. > [Joe] This is where a standard fingerprint format can help. > 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. [Joe] So in this scenario you match the end entity cert against a local store, correct? >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
