Internet DRAFT - draft-cao-open-sec
draft-cao-open-sec
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]