RE: [Syslog] Charter comments from IESG Review
On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: Of course, a threat model should also be developed, but please keep in mind that anything other than signatures breaks what this WG has fought for since Vancouver. syslog-protocol should be finished (I hope we are there soon) as well as syslog-transport-udp. Then, these both should be taken to a rest and syslog-sign be modified in the sense of -transport and being worked on. I think this can probably done quickly, because -sign is almost complete and just needs to be modified to take advantage of -protocol. To be honest, though, I have to admit that I expect many of the upcoming implementations to violate syslog-protocol by just implementing -protocol and -transport-udp, but not -sign. But that's probably not something to care about... I know that some other mails discussed the same topic and a misunderstanding has already been resolved about whether to support transport-udp or not. I would say that addressing the security concerns at the transport level is way easier management and implementation wise than implementing syslog-sign. And in addition they address a different problem: 1) transport level implements security mechanisms on a per hop-by-hop basis, the message itself is not authenticated, each of the relay stations can modify the message 2) syslog-sign implements per-message, end-to-end authenticity where the relay hosts cannot modify messages as they are individually signed by their origin. So I'd go with using TLS/DTLS on the transport first and then possibly adapting syslog-sign when the transport issues are resolved. -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Charter comments from IESG Review
I agree with Balazs suggestion and his reasoning. Rainer -Original Message- From: Balazs Scheidler [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 10:52 AM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] Charter comments from IESG Review On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: Of course, a threat model should also be developed, but please keep in mind that anything other than signatures breaks what this WG has fought for since Vancouver. syslog-protocol should be finished (I hope we are there soon) as well as syslog-transport-udp. Then, these both should be taken to a rest and syslog-sign be modified in the sense of -transport and being worked on. I think this can probably done quickly, because -sign is almost complete and just needs to be modified to take advantage of -protocol. To be honest, though, I have to admit that I expect many of the upcoming implementations to violate syslog-protocol by just implementing -protocol and -transport-udp, but not -sign. But that's probably not something to care about... I know that some other mails discussed the same topic and a misunderstanding has already been resolved about whether to support transport-udp or not. I would say that addressing the security concerns at the transport level is way easier management and implementation wise than implementing syslog-sign. And in addition they address a different problem: 1) transport level implements security mechanisms on a per hop-by-hop basis, the message itself is not authenticated, each of the relay stations can modify the message 2) syslog-sign implements per-message, end-to-end authenticity where the relay hosts cannot modify messages as they are individually signed by their origin. So I'd go with using TLS/DTLS on the transport first and then possibly adapting syslog-sign when the transport issues are resolved. -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Charter comments from IESG Review
On Tue, 2006-01-10 at 22:02 +1100, Darren Reed wrote: On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote: I would say that addressing the security concerns at the transport level is way easier management and implementation wise than implementing syslog-sign. I disagree with the statement about management as the problem is the same for using a secure protocol at either transport or application level. My reasoning is that people are used to encrypting channels with SSL, they are used to the PKI requirements it involves, they are familiar with SSL cipher suites, CA verification parameters and the like, in summary SSL/TLS itself is a familiar cryptographic framework. Syslog-sign on the other hand is different, it is true that it is going to use X.509 PKI, but all the other familiarity is gone. My point regarding managebility is that network operators use TLS already with a lot of applications (HTTPS is the primer example), compared to this using syslog/TLS is simple. 1) transport level implements security mechanisms on a per hop-by-hop basis, the message itself is not authenticated, each of the relay stations can modify the message 2) syslog-sign implements per-message, end-to-end authenticity where the relay hosts cannot modify messages as they are individually signed by their origin. So I'd go with using TLS/DTLS on the transport first and then possibly adapting syslog-sign when the transport issues are resolved. (1) and (2) are complimentary and one do not exclude the other from being necessary. True, (1) and (2) are independent, my point was to give priority to the first one as it already solves a lot of problems and will help us keep focused. -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Re: Threat model and charter
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 Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[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 Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
