inline > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] > Sent: Monday, February 20, 2006 11:04 PM > To: Chris Lonvick (clonvick); [EMAIL PROTECTED] > Subject: RE: [Syslog] Coming to consensus on syslog threats > > > ... > > > > 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 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. > > 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 protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
