pkix Zhou, Ed. Internet-Draft Huawei Technologies, Inc. Intended status: Standards Track June 15, 2009 Expires: December 17, 2009 draft-zhipeng-pkix-drm-proxy-architecture-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 17, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies a method and its architecture for proxy DRM application based on the PKI environment with X.509 certificate [X.509]. It can be a common solution for the proxy DRM application Zhou Expires December 17, 2009 [Page 1] Internet-Draft June 2009 regardless the specific DRM standard that is implemented on the interface between the Client Device and Service Server. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Proxy Architecture for DRM service . . . . . . . . . . . . . . 4 4. Trust Architecture for Proxy DRM service . . . . . . . . . . . 5 5. Format of Authorization Document . . . . . . . . . . . . . . . 6 5.1. Example of Authorization Document . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Zhou Expires December 17, 2009 [Page 2] Internet-Draft June 2009 1. Introduction This document specifies a method and its architecture to fulfill that a device can apply for the DRM (Digital Rights Management) service or content on behalf of another device. Below list two typical situations when an application may want to use this proxy method : - In home network, the home server or home gateway can manage the home devices and subscribe services for these home devices. Only the home server or home gateway has the right to subscribe services. The home devices can only access service under the permission of home server or home gateway. - In business environment, the device with higher grade can control the access rights of the devices with lower grade. So the lower grade device can only access some special services or some secret content from a server when it holds the authorization of a device with higher grade. To verify the service subscription or service acquisition, the Service Provider (Service Server) SHOULD verify the trusty relationship between the request device and the proxy device. Currently, most DRM architectures are based on PKI technology. So, it is available to conduct such verification to support such proxy DRM service under the PKI environment with X.509 certification. Generally, in order to set up the trusty relationship with proxy device, request device SHALL create an authorization document with its digital signature to authorize the proxy device of proxy responsibilities. The authorization document SHALL contain the detail service information that the proxy device can subscribe for the request device. After receiving the authorization document, the proxy device can follow the authorization to take the service operation for the request device. Meanwhile the authorization between the request device and the proxy device SHALL be delivered to the Service Server. Thus the Service Server will only send or issue the service response which is compliant to the authorization to the proxy device. Finally, the service response will be transferred to the request device by the proxy device. Under this proxy method and architecture, the proxy device on one hand can manage the service subscription of the request device, and on the other hand can take on most communication tasks with the Service Server to reduce the burden of request device. Zhou Expires December 17, 2009 [Page 3] Internet-Draft June 2009 As for the implementation, two issues will not be defined in this document and SHOULD depend on the specific application: First issue is "types of DRM service". This document does not define the types of DRM service while in section 5 the services defined in OMA DRM specification [OMA DRM2.1 TS] such as "RO Acquisition" and "Join Domain" are referred as an example. Second issue is "message of DRM service". This document will not define the message of DRM service either. It can depend on the DRM specification. The method defined in this document can be used for any DRM devices if they support PKI and X.509 certificate. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Proxy Architecture for DRM service The general service architecture for the proxy application is listed as Figure 1: +----------+ DRM Request +----------+ Proxy DRM Request +----------+ | Request | -----------> | Proxy | ------------------>| Service | | Device A |<----------- | Device B |<------------------ | Server | +----------+ DRM Response +----------+ Proxy DRM Response +----------+ Figure 1. Proxy Architecture for DRM service On the request flow, the Request Device A creates the "DRM Request" and sends it to the Proxy Device B. After verifying over the request successfully, the Proxy Device B creates and sends the "Proxy DRM Request" to Service Server to apply for service for the Request Device A. The "Proxy DRM Request" can contain the whole "DRM Request" as an element or contain relative elements picked up from the "DRM Request". Similarly, on the response flow, the Service Server sends the "Proxy DRM Response" upon the "Proxy DRM Request" to the Proxy Device B. Then the Proxy Device B transfers or creates the "DRM Response" on the basis of the "Proxy DRM Response" to the Request Device A. In general third party proxy services, such kind of interactive flow is rather usual. While for DRM application, the key issue is to build up and to effectively deliver the trust mechanism since the Service Zhou Expires December 17, 2009 [Page 4] Internet-Draft June 2009 Server SHOULD control the risk from all the devices that could access the service or content. A solution to deliver the trust mechanism is that the Request Device A sets up trusty authorization with Proxy Device B and authorize the Proxy Device B with the proxy rights to take service operation with Service Server for the Request Device A. After the Proxy Device B completes the service session with Service Server, it will send the response that corresponds to the trusty authorization back to the Request Device A. In section 4, the mechanism to set up trusty relationship is fully elaborated. 4. Trust Architecture for Proxy DRM service In bi-entity architecture, based on PKI environment, the trust verification is conducted via verifying the Certificate Chain of each other between the two entities of the service. So, to fulfill the trust verification among the three entities within the proxy service, a method is given that the Request Device creates an authorization to enumerate what right the Proxy Device can hold to subscribe the service for the Request Device A. The Trust Architecture is listed as Figure 2: Certificate A Certificate A + Certificate B + + +----------+ Authorization +----------+ Authorization +----------+ | Request | ------------->| Proxy | -----------------> | Service | | Device A |<------------- | Device B |<----------------- | Server | +----------+ DRM Response +----------+ Proxy DRM Response +----------+ Figure 2. Trust Architecture for proxy DRM service The Authorization Document is sent to Proxy Device B as well as the Certificate Chain of Request Device A. The Proxy Device B verifies the secure status of Request Device A by checking certificate revocation list (CRL) [RFC3280][RFC5280] for the Certificate A. If successfully, then verifies the Authorization Document using the public Key of Request Device A that is enclosed in the Certificate A. If all the verifications are correct, the Proxy Device B parses each element in the Authorization document to be aware of the proxy rights that is authorized by the Request Device A and confirms that the trusty relationship has been set up successfully. In the proxy DRM service, the Authorization Document as well as the certificates of both Request Device A and Proxy Device B SHALL also be delivered to Service Server. Upon receiving the two Certificates and the Authorization Document, Service Server SHALL verify the secure status of both Request Device A and Proxy Device B by checking Zhou Expires December 17, 2009 [Page 5] Internet-Draft June 2009 CRL for their certificates. If successfully, then verifies the Authorization Document using the public Key of Request Device A that is enclosed in the Certificate A. Once all these verifications are correct, the Service Server will also catch the rights that are authorized to Proxy Device B by Request Device A via parsing the elements in the Authorization document. After all the operations above have been finished, the trusty relationship has been set up successfully for the proxy service. Thus, the Proxy Device B can only execute the proxy service operation under the authorization by the Request Device A. At the same time the Service Server will only issue the permitted service to the Request Device A via the Proxy Device B according to the Proxy DRM Request (For service flow, please refer to section 3). 5. Format of Authorization Document The Authorization Document is composed of: -- name of Request Device -- CertId of Request Device -- name of Proxy Device -- CertId of Proxy Device -- authorized service rights -- optional extensions -- signature algorithm -- signature The signature is computed across hash of the Authorization Document except the signature itself. Since the format of each element in this Authorization Document depends on the real application and can be based on some a DRM specification. This document just gives an example of the Authorization Document based on [OMA DRM2.1 TS] . 5.1. Example of Authorization Document This section provides a structure of Authorization Document as an instance. In this instance, the service types or service authorization are based on the OMA DRM2.1 specification (For details, please refer to [OMA DRM2.1 TS] ). Defined in the specification of OMA DRM2.1, the service operations include "2-pass RO Acquisition","4-pass Confirmed RO Acquisition", "1-pass RO Acquisition","3-pass Confirmed RO Acquisition","2-pass Join Domain", "2-pass Leave Domain", "2-pass Metering Report" and "2-pass RO Upload". Zhou Expires December 17, 2009 [Page 6] Internet-Draft June 2009 A data structure for the Authorization Document is described as follows: AuthorizationDocument() { DeviceId() // The id of Request Device A CertId() // The key information of certificate A DeviceId() // The id of Proxy Device B CertId() // The key information of certificate B ServiceRights() //Authorized service rights to Proxy Device B ExpireDate //The deadline of validity, UTC time SignatureAlgorithm() //Refer to X.509 Signature() } DeviceId() { Hash() } CertID() { hashAlgorithm 8 uimsbf //AlgorithmIdentifier, issuerNameHash() //Hash of Issuer's name issuerKeyHash() //Hash of Issuer's public key serialNumber 32 uimsbf //CertificateSerialNumber } issuerNameHash(){ Hash() } issuerKeyHash(){ Hash() } Hash(){ // Hash Value, the Hash algorithm refers to [SHA-1] OctetString8() } AuthorizedRights(){ // The following service rights in proxy service are defined: // 0 2-pass RO Acquisition // 1 4-pass Confirmed RO Acquisition // 2 1-pass RO Acquisition // 3 3-pass Confirmed RO Acquisition // 4 2-pass Join Domain // 5 2-pass Leave Domain // 6 2-pass Metering Report // 7 2-pass RO Upload Zhou Expires December 17, 2009 [Page 7] Internet-Draft June 2009 // at most contain 8 kinds of authorized rights as listed above for( i = 0; i < RightsNub; i++ ){ ProxyRightsId 8 uimsbf } } ExpireDate(){ // Deadline of Validity OctetString8() } Signature(){ // Signature Value OctetString8() } OctetString8(){ length 8 uimsbf for( i = 0; i < length; i++ ){ octet 8 uimsbf } } The fields are defined as follows: .length - Length of the octet string .octet - A byte 6. Security Considerations To guarantee the Authorization Document is valid in limited period, it SHALL contain the expiration date which SHALL be earlier than the expiration date ("notAfter" element defined in X.509) of the certificates of both Request Device and Proxy Device. During the valid period, the authorization document does not need to be delivered in every service operation if the target entity (the Proxy Device or Service Server) has already held it. If during the valid period, either the Request Device or the Proxy Device has updated its certificate, this Authorization Document will expire automatically. It means either the Proxy Device or the Service Server will reject the DRM Request or Proxy DRM Request if the authorization document can not be verified successfully. Therefore the Request Device needs to create a new one if it like to continue the proxy service. Regarding both the Request Device and Proxy Device, they are completely DRM devices and SHALL obey the DRM specification strictly and SHALL own the security capability requested for DRM device in the Zhou Expires December 17, 2009 [Page 8] Internet-Draft June 2009 DRM specification. Therefore all the related security measures defined in DRM specification SHALL be completely implemented in these Devices. The Proxy Device MAY need to register with Service Device and only the registered Proxy Device can conduct the Proxy Service. But the Proxy Device will be able to take proxy service for any Request Device although it SHOULD send the certificate of Request Device to the Service Server to ensure the Service Server can verify the Request Device's security status. Regarding the Service Server, it SHALL obey the DRM specification too. For instance, it acts as the RI (Rights Issuer) that is defined in OMA DRM2.1 [OMA DRM2.1 TS] . 7. IANA Considerations This document requires no actions from IANA. 8. Acknowledgements Many thanks to all the members of Huawei DRM project team. Countless discussions and ceaseless effort have surely helped us transcend each tough process one after another. Great and Cheer! Also many thanks to all the people I know in the DRM-related Chinese and international standard organizations. Interesting debate and communication helps me much and will remains in my mind forever. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [X.509] "ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks". [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Zhou Expires December 17, 2009 [Page 9] Internet-Draft June 2009 (CRL) Profile", RFC 5280, May 2008. [OMA DRM2.1 TS] OMA-TS-DRM_DRM-V2_1-20081106-A, "DRM Specification". [SHA-1] National Institute of Standards and Technology (NIST), "FIPS 180-2: Secure Hash Standard", August 2002. Author's Address Zhipeng Zhou (editor) Huawei Technologies, Inc. Floor 2, Building A, NO.48, Ning Nan AV., Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-82276771 Email: zhouzp@huawei.com Zhou Expires December 17, 2009 [Page 10]