Re: Why not TLS was Re: [Syslog] Secure substrate - need your input
Just to add the figures that support my assertion, in an e-mail from Wes Hardaker, who surveyed the network operators, to isms Of the various authentication systems in use at that time by the people that responded: 66% local accounts 49% SSH-keys 40% Radius 29% TACACS+ 14% X.509 Certificates 10% Kerberos [numbers don't add to 100 because more than one option could be selected] which I have paraphrased as SSH a significant number TLS so small as to be invisible Of course, as I hope is clear, I am talking in the context of network operations, not of Web access (where I accept that SSL dominates). Tom Petch - Original Message - From: Rodney Thayer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 25, 2005 11:46 PM Subject: Re: Why not TLS was Re: [Syslog] Secure substrate - need your input Tom Petch wrote: 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 A couple of comments - I disagree that TLS is rare. TLS is common, in my experience, because many devices have web-based management interfaces and those are secured with TLS. Also, if your logic were correct, then all those SASL folks who hassled us TLS people into going with STARTLS/SASL/etc must have been wrong - this is one of those the IETF can't declare both 1 and 0 to be truth, depending on which RFC you read problems. OTOH you are using SOME standard protocol so I'm fine with SSH... ___ 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: Why not TLS was Re: [Syslog] Secure substrate - need your input
There is a miss understanding of the information I have seen given by many people on this list regarding TLS. I think this miss understanding is also being applied to SSH. Most people get the facts right on server-side-authentication. SSL for years supported Server side authentication. This allows a common-user to know that they are indeed connecting to the right service. Thus they know that this is indeed their bank that they are providing their credentials to. There is a wealth of standards and tools that accomplish this. The facts get much more confused when people start to add requirements to authenticate the client side. The first confusion comes when people don't really ask 'who do they want to authenticate?' Most common authentication schemes want to authenticate the user. The advantage to these services is that they then can apply preferences, user behavior tracking, access controls based on user/role, etc. The problem with this mode of client authentication is that the service knows nothing about the machine that the user is using at this time. For most portals this is a benefit as it allows the user to use any kiosk, thus user frustration is low. The problem is that that kiosk could be highly compromised... Enough said. Thus there is a need to authenticate the client-machine. Given the above concern, this is becoming more and more common. So, SYSLOG needs to ask do they want to authenticate the user, machine, or both? TLS does support mutual node authentication. The healthcare world has been using mutual-node-authenticated-TLS for over three years. We use it often to ensure that a X-Ray device is actually talking to the Picture Archiving Service. Both systems need to know that they are talking to the right 'other' system. This transaction doesn't need to have user authentication as the process is fully automated. Indeed we don't always turn on TLS encryption. But we do always do mutual-authentication. Yes this means that there is a X.509 certificate managed for both nodes. But this certificate management is not nearly as complex as person-certificates (another discussion we can have on miss-understandings due to the wrong questions being asked). The problem is that many people quickly associate TLS/SSL with it's earlier SSL, which leads to HTTPS, which leads them to look at browsers. The end result is that you find at most one browser that supports mutual-authenticated-TLS. Note that the browsers will claim to authenticate the 'client', but this is HTTP-authentication. This HTTP-authentication is a different layer than the TLS authentication. I don't think that the SYSLOG community is likely to be using browsers. They will likely be using tools like JAVA, and the good news is these tools do support mutual-node-authentication (See: JAVA SSLSocket). John ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: Why not TLS was Re: [Syslog] Secure substrate - need your input
Anton, Thanks for your support. I do want to caution your enthusiasm for the browser support. I believe that all current production browsers implement the feature you found using HTTP-authentication, not TLS/SSL. Trying to create a user interface for this complex concept can't be easy, and the prevailing reason to use client certificates was for user authentication. Thus they took the most logical short-cut. It is my understanding that IE7 will have true TLS/SSL client-certificate authentication. It is also my understanding that firefox current 1.5 has TLS/SSL client-certificate authentication. I had seen test results that indicated this was true. http://www.mozilla.org/projects/security/pki/nss/results.html I have not been able to confirm this personally. John -Original Message- From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 26, 2005 1:44 PM To: Tom Petch; Moehrke, John (GE Healthcare); [EMAIL PROTECTED] Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input TLS does support mutual node authentication. The healthcare world has been using mutual-node-authenticated-TLS for over three years. We use it often to ensure that a X-Ray device is actually talking to the Picture Archiving Service. Both systems need to know that they are talking to the right 'other' system. This transaction doesn't need to have user authentication as the process is fully automated. Indeed we don't always turn on TLS encryption. But we do always do mutual-authentication. Yes this means that there is a X.509 certificate managed for both nodes. But this certificate management is not nearly as complex as person-certificates (another discussion we can have on miss-understandings due to the wrong questions being asked). Tom- this one puzzles me. SSH has got server and client authorisation defined in the I-Ds, soon to be RFCs. Reading the TLS I-Ds I see no sign of client authorisation and since that is a must for SNMP, then the note I quoted earlier, to the isms list, saying that SASL would needed alongside TLS made perfect sense (as I would expect since it came from the Security AD:-). So where does mutual authentication come from? What RFC or I-D defines it? Is it a proprietary extension? Is it two simplex transmissions with only server authentication? Sometimes it does matter to know what goes on under the covers. (Of course, if client authentication is not needed then this is academic). Client auth is a fundamental feature of TLS. It is all over the TLS RFC: http://www.faqs.org/rfcs/rfc2246.html Search it for client authentication or client certificate. There are whole sections on it. It is part of the initial SSL/TLS setup. Server may require client-auth if configured so. If you don't believe that it is deployed, open you browser security settings. John mentioned that not all browsers supports client certs for SSL/TLS. Well... At least IE, Netscape, Firefox support it and had for some time. In fact, they have pretty advanced features around client certs. For example, you can use a different client cert with different sites. The real question IMO, again, is whether or not symmetric auth (password / shared secret based) is considered important. SSH has it. TLS does not. If client certs are acceptable to people, then TLS is a perfect solution. I think certificate-based infrastructure is more secure and easier to manage in the end. No interactive user auth is needed for syslog, as John mentioned. And if you store passwords instead of having user type them in, then you are really only one-step away from using certs. Thanks, Anton. snip John ___ 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
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