Chris, I can probably not comment on everything in the conversation between Chris and Sam, but I can put in some real-world experience. With syslog, we have not (yet) natively implemented TLS (this is planned, but if an I-D will surface, we'll probably wait a little bit and try to do it "the standards way"). However, we support syslog over SSL/TLS with the help of the stunnel tool. This option is quite popular. Besides that it requires a second software, you can think of it as being an syslog/TLS implementation (this is also the reason we are not really pressed in implementing it natively).
It is true, TLS does not necessarily provide peer authentication. Many folks have deployed it without authentication because their primary threat is the clear text message transport. They do not want the data to be visible to an onlooker. Unauthenticated TLS works well with that. These systems are often inside the local Intranet, only. Some of them guard the syslogd via firewall rules, others allow only specific senders and again others combine these two methods. As the underlying transport is (non-standard) syslog/plain tcp, it is not trivial to spoof a sender IP address, so this level of "authentication" is usually considered to be sufficient. It is also extremly esay to implement, which explains its popularity. However, it *is* possible to authenticate the peers via X.509 certificates. Any TLS implementation can do client and server certificate verification as part of the session setup process. To the best of my knowledge, some folks use this feature with stunnel. So the server accepts messages only from clients which are authenticated via their certificate (their certificate-based names are configured at the server side). Please note that this does not authenticate a specific *user* but rather a sender machine (or process). In my point of view, this is not a disadvantage but a requirement. Syslog senders need to be capable of automatically restarting and thus some authentication information must be stored at the client (please note that for highest security, you can protect the certificate with a passphrase so that upon machine startup an operator must manually enter it - this option is IMHO impractical for syslog, but I wanted to state it). Based on this experience, I would recommend the following: #1 REQUIRE (unauthenticated) TLS to address 6.4 Reliable Delivery 6.6 Message Observation #2 RECOMMEND / allow certificate-based authentication during TLS session setup to address 6.5 Message Integrity 6.3.4 Replaying 6.2 Message Authenticity 8.8. Misconfiguration (from -protocol-16, solved partly) 8.11. Denial of Service (from -protocol-16, mitigated) [all section numbers are from RFC 3164 except otherwise noted] The important point is that I recommend NOT to mandate authentication, as the operational overhead might not be desirable for an operator (practice tells me this). On the other hand, it might make sense to mandate that a -transport-tls (let me call it so for now) compliant implementation MUST support #2, but MUST be configurable to not use it. That way, we would require that each implementation supports full security but do not force the operator to use it. However, I am not sure if such wording is within the scope of the IETF. Programatically, implementing #2 is pretty easy when #1 is done. So #2 should technically not cause any loss of implementor acceptance. I am not expert enough to tell what other subleties TLS might have in stock. I am talking on my practical experience ;) -transport-tls would need to have two parts: #1 framing (how to place -transport messages into the stream) #2 tls specific wording If it helps, I would be available to work on #1, but #2 is most probably above my head. As -transport-tls calls to a final solution to the dangling framing issue, it technically makes sense to hold final submission of -protocol until this has been solved. The framing discussion might be more productive if we are somewhat flexible in the -protocol area (namely: ending terminator, we have only a very weak consensus on this). I do not see any big problem when we hold submission of -protocol and -transport-udp unless -transport-tls is finished. Except, of course, all milestones must be moved accordingly. In any case, we should still finish work on -protocol and -transport-udp NOW and then concentrate on -transport-tls. Changes to -protocol should only be made if there is really good reasoning to do so. Given the wide deployment of SSL/TLS syslog and the low deployment of SSH (I think Kiwi uses it optionally), I'd strongly recommend taking the TLS route. Implementor acceptance will probably be much greater thanks to the well-known, well-used, well-available and quite good openssl library. I do not see what SSH would offer us that TLS can not do. Rainer > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick > Sent: Tuesday, January 10, 2006 7:33 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [Syslog] Re: Threat model and charter > > Hi Working Group, > > I'll pass this along to those people who have already implemented > syslog/TLS(SSL). Please be specific about why you did this. > > Thanks, > Chris > > On Tue, 10 Jan 2006, Sam Hartman wrote: > > > Hi. > > > > Can you explain what actions on a part of an attacker are > prevented in > > terms of attacks on message integrity without authenticating the > > source of the message? > > > > In general, the security community is very suspicious of mechanisms > > that provide integrity without authentication. If you are going to > > propose such a mechanism then you need to explain why it is > > appropriate in your environment. > > > > In effect, in terms of integrity, it sounds like you say that it is > > important for a sender to know that the message has been transported > > to the receiver unmodified. However since the receiver > does not know > > who is sending it the message, the receiver cannot know > anything about > > the integrity of the message. > > > > It may be a bit more complicated than that. If the message contains > > confidential information that an attacker could not have generated > > then the receiver may actually know that the message is unmodified > > without knowing who generated it. > > > > However it seems like your proposal does not protect > against a number > > of attacks. In particular, an attacker can generate messages > > appearing to come from any source and containing content of the > > attacker's choosing. This combined with the ability to suppress > > messages sounds like enough to get around any message integrity you > > might have. > > > > > > Also, I'd reword the charter bullet regarding the secure transport. > > You want a bullet claiming that you will write a document > describing a > > secure transport. Actually requiring the secure transport be > > implemented happens in the protocol document. As a result, > you cannot > > submit syslog-protocol to the IESG until this transport document is > > written. It might be possible for the protocol document not to > > discuss mandatory transports at all and for there to be a later > > applicability statement for syslog requiring protocol, the secure > > transport and UDP. RFC 2026 does allow that structure but I don't > > know of any WG who has actually done things that way. > > > > --Sam > > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
