Internet Engineering Task Force Z. Cao Internet-Draft H. Deng Intended status: Informational J. Zhu Expires: September 3, 2012 China Mobile March 2, 2012 The Architecture of Open Security Capability draft-cao-open-sec-00 Abstract This position paper introduces an architecture of opening the operator's security capability to third party smart object applications. With this architecture, the authentication, integrity and encryption capabilities can be wrapped up as Application Programming Interfaces and provided to third party application developers. So the third party applications do not have to spare energy on these basic security functionalities. As a consequence, the barrier for new applications is lowered, and it avoids the need of providing security by multiple applications and hence saves the computing and communication resources on constrained nodes. Note: This document is submitted for the IAB Workshop on Smart Object Security on March 23, 2012, Paris. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 3, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Cao, et al. Expires September 3, 2012 [Page 1] Internet-Draft Open Sec Arch March 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Capability Opening Architecture . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4. Informative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Cao, et al. Expires September 3, 2012 [Page 2] Internet-Draft Open Sec Arch March 2012 1. Introduction The trend of opening telecommunication capability is obvious. There are many activities in the direction of opening voice, paging, SMS, localization capabilities to third parties. Both the operator and application developers benefit from this. First of all, the barrier for new application developers is lowered down. Secondly, end users can enjoy the diversity of applications, both for communication and entertainment. What's more, the operator can cultivated the developers' society, building up a mature industrial. This is a win- win situation. Security capabilities can also be opened to third party applications. While developing their own security services such as authentication, integrity, and encryption, the application developers should do much work and these efforts are sometimes difficult to deploy. The credential provisioning, the limit caused by the constrained device platform, and the overhead of security protocols are both problems that third party applications will encounter when they want to provide the security service. However, the operator's smart objects or M2M devices have already been embedded with credentials (SIM card or certificates), and the operator has network-side authentication platform for user authentication and key management. In the open capability architecture, the third party applications could invoke the APIs for authentication, key management, and message integrity and confidentiality. It will greatly benefit the industrial chain. 2. Security Capability Opening Architecture This section introduced the open security capability architecture, as depicted in Figure 1. The operator controlled module is a component provided and controlled by the operator. It contains a security module, which includes authentication module, but also contains a group of security features that provides key derivation, integrity, confidentiality and any other possible security features. The operator controlled network side security platform is an entity that handles authentication, integrity and encryption keys management, for example, the existing HLR (Home Locator Registry) or AAA server, or other integrated platforms. The ways of opening security capabilities to third party applications can include, but not limited to the following items. Cao, et al. Expires September 3, 2012 [Page 3] Internet-Draft Open Sec Arch March 2012 o Authentication. The operator controlled module can open an API for authentication to the 3rd party application platform based on some authorization methods. After invocation of this API, the operator controlled network-side security platform will give feedback by a success or failure message, by invoking callback functions with the 3rd Party Platfom. o Key distribution. After authentication, shared keys or group keys are shared between the two end of operator controlled module or operator controlled security platform. Third party applications and their platform could derive their shared keys with the device based on the network side shared keys using the open APIs. [3GPP.33.220]has similar design. o Information Integrity and Confidentiality. The 3rd party application can delegate some security integrity and confidentiality protection to the network layer. Operator controlled modules can delegate the security computing tasks from the third party applications and platforms. For example, the module can generate a message authentication code (MAC) or the encrypted counterpart for communication needs. +--------------------+ +--------------------+ | 3rd Party APPs | | 3rd Party Platform | +--------------------+ +--------------------+ | | | | | | | API API API API API or Callback | | | | | | | +---------------------+ +-------------------------------+ | Operator Controlled |========| Operator Controlled | | Module on M2M Dev |========|Network-side Security Platform | +---------------------+ +-------------------------------+ Note: Authentication capability of the API needs to be very careful. SIM card based authentication can only be invoked based on operator authorization Figure 1: Open Security Architecture With this architecture, the applications do not have to design their own security protocols and providing security services. All the security computings can be based on the operator's module, and interfaces between the security platforms and 3rd party platforms. The pain of credential provisioning, key management, encryption and authentication in the application layer can go away. Cao, et al. Expires September 3, 2012 [Page 4] Internet-Draft Open Sec Arch March 2012 3. Security Considerations The trust relationship between the operator and third party applications is the key to the success of this architecture. For authentication, the 3rd party application should assume the one authenticated by the operator platform is also trusted by itself. If this trust is broken or attacked, since the operators security capability has been opened by the API, then it could be abused by the attackers, they can know very well about the operators security capability and pry into the security parameters. So this usage of the open security capability by the 3rd party must be authorized by the operators Further considerations of secure delegation will be discussed in future. 4. Informative References [3GPP.33.220] 3GPP, "Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA)", 3GPP TS 33.220 10.0.0, October 2010. Authors' Addresses Zhen Cao China Mobile Xuanwumenxi Ave No.32 Beijing, 100053 China Phone: Email: zehn.cao@gmail.com, caozhen@chinamobile.com Hui Deng China Mobile Xuanwumenxi Ave No.32 Beijing, 100053 China Phone: Fax: Email: denghui@chinamobile.com URI: Cao, et al. Expires September 3, 2012 [Page 5] Internet-Draft Open Sec Arch March 2012 Judy Zhu China Mobile Xuanwumenxi Ave No.32 Beijing, 100053 China Phone: Fax: Email: zhuhongru@chinamobile.com URI: Cao, et al. Expires September 3, 2012 [Page 6]