Section 4.2 is better, but it still needs work to separate the policy decisions from the protocol definition. Policy decisions are driven by risk analysis of the assets, threats, and environment (among other things). These are not uniform over all uses of syslog. That makes it important to separate the policy from the protocol, in both the specifications and in the products.
In the healthcare environment we use TLS to protect many of our connections. This is both an authentication protection and a confidentiality protection. The policy decisions regarding key management and verification will be very similar for a healthcare use of syslog. Some healthcare sites would reach the same policy decision as is in 4.2, but here are three other policy decisions that are also appropriate: Policy A: The clients are provided with their private keys and the public certificates for their authorized servers by means of physical media, delivered by hand from the security office to the client machine support staff. (The media is often CD-R because it's cheap, easy to create, easy to destroy, and easy to use.) During TLS establishment the clients use their assigned private key and the server confirms that the connection is from a machine with one of the assigned private keys. The client confirms that the server matches one of the provided public certificates by direct matching. This is similar to the fingerprint method, but not the same. My most recent experience was with an installation using this method. We had two hours to install over 100 systems, including the network facilities. This can only be done by removing as many installation schedule dependencies as possible. The media method removed the certificate management dependencies. Policy B: These client systems require safety and functional certification before they are made operational. This is done by inspection by an acceptance team. The acceptance team has a "CA on a laptop". After accepting safety and function, they establish a direct isolated physical connection between the client and the laptop. Then using standard key management tools, the client generates a private key and has the corresponding public certificate generated and signed by the laptop. The client is also provided with a public certificate for the CA that must sign the certs for all incoming connections. During a connection setup the client confirms that the server key has been signed by that CA. This is similar to a trusted anchor, but not the same. There is no chain of trust permitted. The key must have been directly signed by the CA. During connection setup the server confirms that the client cert was signed by the "CA on a laptop". Again, no chain of trust is permitted. This policy is incorporating the extra aspect of "has been inspected by the acceptance team" as part of the authentication meaning. They decided on a policy-risk basis that there was not a need to confirm re-inspection, but the "CA on a laptop" did have a revocation server that was kept available to the servers, so that the acceptance team could revoke at will. Policy C: This system was for a server that accepted connections from several independent organizations. Each organization managed certificates differently, but ensured that the organization-CA had signed all certs used for external communications by that organization. All of the client machines were provided with the certs for the shared servers (by a method similar to the fingerprint method). During TLS connection the clients confirmed that the server cert matched one of the certs on their list. The server confirmed that the client cert had been signed by the CA responsible for that IP subnet. The server was configured with a list of organization CA certs and their corresponding IP subnets. I do not expect any single policy choice to be appropriate for all syslog uses. I think it will be better to encourage a separation of function in products. There is more likely to be a commonality of configuration needs for all users of TLS on a particular system than to find a commonality of needs for all users of syslog. The policy decisions implicit in section 4.2 make good sense for many uses. They are not a complete set. So a phrasing that explains the kinds of maintenance and verification needs that are likely is more appropriate. The mandatory verifications can be separated from the key management system and kept as part of the protocol definition. The policy decisions should be left as important examples. 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
