Rainer Gerhards wrote: > This text is along a fine line of differences: it talks about the > sender checking the server. It is the same model that HTTPS uses > (sorry, but this *is* the analogy). The server is authenticated but > the client not. > > The text is NOT talking about the server authenticating the client.
Yes, the text was intended to clarify Section 4.2.1; Section 4.2.2 also needs similar clarifications (although as you note, the text isn't necessarily identical, and different requirements for minimal compliance could be specified). > Let's look at a syslog.conf line: > > *.* @@<server> > > Where server is the remote server's name or IP address. This is > (extended) rsyslog syntax, but in essence it is the same for all > implementations. What always must be configured is the name of the > server. > > So it is quite easy to check the server identity (again, just like > https) - we can simply compare the name from the cert to what was > configured as <server>. Note that this process is fully automatic if > the sender ships with a set of trusted root certs (like web browsers > do) and the server operator obtained a cert from one of those > authorities. As I said myself, a home user is not likely to pay the > associated fee, but a small biz may do. The advantage is obvious, > because we have instant security without any need to configure > anything (that would not be configured in any case). > > A server cert fingerprint requires a bit more of configuration, but > can obviously be a good solution in scenarios where neiterh PKI nor > paid public certs are available. > > If we look at the server, there is no such semi-automatic > authentication available. The client can not actually be > authenticated. We have a hop by hop archetecture and we have no > required indication of relays inside the message. So for the server, > we can not have a check if client is authentic (is who it claims it > is) but instead we can just have access control - we can check if > the client is permitted to send to us. IMHO this is different from > verifying authenticity. In a relay chain, the relay may still > receive spoofed messages from a relay in front of it. So we can not > autenticate the messages themselfs but only provide access control > for the machine that is connecting to us. Once we are beyond that > stage, we may still receive spoofed, faked, whatever messages. We > can only trust messages if all relays in the chain are configured > with TLS and the same access control. For *nix based syslogds, even > that does not help, because the message on the OS log socket may > already be spoofed. > > Thus, I consider authenticating the originator or relay to the > receiver (or relay) quite less important than authenticating the > server to the client. > > This is the reason that I propose to not only split these two modes > (as already happened), but have different minimal requirements for > them. > > A useful mode to actually authenticate messages is to check the > hostname provided inside the message against the clients > certificate. Of course, this only work on the first hop after the > originator, only if we have syslog-protcol formatted messages and is > still somewhat vulnerable to local log injection in a *nix > environment (there is no cure against that). If one thinks along > these lines, it would be quite useful to have an additional access > policy the requires a given server to accept only a given set of > hostnames from a remote client (those that it is permitted to relay > from). This check is probably more useful than the initial > cert-based access control check because it (somewhat) protects > against injecting malicious messages (somewhat, because it still > depends on the full chain being properly protected, it is just > easier to detect simpler attacks, what I find useful). So far, the security checks in -transport-tls draft have been solely at the *transport* level, and not concerned with the contents of the message. (The security considerations text needs to explicitly say this, though -- currently, it doesn't.) Best regards, Pasi _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
