Tom: TLS provides for asymmetric authentication. RFC 2264 Section 1:
"The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers." SSL/TLS with server-side certs is pretty much a norm for all HTTPS deployments. SSL/TLS with client-side certs are used less frequently, but some organizations use those in mail clients. SMTP, IMAP, POP3 and ACAP all have mappings to TLS transport (RFC2487, RFC 2595) with commercial deployments. I think the reason SASL comes into the picture with certain protocols (like RFC 2595) is that TLS provides asymmetric authentication, and SASL symmetric (based on passwords), which is preferred in some protocol like mail for legacy reasons. Not sure if SSH provides for symmetric auth for server (vs. user) authentication. As far as I can tell from quick scan only asymmetric key support is required in SSH draft (sec 4.1): http://www.employees.org/~lonvick/secsh-wg/2005-sep-07/draft-ietf-secsh-architecture-23.txt I am not sure if support for symmetric keys (passwords) should be a requirement, anyway. Maintaining a database of passwords instead of public keys (in form of certs or other way) sounds like a security threat, not to mention a choir when one could just maintain single root CA (plus revocation lists if needed). Thoughts? Finally, I suspect mapping to SSH will take longer to develop and longer to deploy because it will be dependent on SSH drafts (see above). Thanks, Anton. > -----Original Message----- > From: Tom Petch [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 12:39 PM > To: Anton Okmianski (aokmians); Chris Lonvick (clonvick); > [EMAIL PROTECTED] > Subject: Why not TLS was Re: [Syslog] Secure substrate - need > your input > > In the context of isms, ie SNMP, the choice was SSH v TLS + > SASL; TLS provides the security but not the authentication > while SSH does both. And SSH is a well-established protocol. > > I agree that TLS/SSL is the most widely used but that is > because more people access websites (securely) than access > network devices. If you limit yourself to network operations > of network devices, then it appears to be SSH a significant > number TLS so small as to be invisible > > Tom Petch > > ----- Original Message ----- > From: "Anton Okmianski (aokmians)" <[EMAIL PROTECTED]> > To: "Chris Lonvick (clonvick)" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Tuesday, October 25, 2005 5:10 PM > Subject: RE: [Syslog] Secure substrate - need your input > > > > Hi Folks, > > > > I'll be asking this in Vancouver but would like to get some > input from > > the mailing list. > > > > Our charter says that we will develop a secure method to transport > > syslog messages. We have BEEP (RFC 3195) but it has a low > > implementation record. > > Other groups have specified BEEP as well but are also moving along > > towards using SSH or SSL. > > > > > > 1) What secure substrate should the WG look towards: > > > > __ ssl > > > > __ ssh > > > > __ dtls > > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt > > > > __ other > > I believe it should be SSL 3.0 / TLS 1.0. At least in > web-server farm environments, you got SSL everywhere with a > bunch of SSL accelerator hardware already in place. > > I also think several mappings can be defined. I am not a fan > of options when it comes to standards, but allowing syslog > over any kind of secure transport is a good thing. This was > the whole idea of separating syslog-protocol from > syslog-transport. Frankly, I don't think it will be a lot of > work to define those transport mappings. > > > 2) Why? > > SSL/TLS is the most widely deployed network security protocol > today. All e-commerce happens over it. Dozens of companies > provide all shapes and forms of SSL accelerators. Many > routers now have SSL accelartor modules. > > If I need to manage a large environment of servers where > distributed logging really makes sense, being able to re-use > existing infrastructure for scaling really helps. A search > for "SSH accelerator" on google does not reveal anything > interesting, but "SSL accelarator" shows up with a bunch of > listings, several of which claim thousands of new SSL > sessions per second. This confirms my experience. BTW, with > SSL session caching, accelerators (ie. load balancers) can do > 100,000 connections per second and more. So, to scale syslog > over SSH would I have to wait for SSH accelerators to come to market? > > I see that there is a lot of work around SSH connection > protocol and its potential use in new protocols. I have not > followed these developments. There must have been a good > reason for it. I would like to understand why people object > to SSL, which is a well established technology. Any pointers? > > Thanks, > Anton. > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
