Subject: RE: [Syslog] Coming to consensus on syslog threats

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Mon, 20 Feb 2006 10:03:47 -0500

...

> > 5, Protocol Elements
> > 5.1 Initiation
> > The Sender should initiate a connection to the Receiver on the 
> > appropriate port and then send the TLS ClientHello to begin the TLS 
> > handshake. When the TLS handshake has finished the Sender may then 
> > initiate the first SYSLOG message.
> > Note: We need to define how syslog interpret the authentication 
> > certificates exchanged by handshake protocol.

Very good point. I think we should specify that Common Name (CN) field of the server certificate must be matched to what's configured on the client. Any other ideas?
   
> > Note: We need to discuss what authentication we need: client 
> > authenticated to server, server authenticated to client, or both 
> > (mutual authentication)

I think both options should be supported.  If we support client authentication, there are two possibilities with certificates: generic vs. unique.  With a generic cert I can have all clients have the same cert. In this case, I would authenticate that they all are clients from my organization, for example, but won't ascertain the client identity.  

With unique certificates, the certificate has to include the identity of the client which must be logged/used by the receiver - otherwise you won't know which client you received the message from. For unique client certificates, I think we should state that the identity of the client must be represented in the certificate CN field, but we can leave the format and content undefined.    

> 5.3 Closure
> Sender MUST send a closure alert before closing the connection. Sender 
> which are unprepared to receive any more data MAY choose not to wait 
> for the Receiver 's closure alert and simply close the connection, 
> thus generating an incomplete close on the Receiver side. Receiver 
> MUST attempt to initiate an exchange of closure alerts with the Sender before closing the connection.
> Receiver MAY close the connection after sending the closure alert, 
> thus generating an incomplete close on the Sender side.

So, the sender can keep the persistent connection for as long as it wants unless receiver closes it.  I think we need to recommend that client SHOULD close the connection if it is not using it. If server always initiates connection closing, can it end up with a bunch of sockets in the TIME_WAIT state, which may hinder scalability?     

Should we specify client behavior in case of connection reset by the server? It probably SHOULD retry the un-acknowledged message. Should we recommend incremental back-off? 

Do we need an RPC style message delivery as well, where the server can acknowledge messages after they have been processed by application layer as opposed to ack'ed by the TCP stack?

Thanks,
Anton. 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Miao Fuyou <[email-masked]>
Date: Fri, 24 Feb 2006 10:51:35 +0800

inline

> -----Original Message-----
> From: Anton Okmianski (aokmians) [mailto:[email-masked]] 
> Sent: Monday, February 20, 2006 11:04 PM
> To: Chris Lonvick (clonvick); [email-masked]
> Subject: RE: [Syslog] Coming to consensus on syslog threats
> 
> 
> ...
> 
> > > 5, Protocol Elements
> > > 5.1 Initiation
> Very good point. I think we should specify that Common Name 
> (CN) field of the server certificate must be matched to 
> what's configured on the client. Any other ideas?
>    

> I think both options should be supported.  If we support 

I agree upon that both options should be supported. It is up to the
application 
to decide what authentication is required in specific scenarios. One of my 
consideration is server authentication is indispensible for confidentiality.
If a 
server is spoofed, syslog messages are disclosed to the spoofed server even
if encryption is enabled. 

> client authentication, there are two possibilities with 
> certificates: generic vs. unique.  With a generic cert I can 
> have all clients have the same cert. In this case, I would 

I thinks it is good that all TCP/TLS clients in the same host
(device, relay or collector) share same client cert. My further suggestion
is to resuse
tls session for all clients in same host.  But, I don't think 
the certs can be generic to different hosts, it will weaken the security of
TLS. 

> authenticate that they all are clients from my organization, 
> for example, but won't ascertain the client identity.  
> 
> With unique certificates, the certificate has to include the 
> identity of the client which must be logged/used by the 
> receiver - otherwise you won't know which client you received 
> the message from. For unique client certificates, I think we 
> should state that the identity of the client must be 
> represented in the certificate CN field, but we can leave the 
> format and content undefined.    

> > MUST attempt to initiate an exchange of closure alerts with 
> the Sender before closing the connection.
> So, the sender can keep the persistent connection for as long 
> as it wants unless receiver closes it.  I think we need to 
> recommend that client SHOULD close the connection if it is 
> not using it. If server always initiates connection closing, 
> can it end up with a bunch of sockets in the TIME_WAIT state, 
> which may hinder scalability?     
> 
> Should we specify client behavior in case of connection reset 
> by the server? It probably SHOULD retry the un-acknowledged 
> message. Should we recommend incremental back-off? 
> 
> Do we need an RPC style message delivery as well, where the 
> server can acknowledge messages after they have been 
> processed by application layer as opposed to ack'ed by the TCP stack?
> 
> Thanks,
> Anton. 
>