Re: [Syslog] Document shepherd report of AD concerns

[<[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/syslog