Subject: RE: [Syslog] Secure transport alternatives

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Thu, 22 Jun 2006 12:17:36 -0400

I am not sure RFC 3195 is completely market-abandoned. Cisco has some interest in it. Although I cannot comment on any product roadmaps. 

Anton. 

> -----Original Message-----
> From: Miao Fuyou [mailto:[email-masked]] 
> Sent: Thursday, June 22, 2006 1:49 AM
> To: 'David Harrington'; 'Rainer Gerhards'; [email-masked]
> Subject: RE: [Syslog] Secure transport alternatives
> 
> 
> Hi, 
> 
> IMO, most current security protocols(TLS, DTLS, SSH, IPsec) 
> provide similiar
> security service for application, such as confidentiality, integrity,
> anti-replay and peer identity authentication. In the same 
> time, most of the
> applications share similiar security threats, such as hijacking, MITM,
> falsification, eveasdropping etc. So, it may does make much 
> sense to invest
> too much effort on evaluating/matching security threats and 
> service. In the
> same time, most current security protocols come from security 
> mechanisms
> specific to some applications. For example, SSL was designed 
> to secure HTTP,
> SSH is an application protocol for interactive shell command. 
> They are not
> real "general" security mechanisms(except IPsec, but it is not
> application-friendly). So, IMHO the primary criteria for 
> selection is: is it
> convenient for the application to invoke the security service 
> provided by
> the security protocol? 
> 
> Taking convenience in mind: the order may be: DTLS -> TLS -> 
> SSH -> BEEP(?)
> -> IPsec
> 
> >From an implementer's perspective, I think DTLS costs the 
> least  effort to
> implement, TLS second. I have not much idea on how much SSH 
> and BEEP take,
> but I believe it cost more than DTLS/TLS. There is few RFC3195
> implementation, it sounds bad to revive an market-abandoned 
> solution to just
> satisfy IESG. IPsec? It costs the specifcation and program developer
> nothing, but it costs too much to provision, never a good solution for
> Syslog.
> 
> My 1 cent!
> 
> Miao
> > -----Original Message-----
> > From: David Harrington [mailto:[email-masked]] 
> > Sent: Thursday, June 22, 2006 1:58 AM
> > To: 'Rainer Gerhards'; [email-masked]
> > Subject: [Syslog] Secure transport alternatives
> > 
> > Hi,
> > 
> > [Posting as a contributor]
> > 
> > I am involved in a number of NM and Security WGs, and I can 
> make these
> > observations:
> > 
> > Running an NM protocol over SSH has been done in both netconf 
> > and ISMS. I suspect it would be fairly easy to adapt the 
> > netconf-over-SSH draft to work for syslog-over-SSH. I suspect 
> > it would take a week or so to write a syslog-over-SSH draft 
> > since most could be cut-and-paste from the netconf-over-SSH draft. 
> > 
> > I am the author of the ISMS drafts, and I adapted the 
> > netconf/SSH draft for ISMS purposes. Syslog and netconf seem 
> > to be closer in their requirements than syslog and ISMS. ISMS 
> > has this whole model of access control to deal with that is 
> > not part of the threat model for syslog or for netconf at 
> this time. 
> > 
> > There is a parallel discussion of running syslog messages 
> > over netconf. As Rainer has pointed out to Phil, having a 
> > consistent terminology would be very helpful. I think having 
> > a consistent security solution would probably be helpful in 
> > that situation as well.
> > 
> > I have concerns about 3195bis as the only alternative we 
> > consider, because I have not seen much interest in RFC3195 
> > yet, nor has there been much expresseed interest in netconf 
> over BEEP.
> > 
> > Since there may be delay involved in this WG no matter what, 
> > would somebody be willing to volunteer to write a 
> > syslog-over-SSH draft, so the WG can compare the three approaches? 
> > 
> > There are other possibilities as well (and I am being serious 
> > here, not "let's make this absurd by proposing a whole slew 
> > of alteratives documents").
> > 1) Tom mentioned DTLS, which might be a viable alternative 
> > given syslog's UDP roots. Tom would you, or somebody else, be 
> > willing to write a proposal for syslog/DTLS?
> > 2) Andy Bierman observed that if syslog messages are going to 
> > be transported over netconf, then why not simply use 
> > syslog/netconf and let netconf deal with the security issues. 
> > That could be an alternative proposal. Is anybody willing to 
> > write a draft proposing that as a syslog secure transport solution?
> > 
> > My $.02 as a contributor,
> > 
> > David Harrington
> > [email-masked]
> > [email-masked]
> > [email-masked]
> >  
> > 
> 
> > > -----Original Message-----
> > > From: Rainer Gerhards [mailto:[email-masked]] 
> > > Sent: Tuesday, June 20, 2006 9:44 AM
> > > To: [email-masked]
> > > Subject: [Syslog] IESG secure transport requirement can be 
> > > quickly solved...
> > > 
> > > Hi all,
> > > 
> > > I propose to update RFC 3195 in the spirit of syslog-protocol 
> > > to satisfy
> > > the IESG secure transport requirement (I will call this 
> > > derivative work
> > > RFC3195bis below). I sincerely believe that this option would 
> > > enable us
> > > to submit syslog-protocol, -transport-UDP and RFC3195bis within a
> > few
> > > weeks. 
> > > 
> > > My reasoning for this proposal is as follows:
> > > 
> > > We all know that 3195 has limited acceptance in the community and
> > very
> > > few implementations. However, it satisfies all IESG criteria 
> > > we have in
> > > our charter. Also, it *is* something that can be used in practice
> > and
> > > implementing it becomes easier as support libraries 
> become visible.
> > I
> > > know it is not an optimal choice. On the other hand, we have
> > > syslog-transport-tls, which has been encrumbered by a 
> patent claim.
> > As
> > > it looks, this will need months to solve. RFC3195bis can not be
> > taken
> > > hostage by any patent claims, because there is well-defined 
> > > prior art in
> > > RFC 3195. Focussing on RFC 3195bis would enable us to complete our
> > > mission and finsh work that is in the queue for many years 
> > > now. I think
> > > this is urgently needed. We might even put the netconf WG 
> with their
> > > syslog gateway on hold (because syslog-protocol can not 
> be published
> > > without resolving the secure transport). Or netconf might 
> > > choose to drop
> > > syslog-protocol in order to publish.
> > > 
> > > And the good news is that 3195bis can definitely very quickly 
> > > be done. I
> > > am saying this on the assumption that we do not revisit the basics
> > of
> > > 3195 but just adopt it to syslog-protocol. I've gone through 
> > > 3195 today
> > > and the changes are absolutely minimal:
> > > 
> > > Section 2:
> > > Most of it simply needs to be removed because the entity roles are
> > > defined in syslog-protocol.
> > > 
> > > Section 3:
> > > - the message samples must be upgraded to -protocol-format
> > > - syslog-framing in section 3.3 must be changed (could be 
> > > octet-counting
> > > or disallow of multiple messages per ANS, what I recommend)
> > > 
> > > Section 4:
> > > 4.4.2 
> > >  - needs to be updated with the new HEADER fields and
> > STRUCTURED-DATA 
> > >  - some work on "deviceFQDN" and "deviceIP" needed
> > >  - some transformation rules (page 15) need to be removed
> > >  - handling of invalid message formatting must be removed 
> (no longer
> > a
> > > concern)
> > >  - samples must be adjusted
> > > 
> > > 4.4.3
> > >  - sample on page 24 (top) must be checked and/or adjusted
> > > 
> > > Section 7:
> > > - DTD needs to be adjusted
> > > 
> > > Section 9:
> > > - new URIs for 3195bis (also in some other places)
> > > [we can reuse well-known port 601 for -protocol]
> > > 
> > > Overall
> > > References to 3164 must be changed to -syslog-protocol. This 
> > > seems quite
> > > trivial, because the  references are easy to spot and do not touch
> > any
> > > substance (except outlined above).
> > > 
> > > Other than these minor things, there are *NO* other changes
> > necessary.
> > > I'd expect that an initial version of 3195bis can be 
> created within
> > a
> > > single working day. Add some quick review and a very 
> limited number
> > of
> > > edits to change discovered nits - and we have something to publish
> > by
> > > summer.
> > > 
> > > I find this extremely tempting. It breaks the deadlock 
> > > situation we are
> > > currently in. Especially as we have planned to do 3195bis 
> some time
> > > later anyhow. I don't know if the authors of 3195 would 
> > > volunteer to do
> > > the edit. But I hope so.
> > > 
> > > I would appreciate if the chairs could try to reach 
> consensus on my
> > > proposal.
> > > 
> > > Comments are appreciated.
> > > Thanks,
> > > Rainer
> > > 
> > > _______________________________________________
> > > Syslog mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/syslog
> > > 
> > 
> > 
> > _______________________________________________
> > Syslog mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/syslog
> > 
> 
> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

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