📄 openslp_security_whitepaper.html
字号:
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"><html><head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="Mozilla/4.76C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"> <title>OpenSLP Programmers Guide - Security Whitepaper</title></head><body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000"><h1><hr WIDTH="100%"></h1><h1>OpenSLP and SLPv2 Authentication</h1>February 6, 2001<p>Matthew Peterson <matt@caldera.com><p><hr WIDTH="100%"><h3>Abstract</h3>This document is summary of SLPv2 security discussions along with someconclusions that suggest direction for future Caldera sponsored developmentof the<a href="www.openslp.org">OpenSLP</a> implementation of ServiceLocation Protocol.<br> <h3>Introduction</h3>Early in December 2000, it was suggested that OpenSLP be submitted forsecurity review by noted security expert Olaf Kirch. Olaf offeredsome very useful feedback including a suggestion to implement optionalSLPv2 authentication as specified by <a href="http://www.openslp.org/doc/rfc/rfc2608.txt">RFC2608 section 9.2.</a> Olaf was worried that in the absenceof SLPv2 authentication, users of OpenSLP might unknowingly trustmalicious services that have been setup to "masquerade" as legitimate services. In Olaf's estimation leaving out SLP authentication opens a security holethat is not acceptable. With respect to <i>Volution</i>'s useof SLP to locate services Olaf wrote the following:<blockquote><tt>"Not authenticating registration and deregistration requestsis clearly inacceptable in an environment where there's a non-zero securityawareness. If everyone is able to change the LDAP server Volution usesto obtain its information from, then we might as well replace /bin/loginwith a symlink to /bin/bash" -- Olaf Kirch</tt></blockquote>The initial response to Olaf's security review was one of complete compliance. Code changes were quickly made for the next release of OpenSLP (ver 0.8.1)to resolve all security issues <i>except</i> implementation of SLPv2 authenticationwhich was expected to be an involved change that would take several daysto complete. After a couple days of research, it becameobvious that the addition of SLPv2 security would be much more complexthan simply writing several hundred lines of security enabling code. The final conflict eventually boiled down to a fundamental security / usabilitytradeoff that would be unresolvable even with a perfect implementation.<br> <h3>Objective of SLP</h3>SLP can be thought of as a very simple global service registry (or directory). Software entities that provide services register with SLP so that softwareentities that want to use a services can locate them. SLP offers a very simple mapping of service types (or characteristics)to service URLs. This means that only the <i>type or characteristics</i>of a service need to be known in order for a user or application to locatea service for use. The major feature SLP providesis usability. Basically, SLP allows application developersto write more usable and manageable software. With SLP usersno longer need to memorize network addresses, host names or other informationto configure their client applications and administrators do not have toset up elaborate means to supply this information.<p>In discussing security problems associated with SLP it is importantto note two things from <a href="http://www.openslp.org/doc/rfc/rfc2608.txt">section1 of RFC 2608</a>:<ul><li>SLP is designed for enterprise networks not as a solution for the globalInternet</li><li>The goal of SLP is to provide a framework that allows developers to writesoftware that is user friendly and easily managed.</li></ul><h3>SLP Security</h3>Imagine now that in an enterprise environment there is a malicious or overlycurious individual that would like to obtain confidential information. SLP could be exploited to obtain information from software that was otherwisesecured by virtue of manual configuration. For example,an OpenSource help desk application consisting of "server" and "client"software is SLP enabled because the network administrators got tired ofhelping employees set up the "client" software with location and configurationinformation used to connect with the "server" software.<p>Since the source code is readily available, a sneaky employee makesa few modifications to the server code that allows him to obtain user namesand passwords. He recompiles the source and brings up the "rogue"help desk server. Since the "rogue" help desk server and the realhelp desk server both have similar SLP registerations, it is possible thatclients may connect to the "rogue" server instead of the real one. When the users log in, the "rogue" server saves off a copies of user namesand passwords. The malicious employee can use these user names andpasswords later to impersonate other people.<p>In order to prevent this type of attack, SLP is designed so that servicesregistrations and requests can be made with authentication information. When properly implemented, SLP requests can be issued that will only returnregistrations made by trusted services. With SLP Securityenabled developers could trust that the service information returned bythe SLP API (URLs and configuration information). They do nothave to question (as much) whether the service at the other end of theprovided URL is a rogue because SLP can guarantee that services have been"blessed" by administrators by virtue of key information.<br> <h3>SLP Security vs SLP Usability</h3>It is a well known fact that any increase in security inevitable reducesusability for the legitimate user. This is especially true with SLP security -- establishment of trust is unacceptable barrier to SLP usability. The whole reason for using SLP in the first place is to allow "plug andplay" features to be built into applications!<p>Due to the lack of PKI standards, establishing the trust needed to ensurethat service registrations can be authenticated would require manual distributionof key material. One solution would be to have the administratorverify the authenticity of a single SLP host key or certificate which wouldauthenticate all services provided from a given host, but this would notprevent an attacker from masquerading services if they have access to theauthenticated machine. A more secure approach is to provideper service or per user keys at the expense of increased manual interventionto establish authenticity of numerous keys or certificates. Wait... even with SLP secured, there is still the possiblity of DNS, DHCPor ARP spoofing, so you are still not secure.<p>After a few minutes of meditation it becomes evident that in order tobe totally safe, applications need to establish the security of their ownend to end communications. Two very good examples are PGP and SSH. Neither application makes any assumptions about the reliability of intermediateprotocols. Everything is suspect from DNS to ARP. Supposethat a specialized application was written that used PGP encrypted messagesto communicate. SLP is chosen to locate remote users of thesame application. Now, assume that none of the SLP securityfeatures are implemented, is the application at risk? The answeris no because care was taken by the application developer to secure hisown end to end communication.<br> <h3>IETF Workgroup (srvloc) Discussion</h3>The idea that authentication belongs in the application itself and notin the location protocol (or other intermediate protocols) was broughtup for discussion on the IETF Service Location workgroup mailing list withthe following post entitled "Theoretical SLP security discussion (long)":<blockquote><tt>SLPv2 is designed to be able to authenticate agents. Inother words, SLPV2 can guarantee that SAs and DAs are trustworthy. Witha proper SLPv2 implementation and installation, UAs can be sure that repliesto SLP requests come from trustworthy agents. There is no need to wonderif a responding agent is representing malicious services. For example,with SLPv2 authentication, I can request a service of type "service:ldap"and implicitly trust that the service urls I receive in return are ldapservers that are considered trustworthy by whoever set up the SLP installations.</tt><p><tt>Sounds pretty nice doesn't it -- at least until you start thinkingabout what is required to deliver key information (certificates) that makestrust relationships possible. I think I'm safe in saying that without exception,no automated delivery of key information is secure unless it requires actualvalidation by a human that results in some form of real-life action (phonecall, hand delivery, etc).</tt><p><tt>Administration of trust relationships are completely un-addressedby the SLPv2 and SLP API specs -- which is probably why authenticationis considered an optional feature. One might even take the position thatSLPv2 Authentication invalidates the SLP's claim to reduce administrativeworkload as there is no way to deploy secure SLP without significant (manual)administrative overhead to establish certificate or key information trust.</tt><p><tt>In contemplating implementation and use of SLPv2 authenticationin OpenSLP we found that there is nearly nothing in the way of standardizedcertificate delivery mechanisms that might actually make SLPv2 authenticationpossible. We did find bits and pieces from OpenSSL and various signing⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -