The Universal Plug and Play Forum (UPnP) Security Working Committee has issued a call for industry review of two new XML-based specifications, SecurityConsole: Service Template Specification and DeviceSecurity: Service Template Specification. The working committee invites comments on these level 0.93 specifications, particularly with regard to the robustness of the proposed security solution and to potential security vulnerabilities. The UPnP Forum seeks to develop standards for describing device protocols and XML-based device schemas for the purpose of enabling device-to-device interoperability in a scalable networked environment.

The goal of UPnP technology is to make home networking "simple and affordable for users so the connected home experience becomes a mainstream experience for users experience and great opportunity for the industry. UPnP architecture offers pervasive peer-to-peer network connectivity of PCs of all form factors, intelligent appliances, and wireless devices. It leverages Internet standards including IP, TCP, UDP, HTTP, and XML; its contracts are based on wire protocols that are declarative, expressed in XML, and communicated via HTTP. The UPnP description for a device is expressed in XML and includes vendor-specific, manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, etc. The description also includes a list of any embedded devices or services, as well as URLs for control, eventing, and presentation."

The draft UPnP Device Security Service specification provides the services necessary for strong authentication, authorization, replay prevention, and privacy of UPnP SOAP actions. It describes the actions used in the creation and editing of Access Control Lists (ACLs), while the Security Console specification documents a user interface for administration of access control on security-aware UPnP devices. Both specifications reference W3C/IETF XML Signature as well as the Universal Plug and Play Device Architecture Version 1.0.

Bibliographic Information

DeviceSecurity: Service Template Specification. By Carl Ellison (Intel Corporation) [WWW]. Public Review Draft for UPnP Version 1.0. August 12, 2003. 74 pages. Copyright (c) 2002-2003 by contributing members of the UPnP Forum. Section 6 (pages 66-74) presents the XML Service Description.

SecurityConsole: Service Template Specification. By Carl Ellison (Intel Corporation) [WWW]. Public Review Draft for UPnP Version 1.0. August 12, 2003. 23 pages. Copyright (c) 2002-2003 by contributing members of the UPnP Forum. Section 4 (pages 21-23) presents the XML Service Description.

UPnP Version 1 Overview

"UPnP V1 is a suite of protocols (SSDP for device discovery, SOAP for control, GENA for eventing) that enable home networking without a classical network administrator. UPnP V1 Security is a pair of services: DeviceSecurity (to be added to any device that needs to be access-controlled) and SecurityConsole (offered by the administrative application or device at which the homeowner makes security decisions known to the home network).

UPnP V1 Security does not assume that the home network is already secured. Rather, it assumes that the home network is open to guests, neighbors, or even the driveway-guy (who breaks into a home wireless network). Devices and their resources are secured even when guests who are not especially trusted are invited to attach to the home network, when one has roommates, etc.

UPnP V1 categorizes components into two classes: Devices, offering services and holding resources, and Control Points, discovering Devices, asking for services via SOAP RPC and maybe getting event notifications via GENA. UPnP V1 Security adds a third component, the Security Console, that is both a Device and a Control Point. It discovers all security-aware components, lets the user name those s/he cares about, and lets the user:

1. take ownership (or share ownership) of the user's devices (where ownership means the ability to edit a device's ACL)
2. edit the ACL of any owned device, granting authorizations to Control Points of the user's choice
3. (optionally) generate certificates for defining named groups of control points or for delegating authorization

Each security-aware component has its own RSA key pair and a Device or Control Point is known to the Security Console by the hash of its public key. This is an unfriendly quantity, so the user is allowed/expected to name any component in his/her personal network and use that name instead. Details are available in the published spec drafts." [personal email exchange with Carl Ellison]

Additional information: For further technical detail, see "Universal Plug and Play" (pages 45-47) in the article "Home Network Security," by Carl M. Ellison (Corporate Technology Group, Intel Corporation). Excerpt:

"The basic architecture of UPnP V.1 is client-server, with the client called a 'Control Point' (CP) and the server called a 'Device'. There are three protocols used to let components interact with each other: [1] SOAP (Simple Object Access Protocol): for remote procedure calls from a CP to a Device. [2] SSDP (Simple Service Discovery Protocol): for discovery of Devices. [3] GENA (General Event Notification Architecture): for subscribing to event reports and publication of those events. SOAP carries the bulk of the work and the security of SOAP is described in detail below. In brief, SOAP is secured by allowing only authorized Control Points to invoke any secured action within a Device. This is accomplished by an ACL in each secured Device, each of the entries of which lists a Control Point (CP) unique ID, a name of a group of CPs or the universal group, <any/>, and what that CP or group is allowed to do on that Device.

SSDP is difficult to secure. It is vital for the authorized user to discover other Devices on the home network, but it is desirable that an attacker not be able to take an inventory of the home network's equipment. Therefore, to secure SSDP, the existence of Devices is announced, but they are announced as generic Devices, and are not described in any detail except in response to requests from authorized Control Points. It is still possible for a determined attacker to take an inventory of a home network, even if all traffic was completely encrypted (e.g., via IPSEC), just based on timing and length of messages. Therefore, securing SSDP is considered low priority until there are significant new research results in anonymity protection.

For security of GENA, we define a normal event variable that anyone can read, named 'EncryptedEvent' but it contains any event variables that are to be made available only to authorized Control Points. An EncryptedEvent is sent to a Control Point encrypted in a key known only to the Device and that Control Point. Control Points not allowed to see such an event, are not allowed to subscribe to those events, and are not able to see the events by eavesdropping on the network..."

From the UPnP DeviceSecurity and SecurityConsole Specifications

DeviceSecurity Service Template. The UPnP Device Security Service "provides the services necessary for strong authentication, authorization, replay prevention, and privacy of UPnP SOAP actions. Under this architecture, a device enforces its own access control but its access control policy is established and maintained by an administrative application, the Security Console, which uses some of the actions provided as part of this service. Nothing prevents a device with the proper user interface capabilities from providing its own administration interface, although presumably it is a valuable ability to administer access from one location for an entire household network... DeviceSecurity implements access control for itself and for other Services in the same Device (or embedded Device). There are two classes of access control grant defined here: ownership and normal permission. Each security-aware device has an ownership list capable of holding at least one entry. Any Security Console listed as an owner has full rights for the device, specifically to all actions including the DeviceSecurity actions that specify other access control. In addition to the owner list, the device usually has an access control list (ACL) maintained by DeviceSecurity. Entries in the ACL grant a Security Console or other Control Point symbolic permissions that, in turn, grant access to sets of actions. Those permissions typically grant less than the full access that ownership grants. A Security Console, at the option of the device vendor, might also be granted the permission to delegate rights to others without having to be a full owner of the device or to define named groups of Control Points to be granted access as a group in a single operation. These last two capabilities depend on the implementation of certificate processing by the Device and that is an optional feature of DeviceSecurity..." [adapted from v0.93 DeviceSecurity, Overview and Scope]

SecurityConsole Service Template. "This service is offered by a Security Console (SC). The Security Console offers a user interface for administration of access control on security-aware devices. DeviceSecurity provides a description of the actions used in the creation and editing of Access Control Lists (ACLs) and in taking security ownership of devices. As a device the Security Console is self-owned. If it has any access-controlled actions, then those are to be administered by the human user and not by some other Security Console. Therefore, a Security Console does not need to include a DeviceSecurity service. It does have a certificate cache, but it is an outgoing cache rather than an incoming cache. A network built of the user's own components with no connection to anything outside the user's personal domain and with no control points belonging to anyone other than the user ever attached to the network would not require the features of UPnP Security. Network isolation would already have achieved a level of physical security. We are concerned in UPnP Security with networks in which more than the user's own Control Points are present on the physical network and able to reach the user's Devices with control messages. These situations can include: (1) use of wireless, power-line networking or cable modem without a firewall, allowing an attacker to join the network without the user's knowledge or permission; (2) shared infrastructure networks, such as a college dorm or a condominium building wired for Ethernet as one network segment serving more than one person's residence; (3) households of multiple adults or teens, in which each individual wants to establish a private security domain, in addition to any domain of devices or control points shared among them, while using a shared network domain; (4) connections to the Internet via devices or services that create single network segments of multiple subscribers as a side effect of offering network connectivity -- such as some cable modems and some ISP connections ; (5) households in which guests might bring mobile devices or control points into the network temporarily. In such networks of intentional or accidental sharing, one cannot rely on physical network discovery methods (e.g., multicast SSDP) to compile a list of 'My Devices' or 'My Control Points'. This leaves it up to the user manually to select from physically accessible devices and control points, choosing those of interest to that user. One primary function of the SC is to enable the user to make that selection..." [adapted from v0.93 SecurityConsole, Overview and Scope]

About the UPnP Framework

"A UPnP-based network consists of a set of UPnP devices that can be monitored by one or more control points. A UPnP device can contain a number of services and nested devices. For identification purposes, the device must host an XML device description document that lists specific properties about the device, the services associated with the device, and the nested devices. The XML schema for UPnP device descriptions is called the UPnP Template Language (UTL). The device description document must also include a Uniform Resource Locator (URL) for the service description. The service description is an XML document that lists the actions and state variables that apply to a specific service offered by the device. The control point is responsible for enumerating UPnP devices on the network, searching for an instance of a particular UPnP device, and controlling a service on a UPnP device. The control point can also subscribe to events to receive notification of the change of state variables on a UPnP device..." [adapted from the Microsoft document]

About the UPnP Forum

"By defining and publishing UPnP device and service descriptions, members of the UPnP Forum are enabling the emergence of easily connected devices and simplifying the implementation of home and corporate networks. In doing so, UPnP Forum members are creating new product opportunities for their companies and for other organizations.

The UPnP Forum is a group of companies and individuals across multiple industries that intend to play a leading role in the authoring of specifications for UPnP devices and services. Formed in June 1999, the Forum is a non-profit association of more than 617 consumer electronics, computing, home automation, home security, appliances, printing, photography, computer networking, mobile products and other leading companies working together in an open process to design schema and protocol standards for the UPnP initiative.

The goals of the Forum are to allow devices to connect seamlessly and to simplify the implementation of networks in the home and corporate environments. The Forum will achieve this by defining and publishing UPnP device control protocols built upon open, Internet-based communication standards.

UPnP technology is broad in scope in that it targets home networks, proximity networks, and networks in small businesses and commercial buildings. It enables data communication between any two devices under the command of any control device on the network. UPnP technology is independent of any particular operating system, programming language, or physical medium.

The UPnP architecture supports zero-configuration networking and automatic discovery whereby a device can dynamically join a network, obtain an IP address, announce its name, convey its capabilities upon request, and learn about the presence and capabilities of other devices. DHCP and DNS servers are optional and are only used if they are available on the network. A device can leave a network smoothly and automatically without leaving any unwanted state information behind.

Like the creation of Internet standards, the UPnP initiative involves a multi-vendor collaboration for establishing standard Device Control Protocols (DCPs). Similar to Internet-based communication, these are contracts based on wire protocols that are declarative, expressed in XML, and communicated via HTTP." [adapted from the 'About' website page]