pkix Zhou, Ed. Internet-Draft Huawei Technologies, Inc. Intended status: Standards Track Chen Expires: April 24, 2010 China Telecom October 21, 2009 draft-zhipeng-pkix-drm-proxy-architecture-01 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 April 24, 2010. 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 Zhou & Chen Expires April 24, 2010 [Page 1] Internet-Draft October 2009 [X.509]. It can be a common solution for the proxy DRM application regardless the specific DRM standard which 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. Authorization Document based on OMA DRM2.1 . . . . . . . . 7 6. Initiation and Update of Authorization . . . . . . . . . . . . 10 7. Application Example . . . . . . . . . . . . . . . . . . . . . 12 8. Extended Architecture . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 12. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Zhou & Chen Expires April 24, 2010 [Page 2] Internet-Draft October 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 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 and only the home server or home gateway has the right to subscribe services. Thus, the home devices can only access service under the permission of the 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 through 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 trusted 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 trusted 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 & Chen Expires April 24, 2010 [Page 3] Internet-Draft October 2009 As for the implementation, two issues SHOULD depend on the specific application: The first issue is "types of DRM service". This document does not define the types of DRM service while section 5.1 gives the definition of Authorization Document based on the services defined in OMA DRM specification [OMA DRM2.1 TS] such as "RO Acquisition" and "Join Domain" are referred as an example. The 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 creates the "DRM Response" on the basis of the "Proxy DRM Response" and sends the "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 Zhou & Chen Expires April 24, 2010 [Page 4] Internet-Draft October 2009 issue is to build up and to effectively deliver the trust mechanism since the Service Server SHOULD control the risk from all the devices that could access the service or content. The solution defined in this document to deliver the trust mechanism is that the Request Device A sets up trusted authorization with the Proxy Device B and authorizes the Proxy Device B with the proxy rights to take service operations with the Service Server for the Request Device A. After the Proxy Device B completes the service session with the Service Server, it will send the response that corresponds to the trusted authorization back to the Request Device A. The mechanism to set up trusted relationship is fully elaborated in the following section 4. 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 shown 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 can be contained in a document. 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) [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, including verifying the signature and the proxy rights enclosed in the Authorization Document. 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 are authorized by the Request Device A and confirms that the trusted relationship has been set up successfully. Zhou & Chen Expires April 24, 2010 [Page 5] Internet-Draft October 2009 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 statuses of both Request Device A and Proxy Device B by checking CRL for their certificates. If both devices are in secure status, then verifies the Authorization Document using the public Key of Request Device A that is enclosed in the Certificate A. Once the verification of the Authorization Document is successful, the Service Server will catch the rights that are authorized to Proxy Device B by Request Device A via parsing the elements in the Authorization document. For example, if the Authorization Document only contains the rights of 2-pass RO Acquisition, the Proxy Device can subscribe the ROs for the Request Device via the 2-pass RO Acquisition protocol defined in OMA DRM2.1 and can not subscribe for the Request Device for joining a Domain. After all the operations above have been finished, the trusted 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 -- extensions -- signature algorithm -- signature The signature is computed across hash of the Authorization Document except the signature itself. Since the "authorized service rights" depends on the real application and SHOULD be based on a specific DRM specification, this document just gives the definition of proxy rights based on [OMA DRM2.1 TS] for the OMA DRM service while the definitions of proxy rights can adapt to the real application when needed. Zhou & Chen Expires April 24, 2010 [Page 6] Internet-Draft October 2009 5.1. Authorization Document based on OMA DRM2.1 This sub-section provides a structure of Authorization Document. 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". The 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 AuthorizedRights() //proxy rights authorized to Proxy Device B ExpireDate() //The deadline of validity, UTC time SerialNumber 32 uimsbf SignatureAlgorithm() //Refer to X.509 Signature() } DeviceId() { Hash() } CertId() { hashAlgorithmId 8 uimsbf //AlgorithmIdentifier issuerNameHash() //Hash of Issuer's name issuerKeyHash() //Hash of Issuer's public key serialNumber 32 uimsbf //CertificateSerialNumber } The "hashAlgorithmId" is used to indicate the hash Algorithm. Following is the definitions of "hashAlgorithmId" in this document. +----------------------------------------+ | hash Algorithm | value | +---------------------+------------------+ | SHA-1 | 0 | +---------------------+------------------+ | rfu | 1~255 | +---------------------+------------------+ Zhou & Chen Expires April 24, 2010 [Page 7] Internet-Draft October 2009 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 //at most contain eight kinds of authorized right as listed above for( i = 0; i < RightsNub; i++ ){ ProxyRightsId 8 uimsbf } for( i = 0; i < RightsNub; i++ ){ SuspendedRightsId 8 uimsbf } for( i = 0; i < AuthorizationDocumentNub; i++ ){ //Serial Number of the Authorization Document to be suspended SuspendedAuthorizationNumber 32 uimsbf } } ExpireDate(){ // Deadline of Validity OctetString8() } Signature(){ // Signature Value OctetString8() Zhou & Chen Expires April 24, 2010 [Page 8] Internet-Draft October 2009 } 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 The Authorization Document contains the essential information for other entities to verify the authorization of the Request Device to the Proxy Device. Following is the detailed description: DeviceId: In OMA DRM 2.1, is defined as the hash of the Device's public key info. Here that definition is followed and the hash algorithm is SHA-1 that is set as default hash algorithm in OMA DRM 2.1. CertId: The essential information of the device's Public Key Certificate, including hashAlgorithmId, issuerNameHash, issuerKeyHash, and serialNumber. AuthorizedRights: It contains three parts: ProxyRightsId, SuspendedRightsId and SuspendedAuthorizationNumber. The ProxyRightsId indicates the right that the Request Device has authorized to the Proxy Device to subscribe a specific service. This document supports the services defined in OMA DRM2.1, including 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. To support suspending a proxy right, the SuspendedRightsId is used to indicate which right is suspended (refer to the section of "Update of Authorization").The SuspendedAuthorizationNumber indicates the suspended Authorization Document by its serial number. ExpireDate: For security concern, the Authorization Document contains an "ExpireDate" element. Once that date exceeds the ExpireDate, the authorization turns invalid immediately. SerialNumber: the serial number of the Authorization Document. The Request Device SHALL assign each Authorization Document a unique serial number. Signature and SignatureAlgorithm: The Authorization Document contains the digital signature over the other part of the Authorization Zhou & Chen Expires April 24, 2010 [Page 9] Internet-Draft October 2009 Document except the Signature itself under the request Device's private device key. The SignatureAlgorithm indicates the Algorithm for creating the digital signature. 6. Initiation and Update of Authorization The procedure of initiating or updating the Authorization can be an independent service flow. The Request Device will get a response for its request of Authorization Initiation or Authorization Update. Once the authorization is expired, the trusted relationship between the Request Device and the Proxy Device will not exist any more. The Request Device needs to initiate a new Authorization. And during the valid duration, the authorization can also be updated. For example, the Request Device wants to authorize the Proxy Device some more rights, it can either suspend the original Authorization Document and then create a new Authorization Document or just create another Authorization Document containing the additional authorized rights. Hence the Proxy Device can conduct all the proxy rights up to date. If the Request Device wishes to suspend the whole or part of the existing authorization, it can create an Authorization Document to the Proxy Device to indicate which Authorization Document or which proxy right SHOULD be suspended on the base that the Proxy Device is fully trusted by the Request Device. If to guarantee a higher security, the Request Device can take a measure to inform the Service Server that the trusted relationship to the Proxy Device or some a proxy right is suspended. On the other side, in the real application, the Proxy Device can also suspend part or whole of the trusted relationship. Thus the Proxy Device will not apply for the suspended service for the Request Device any more. The procedure of Authorization Initiation & Update is shown in Figure 3 below. Zhou & Chen Expires April 24, 2010 [Page 10] Internet-Draft October 2009 Authorization Proxy Authorization +----------+ Request +----------+ Request +---------+ | Request | ------------->| Proxy | ------------------->| Service | | Device A |<------------- | Device B |<------------------- | Server | +----------+ Authorization +----------+ Proxy Authorization +---------+ Response Response Figure 3. Procedure of Authorization Initiation & Update The message formats are defined as follow: AuthorizationRequest() { AuthorizationDocument(); Certificate A; } AuthorizationResponse() { Status; } ProxyAuthorizationRequest() { AuthorizationDocument(); Certificate A; Certificate B; } ProxyAuthorizationResponse() { Status; } The possible status value of AuthorizationResponse and ProxyAuthorizationResponse are defined as below: +---------------------------------------------+ | status | value | +--------------------------+------------------+ | SUCCESS | 0 | +--------------------------+------------------+ | Certificate A invalid | 1 | +--------------------------+------------------+ | Certificate B invalid | 2 | +--------------------------+------------------+ | Certificate A&B invalid | 3 | +--------------------------+------------------+ | Authorization invalid | 4 | +--------------------------+------------------+ | rfu | 5~255 | +--------------------------+------------------+ In the Authorization Request, the certificate of Request Device Zhou & Chen Expires April 24, 2010 [Page 11] Internet-Draft October 2009 A(certificate A) and the Authorization Document are contained. If the certificate A and Authorization Document are verified successfully by the Proxy Device B, and the Proxy Device B has accepted the Authorization request, then the Proxy Device B will send the Proxy Authorization Request to the Service Server, else return the Authorization Response with the status value indicating the failure reason. The Proxy Authorization Request contains the certificates of both Request Device A and Proxy Device B(certificate A and certificate B) and the Authorization Document. If the information in the Proxy Authorization Request is verified successfully and Service Server has accepted the Proxy Authorization Request, the Proxy Authorization Response will contain the status value of 'SUCCESS', else contain the status value according to the failure reason. Once the Proxy Device B receives the Proxy Authorization Response with the status value of 'SUCCESS', it will return the Request Device A the Authorization Response with the status value of 'SUCCESS', else if the failure reason in the Proxy Authorization Response is only on the side of Proxy Device B(such as the 'Certificate B invalid'), it will correct the errors and send the Proxy Authorization Request again to the Service Server, else will return the Request Device A the Authorization Response with the status value of the failure reason. 7. Application Example Take the home application as an example, the Home Gateway( or the Home Server) acts as the Proxy Device. The benefit is the User can just register one Device(the Home Server) to the Service Provider and apply for the services for all his personal devices as his desire very conveniently. The procedure is very simple that the User operates a device to create and send an Authorization Document to the Home Server. Then he can use that device to apply for DRM service via the Home Server's proxy at once after the Home Serve accepts the authorization. On this architecture the service charging will also be very convenient to the service since the charge can be bounded on the Home Server only. On this architecture, another advantage is that the Home Server can actually control the other devices for applying the service. Somehow this architecture acts similarly as the "Parent Mechanism" to constrain the children's content applications via controlling the devices of the children since the Home Server can judge and refuse the service applications of the Request Device, or refuse the "Authorized Rights" from the Request Device. Zhou & Chen Expires April 24, 2010 [Page 12] Internet-Draft October 2009 On some cases, the Request Device SHOULD ask the Home Server to suspend some service applications. For instance, the Request Device will be given to the User's friend, then the Proxy relationship can be suspended once the Request Device sends the Authorization Document containing the suspending rights. 8. Extended Architecture In the section 3, one Proxy Device is deployed in the Proxy Architecture for DRM Service. In fact, by the proxy mechanism defined above, a Multiple-Proxy Architecture can be implemented. It is shown in Figure 4 below: DRM Proxy DRM Proxy DRM +--------+ Request +---------+ Request-1 +---------+ Request-n +-------+ |Request | ------->|Proxy | .........>|Proxy |---------->|Service| |Device A|<------- |Device-1 |<..........|Device-n |<----------|Server | +--------+ DRM +---------+ Proxy DRM +---------+ Proxy DRM +-------+ Response Response-1 Response-n Figure 4. Multiple-Proxy Architecture for DRM Service In the Multiple-Proxy DRM Architecture, if the Proxy Device can not apply for service to the Service Server directly either, it can forward the Request to the next Proxy Device. On the return way, the Response will be delivered back one by one to the Request Device. The Trust Architecture for Multiple-Proxy DRM Service is shown in Figure 5 below. Certificate-A Certificate-A + Certificate-1 + + +---------+ Authorization +---------+ Authorization +---------+ |Request | -------------->|Proxy | ...................>|Proxy | |Device A |<-------------- |Device-1 |<....................|Device-n | +---------+ DRM Response +---------+ Proxy +---------+ DRM Response-1 | | | | | | Certificate-A | | + ...... | | + Certificate-n | | +-------+ + Authorization | | |Service|--------------------------+ | |Server |----------------------------+ +-------+ Proxy DRM Response-n Figure 5. Trust Architecture for Multiple-Proxy DRM Service Zhou & Chen Expires April 24, 2010 [Page 13] Internet-Draft October 2009 In the Trust Architecture for the Multiple-Proxy DRM Service, the certificates and authorization SHOULD be relayed until to the Service Server. If in one step, the verification of certificates and Authorization is not successful, the trusted relationship chain between the Request Device and the Service Server can not be built up. Hence the proxy service will not be available for the Request Device. 9. 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 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 the Request Device to the Service Server to ensure that 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] . 10. IANA Considerations This document requires no actions from IANA. Zhou & Chen Expires April 24, 2010 [Page 14] Internet-Draft October 2009 11. 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 debates and discussions help me much and will remain in my mind forever. Wish all of us big success in the future. 12. 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". [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 (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. Authors' Addresses 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 & Chen Expires April 24, 2010 [Page 15] Internet-Draft October 2009 Ge Chen China Telecom 109 West Zhongshan Ave, Tianhe District Guangzhou, Guangdong Province 510630 P.R.China Phone: +86-20-38639766 Email: cheng@gsta.com Zhou & Chen Expires April 24, 2010 [Page 16]