SLP Security

The SLP Security Problem

The 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 Simple Service Registration Transaction Integrity for SLPv2:

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.

Since the source code is readily available, a sneaky employee makes a few modifications to the server code that allows him to obtain user names and passwords.  He recompiles the source and brings up the "rogue" help desk server.  Since the "rogue" help desk server and the real help desk server both have similar SLP registerations, it is possible that clients 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 names and passwords.  The malicious employee can use these user names and passwords later to impersonate other people.

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 Requirements

Most 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 transit (integrity).  At the application level, this means that an application developer (probably using the SLP API) can trust *all* SLP delivered information.  This allows the developer to be more relaxed about how service specific communication is performed.

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 located via secure SLP.  For example, LDAP enabled software uses SLP to locate an LDAP directory.  If SLP information is secure, the username and password to establish a connection with the LDAP directory can be sent with out having to use any other method to establish the identity of LDAP directory.  However, with LDAP (and many other protocols)  is is now possible to establish the identity of both the "server" and "client" nodes without trusting the service location method.  In fact, for any SSL or equivilant transport it is crucial to cyptographically establish the identity of the "other side" in a way that is seperate from the URL that was used to initiate the connection.

As expressed in Simple Service Registration Transaction Integrity for SLPv2, 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 alternative.

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 using SLP. The client would try to establish an SSL connection with each of the discovered LDAP servers until an LDAP server that comes to an LDAP server that is trusted.  If SLP finds an LDAP servers that is not trusted it should display a warning message (thus helping to track down the rogue or misconfigured LDAP server).  In this example above there is one no chance for security compromise in the LDAP application due to it's use of SLP.  There is, however a chance that "suppresion attacks" could burdon the application.

SLP Security Attacks

As 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:

Attack Description
Unauthorized Directory Agent An unauthorized directory agent could be installed on the network with the intention of sending incorrect information to UAs.   A malicious DA could disrupt the operation of SLP enabled applications by returning unauthorized service URLs, by returning unauthorized attributes, or by simply not returning any results at all.  Since UAs are required to use a DA if it exists, it is possible that it might attach to the unauthorized DA and receive service URLs that point to rogue services,  receive attributes that disrupt normal operation, or  not receive any service location information at all
Unauthorized Service Agent An unauthorized service agent could be installed on the network with the intention of duplicating a registrations made by authorized SAs.  In environments involving DAs, unauthorized SA would cause the unauthorized registration, deregistration, and registration problems described below.   In a multicast environments an unauthorized SA could  cause duplicate replies to be sent to service, attribute and service type requests.   Duplicate replies may cause problems when several differing attributes lists are returned for the same service URL.   UAs would be unable to tell which attributes are really valid.
Unauthorized Registrations with DA Contacting the DA to register many bogus services of the same service-type as a valid service.  Even SLP enabled applications that rely on service specific security protocols (SSL, etc) would take a long time to connect to a valid service as  it would probably have to iterate through a  lot of bogus services before it found a valid one.
Unauthorized Deregistration with DA Contacting the DA to de-registering valid registrations so that they can not be found by UAs.
Unauthorized Reregistration with DA Contacting the DA to replacing an existing registration with a new registration with modified attributes. 
Man-in-the-middle Modification  Contacting the DA to register many bogus services of the same service-type as a valid service.  Even SLP enabled applications that rely on service specific security protocols (SSL, etc) would take a long time to connect to a valid service as  it would probably have to iterate through a  lot of bogus services before it found a valid one.
Man-in-the-middle Replay "transport-time" retransmission of SLP registration, or reply messages that were previously "sniffed" from the network.
Man-in-the-middle Scrambling Blind "transport-time" modification of messages that makes them invalid so that they will be rejected by the valid SLP implementations.

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 SLPv2 with RFC2608 security SLPv2 with SSRTI-SLPv2 SLPv2 without security
Unauthorized Directory Agent PREVENTABLE DETECTABLE DETECTABLE
Unauthorized Service Agent PREVENTABLE DETECTABLE DETECTABLE
Unauthorized Registrations with DA PREVENTABLE PREVENTABLE DETECTABLE
Unauthorized Deregistration with DA PREVENTABLE PREVENTABLE VULNERABLE
Unauthorized Reregistration with DA PREVENTABLE PREVENTABLE VULNERABLE
Man-in-the-middle Modification PREVENTABLE VULNERABLE VULNERABLE
Man-in-the-middle Replay DETERRABLE PREVENTABLE VULNERABLE
Man-in-the-middle Scrambling VULNERABLE VULNERABLE VULNERABLE
Definitions:
PREVENTABLE Attack can be prevented entirely.
DETECTABLE Attack can not be prevented, but can be detected by appropriately written SLP software
DETERRABLE Attack can not be detected or entirely prevented, but it can be deterred
VULNERABLE Attack can not be prevented, deterred or detected