Re: [Syslog] Secure transport alternatives
David Harrington wrote: Hi Darren, [posting as a contributor] I don't know GSSAPI or SASL well enough to evaluate their approriateness for securing syslog. Are you willing to write one or two drafts proposing these as possible solutions so the WG can evaluate them as alternatives? [posting as a contributor] I'll see what I can do but I'm not sure if I have the time available in the next couple of months. -- Darren J Moffat ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Secure transport alternatives
Miao, technically, I agree with you. HOWEVER, I need to point out that your company is the root cause of the problem. The IPR rights claimed on your transport-tls document have taken it hostage. Even though the licensing terms seem reasonable (which needs to be prooven in undisclosed detail), there honestly is nothing novel in the draft. Your legal department is not even telling us which section is claimed to have been invented by Huawei. The simplest and most productive way to solve the current issue is make your legal department drop the patent claim. My understanding is that it can be easily challenged (for those with big legal departments...) so it will probably be without substance, too. You should also talk to your legal department and superiors that Huawei's peformance in this WG is costing Huawei a lot of its goodwill in the community and probably even in the end-user space. For example, the largest German IT-Site (Heise press[1]) has carried a story about Huawei's move and Huawei has not made a good picture in the user feedback. I also promise that I personally will try to get more press coverage of this move. It is one thing to secure one's intellectual property. It is another thing to be a patent troll. And it is yet another thing to be a patent troll who steals other people's work. I have to admit that I consider Huawei (as far as the syslog WG is concerned) to be part of the third camp. Get *that IPR issue* solved and the technical issue is solved, too. In the mean time, we try to provide an open standard. RFC 3195bis seems to be the most appropriate choice here, because it can't be taken hostage by another abusive patent claim as it bases on well-defined prior art (RFC 3195). Far more important standardization efforts have been brought to a hold by IPR claims (think: SPAM). Claiming IPR where there are none is of no utility. Huawei needs to learn this. [1] http://www.heise.de/newsticker/meldung/74342 (in German) Rainer -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 7:49 AM To: 'David Harrington'; Rainer Gerhards; [EMAIL PROTECTED] 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 PROTECTED] Sent: Thursday, June 22, 2006 1:58 AM To: 'Rainer Gerhards'; [EMAIL PROTECTED] 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
Re: [Syslog] Secure transport alternatives
David You will know, and the archives show, that I spent much time in 2005 arguing for SSH as the transport for isms and, happily, the WG agreed. The archives also show that my efforts in syslog were to no avail and the WG overwhelmingly chose TLS. The argument in favour was the marketing one - syslogoTLS is already out there, just feel all those 220,000 hits in Google. And it was on that basis, that WG member's would commit to producing such products, that the WG was rechartered, as opposed to being wound up. (I now see that I should have threatened the syslog WG with an IPR claim on TLS and then we would not be having this discussion :-) 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. 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
Re: [Syslog] Secure transport alternatives
Miao Fuyou wrote: 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? That to me sounds like GSSAPI or SASL. Any reason these aren't being considered ? -- Darren J Moffat ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Secure transport alternatives
Rainer Looking at the outstanding milestones, I see Nov 2006Submit Syslog UDP Transport Mapping to the IESG for consideration as a PROPOSED STANDARD Nov 2006Submit Syslog Protocol to the IESG for consideration as a PROPOSED STANDARD Nov 2006Submit Syslog TLS Transport Mapping to the IESG for consideration as a PROPOSED STANDARD Nov 2006Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD Nov 2006Submit 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
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 2006Submit Syslog UDP Transport Mapping to the IESG for consideration as a PROPOSED STANDARD Nov 2006Submit Syslog Protocol to the IESG for consideration as a PROPOSED STANDARD Nov 2006Submit Syslog TLS Transport Mapping to the IESG for consideration as a PROPOSED STANDARD Nov 2006Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD Nov 2006Submit 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
RE: [Syslog] Secure transport alternatives
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 2006Submit Syslog UDP Transport Mapping to the IESG for consideration as a PROPOSED STANDARD Nov 2006Submit Syslog Protocol to the IESG for consideration as a PROPOSED STANDARD Nov 2006Submit Syslog TLS Transport Mapping to the IESG for consideration as a PROPOSED STANDARD Nov 2006Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD Nov 2006Submit 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
RE: [Syslog] Secure transport alternatives
Hi Darren, I don't know them well enough to comment. Are you willing to write one or two drafts proposing these as possible solutions so the WG can evaluate them as alternatives? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 6:14 AM To: Miao Fuyou Cc: 'David Harrington'; 'Rainer Gerhards'; [EMAIL PROTECTED] Subject: Re: [Syslog] Secure transport alternatives Miao Fuyou wrote: 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? That to me sounds like GSSAPI or SASL. Any reason these aren't being considered ? -- Darren J Moffat ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Secure transport alternatives
David, Your actions as co-chair of this group represent a conflict of interest for so long as Huawei maintains it has an intellectual property claim with respect to its work. I would request that you either step down as co-chair of the group, cease employment with Huawei or convince Huawei to cease the IPR action. Of course the latter two of these are not what I would call reasonable demands to make of anyone given that there are financial issues (and more) involved, but I would request that you step down as co-chair of this group. I would also ask Darren Moffat (and others within this IETF group) to ignore this request and others coming from you, regardless of their relevance to the IPR, because your involvement with Huawei makes you unfit for this role within the syslog IETF group. If you do not wish to step down then the best we can do is to ignore your attempts to continue to function in this role and continue to apply pressure for it to be resolved. This group needs to develop open standards, not IP for Huawei. Your involvement as co-chair and Huawei's IPR claim cast that shadow over this group. I'm sure we all would welcome your continued involvement with the group, just not as co-chair. If Chris is having difficulties with managing the IETF side of things by himself then I'm sure we can find someone else to fill in for you. In no way am I implying you are doing a bad role now or in the past, just that your current association makes you ineligable for being co-chair. Cheers, Darren Hi Darren, I don't know them well enough to comment. Are you willing to write one or two drafts proposing these as possible solutions so the WG can evaluate them as alternatives? David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 6:14 AM To: Miao Fuyou Cc: 'David Harrington'; 'Rainer Gerhards'; [EMAIL PROTECTED] Subject: Re: [Syslog] Secure transport alternatives Miao Fuyou wrote: 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? That to me sounds like GSSAPI or SASL. Any reason these aren't being considered ? -- Darren J Moffat ___ 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
RE: [Syslog] Secure transport alternatives
Hi Darren, [posting as a contributor] I don't know GSSAPI or SASL well enough to evaluate their approriateness for securing syslog. Are you willing to write one or two drafts proposing these as possible solutions so the WG can evaluate them as alternatives? [posting as a contributor] David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 22, 2006 6:14 AM To: Miao Fuyou Cc: 'David Harrington'; 'Rainer Gerhards'; [EMAIL PROTECTED] Subject: Re: [Syslog] Secure transport alternatives Miao Fuyou wrote: 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? That to me sounds like GSSAPI or SASL. Any reason these aren't being considered ? -- Darren J Moffat ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
