Internet DRAFT - draft-cheng-intarea-ugccnet-security
draft-cheng-intarea-ugccnet-security
Intarea Working Group M. Cheng
Internet-Draft F. Feng
Intended status: Standards Track BII Group Holdings Ltd.
Expires: October 26, 2014 April 24, 2014
Security for Ubiquitous Green Community Control Network
draft-cheng-intarea-ugccnet-security-00
Abstract
This document describes enhanced security management function for the
protocol defined in "Ubiquitous Green Community Control Network",
specifies security requirements, defines system security
architecture, gives a standardized description of authentication,
authorization, along with security procedures and protocols. This
standard can avoid unintended data disclosure to the public and
unauthorized access to resources, while providing enhanced integrity
and confidentiality of transmitted data in the ubiquitous green
community control network.
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 October 26, 2014.
Copyright Notice
Copyright (c) 2014 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
(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
Cheng & Feng Expires October 26, 2014 [Page 1]
Internet-Draft UGCC Network Security April 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
3. Security Requirements . . . . . . . . . . . . . . . . . . . . 3
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Architecture . . . . . . . . . . . . . . . . . . . . 5
5.1. System Architecture . . . . . . . . . . . . . . . . . . . 5
5.2. Initiator and responder . . . . . . . . . . . . . . . . . 6
5.3. Identifier . . . . . . . . . . . . . . . . . . . . . . . 6
6. AAA Function Definition . . . . . . . . . . . . . . . . . . . 7
6.1. TLS Configuration Manager(TCM) . . . . . . . . . . . . . 7
6.2. Authentication Manager(AM) . . . . . . . . . . . . . . . 7
6.3. Access Control Manager(ACM) . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
This document describes enhanced security management function for the
protocol defined in "Ubiquitous Green Community Control Network"
(UGCCNet), specifies security requirements, defines system security
architecture, gives a standardized description of authentication,
authorization,along with security procedures and protocols. This
standard can avoid unintended data disclosure to the public and
unauthorized access to resources, while providing enhanced integrity
and confidentiality of transmitted data in the ubiquitous green
community control network.
The purpose of this standard is to define a security management
function in the ubiquitous green community control network that
provides an interoperable, high quality and secure applications
operation platform. As an open system, ubiquitous green community
control network assumes multi-domain operation and public access from
other system components.
This specification defines the architecture and framework that
provides security for UGCCNet systems. As an interactive monitoring
and control system based on sensor-actuator networks, UGCCNet systems
without security suffer from some potential security threats.
Unintended users or systems may capture sensor readings and control
HVAC or lights easily;Information exchanged and data stored may be
Cheng & Feng Expires October 26, 2014 [Page 2]
Internet-Draft UGCC Network Security April 2014
overwritten by unauthorized users or components. This document
specifies a security framework to protect the message exchange path
of both data plane and control plane of UGCCNet system from such
security threats, providing mutual authentication, access control,
message integrity, data confidentiality and so on.
UGCCNet protocol is bound to SOAP and normally takes HTTP for the
transportation of its SOAP messages. To meet the security
requirements and protect from security threats, HTTP over TLS (HTTPS)
shall be adopted. This is because HTTPS has been widely used, and
can satisfy the security requirements with small implementation cost.
2. Terminology and Conventions
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].
o access control: The means to allow authorized entry and usage of
resources.
o Access control: The prevention of unauthorized use of a resource,
including the prevention of use of a resource in an unauthorized
manner.
o Confidentiality: The property that information is not made
available or disclosed to unauthorized individuals, entities, or
processes.
o Data integrity: The property that data has not been altered or
destroyed in an unauthorized manner without detection or
awareness.
o Digital signature: Data appended to, or a cryptographic
transformation of, a data unit that allows a recipient of the data
unit to verify the source and integrity of the data unit and
protect against forgery.
3. Security Requirements
a) Comprehensive security protection
The security defined in this standard should cover all functions and
procedures in UGCCNet, including information retrieval, information
storage, information transmission, integrated utilization of
information, remote control, registration and so on.
b) High-efficient with low-cost
Cheng & Feng Expires October 26, 2014 [Page 3]
Internet-Draft UGCC Network Security April 2014
The security methods and protocols defined in this document shall
limit the additional time cost, communication resources consumption
and computational resources consumption within a reasonable and
acceptable range.
c) Confidentiality of the UGCCNet exchanging message
Confidentiality is the security service that protects data from
unauthorized disclosure. The goal is to protect information from
passive threat.
d) Integrity of UGCCNet exchanging message
Integrity means to protect information, data and other resources from
being unintentionally altered during the transmission procedures.
Besides, all modifications to data should be detectable. The purpose
is to improve accuracy and completeness for information and
corresponding processing methods, protecting information from active
threat.
e) Access control of components
Access control provides the capability to verify access right to a
certain resource from a certain component. UGCCNet security shall
deal with the access control for pointIDs in UGCCNet components to
which other UGCCNet components can access.
f) Mutual authentication between components
A pair of requester and responder is called "peers". Mutual
authentication enables both peers to authenticate each other.
UGCCNet security shall enable a client to connect to the intended
server (e.g. Storage), and a server to know which client (e.g. APP)
is connected. This allows them to protect from miss-sending or miss-
receiving UGCCNet messages between a malicious or unintended UGCCNet
component. In some cases, the server may allow the clients to access
to some data with no authentication. Furthermore, the client may
also not need to authenticate the server. The UGCCNet security
allows those cases by the configuration.
g) Scalable authentication and access control mechanisms
UGCCNet Security shall be applied into various types of UGCCNet
system because the UGCCNet would be used in wide varieties of system
scalability, and in several types of management formation. Even when
an UGCCNet system deploys millions of devices, the authentication and
access control mechanisms shall scale easily.
Cheng & Feng Expires October 26, 2014 [Page 4]
Internet-Draft UGCC Network Security April 2014
4. Design Principles
a) Reuse existing technologies
Applications of standardized and widely-used security technologies
are adopted. UGCCNet security can inherit the basic properties by
using standard interfaces and software libraries. Since UGCCNet is
designed over HTTP, this standard employs TLS-based HTTP(HTTPS). TLS
is widely used for mutual authentication, data integrity and
confidentiality. By adopting HTTPS, UGCCNet can easily take these
properties. To satisfy authentication requirement, X.509 is employed
in this standard. This is because X.509 is widely deployed and TLS
can handle it.
b) Separate Certificate Management and Access Control Management
Functionality
In order to meet the requirement of scalability of UGCCNet security,
Certificate Management and Access Control Management are separated as
independent function in this standard.
c) Compatibility
The security architecture should introduce modification to UGCCNet
architecture and functional entities as less as possible.
5. Security Architecture
5.1. System Architecture
The goal of UGCCNet security system is to protect an UGCCNet system
against security threats.UGCCNet system takes TLS (HTTPS instead of
plain HTTP) to protect the communication among components and
registries. UGCCNet system shall be cognizant of application
requirements before initiating TLS procedure. Components and
registries should have a certificate to identify their identifiers
over the TLS connection.
The components (APP, Storage and GW) and the registry are typically
defined in UGCCNet. AAA Function has three functionalities: TLS
Configuration Manager (TCM), Authentication Manager (AM) and Access
Control Manager (ACM).
TCM manages and maintains TLS parameters configuration depending on
application requirements. TCM enforces some TLS configuration such
as encryption algorithms, key length and so on (CipherSuite
parameters).
Cheng & Feng Expires October 26, 2014 [Page 5]
Internet-Draft UGCC Network Security April 2014
AM has two functions: Certificate Verification (CV) and Identifier
Verification (IV). CV checks the certificate posted from TLS Client
or TLS Server, and provides the answer whether the certificate is
trustable or not. CV verifies the certificate based on the list of
trust anchors pre-installed in itself. IV handles peer
authentication.
ACM replies whether the connected TLS Client has the access rights to
the requested resources (e.g., methods and points) or not. The
policy of access control is managed here, usually in the form of pre-
configured access control list (ACL).
5.2. Initiator and responder
UGCCNet defines components and registries as the communication
entities. However, from the point of security, the implementers
should be aware of the direction of communication rather than the
role of entities. Therefore, the entities should be classified based
on the direction of the communication and their roles within the
secure communication procedure. This specification introduces the
new terms of "Initiator" and "Responder" to describe security-
enabled UGCCNet entities. This concept corresponds to "TLS Client"
and "TLS Server" defined in the TLS specification (RFC5246).
5.3. Identifier
Assign identifier for UGCCNet entities: An original UGCCNet component
or registry (hereafter, referred simply as "entity") itself does not
have an identifier -- it only has an access URI to address in the
Internet space. In the context of the UGCCNet security, each
component and registry must have an identifier (ID) to identify
itself for authentication with each other, and to enable access
control of the peer at the server side. This specification defines
the following rules to assign an ID for each UGCCNet entity.
Initiator and responder shall contain only one UGCCNet component or
registry.
Initiator or responder shall have a globally unique name and put
their name in subject alternative name (SAN) section in X.509
certificate format (RFC 5280 section 4.2.1.6). This globally unique
name is an identifier.
Format of Subject Alternative Name (SAN):(1)Host-Role Certificate:
Host-role certificate shall have either a FQDN-formatted identifier
[ref: RFC1035] or IPv4 address [ref: RFC791] or IPv6 address [ref:
RFC2460]. The identifier is stored in their sole SAN (i.e., type:2-
dNSName [ref: RFC5280 section 4.2.1.6]). The access URI of the
Cheng & Feng Expires October 26, 2014 [Page 6]
Internet-Draft UGCC Network Security April 2014
Responder shall contain the FQDN or IP address. In addition, if the
dentifier uses FQDN format, it shall be resolved by some name
resolution systems, typically by the domain name system (DNS).(2
)Client-Role Certificate: Client-Role Certificate shall have an E
-mail-formatted identifier [ref: RFC5322 Section 3.4.1] and stores
the ID in their sole SAN (i.e., type:1 - rfc822Name [ref: RFC2459
section 4.2.1.7]). The e-mail address does not have to be reachable
(as an e-mail address).
"Anonymous" Identifier:If a component cannot be identified, the
component can be handled as a component that has the identifier
"anonymous". In other words, identifier "anonymous" is reserved and
shall not intentionally assigned to any components.
6. AAA Function Definition
6.1. TLS Configuration Manager(TCM)
TLS Configuration Manager (TCM) manages TLS configurable connection
parameters. For example, TCM may enforce to use a specific
encryption algorithm that will be used for any connections or a
specific connection that is categorized by peer identifiers or Access
URI and so on.
TCM shall provide two functions: for initiators (TLS Client), TCM
provides candidate TLS parameter suites. While for responders (TLS
Server), TCM allows or rejects a given parameter suites from the
communication peer initiator (TLS Client).
TCM may provide a function that returns a connection parameters for a
given peer identifier of a domain name or an IP address.
6.2. Authentication Manager(AM)
Authentication Manager (AM) shall provide at least two functions:(1)
Certificate Verification (CV) and (2) Identifier Verification (IV).
CV allows an initiator or responder to check whether a given
certificate from the remote peer is valid or not. The fundamental
behavior for this certificate verification should be guided by
RFC5280. The role of IV is the identification of the responder:
i.e., for an initiator to guarantee that it is connecting the correct
peer.
6.3. Access Control Manager(ACM)
Access Control Manager (ACM) compares the access control list. ACM
returns accept or denial for each requests.
Cheng & Feng Expires October 26, 2014 [Page 7]
Internet-Draft UGCC Network Security April 2014
7. Acknowledgements
Funding for the RFC Editor function is currently provided by BII
Group.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
[RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate
Status Protocol Algorithm Agility", RFC 6277, June 2011.
Authors' Addresses
Mike Cheng
BII Group Holdings Ltd.
Beijing
P. R. China
Email: mikecheng@biigroup.com
Frankey Feng
BII Group Holdings Ltd.
Beijing
P. R. China
Email: gfeng@biigroup.cn
Cheng & Feng Expires October 26, 2014 [Page 8]
