RE: [Syslog] Authentication, certificates, trust anchor, cipher suite and deployability for syslog/tls

[Miao Fuyou <miaofy at huawei.com>]

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 at lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/syslog
> > 
> 



_______________________________________________
Syslog mailing list
Syslog at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog