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.

ACCESS AUTHENTICATION

DCP provides a simple challenge-response authentication mechanism which may be used by a target to challenge a initiator request and by a initiator to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication via that scheme.

Syntax

The 401 (unauthorized) response message is used by an origin target to challenge the authorization of a user agent. This response must include a DCP-Authenticate header field containing at least one challenge applicable to the requested resource.

Syntax

The realm attribute (case-insensitive) is required for all authentication schemes which issue a challenge. The realm value (case-sensitive), in combination with the canonical root URL of the target being accessed, defines the protection space. These realms allow the protected resources on a target to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin target, which may have additional semantics specific to the authentication scheme.

A user agent that wishes to authenticate itself with a target-- usually, but not necessarily, after receiving a 401 response--may do so by including an Authorization header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

Syntax

The domain over which credentials can be automatically applied by a user agent is determined by the protection space.

If a prior request has been authorized, the same credentials may be reused for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot extend outside the scope of its target. If the target does not wish to accept the credentials sent with a request, it should return a 403 (forbidden) response.

The DCP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional mechanisms may be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, these additional mechanisms are not defined by this specification.

Proxies must be completely transparent regarding user agent authentication. That is, they must forward the WWW-Authenticate and Authorization headers untouched, and must not cache the response to a request containing Authorization. DCP does not provide a means for a client to be authenticated with a proxy.

A widely used authentication scheme is the Basic Authentication Scheme.


BASIC AUTHENTICATION SCHEME

The "basic" authentication scheme is a form of access authentication that is based on the model that the user agent must authenticate itself with a user-ID and a password for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms on that target. The target will authorize the request only if it can validate the user-ID and password for the protection space of the request URI. There are no optional authentication parameters.

Upon receipt of an unauthorized request for a URI within the protection space, the target should respond with a challenge like the following:

Example 

WWW-Authenticate: Basic realm = "DcpWorld"

where "DcpWorld" is the string assigned by the target to identify the protection space of the request URI.

To receive authorization, the initiator sends the user-ID and password, separated by a single colon (":") character, within a base64 [5] encoded string in the credentials.

Syntax
basicCredentials = "Basic" sp basicCookie
basicCookie = base64 encoding of userIdPassword, except not limited to 76 char/line
userIdPassword = [ token ] ":" *text

If the user agent wishes to send the user-ID "Aladdin" and password "open sesame", it would use the following header field:

Example 

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

The basic authentication scheme is a non-secure method of filtering unauthorized access to resources on an DCP target. It is based on the assumption that the connection between the initiator and the target can be regarded as a trusted carrier. As this is not generally true on an open network, the basic authentication scheme should be used accordingly. In spite of this, initiators should implement the scheme in order to communicate with targets that use it.

© 2000 Chris Armbruster