Miao: > Security sensitive environment: > The server and the client are both configured with > certiifcates. The trust anchors must be configured for both > server and client, so the client and server can validate the > certificate to a common trust anchor. It is not easy to > deploy because there are a lot of work for certificate and > trust anchor configuration. > This configuration could defense all the threats identifed. > > Environment where active attack is concern: > The server is configured with certificate, but the client is > not to be required to be configured with a certificate. The > client can generate a selt-signed certificate by itself.
Why do you need a self-signed certificate here? What purpose does it serve? You are not proposing using it for client authentication here, are you? > However, the client must be configured with trust anchor, so > it can validate the server certificate is trustable. > This configuration is still difficult for deployment because > there are a lot of configuration work to be done. > This confguration could defense active attack, 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. > 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-signed > certificates. 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. 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. > 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_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
