Chris Lonvick
Mon, 15 Oct 2007 11:42:53 -0700
Hi Folks,I have not seen any further discussion on this but we still have some open issues.
I like the idea of describing the cases for the clients and servers to have (or not have) certificates. For high deployability, I believe that the client would not need one at all. At the other extreme, for high security, the clients and servers would need common trust points and certificates.
Please pitch in on this discussion. Thanks, Chris On Wed, 3 Oct 2007, Miao Fuyou wrote:
Hi Anton, Thanks for your feedback!Environment where active attack is concern: The server is configured with certificate, but the clientis not to berequired to be configured with a certificate. The clientcan generatea selt-signed certificate by itself.Why do you need a self-signed certificate here? What purpose does it serve?The client MAY use a self-signed certificate.You are not proposing using it for client authentication here, are you?Not exactly. This is to explore various possible options with regard to certificate, perhaps it is not necessary to appear in the specification.What is that? Let's be more specific if you intend to put this in the doc (same goes for names of these 3 scenarios). I think this configuration does two things: encryption and server authentication.Active attack involves an attempts to change information by contrast with passive attack. To be more specific, it is man-in-the-middle attack is this case.but is vulnerable to client spoof. Security insensitive environment: Both the client and server are not required to be configured with certificate and trust anchor. They generate self-signedcertificates. Again, why do you need client self-signed certificate here?It is very easy for deployment because almost there is no configuration required. Note this configuration is vulnerable to active attack.More specifically, this configuration provides only encryption, but no authentication.Which configuration should be mandatory? I seems we need not a mandatory configuration from the PoV of implementation, right? However, we do need to mandate the implementation (both client and server) to support certificate configuration, trust anchor configuration, and self-signed certificate.Let's separate what is required for implementation, and what is required for deployment. I think server MUST implement & be deployed with a server-based certificates for this transport. Whether it is self-signed or CA-signed can probably be left to a deployment choice. If it is self-signed, then effectively no server authentication is done, just encryption. The other part is client authentication. I think the server MUST support authenticating clients with certificates and client authentication is OPTIONAL for deployment. The minimum authentication that server MUST support is validating the client certificate against trusted CA.OK.A more secure server MAY also want to implement a mechanism which prevents an authenticated client from masquerading as something else in the messages that it emits. For example, 1mln certs may be signed by the same CA, but we don't want one client with one such cert to be able to masquerade as any of the 1mln other clients. To accomplish this, the server need to take client identity from CN field of the certificate and either validate it against some field in syslog message, or at least plug the CN value into the syslog message structured data, so that admin can do whatever validation he/she desires when needed. I think it is good to describe this additional client authentication consideration, but leave it as OPTIONAL. I think we discussed standardizing a unique CN field value before and it was not fruitful. Standard syslog structured field name for CN value would be a good idea.Good idea, but I tend to not mix the content with its tranport. BTW, TLS transport is hop-by-hop protocol rather than an end-to-end protocol, so it will have difficulties to decide the content when the client is just a relay.We will need to specify a cipher suite (probably RSA-AES-CBC) for inter-operatability,We need to specify at least 2 because one of them may become vulnerable after standard is released and software is deployed. The client MUST advertise support of cipher suite X & Y. Server will select the appropriate one based on its configuration for the TLS session. Server should not be forced to select one of those two. I don't think there is any server requirement here. As for specific cipher suites, it will probably be a religious debate. Maybe IETF has a policy on this? I have seen one other standard require these two: * RSA_WITH_3DES_EDE_CBC_SHA * RSA_WITH_RC4_128_SHARC4 is for stream application, does it apply to Syslog/TLS? RFC4346 mandates TLS_RSA_WITH_3DES_EDE_CBC_SHA, however, I think 3DES is a interim algorithm. Actually TLS 1.2 draft mandates TLS_RSA_WITH_AES_128_CBC_SHA.My only concern would be that at least one of them (or better both) is popular enough to be in most of today's major TLS implementations. Regards, Anton.but probably we don't need to specify different cipher suites for 3 various ssenarios because all the scenarios above requires certificate for key pair generation. Regards, Miao _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog_______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog