David, let me start with the relays: given the recent discussion, I think it would be much more advisible to add a few sentences to -protocol (I already made a proposal) that clarifies the situation. It is not much that needs to be added. It would resolve all those other issues.
Regarding generic certificates, I do not see an overwhelming reason to have them (and I was one of them who liked them). I agree with Sam that there can be placed unique certificates on the device during the manufacturing process. Another story, however, is the need to authenticate/verify a device. Without any doubt, there is more than one scenario where authentication based on the device is mandatory. However, syslog is also often deployed in (low end) scenarios where the (part-time) operator is simply interested receiving log messages from his 5 or so routers. This admin is often not very knowledgable. If we now require that admin to either a) configure access rules for all (though few) devices or b) use unencrypted UDP syslog I am sure many of these admins will resort to b) because a) requires too much learning. In the essence, strong security/authentication would bring us less real-world security (pretty much the same thing with strong passwords ... so strong that they are "stored" on post-it notes under the keyboard). So I would not like to see client and server authentication to be a MUST. Well ... a MUST for an implementation to have that capability would be OK. But an admin must be capable to configure sender and/or receiver to work without authentication. No matter what we specify in -protocol, that capability will be available in all implementations that I foresee. IMHO an uncoditional MUST would create a false sense of security ... and the most insecure thing is false sense of security. Rainer > -----Original Message----- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Monday, February 05, 2007 5:14 PM > To: 'tom.petch'; 'Miao Fuyou'; 'Sam Hartman'; [EMAIL PROTECTED] > Subject: RE: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog- > transport-tls > > Hi WG, > > [speaking as co-chair] > > As co-chair, I will need to advise Miao to remove support for generic > certificates unless there is overwhelming WG consensus to keep them, > and the explanation of why reuse of private keys is necessary will > need to be compelling. Please read RFC4107 (which is short). > > There are ambiguities in the TLS document regarding who MUST > authenticate that will need to be tightened up. As the email from Tom > reflects, part of the problem is the ambiguity in the definition of > relay; I think it needs to be made clearer in the -protocol- document > that a relay is a receiver and is a sender, and clearer in the -tls- > document that authentication is hop-by-hop. > > Personally, I think we should make authentication more mandatory than > is currently described, but the WG needs to reach such a consensus. If > we keep the optional authentication(s), then the WG should justify in > the document why it makes "protocol sense" for the authentication(s) > to be optional. > > The WG needs to develop the table showing how the various > authentication options mitigate threats, especially MITM threats, and > we should have text that describes this as well. > > Please work with Miao to address these issues. > > Thanks, > David Harrington > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > co-chair, Syslog WG > > > > -----Original Message----- > > From: tom.petch [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, January 31, 2007 12:53 PM > > To: Miao Fuyou; 'Sam Hartman'; [EMAIL PROTECTED] > > Subject: Relays was Re: [Syslog] AD Review for > > draft-ietf-syslog-transport-tls > > > > <inline> > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Miao Fuyou" <[EMAIL PROTECTED]> > > To: "'Sam Hartman'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Wednesday, January 31, 2007 5:50 AM > > Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > > > Hi Sam, > > > > > > Thanks for the review! My response is inline. > > > > > > Regards, > > > Miao > > > > > > > -----Original Message----- > > > > From: Sam Hartman [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, January 31, 2007 7:23 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > > > > > > Hi, folks. I had no comments on the UDP draft or the main > > > > protocol draft so I have forwarded them to IETF last call. > > > > > > > > I do have some concerns with the TLS draft. > > > > > > <snip> > > > > > > > > > > Are senders and relays required to have a certificate and to > > > > use that certificate? > > > > > > > > > > It is not required, but it is preferrable for some deployment > where > > > malicious senders may send lots of messages to overwhelm > > the receiver. > > > > > Sam > > > > I have a slightly different view. To quote the I-D, where it says > > "The sender/relay should initiate a connection to the receiver" > > I take that as the sender initiates a connection to the > > receiver if no relay is > > present or to the relay (when present), the relay (when > > present) initiates the > > connection to the receiver (collector). Relay and receiver > > become TLS Servers > > and insofar as TLS Servers have certificates, the relay will have > one! > > > > When the next paragraph says > > "When a sender/ relay authenticates a receiver it MUST > > validate the certificate" > > I take that to mean that the sender authenticates the > > receiver if no relay is > > present or the sender authenticates the relay (when present) > > and the relay > > authenticates the receiver. > > > > relay and sender are TLS clients. > > > > I appreciate that this is hop by hop security and not ideal > > end to end security. > > > > Tom Petch > > > > --Sam > > > > > > > > > > > > _______________________________________________ > > > > Syslog mailing list > > > > [email protected] > > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > [email protected] > > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > > Syslog mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
