An advantage of TLS over SSH that is not technical in nature is that TLS/SSL is already found in very low end devices as it is used for other purposes. Utilizing it is far better than requiring that these devices now take on the additional SSH (or other) protocols. SSH tends not to be as widely deployed in embedded systems as most of it's general purpose uses are in interactive-remote-control type applications.
John > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 22, 2006 7:13 AM > To: Tom Petch; David Harrington; [EMAIL PROTECTED] > Subject: RE: [Syslog] Secure transport alternatives > > Tom, > > I have to admit I have overlooked this item. I agree that we > (especially > me) were very TLS-minded. My memories tell me we > intentionally left the > door open for other transports, but I may be wrong. As it > looks, I need > to re-visit the mailing list archive. I hope I will be able to do so > soon. > > I also have on my mind that we intended to do 3195bis after tls was > finshed, so we did not plan to totally abandon it. Again, all of this > out of my memory... > > Rainer > > > -----Original Message----- > > From: Tom Petch [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 22, 2006 12:03 PM > > To: Rainer Gerhards; David Harrington; [EMAIL PROTECTED] > > Subject: Re: [Syslog] Secure transport alternatives > > > > Rainer > > > > Looking at the outstanding milestones, I see > > > > Nov 2006 Submit Syslog UDP Transport Mapping to the IESG > > for consideration as > > a PROPOSED STANDARD > > Nov 2006 Submit Syslog Protocol to the IESG for > > consideration as a PROPOSED > > STANDARD > > Nov 2006 Submit Syslog TLS Transport Mapping to the IESG > > for consideration as > > a PROPOSED STANDARD > > Nov 2006 Submit Syslog Device MIB to IESG for > > consideration as a PROPOSED > > STANDARD > > Nov 2006 Submit a document that defines a message signing > > and ordering > > mechanism to the IESG for consideration as a PROPOSED STANDARD > > > > which is why I see TLS as embedded in the charter (as well > > as, more obscurely, > > in the discussions that led up to the charter change). > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Rainer Gerhards" <[EMAIL PROTECTED]> > > To: "Tom Petch" <[EMAIL PROTECTED]>; "David Harrington" > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Thursday, June 22, 2006 10:48 AM > > Subject: RE: [Syslog] Secure transport alternatives > > > > > > Tom, > > > But, in all seriousness, changing from TLS to anything is a > > > charter change that > > > I think needs the approval of the IESG, and should require > > > commitment, similar > > > to that given at the turn of the year, to produce > > conformant products. > > > > I do not agree here. We have deliberately not used the term > > "TLS" in the > > charter. The relevant excerpts are: > > > > ### > > The threats that this WG will primarily address are modification, > > disclosure, and masquerading. A secondary threat is message stream > > modification. Threats that will not be addressed by this WG > > are DoS and > > traffic analysis. The primary attacks may be thwarted by a secure > > transport. However, it must be remembered that a great deal of the > > success of syslog has been attributed to its ease of > > implementation and > > relatively low maintenance level. The Working Group will > > consider those > > factors, as well as current implementations, when deciding upon a > > secure transport. > > ### > > > > ### > > - A document will be produced that requires a secure > transport for the > > delivery of syslog messages. > > ### > > > > As far as I remember (not looked up the archive yet), we did this > > intentionally so that we could change transports if need arises. At > > least for now, I think this need has arisen. > > > > The really bad thing about the IPR claim is that we do not even know > > what actually has been claimed. But I do not intend to invest > > any of my > > work into something that somebody else claims exclusive > rights on. So > > -tls is a dead end for me as long as the claim is not > > dropped. I foresee > > similar harsh reaction at least of the open source commuity > > (*the* major > > driving factor behind syslog implementation) when we standardize > > something encrumbered by a patent. > > > > Rainer > > > > > > > > Tom Petch > > > > > > > > > ----- Original Message ----- > > > From: "David Harrington" <[EMAIL PROTECTED]> > > > To: "'Rainer Gerhards'" <[EMAIL PROTECTED]>; > > <[EMAIL PROTECTED]> > > > Sent: Wednesday, June 21, 2006 7:58 PM > > > 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 PROTECTED] > > > > [EMAIL PROTECTED] > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > -----Original Message----- > > > > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > > > > Sent: Tuesday, June 20, 2006 9:44 AM > > > > > To: [EMAIL PROTECTED] > > > > > 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 > > > > > Syslog@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > Syslog@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
