Device Control Protocol Specification (DCP)
an Internet Protocol for Controlling Devices

CONTENTS

Up
Introduction
Conventions
Parameters
Fundamentals
Message Format
Requests
Responses
Entities
Request Methods
Reserved Objects
Status Codes
Headers
Session Management
Authentication
Security
XML DTD

 

Back ] Next ]

 

 


 

 

Click Here to visit the home page belonging to the creator of DCP and get access to other downloads, including a white paper on forward compatible design for the Internet.

SECURITY CONSIDERATIONS

This section is meant to inform application developers, information providers, and users of the security limitations in DCP as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does make some suggestions for reducing security risks.


AUTHENTICATION OF CLIENTS

As mentioned, the Basic authentication scheme is not a secure method of user authentication, nor does it prevent the entity body from being transmitted in clear text across the physical network used as the carrier. DCP does not prevent additional authentication schemes and encryption mechanisms from being employed to increase security.


SAFE METHODS

The writers of initiator software should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they may take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the get and subscribe methods should never have the significance of taking an action other than retrieving information. These methods should be considered "safe." This allows user agents to represent other methods, such as set, event, tether and call, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the target does not generate side-effects as a result of performing a get request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side effects, so therefore cannot be held accountable for them.


ABUSE OF LOG INFORMATION

A target is in the position to save personal data about a user's requests that may identify their patterns of DCP usage. This information is clearly confidential in nature and its handling may be constrained by law in certain countries. People using the DCP protocol to provide data are responsible for ensuring that such material is not distributed without the permission of any individuals that are identifiable by the published results.


TRANSFER OF SENSITIVE INFORMATION

Like any generic data transfer protocol, DCP cannot regulate the content of the data that is transferred, nor is there any a prior method of determining the sensitivity of any particular piece of information within the context of any given request. Therefore, applications should supply as much control over this information as possible to the provider of that information. Two header fields are worth special mention in this context: Target and Initiator-Agent.

Revealing the specific software version of the Target may allow the Target object to become more vulnerable to attacks against software that is known to contain security holes. Implementers should make the Target header field a configurable option.

The information sent in the Initiator-Agent field might conflict with the user's privacy interests or their site's security policy, and hence it should not be transmitted without the user being able to disable, enable, and modify the contents of the field. The user must be able to set the contents of this field within a user preference or application defaults configuration.


ATTACKS BASED ON OBJECT AND PATH NAME

Implementations of DCP origin targets should be careful to restrict the data returned by DCP requests to be only that that was intended by the target administrators. If an DCP target translates DCP URIs directly into object calls, the target must take special care not to serve deliver that was not intended to be delivered to DCP initiators. For example, Unix, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On such a system, an DCP target must disallow any such construct in the request URI if it would otherwise allow access to a resource outside those intended to be accessible via the DCP target. Similarly, data intended for reference only internally to the target (such as access control data, configuration data) must be protected from inappropriate retrieval, since they might contain sensitive information.

© 2000 Chris Armbruster