The SLP Security ProblemThe SLP security problem can be divided into three categories: SLP security attacks, security configuration and management problems, and ignorance of secure SLPv2 usage. The following is an introduction to problems that will be examined in more detail later in this document.
The obvious SLP security problems are those that are similar to the one that is described by the following example from SLPv2 Authentication - Is it worth the trouble ):
Imagine that in an enterprise environment there is a malicious or overly curious individual that would like to obtain confidential information. SLP could be exploited to obtain information from software that was otherwise secured only 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 of helping employees set up the "client" software with location and configuration information used to connect with the "server" software.The obvious solution to this and other related SLP security problems is to build security features into the SLP protocol itself. This is the approach that is taken by SLPv2 and it is indeed successful in preventing nearly all of the SLP security attacks in a way that requires very little effort on the part of user and application developer. However, it places a huge security configuration and management burdon on the system administrator and makes (application level) interoperability between SLP implementations difficult if not impossible. In other words, the SLPv2 security specification does a great job at solving most SLP security problems from a protocol perspective, but in most applications, it creates a configuration and management nighmare that challenges the fundamental SLP usability claim"
"Using this protocol, computers using the [network] need little or no static configuration of network services for network based applications." -- RFC 2608 (abstract)SLPv2 uses public key cryptography to generate signatures that ensure integrity of SLP messages. Authenticity of SLP message signatures is established by the relationship of SPI and keys -- unfortunately this is a relationship that has to be established manually or by some other trusted PKI framework. Another unfortunate reality is that there are no standards for PKI frameworks to which SLP protocol implementors can write nor are there any standard for manual configuration. The result is that none of the secure SLPv2 security implementations are interoperable from a security configuration or management standpoint. With out security configuration and management standards, software developers have a difficult time writing management software and System administrators are stuck with the prospect of having to manually configure key distibution and SPI configuration.
Finally, very little information is given in RFC 2608 or in RFC 2614 (especially) to educates developers of SLP software about the subelties of SLP security and how SLP must be used in order to be secure. It turns out that there many things that developers can do to write software that is resistant to SLP related attacks that do not require use of SLPv2 protocol security features. As discussed later in this document, it may be possible for educated developers to write acceptibly secure SLP enabled software that does not require any security configuration or management overhead.
Limiting SLP Security RequirementsMost Internet security problems are approached with the assumption that no one is trustworthy and that no one is trackable or accountable. This is probably not an appropriate approach to SLP security because SLP is not intended for the Internet.
SLP is intended to function within networks under cooperative administrative control. Such networks permit a policy to be implemented regarding security, multicast routing and organization of services and clients into goups which are not be feasible on the scale of the Internet as a whole. -- RFC 2608 (section 1.1 Applicability Statement)In approaching the SLP security problem, one should continue to assume that no one is trustworthy, however, it SHOULD NOT be assumed that no one is accountable or trackable. In fact, in "networks under cooperative administrative control" it is very easy track and confront individuals that corrupt otherwise insecure systems as long as it can be identified that a corruption has been attempted or has occured. Because they can be held accountable, fear of consequences keep otherwise untrustworthy individuals in line.
SLPv2 security as described by RFC 2608 supplies, at the protocol level
, everything that is needed to ensure that service location information
was sent by a trusted entity (authentication) and that the information
was not changed in
Blind trust of SLP deliverd information (URLs, etc) is especially significant
in common situations where confidential information (username and password)
are exchanged with an entity authenticated only by the fact that it was
As expressed in SLPv2 Security - Is it worth
the pain , SLPv2 security does not really do much protect confidential
data and resources unless the service-specific protocols are secure.
Why would it be useful to have a secure location mechanism if protocol
being use to actually control confidential data and resources can be easilly
compromised? If SLP security is not interest to
anyone unless they use SLP in conjunction with some other secure protocol.
then SLP security is only valuable if it can be used without disrupting
the operation already secure software.
Security by Fear
Under heavy attack, secure software ultimately has one alternative, it can stop working rather than give access to confidental data and resources. Ignoring requests for services turns out to be only alternata
Continuing the LDAP example from above, it is possible to write a secure
LDAP enabled "client" application that uses "insecure" SLP to discover
the LDAP server. The client would locate URLs for *all* LDAP services
SLP Security AttacksAs mentioned in the previous section, the use of secure service specific protocols/frameworks in an environment "under cooperative administrative control" greatly reduces the scope of the SLP security problem. Instead of having to ensure that every bit of SLP information is delivered with authenticity and integrity, it could be argued that SLP only has to worry about a those portions SLP delivered information that can be subverted with out alerting the system administrator. However, since the system administrators can't be expected to be constantly vigilant or timely in their response to alerts, it is also important that SLP enabled software be still be written in a way that does not compromize confidental data or resources when under attack.
Since SLP controlled information is publically available, most SLP security attacks are calculated to compromize information and resources controlled by service-specific protocols than information that is controlled by SLP itself. There are two categories of SLP attack: impersonation attacks, and disruption attacks. Impersonation attacks involve manipulation of SLP in order trick SLP enabled software into using rogue service. The ultimate goal of impersonation attacks is to obtain confidential information. Disruption attacks involve manipulations of SLP in order to disrupt or halt normal operation of SLP enabled software with the ultimate goal of making life hard for the system adminstrator.
If SLP enabled software uses secure service-specific protocols, impersonation
attacks have almost no chance of being successful. SLP related disruption
attacks, on the other hand, have a very good chance of being successful.
The following table is a list of disruption attacks that could be directed
at SLP enabled software:
Preventing Disruption Attacks
There are several approaches to solving security problems. The
first approach is to use SLPv2 security as specified by RFC 2608 and deal
with the associated manual configuration and management overhead.
The second approach is to use custom security extensions to the SLPv2 protocol
which may or may not be interoperable with other SLP software. The
third approach would be to not use any SLP security enhancements at all.
Though provisions for security have been designed into the SLPv2 protocol,
security is not a mandatory feature. The following table presents
the vulnerability of SLPv2 to attack:
Attack can be prevented entirely.