Hi Robert, Section 4.2 includes some requirements for "management interface for policy decisions" because we need interoperabile security.
Since TLS doesn't really verify the certificate (except extracting the public key), in order to get two something-over-TLS implementations to interoperate, you still need to specify how to configure one end to accept the certificate of the other end. Traditionally, the answer has been "just read the PKIX documents", but for small syslog deployments, we really need something more deployable. The fingerprint check in draft version -12 attempts to fill this gap. It's definitely not perfect, or the only possible solution; as you note, it's very similar to actually copying the certificate (your Policy A below). The current text requires management interface support for displaying and configuring fingerprints (instead of displaying and configuring whole certificates) because it was assumed that for many command line and web-based management interfaces, it's much simpler to cut-and-paste a short ASCII string instead of a binary file. (And this should make it more deployable for small syslog environments.) However, it would be perfectly fine to have a management interface that also supports exporting/importing whole certificates. Also, Section 4.2 does not require that a particular deployment actually uses any of the mandatory-to-implement mechanisms, so all your policies A/B/C would be OK. (Also, while Section 4.2 currently has both certification path validation and fingerprints as mandatory-to-implement, it's not totally out-of-the-question that only one of them would be a MUST, and the other one a SHOULD.) Best regards, Pasi > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of ext [EMAIL PROTECTED] > Sent: 08 May, 2008 18:53 > To: Joseph Salowey (jsalowey); [email protected] > Subject: Re: [Syslog] I-D > Action:draft-ietf-syslog-transport-tls-12.txt > > 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
