scope:

Overview and Scope

The 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 (see SecurityConsole:1), 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. In what follows, the term "Security Console" refers to any Control Point that chooses to exercise the administrative functions defined here in DeviceSecurity.

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

A device implementing DeviceSecurity will need to support the basic cryptographic algorithms used in this service:

AES 128-bit, for symmetric bulk encryption, labeled "AES-128-CBC", with blocks padded as described in section 4.8 below.

SHA1 HMAC, for symmetric signatures and for TakeOwnership, labeled "SHA1-HMAC"

RSA 1024-bit, for identification and for establishing secure sessions, and possibly for other operations, labeled "RSA". In the current version of this DeviceSecurity specification, there is no reason for a device to have a public-key algorithm signature key. Therefore a device will offer a public confidentiality key but does not need to offer a signature key at this time. [In particular, actions that are authorized by public-key algorithm signatures do not have digitally signed responses.] The algorithm identifier "RSA" when used for encryption in this service implies (RSA, PKCS#1) and when used for signing implies (RSA, SHA-1, PKCS#1).

Other algorithms may be added to this list, if these develop flaws and need to be supplanted. For example, if another hash algorithm were to be added, one would need to identify it and also identify RSA using it for signing. So, for example, if one adds the hash algorithm FOOBLA, one would need to add RSA-FOOBLA and FOOBLAHMAC to the algorithm list.