> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Martin Schütte > Sent: Saturday, May 10, 2008 10:33 AM > To: [email protected] > Subject: [Syslog] lower requirements? (Re: > I-DAction:draft-ietf-syslog-transport-tls-12.txt) > > > The transport sender (TLS client) has three different options for > > authenticating and authorizing the transport receiver > (TLS server). > > I do not know if this has been discussed previously, but what > is your opinion on lower requirements in order to get > transport-tls supported by embedded devices, i.e. switches > and printers? > [Joe] TLS is deployed to mitigate certain threats such as those described in the document. If you fail to mitigate these threats then the value of deploying TLS is diminished.
> Scenario: > I could imagine a printer (as the client) having a > self-signed certificate and no ability to authenticate the > server's certificate. > As long as the server has a copy of the client's certificate > and can verify it, a secure transport is possible. As an > admin I would rather configure this one-way authentication > and get a TLS-enabled device than having to fall back to UDP. > Should this be an allowed scenario to be covered by tls-transport? > [Joe] The scenario above does not mitigate server masquerade. I'm not sure this would be generally acceptable. However, I realize there are systems that work much in this way today. > Scenario2: > Say the same printer with its self-signed cert is > configurable with a CA-cert that enables it to authenticate > the server (but maybe without checking the certificate's > CN/dNSName/IP). > That would allow a reasonably secure setup. -- Should this be > an allowed scenario to be covered by tls-transport? > In my opinion it should be, thus I would like to keep the > requirements on authentication rules as simple as possible. > [Joe] This seems like a workable scenario to me in some environments. This would require the CA to issue certificates only to authorized parties. Perhaps the argument can be made to for the configuration of a root as a MUST and the specific types of subject Name checks as RECOMMENDED with the appropriate security considerations discussion. > -- > Martin > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
