Internet DRAFT - draft-li-ugccnet-security

draft-li-ugccnet-security







Network Working Group                                              F. Li
Internet-Draft                                                   Z. Zhou
Intended status: Standards Track      PetroChina Huabei Oilfield Company
Expires: May 22, 2016                                           L. Jiang
                                                                 Y. Song
                                                 BII Group Holdings Ltd.
                                                       November 19, 2015


        Security for Ubiquitous Green Community Control Network
                      draft-li-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 May 22, 2016.

Copyright Notice

   Copyright (c) 2015 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



Li, et al.                Expires May 22, 2016                  [Page 1]

Internet-Draft            UGCC Network Security            November 2015


   (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  . . . . . . . . . . . . . . . . . . . . . . . .   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) . . . . . . . . . . . . . . .   8
   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



Li, et al.                Expires May 22, 2016                  [Page 2]

Internet-Draft            UGCC Network Security            November 2015


   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.

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




Li, et al.                Expires May 22, 2016                  [Page 3]

Internet-Draft            UGCC Network Security            November 2015


   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





Li, et al.                Expires May 22, 2016                  [Page 4]

Internet-Draft            UGCC Network Security            November 2015


   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.

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).



Li, et al.                Expires May 22, 2016                  [Page 5]

Internet-Draft            UGCC Network Security            November 2015


   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).

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.




Li, et al.                Expires May 22, 2016                  [Page 6]

Internet-Draft            UGCC Network Security            November 2015


   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.

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.




Li, et al.                Expires May 22, 2016                  [Page 7]

Internet-Draft            UGCC Network Security            November 2015


6.3.  Access Control Manager(ACM)

   Access Control Manager (ACM) compares the access control list.  ACM
   returns accept or denial for each requests.

7.  Acknowledgements

   Funding for the RFC Editor function is currently provided by
   PetroChina Huabei Oilfield Company and BII Group.

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [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, DOI 10.17487/RFC5280, May 2008,
              <http://www.rfc-editor.org/info/rfc5280>.

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,
              <http://www.rfc-editor.org/info/rfc6066>.

   [RFC6277]  Santesson, S. and P. Hallam-Baker, "Online Certificate
              Status Protocol Algorithm Agility", RFC 6277,
              DOI 10.17487/RFC6277, June 2011,
              <http://www.rfc-editor.org/info/rfc6277>.

Authors' Addresses

   Fengmin Li
   PetroChina Huabei Oilfield Company
   Renqiu
   P. R. China

   Email: wty_lfm@petrochina.com.cn





Li, et al.                Expires May 22, 2016                  [Page 8]

Internet-Draft            UGCC Network Security            November 2015


   Zhimin Zhou
   PetroChina Huabei Oilfield Company
   Renqiu
   P. R. China

   Email: tx_zhm@petrochina.com.cn


   Lianshan Jiang
   BII Group Holdings Ltd.
   Beijing
   P. R. China

   Email: lsjiang@biigroup.cn


   Yang Song
   BII Group Holdings Ltd.
   Beijing
   P. R. China

   Email: ysong@biigroup.cn





























Li, et al.                Expires May 22, 2016                  [Page 9]