An Architecture for a Secure Service Discovery Service Steven E Czerwinski Ben Y Zhao Todd D Hodes Anthony D Joseph and Randy H Katz Computer Science Division University of California Berkeley czervin ravenben hodes adj randy Bcs berkeley edu vices We define such services as applications with well known interfaces that perform computation or actions on behalf of client users For example an application that allows a user to control the lights in a room is a service Other examples of services are printers fax machines and music servers Ultimately we expect that just as there are hundreds of thousands of web servers there will be hundreds of thousands or millions of services available to end users Given this assumption a key challenge for these end users will be locating the appropriate service for a given task where appropriate has a user specific definition e g cost location accessibility etc In addition trustworthy and secure access to such services are critical requirements Clients cannot be expected to track which services are running or to know which ones can be trusted Thus clients will require a directory service that enables them to locate services that they are interested in using We have built such a service the Ninja Service Discovery Service SDS to provide this functionality and enable clients to more effectively search for and use the services available in the network Like the rest of the major components of Ninja the SDS is implemented in Java lo The SDS is a scalable fault tolerant and secure information repository providing clients with directorystyle access to all available services It stores two types of information descriptions of services that are available for execution at computational resources embedded in the network so called unpinned services and services that are already running at a specific location The SDS also supports both push based and pull based access the former allows passive discovery while the latter permits the use of a query based model Service descriptions and queries are specified in eXtensible Markup Language XML 4 leveraging the flexibility and semantic rich content of this self describing syntax The SDS also plays an important role in helping clients determine the trustworthiness of services and vice versa This role is critical in an open environment where there are many opportunities for misuse both from fraudulent services and misbehaving clients To Abstract The widespread deployment of inexpensive communications technology computational resources in the networking infrastructure and network enabled end devices poses an interesting problem for end users how to locate a particular network service or device out of hundreds of thousands of accessible services and devices This paper presents the architecture and implementation of a secure Service Discovery Service SDS Service providers use the SDS to advertise complex descriptions of available or already running services while clients use the SDS to compose complex queries for locating these services Service descriptions and queries use the extensible Markup Language XML to encode such factors as cost performance location and device or service specific capabilities The SDS provides a highlyavailable fault tolerant incrementally scalable service for locating services in the wide area Security is a core component of the SDS and where necessary communications are both encrypted and authenticated Furthermore the SDS uses an hybrid access control list and capability system to control access to service information 1 Introduction The decreasing cost of networking technology and network enabled devices is enabling the large scale deployment of such networks and devices 321 Simultaneously significant computational resources are being deployed within the network infrastructure this computational infrastructure is being used to offer many new and innovative services to users of these network enabled deThis work was supported in part by grants from Ericsson Intel Sprint and Motorola by DARPA under contract DABT63 98C 0038 by the State of California under the MICRO program and by NSF Research Infrastructure grant CDA 94 01156 Permission to make digi or hard copies of all or part of this work for personal or classroom USCis granted without fee provided thar copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the tirst page To copy otherwise to republish to post on sewers or to redistrihutc to lists requires prior specific permission and or a fee The Ninja project is developing a scalable fault tolerant distributed composable services platform 30 Mobicom 99 Seattle Washington USA Copyright ACM 1999 I 58113 142 9 99 08 5 00 24 address security concerns the SDS controls the set of agents that have the ability to discover services allowing capability based access control i e to hide the ezistence of services rather than or in addition to disallowing access to a located service As a globally distributed wide area service the SDS addresses challenges beyond those of services that operate solely in the local area The SDS architecture handles network partitions and component failures addresses the potential bandwidth limitations between remote SDS entities arranges the components into a hierarchy to distribute the workload and provides application level query routing between components This paper presents the design of the SDS focusing on both the architecture of the directory service and the security features of the system Section 2 begins our discussion by describing the design concepts used in order to achieve our goals The SDS architecture is described in Section 3 Wide area operation is discussed in Section 4 Performance measurements from the SDS prototype implementation are presented in Section 5 followed by a discussion of related systems in Section 6 Finally we summarize and conclude in Section 7 2 Design work l We will describe our use of announce listen Sections 3 1 and 3 2 2 2 2 3 Information XML Service Descriptions Rather than use flat name value pairs as in e g the Session Description Protocol 12 the SDS uses XML 4 to describe both service descriptions the identifying information submitted by services and client queries XML allows the encoding of arbitrary structures of hierarchical named values this flexibility allows service providers to create descriptions that are tailored to their type of service while additionally