| Intarea Working Group | M. Cheng |
| Internet-Draft | F. Feng |
| Intended status: Standards Track | BII Group Holdings Ltd. |
| Expires: November 08, 2014 | May 07, 2014 |
Security for Ubiquitous Green Community Control Network
draft-cheng-intarea-ugccnet-security-00
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.
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 November 08, 2014.
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 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.
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 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.
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].
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
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.
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.
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).
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).
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).
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 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.
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.
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.
Access Control Manager (ACM) compares the access control list. ACM returns accept or denial for each requests.
Funding for the RFC Editor function is currently provided by BII Group.
| [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. |