OpenSLP Programmers Guide - Security Whitepaper

About
what is openslp

Download
how to get openslp

Contribute
how to help out

Documentation
how to find out more

Credits
who to blame

## OpenSLP and SLPv2 Authentication

### February 6, 2001
Matthew Peterson <matt@caldera.com>

### Abstract

This document is summary of SLPv2 security discussions along with some conclusions that suggest direction for future Caldera sponsored development of the OpenSLP implementation of Service Location Protocol.

### Introduction

Early in December 2000, it was suggested that OpenSLP be submitted for security review by noted security expert Olaf Kirch. Olaf offered some very useful feedback including a suggestion to implement optional SLPv2 authentication as specified by RFC 2608 section 9.2. Olaf was worried that in the absence of SLPv2 authentication, users of OpenSLP might unknowingly trust malicious services that have been setup to "masquerade" as legitimate services. In Olaf's estimation leaving out SLP authentication opens a security hole that is not acceptable. With respect to Volution's use of SLP to locate services, Olaf wrote the following:

> "Not authenticating registration and deregistration requests is clearly inacceptable in an environment where there's a non-zero security awareness. If everyone is able to change the LDAP server Volution uses to obtain its information from, then we might as well replace /bin/login with a symlink to /bin/bash"
> -- Olaf Kirch

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 except implementation of SLPv2 authentication which was expected to be an involved change that would take several days to complete. After a couple days of research, it became obvious that the addition of SLPv2 security would be much more complex than simply writing several hundred lines of security enabling code. The final conflict eventually boiled down to a fundamental security / usability tradeoff that would be unresolvable even with a perfect implementation.

### Objective of SLP

SLP can be thought of as a very simple global service registry (or directory). Software entities that provide services register with SLP so that software entities 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 type or characteristics of a service need to be known in order for a user or application to locate a service for use. The major feature SLP provides is usability. Basically, SLP allows application developers to write more usable and manageable software. With SLP users no longer need to memorize network addresses, host names or other information to configure their client applications and administrators do not have to set up elaborate means to supply this information.

In discussing security problems associated with SLP it is important to note two things from section 1 of RFC 2608:

- SLP is designed for enterprise networks not as a solution for the global Internet
- The goal of SLP is to provide a framework that allows developers to write software that is user friendly and easily managed.

### SLP Security

Imagine now 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 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.

In order to prevent this type of attack, SLP is designed so that services registrations and requests can be made with authentication information. When properly implemented, SLP requests can be issued that will only return registrations made by trusted services. With SLP Security enabled developers could trust that the service information returned by the SLP API (URLs and configuration information). They do not have to question (as much) whether the service at the other end of the provided URL is a rogue because SLP can guarantee that services have been "blessed" by administrators by virtue of key information.

### SLP Security vs SLP Usability

It is a well known fact that any increase in security inevitable reduces usability 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 and play" features to be built into applications!

Due to the lack of PKI standards, establishing the trust needed to ensure that service registrations can be authenticated would require manual distribution of key material. One solution would be to have the administrator verify the authenticity of a single SLP host key or certificate which would authenticate all services provided from a given host, but this would not prevent an attacker from masquerading services if they have access to the authenticated machine. A more secure approach is to provide per service or per user keys at the expense of increased manual intervention to establish authenticity of numerous keys or certificates. Wait... even with SLP secured, there is still the possiblity of DNS, DHCP or ARP spoofing, so you are still not secure.

After a few minutes of meditation it becomes evident that in order to be totally safe, applications need to establish the security of their own end to end communications. Two very good examples are PGP and SSH. Neither application makes any assumptions about the reliability of intermediate protocols. Everything is suspect from DNS to ARP. Suppose that a specialized application was written that used PGP encrypted messages to communicate. SLP is chosen to locate remote users of the same application. Now, assume that none of the SLP security features are implemented, is the application at risk? The answer is no because care was taken by the application developer to secure his own end to end communication.

### IETF Workgroup (srvloc) Discussion

The idea that authentication belongs in the application itself and not in the location protocol (or other intermediate protocols) was brought up for discussion on the IETF Service Location workgroup mailing list with the following post entitled "Theoretical SLP security discussion (long)":

> `SLPv2 is designed to be able to authenticate agents. In other words, SLPV2 can guarantee that SAs and DAs are trustworthy. With a proper SLPv2 implementation and installation, UAs can be sure that replies to SLP requests come from trustworthy agents. There is no need to wonder if 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 ldap servers that are considered trustworthy by whoever set up the SLP installations.`

> `Sounds pretty nice doesn't it -- at least until you start thinking about what is required to deliver key information (certificates) that makes trust relationships possible. I think I'm safe in saying that without exception, no automated delivery of key information is secure unless it requires actual validation by a human that results in some form of real-life action (phone call, hand delivery, etc).`

> `Administration of trust relationships are completely un-addressed by the SLPv2 and SLP API specs -- which is probably why authentication is considered an optional feature. One might even take the position that SLPv2 Authentication invalidates the SLP's claim to reduce administrative workload as there is no way to deploy secure SLP without significant (manual) administrative overhead to establish certificate or key information trust.`

> `In contemplating implementation and use of SLPv2 authentication in OpenSLP we found that there is nearly nothing in the way of standardized certificate delivery mechanisms that might actually make SLPv2 authentication possible. We did find bits and pieces from OpenSSL and various signing utilities, which lead us to start questioning why we were trying to authenticate services via SLP anyway? Why not just let services authenticate themselves?`

> `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.`

> `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.`

> `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.`

> `Please comment. Do you agree or disagree? Why?`

Response from ebi@cup.hp.com:

> `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.`

> `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.`

> `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 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.`

Rebuttal from mpeterson@caldera.com:

> `I do not believe that the "denial of service" attack scenario described above is much of an issue.`

> `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.`

> `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.`

> `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." 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).`

> `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.`

> `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...)`

> `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. 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.`

Response from ebi@cup.hp.com:

> `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 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).`

Rebuttal from mpeterson@caldera.com:

> `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?`

> `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.)`

> `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.`

The discussion eventually involves several engineers from a number of organizations and becomes quite lengthy. At least, the exchange included above should give a taste of the arguments involved. For those that are interested in reading the entire thread, it can be found at http://www.srvloc.org/hypermail/0826.html.

### Conclusions

For those that are not willing to endure the tedium of reading the entire mailing list discussion, the conclusion was eventually made (at least by the author) that though SLP authentication may be appropriate in some specialized SLP deployments, it is probably not beneficial in normal network computer environments. This conclusion is based on the following premises:

- 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.
- Common helper protocols DNS, DHCP, IP, even ARP are currently insecure for usability reasons. SLP fits into this category of protocols where lack of security may be considered a feature when it allows for maximal usability.
- 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.
- In the presence of appropriate end to end security mechanisms, SLP related security attacks are limited to the realm of "denial of service" or "disruptions" -- even when no authentication is implemented in SLP. 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.

So, for the OpenSLP project, there are not any plans to implement SLPv2 security. (This may change in the future depending on the success of ongoing PKI standardization efforts.) There are, however, many things that could be done to reduce opportunities for "denial of service attacks" or other malicious SLP related disruptions. These will be addressed in future versions of OpenSLP. Also, in order to inform developers about the importance of writing secure applications, plans have been made to include an "SLP Security HOWTO" as part of the OpenSLP Documentation.