Subject: RE: [Syslog] Revised proposed charter

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 23 Nov 2005 18:19:38 +0100

I fully agreee.

Rainer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Chris Lonvick
> Sent: Wednesday, November 23, 2005 6:05 PM
> To: [email-masked]
> Subject: [Syslog] Revised proposed charter
> 
> Hi All,
> 
> ==== v2 of proposed charter ===
> 
> Syslog is a de-facto standard for logging system events.  
> However, the 
> protocol component of this event logging system has not been formally 
> documented.  While the protocol has been very useful and 
> scalable, it has 
> some known security problems which were documented in RFC 3164.
> 
> The goal of this working group is to address the security and 
> integrity 
> problems, and to standardize the syslog protocol, transport, 
> and a select 
> set of mechanisms in a manner that considers the ease of 
> migration between 
> and the co-existence of existing versions and the standard.
> 
> syslog has traditionally been transported over UDP and this 
> WG has already 
> defined RFC 3195 for the reliable transport for the syslog 
> messages.  The 
> WG will separate the UDP transport from the protocol so that 
> others may 
> define additional transports in the future.
> 
> 
> - A document will be produced that describes a standardized syslog
> protocol.  A mechanism will also be defined in this document
> that will provide a means to convey structured data.
> 
> - A document will be produced that describes a standardized UDP
> transport for syslog.
> 
> - A document will be produced that describes a standardized mechanism
> to sign syslog messages to provide integrity checking and source
> authentication.
> 
> 
> === ===
> 
> Comments please.
> 
> Thanks,
> Chris
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Wed, 23 Nov 2005 12:29:18 -0500

Chris:

This is fine, but does not include all the other specific details we agreed on and as such is not different from what we had before. I think we can focus our efforts better by creating narrower scope.  How about limiting backwards compatibility to <PRI> only. Requiring standardization of better time stamp. Support for FQDN, IPv6. MSGID. Internationalization (UTF-8). Etc... I am afraid that if we leave the charter open-ended as before, we will be debating the charter again 2 years from now.  

Also, sorry if I missed some earlier discussions on signing messages. Proposed charter mentions source authentication. For TCP mappings (such as BEEP), TLS already provides authentication and encryption.  SSH transport would provide similar facilities. Is there an overlap here? Is message signing targeted at just UDP transport?   

Thanks,
Anton.   

> [mailto:[email-masked]] On Behalf Of Chris 
> Lonvick (clonvick)
> Sent: Wednesday, November 23, 2005 12:05 PM
> To: [email-masked]
> However, the protocol component of this event logging system 
> has not been formally documented.  While the protocol has 
> been very useful and scalable, it has some known security 
> problems which were documented in RFC 3164.
> 
> integrity problems, and to standardize the syslog protocol, 
> transport, and a select set of mechanisms in a manner that 
> considers the ease of migration between and the co-existence 
> of existing versions and the standard.
> 
> WG has already defined RFC 3195 for the reliable transport 
> for the syslog messages.  The WG will separate the UDP 
> transport from the protocol so that others may define 
> additional transports in the future.
> 
> 
> - A document will be produced that describes a standardized 
> syslog protocol.  A mechanism will also be defined in this 
> document that will provide a means to convey structured data.
> 
> - A document will be produced that describes a standardized 
> UDP transport for syslog.
> 
> - A document will be produced that describes a standardized 
> mechanism to sign syslog messages to provide integrity 
> checking and source authentication.
> 
> 
> === ===
> 
> Comments please.
> 
> Thanks,
> Chris
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 23 Nov 2005 18:38:17 +0100

> Also, sorry if I missed some earlier discussions on signing 
> messages. Proposed charter mentions source authentication. 
> For TCP mappings (such as BEEP), TLS already provides 
> authentication and encryption.  SSH transport would provide 
> similar facilities. Is there an overlap here? Is message 
> signing targeted at just UDP transport?   

Signing - as I understand syslog-sign - goes beyong that. You could also
say it serves a different purpose. -sign is about signature inside the
messages that you can use to verify the correctness not only in transit
but also years later in an offline copy. The details are not 100%
technically correct, but I think it conveys the overall idea.

Rainer

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 24 Nov 2005 17:59:05 +0100

> Hi,
> 
> OK - sorry 'bout that.
> 
> Glenn - please update it and get it into the ID repository.
> 
> All - who will commit to reviewing this document?  I will 
> need someone to 
> commit to this before I put it into the proposed charter.

I can look at the syslog side of it, but I am far from being an SNMP
expert. I think we need at least one such expert to review it. So count'
me as half a volunteer ;)

Rainer

> 
> Thanks,
> Chris
> 
> 
> 
> On Thu, 24 Nov 2005, Rainer Gerhards wrote:
> 
> > Oops, I have overlooked that one. I agree with Glenn that 
> this should be
> > in the charter.
> >
> > Rainer
> >
> >> [mailto:[email-masked]] On Behalf Of Glenn
> >> Mansfield Keeni
> >> Sent: Thursday, November 24, 2005 11:33 AM
> >> To: [email-masked]
> >> Subject: Re: [Syslog] Revised proposed charter
> >>
> >> Chris,
> >>      You seem to have dropped the last deliverable which is
> >> in good shape
> >>
> >>>     - A MIB definition for syslog will be produced.
> >>
> >> I would strongly recommend that we include it. It is an
> >> important aspect
> >> of the protocol. Some effort has gone into it. And it is the least
> >> controversial [there are no issues of backward 
> compatibility]. And it
> >> is very close to completion.
> >>
> >> Glenn
> >>
> >> Chris Lonvick wrote:
> >>> Hi All,
> >>>
> >> scalable, it
> >>> has some known security problems which were documented in 
> RFC 3164.
> >>>
> >>> The goal of this working group is to address the security
> >> and integrity
> >>> problems, and to standardize the syslog protocol, transport, and a
> >>> select set of mechanisms in a manner that considers the ease of
> >>> migration between and the co-existence of existing 
> versions and the
> >>> standard.
> >>>
> >>> syslog has traditionally been transported over UDP and this WG has
> >>> already defined RFC 3195 for the reliable transport for the syslog
> >>> messages.  The WG will separate the UDP transport from the
> >> protocol so
> >>> that others may define additional transports in the future.
> >>>
> >>>
> >> mechanism

---

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Mon, 28 Nov 2005 11:29:41 -0500

I support this clarification.   

Anton. 

> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Saturday, November 26, 2005 4:23 AM
> To: Chris Lonvick (clonvick); [email-masked]
> Based on the discussions of the past few days, the one detail 
> that I would add to the charter is about <PRI> and backward 
> compatability, something along the lines of
> 
> While compatability with existing syslog systems is 
> desirable, research shows that these are so diverse that 
> there is nothing in common amongst them apart from <PRI> so 
> that whilst that field will be retained, other fields may not be.
> 
> added to the paragraph on syslog protocol.
> 
> And yes, IESG and the ietf list will doubtless want to know 
> why we regard that as acceptable.
> 
> Tom Petch
> ----- Original Message -----
> From: "Chris Lonvick" <[email-masked]>
> To: <[email-masked]>
> > has some known security problems which were documented in RFC 3164.
> >
> transport, 
> > and a select set of mechanisms in a manner that considers 
> the ease of 
> > migration between and the co-existence of existing versions 
> and the standard.
> >
> > protocol.  A mechanism will also be defined in this 
> document that will 
> > provide a means to convey structured data.
> >