openslp_security_whitepaper.html

SLP协议在linux下的实现。此版本为1.2.1版。官方网站为www.openslp.org

utilities, which lead us to start questioning why we were trying to authenticate
services via SLP anyway? Why not just let services authenticate themselves?</tt>
<p><tt>An analogy from real life... I need to call an associate and relay
some confidential information. I write down his number as it was left on
my voice mail and place the phone call. BEFORE I exchange sensitive information
the individual on the other line, I authenticate their identity (recognize
their voice, etc). Trusting the information available on my voice mail
is not required (as the number may have be to an airport pay phone). Implicitly
trusting a phone number from the white pages or any other source is not
required (or expected) as long as the callers can authenticate themselves.</tt>
<p><tt>Likewise, SLP delivered information need not be trusted to be useful.
As long as the entity providing a service and the entity using the service
can authenticate each other -- separate from the mechanism used to discover
or locate one another. One problem is that many services do not have authentication
capabilities -- which is not too much of a problem because most services
don't have SLP capabilities either. In the end, the only problem is that
developers are just beginning to write secure software. If secure service
and client software were indeed available, there would not be any need
for SLP authentication.</tt>
<p><tt>Having not heard additional comment from other experts, it is my
opinion the SLP need not bear the burden of authenticating services. The
burden of authentication should be placed on the services and their clients
rather than on a protocol valued for simplicity and ease of use, administration,
and deployment.</tt>
<p><tt>Please comment. Do you agree or disagree? Why?</tt>
<br>&nbsp;</blockquote>
Response from [e-mail]:
<blockquote><tt>My take on this would be that it needs to be implemented
and the people deploying it should have the option of enabling/disabling
it.</tt>
<p><tt>Because if this is not implemented, I can see a potential denial
of service attack, where a rogue SA/DA, keeps on responding to all the
discovers sent by the UA. Even though the authentication might fail when
the application tries to authenticate using other means. It can stop the
UA from finding the correct SA/DA, there by creating a denial of service
attack.</tt>
<p><tt>On the other hand managing keys does make the protocol heavy weight.
The problem of effective key management issue, needs to be solved for most
other protocols (like DHCP) as well. Until then, we need</tt>
<br><tt>to be doing the key management manually or use what openSSL uses,
and when there is an optimum key management solution, we can integrate
into that.</tt></blockquote>

<p><br>Rebuttal from [e-mail]:
<blockquote><tt>I do not believe that the "denial of service" attack scenario
described above is much of an issue.</tt>
<p><tt>I think that it is worth clarifying that receiving incorrect information
(service URLs of rogue services from rogue DA/SAs) is not a problem that
involves the "SLP UA portion" of a client application. The problem you
describe above involves the portions of the client application that *use*
information delivered by SLP -- the "UA portion" is only in charge of *getting*
the information not using it. In other words, the problem you describe
above is an SLP usage problem not an SLP problem.</tt>
<p><tt>Regardless of whether or not SLPv2 authentication is implemented
and configured, client applications must not expect that SLP guarantees
availability. SLP could not possibly be expected to guarantee the state
of the network or the persistent state of the registered service. Suppose
that a service registers with SLP just before a WAN outage. At least for
a certain amount of time clients would experience the same "denial of service"
symptoms you describe above. The real solution is to encourage developers
to use the entire list of service URLs. If usage (connection to or authentication
to) one service fails, the client application should try the next.</tt>
<p><tt>Denial of service scenarios like the one you describe are impossible
to prevent. The only protection against denial of service attacks is fear.
Yes, security by fear. Remember, "SLP is intended to function within networks
under cooperative administrative control."&nbsp; The above mentioned attack
would be easy to detect, track and resolve; which means that it would not
probably not be much of a problem in the environments SLP is written to
run in (how many rogue DHCP servers do you see on your network).</tt>
<p><tt>In private network environments, the security problems that you
need to worry about are those that allow confidential data to be compromised
(especially if it can be done in ways can not be detected.) Denial of service
attacks to not compromise data.</tt>
<p><tt>The argument from my original post is that even if SLP authentication
was implemented and configured correctly with (magically) delivered certificates,
there would still be significant service specific security risks that would
be dangerous even in private networks. Upon close inspection SLP authentication
appears to solve only those security problems that are not overly relevant
to private networks in the first place. (Please, if I'm wrong here, give
me some examples...)</tt>
<p><tt>I agree fully that SLP without authentication is in the same realm
(security wise) as DHCP. My question remains -- Is this really a problem
in private networks? If so, why? DHCP continues to be a widely deployed
and extremely useful technology. One of the most useful aspects of DHCP
(and SLP) is that there is no need for extensive configuration. Add requirements
for establishing trust (certificates, keys, etc.) and the "plug and play"
features of DHCP and SLP are gone.&nbsp; As this is a "theoretical discussion"
I might mention that security is not free. There is always a usability
vs. security trade off. I might also mention that sometimes *lack of* security
is a feature if the goal is usability.</tt></blockquote>

<p><br>Response from [e-mail]:
<blockquote><tt>Let me give you another example. If I have a workstation
on the shared lan where my manager's PC is also there. Some companies restrict
root access to people on the main network. So I cannot sniff around to
find password. If there is no security in SLP, then&nbsp; I can register
one of the test machines, which would be in a different network (for which
I have the root access to) as the pop server. Then I get the user name
and password of my manager's pop account (The same thing can be done for
a print spooler or a file server).</tt></blockquote>
Rebuttal from [e-mail]:
<blockquote><tt>Again, Don't you think this is more an illustration of
the weakness of POP3 protocol and mail server/client software than it is
of SLP? I would argue that its is that POP3 needs the security boost --
after all it is in the business of securing an end to end communication.
SLP is not designed to solve the end-to-end authentication problem ...
or is it?</tt>
<p><tt>On the other hand, you do allude to a very valid point -- that most
traditional and widely deployed "end-to-end" service specific protocols
and software are not capable of secure service authentication. (It is usually
possible authenticate the user, but client software can rarely authenticate
the server which means that there is no establishment of trust before sending
client side user credentials.)</tt>
<p><tt>Should SLP be tasked with solving this problem? The answer is definitely
YES if it can be done without completely squashing major SLP usability
features ("plug and play" features). I guess I just don't see how this
can be done.</tt></blockquote>

<p><br>The discussion eventually involves several engineers from a number
of organizations and becomes quite lengthy.&nbsp;&nbsp; At least, the exchange
included above should give a taste of the arguments involved.&nbsp; For
those that are interested in reading the entire thread, it can be found
at <a href="http://www.srvloc.org/hypermail/0826.html">http://www.srvloc.org/hypermail/0826.html</a>
<br>&nbsp;
<h3>
Conclusions</h3>
For those that are not willing to endure the tedium of reading the entire
mailing list discussion,&nbsp; the conclusion was eventually made (at least
by the author) that though SLP authentication may be&nbsp; appropriate
in some specialized SLP deployments, it is probably not beneficial in normal
network computer environments.&nbsp;&nbsp;&nbsp; This conclusion is based
on the following premises:
<ul>
<li>
Implementation of SLP authentication in the absence of public key infrastructure
standards would require enough manual configuration to invalidate all claims
SLP has to increased usability.</li>

<li>
Common helper protocols DNS, DHCP, IP, even ARP are currently insecure
for usability reasons.&nbsp;&nbsp; SLP fits into this category of protocols
where lack of security may be considered a feature when it allows for maximal
usability.</li>

<li>
Given the lack of security in the above mentioned (and other) protocols
self-established authentication of end to end communication is required
anyway for secure communication of network software entities.</li>

<li>
In the presence of appropriate end to end security mechanisms,&nbsp; SLP
related security attacks are limited to the realm of "denial of service"
or "disruptions" -- even when <i>no</i> authentication is implemented in
SLP.&nbsp;&nbsp; In other words there is not a risk of compromise of confidential
information that can be attributed to SLP as long as appropriate end to
end security is established.</li>
</ul>
So, for the OpenSLP project, there are not any plans to implement SLPv2
security.&nbsp;&nbsp; (This may change in the future depending on the success
of ongoing PKI standardization efforts.)&nbsp;&nbsp; There are, however,
many things that could be done to reduce opportunities for "denial of service
attacks" or other malicious SLP related disruptions.&nbsp;&nbsp; These
will be addressed in future versions of OpenSLP.&nbsp;&nbsp;&nbsp;&nbsp;
Also, in order to inform developers about the importance of writing secure
applications, plans have been made to include an SLP&nbsp;Security HOWTO
as part of the OpenSLP&nbsp;Documentation.
</body>
</html>