Hi Anton, Thanks for your feedback!
> > 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? 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-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. 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_SHA RC4 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
