Hi, I summarized the issues resolving, soon I will update the document and get it posted. The resolutions are tentative, if you have different idea to resolutions, please comment on mailing list!
[Issue 0]: Do we need a Syslog TCP port for TLS transport? The security community had debates about whether using special ports is desirable. Tentative resolution: Yes, we need a port < 1024 for syslog/tls (refer to http://www1.ietf.org/mail-archive/web/syslog/current/msg00910.html) [Issue 1]: Is it possible to use "generic certificate for different host? The generic certificate is for specific application type. AND [Issue 2]: What to bind to a certificate? Hostname, Syslog APP- NAME(generic certificate)? APP-NAME binding makes authentication/ access control happens both in TLS handshake and Syslog message processing, is efficiency a problem? Tentative resolution: 1, Generic certificate may not be possible (refer to http://www1.ietf.org/mail-archive/web/syslog/current/msg00918.html). So bind app-name is not required and possible. 2, We need cerficate binding to host name, operator to decide whether to check the binding. Receiver may consult DNS to get host name for a sender, while sender may just query local configuration to get host name. [Issue 3] The problem of CR LF is it can not process binary data well. How to process Syslog signature/certificate message? Tentative resolution: We need byte counter, the byte counter is in a text based format(refer to http://www1.ietf.org/mail-archive/web/syslog/current/msg00902.html). [Issue 4]: Shall we mandate the sender MUST be authenticated? Most of the Syslogd accepts messages only from configured address. Tentative resolution: It should be optional to operator, use SHOULD or MAY instead of MUST and explain security implication. I tend to use SHOULD. (Refer to http://www1.ietf.org/mail-archive/web/syslog/current/msg00912.html) Miao _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
