BS Iso Iec Ieee 18883-2016

BS ISO/IEC/IEEE 18883:2016
BSI Standards Publication
Information technology —
Ubiquitous green community
control network — Security
BS ISO/IEC/IEEE 18883:2016 BRITISH STANDARD
National foreword
This British Standard is the UK implementation of ISO/IEC/IEEE
18883:2016.
The UK participation in its preparation was entrusted to Technical
Committee IST/6, Data communications.
A list of organizations represented on this committee can be
obtained on request to its secretary.
This publication does not purport to include all the necessary
provisions of a contract. Users are responsible for its correct
application.
© The British Standards Institution 2016.
Published by BSI Standards Limited 2016
ISBN 978 0 580 92014 1
ICS 35.110
Compliance with a British Standard cannot confer immunity from
legal obligations.
This British Standard was published under the authority of the
Standards Policy and Strategy Committee on 30 April 2016.
Amendments/corrigenda issued since publication
Date Text affected
INTERNATIONAL ISO/IEC/
STANDARD IEEE
18883
First edition
2016-04-15
Information technology — Ubiquitous

green community control network —
Security
Technologies de l'information — Protocole de contrôle de la
communauté verte omniprésente —Sécurité
Reference number
ISO/IEC/IEEE 18883:2016(E)
© IEEE 2013
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. Neither the ISO Central
Secretariat nor IEEE accepts any liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies
and IEEE members. In the unlikely event that a problem relating to it is found, please inform the ISO Central Secretariat or IEEE at the
address given below.
COPYRIGHT PROTECTED DOCUMENT
© IEEE 2013
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO or IEEE at the respective
address below.
ISO copyright office IE Central Office
IEC Institute of Electrical and
Case postale 56  CH-1211 Geneva 20 3, rue de Varembé Electronics Engineers, Inc.
Tel. + 41 22 749 01 11 CH-1211 Geneva 20 3 Park Avenue, New York
Fax + 41 22 749 09 47 Switzerland NY 10016-5997, USA
E-mail copyright@iso.org E-mail
E- inmail@iec. E-mail stds.ipr@ieee.org
Web www.iso.org Web www.iec.ch Web www.ieee.org
Published in Switzerland
ii © IEEE 2013 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international organizations, governmental and non-
governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO
and IEC have established a joint technical committee, ISO/IEC JTC 1.
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards
through a consensus development process, approved by the American National Standards Institute, which
brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers
are not necessarily members of the Institute and serve without compensation. While the IEEE administers the
process and establishes rules to promote fairness in the consensus development process, the IEEE does not
independently evaluate, test, or verify the accuracy of any of the information contained in its standards.
The main task of ISO/IEC JTC 1 is to prepare International Standards. Draft International Standards adopted
by the joint technical committee are circulated to national bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is called to the possibility that implementation of this standard may require the use of subject matter
covered by patent rights. By publication of this standard, no position is taken with respect to the existence or
validity of any patent rights in connection therewith. ISO/IEEE is not responsible for identifying essential
patents or patent claims for which a license may be required, for conducting inquiries into the legal validity or
scope of patents or patent claims or determining whether any licensing terms or conditions provided in
connection with submission of a Letter of Assurance or a Patent Statement and Licensing Declaration Form, if
any, or in any licensing agreements are reasonable or non-discriminatory. Users of this standard are expressly
advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is
entirely their own responsibility. Further information may be obtained from ISO or the IEEE Standards
Association.
ISO/IEC/IEEE 18883 was prepared by the Corporate Advisory Group of the IEEE-SA Board of Governors (as
IEEE 1888.3-2013). It was adopted by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 6, Telecommunications and information exchange between systems, in parallel with its
approval by the ISO/IEC national bodies, under the “fast-track procedure” defined in the Partner Standards
Development Organization cooperation agreement between ISO and IEEE. IEEE is responsible for the
maintenance of this document with participation and input from ISO/IEC national bodies.
© IEEE 2013 – All rights reserved iii

IEEE Standard for Ubiquitous Green

Community Control Network: Security
IEEE-SA Board of Governors
Sponsored by the
Corporate Advisory Group
IEEE
3 Park Avenue IEEE Std 1888.3™-2013
New York, NY 10016-5997
USA
ISO/IEC/IEEE
IEEE 18883:2016(E)
Std 1888.3™-2013
IEEE Std 1888.3™-2013

Sponsor
Corporate Advisory Group

of the
IEEE-SA Board of Governors
Approved 31 October 2013
IEEE-SA Standards Board
© IEEE 2013 – All rights reserved

Abstract: The enhanced security management function for the protocol defined in IEEE 1888™,
“Ubiquitous Green Community Control Network Protocol,” is described in this standard. Security
requirements, system security architecture definitions, and a standardized description of
authentication and authorization, along with security procedures and protocols, are specified. This
standard can help 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.
Keywords: access control, authorization, certificate, confidentiality, IEEE 1888™,

IEEE 1888.3™, integrity, mutual authentication, security
The Institute of Electrical and Electronics Engineers, Inc.

3 Park Avenue, New York, NY 10016-5997, USA
Copyright © 2013 by The Institute of Electrical and Electronics Engineers, Inc.

All rights reserved. Published 6 December 2013. Printed in the United States of America.
IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics
Engineers, Incorporated.
PDF: ISBN 978-0-7381-8725-9 STD98436

Print: ISBN 978-0-7381-8726-6 STDPD98436
IEEE prohibits discrimination, harassment, and bullying.

For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission
of the publisher.

ISO/IEC/IEEE
IEEE 18883:2016(E)
Std 1888.3™-2013
IEEE Std 1888.3™-2013
Important Notices and Disclaimers Concerning IEEE Standards Documents

IEEE documents are made available for use subject to important notices and legal disclaimers. These
notices and disclaimers, or a reference to this page, appear in all standards and may be found under the
heading “Important Notice” or “Important Notices and Disclaimers Concerning IEEE Standards
Documents.”
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards
Documents
IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use, are
developed within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards
Association (“IEEE-SA”) Standards Board. IEEE (“the Institute”) develops its standards through a
consensus development process, approved by the American National Standards Institute (“ANSI”), which
brings together volunteers representing varied viewpoints and interests to achieve the final product.
Volunteers are not necessarily members of the Institute and participate without compensation from IEEE.
While IEEE administers the process and establishes rules to promote fairness in the consensus development
process, IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the
soundness of any judgments contained in its standards.
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and
expressly disclaims all warranties (express, implied and statutory) not included in this or any other
document relating to the standard, including, but not limited to, the warranties of: merchantability; fitness
for a particular purpose; non-infringement; and quality, accuracy, effectiveness, currency, or completeness
of material. In addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effort.
IEEE standards documents are supplied “AS IS” and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related
to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved
and issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any
other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his
or her own independent judgment in the exercise of reasonable care in any given circumstances or, as
appropriate, seek the advice of a competent professional in determining the appropriateness of a given
IEEE standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO:
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE
UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND
REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
Translations
The IEEE consensus development process involves the review of documents in English only. In the event
that an IEEE standard is translated, only the English version published by IEEE should be considered the
approved IEEE standard.

Official statements
A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board
Operations Manual shall not be considered or inferred to be the official position of IEEE or any of its
committees and shall not be considered to be, or be relied upon as, a formal position of IEEE. At lectures,
symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall
make it clear that his or her views should be considered the personal views of that individual rather than the
formal position of IEEE.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of
membership affiliation with IEEE. However, IEEE does not provide consulting information or advice
pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a
proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a
consensus of concerned interests, it is important that any responses to comments and questions also receive
the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and
Standards Coordinating Committees are not able to provide an instant response to comments or questions
except in those cases where the matter has previously been addressed. For the same reason, IEEE does not
respond to interpretation requests. Any person who would like to participate in revisions to an IEEE
standard is welcome to join the relevant IEEE working group.
Comments on standards should be submitted to the following address:
Secretary, IEEE-SA Standards Board

445 Hoes Lane
Piscataway, NJ 08854 USA
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with
the provisions of any IEEE Standards document does not imply compliance to any applicable regulatory
requirements. Implementers of the standard are responsible for observing or referring to the applicable
regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not
in compliance with applicable laws, and these documents may not be construed as doing so.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws.
They are made available by IEEE and are adopted for a wide variety of both public and private uses. These
include both use, by reference, in laws and regulations, and use in private self-regulation, standardization,
and the promotion of engineering practices and methods. By making these documents available for use and
adoption by public authorities and private users, IEEE does not waive any rights in copyright to the
documents.
Photocopies
Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to
photocopy portions of any individual standard for company or organizational internal use or individual,
non-commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance
Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission
to photocopy portions of any individual standard for educational classroom use can also be obtained
through the Copyright Clearance Center.

ISO/IEC/IEEE
IEEE 18883:2016(E)
Std 1888.3™-2013
IEEE Std 1888.3™-2013
Updating of IEEE Standards documents

Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every ten years. When a document is more than ten
years old and has not undergone a revision process, it is reasonable to conclude that its contents, although
still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to
determine that they have the latest edition of any IEEE standard.
In order to determine whether a given document is the current edition and whether it has been amended
through the issuance of amendments, corrigenda, or errata, visit the IEEE-SA Website at
http://ieeexplore.ieee.org/xpl/standards.jsp or contact IEEE at the address listed previously. For more
information about the IEEE SA or IEEE’s standards development process, visit the IEEE-SA Website at
http://standards.ieee.org.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE-SA Website at the following URL:
http://standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata
periodically.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to
the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant
has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the
IEEE-SA Website at http://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may
indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without
compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of
any unfair discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
responsible for identifying Essential Patent Claims for which a license may be required, for conducting
inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or
conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing
agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely
their own responsibility. Further information may be obtained from the IEEE Standards Association.

Participants
At the time this IEEE standard was completed, the UGCCNet-SEC Working Group had the following
membership:
Dong Liu, Chair

Wenjie Li, Vice Chair
Beijing Jiaotong University Cisco Systems Inc. Raisecom Technology Co., Ltd
BII Group Holdings Ltd. Intel Corporation The University of Tokyo
China Telecommunications Qingdao Gaoxiao Information
Corporation Industry Co., Ltd.
The P1888.3 Working Group gratefully acknowledges the contributions of the following participants.
Without their assistance and dedication, this standard would not have been completed.
Changhe Du Huiling Zhao Shoichi Sakane

Chen Gu Lianshan Jiang Shuai Gao
Dong Liu Masahiro Ishiyama Tsuyoshi Momose
Guoquan Tan Ming Feng Wenjie Li
Hideya Ochiai Ming Qiu Wenjie Ma
Hiroshi Esaki Ning Zou Xiaochuan Gu
Hongke Zhang Yan He
The following members of the entity balloting committee voted on this standard. Balloters may have voted
for approval, disapproval, or abstention.
Beijing Jiaotong University Cisco Systems, Inc. NXP Semiconductors

BII Group Holdings Ltd. Intel Corporation Qingdao Gaoxiao Information
China Datang Corporation Marvell Semiconductor, Inc. Industry Co. Ltd.
China Telecommunications Nippon Telegraph and Raisecom Technology Co., Ltd.
Corporation Telephone Corporation (NTT) The University of Tokyo
When the IEEE-SA Standards Board approved this standard on 31 October 2013, it had the following
membership:
John Kulick, Chair

David J. Law, Vice Chair
Richard H. Hulett, Past Chair
Konstantinos Karachalios, Secretary
Masayuki Ariyoshi Mark Halpin Ron Petersen

Peter Balma Gary Hoffman Gary Robinson
Farooq Bari Paul Houzé Jon Walter Rosdahl
Ted Burse Jim Hughes Adrian Stephens
Wael William Diab Michael Janezic Peter Sutherland
Stephen Dukes Joseph L. Koepfinger* Yatin Trivedi
Jean-Philippe Faure Oleg Logvinov Phil Winston
Alexander Gelman Yu Yuan
*Member Emeritus
vi
Copyright © 2013 IEEE. All rights reserved.

ISO/IEC/IEEE
IEEE 18883:2016(E)
Std 1888.3™-2013
IEEE Std 1888.3™-2013
Also included are the following nonvoting IEEE-SA Standards Board liaisons:
Richard DeBlasio, DOE Representative

Michael Janezic, NIST Representative
Patrick Gibbons
IEEE Standards Program Manager, Document Development
Krista Gluchoski
IEEE Project Specialist, Professional Services
Joan Woolery
IEEE Standards Program Manager, Technical Program Development
vii

Introduction
This introduction is not part of IEEE Std 1888.3-2013, IEEE Standard for Ubiquitous Green Community Control
Network: Security.
This standard describes the enhanced security management function for the protocol defined in IEEE Std
1888™, IEEE Standard for Ubiquitous Green Community Control Network Protocol, specifies security
requirements, defines system security architecture, gives a standardized description of authentication and
authorization, along with security procedures and protocols. This standard can help 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, a ubiquitous green community control network assumes multi-domain
operation and public access from other system components. In this context, security considerations are
needed for operation of the IEEE 1888 protocol.
This specification defines the architecture and framework that provides security for IEEE 1888 systems. As
an interactive monitoring and control system based on sensor-actuator networks, IEEE 1888 systems
without security suffer from some potential security threats. For example, unintended users or systems may
capture sensor readings and control HVAC or lights easily, or information exchanged and data stored may
be overwritten by unauthorized users or components. This standard specifies a security framework to
protect the message exchange path of both the data plane and the control plane of an IEEE 1888 system
from such security threats, providing mutual authentication, access control, message integrity, data
confidentiality, and so on.
The IEEE 1888 protocol is bound to simple object access protocol (SOAP) and normally takes hypertext
transfer protocol (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.
This document distinguishes system reliability issues from security issues. For example, service tolerance
against heavy requests from clients and communication tolerance against temporal physical link failure are
out of the scope of this document.
This document is organized as follows:
 Clause 4 specifies security requirements and design principles.

 Clause 5 describes security system architecture.
 Clause 6 defines security protocols, including communication sequence, software interface, and
identifier (ID) system.
viii

ISO/IEC/IEEE
IEEE 18883:2016(E)
Std 1888.3™-2013
IEEE Std 1888.3™-2013
Contents
1. Overview .................................................................................................................................................... 1
1.1 Scope ................................................................................................................................................... 1
1.2 Purpose ................................................................................................................................................ 1
2. References .................................................................................................................................................. 2
2.1 Normative references ........................................................................................................................... 2
2.2 Additional References ......................................................................................................................... 2
3. Definitions, abbreviations, and acronyms .................................................................................................. 3

3.1 Definitions ........................................................................................................................................... 3
3.2 Abbreviations and acronyms ............................................................................................................... 3
4. Security requirements and design principles .............................................................................................. 4

4.1 Security issues overview...................................................................................................................... 4
4.2 Security requirements .......................................................................................................................... 6
4.3 Design principles ................................................................................................................................. 7
5. Security architecture ................................................................................................................................... 8

5.1 System architecture.............................................................................................................................. 8
5.2 Initiator and responder ......................................................................................................................... 9
5.3 Identifier .............................................................................................................................................. 9
6. Security protocols ......................................................................................................................................10

6.1 Communication sequence ...................................................................................................................10
6.2 Interface definition .............................................................................................................................11
6.3 Authentication, Authorization, and Accounting (AAA) Function definition .....................................14
6.4 Rejecting connection ..........................................................................................................................18
ix


ISO/IEC/IEEE
IEEE 18883:2016(E)
Std 1888.3™-2013
IEEE Std 1888.3™-2013

IMPORTANT NOTICE: IEEE Standards documents are not intended to ensure safety, security, health,
or environmental protection, or ensure against interference with or from other devices or networks.
Implementers of IEEE Standards documents are responsible for determining and complying with all
appropriate safety, security, environmental, health, and interference protection practices and all
applicable laws and regulations.
This IEEE document is made available for use subject to important notices and legal disclaimers.
These notices and disclaimers appear in all publications containing this document and may
be found under the heading “Important Notice” or “Important Notices and Disclaimers
Concerning IEEE Documents.” They can also be obtained on request from IEEE or viewed at
http://standards.ieee.org/IPR/disclaimers.html.
1. Overview
1.1 Scope
This specification provides security service enhancements for the protocol defined in IEEE Std 1888™ 1,
IEEE Standard for Ubiquitous Green Community Control Network Protocol. This standard describes
security requirements for the ubiquitous green community control network and specifies the system
security architecture along with security procedures and protocols.
1.2 Purpose
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. Use of this standard helps 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.
1
Information on references can be found in Clause 2.
1

IEEE Std 1888.3-2013

IEEE Standard for Ubiquitous Green Community Control Network: Security
2. References
2.1 Normative references
The following referenced documents are indispensable for the application of this document (i.e., they must
be understood and used, so each referenced document is cited in text and its relationship to this document is
explained). For dated references, only the edition cited applies. For undated references, the latest edition of
the referenced document (including any amendments or corrigenda) applies.
IEEE Std 1888™, IEEE Standard for Ubiquitous Green Community Control Network Protocol. 2, 3
RFC 791, Internet Protocol, J. Postel, Ed., September 1981. 4
RFC 1035, Domain Names—Implementation and Specification, P. Mockapetris, November 1987.
RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, R. Housley, W. Ford, W.
Polk, and D. Solo, January 1999.
RFC 2460, Internet Protocol, Version 6 (IPv6) Specification, S. Deering and R. Hinden, December 1998.
RFC 5246, The Transport Layer Security (TLS) Protocol, Version 1.2, T. Dierks and E. Rescorla, August
2008.
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile, D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, May 2008.
RFC 5322, Internet Message Format, P. Resnick, Ed., October 2008.
RFC 6066, Transport Layer Security (TLS) Extensions: Extension Definitions, D. Eastlake, III, January
2011.
2.2 Additional references
RFC 6277, “Online Certificate Status Protocol Algorithm Agility,” S. Santesson and P. Hallam-Baker, June
2011.
The OpenSSL Project website. 5
2
The IEEE standards or products referred to in this clause are trademarks of The Institute of Electrical and Electronics Engineers, Inc.
3
IEEE publications are available from The Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854,
USA (http://standards.ieee.org/).
4
IETF documents (i.e. RFCs) are available for download at http://www.rfc-archive.org/.
5
Available at: http://www.openssl.org/
2

ISO/IEC/IEEE
IEEE 18883:2016(E)
Std 1888.3™-2013
IEEE Std 1888.3-2013 IEEE Std 1888.3™-2013

3. Definitions, abbreviations, and acronyms
3.1 Definitions
For the purposes of this document, the following terms and definitions apply. The IEEE Standards
Dictionary Online should be consulted for terms not defined in this clause. 6
access control: The prevention of unauthorized use of a resource, including the prevention of use of a
resource in an unauthorized manner.
binding information: The association of the identifier (ID) of a client-role certificate of the responder
with an access uniform resource identifier (URI) for the responder along with the remaining lifetime of that
association.
confidentiality: The property that information is not made available or disclosed to unauthorized
individuals, entities, or processes.
data integrity: The property that data has not been altered or destroyed in an unauthorized manner without
detection or awareness.
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.2 Abbreviations and acronyms
AAA authentication, authorization, and accounting
ACL access control list
ACM access control manager
AM authentication manager
APP application
CA certificate authority
CV certificate verification
DNS domain-name system
DoS denial of service
DDoS distributed denial of service
FQDN fully qualified domain name
GW gateway
6
IEEE Standards Dictionary Online subscription is available at:
http://www.ieee.org/portal/innovate/products/standard/standards_dictionary.html.
3

IEEE Std 1888.3-2013

HTTP hypertext transfer protocol
HTTPS hypertext transfer protocol (HTTP) over transport layer security (TLS)
ID identifier
IP Internet protocol
IPv4 Internet Protocol Version 4
IPv6 Internet Protocol Version 6
IV identifier (ID) verification
Mal-APP malicious application (APP)
OCSP online certificate status protocol
SAN subject alternative name
SOAP simple object access protocol
TCM transport layer security (TLS) manager
TLS transport layer security
TTL time to live
UI user interface
URI uniform resource identifier
4. Security requirements and design principles
4.1 Security issues overview
In a typical IEEE 1888 system (shown in Figure 1), gateways (GWs) connecting sensors and actuators are
deployed distributed in multiple tenants. GWs upload data from sensors to local storage and remote storage
in the data center. The application (APP) components in the tenants can individually retrieve data from
local/remote storage and use them for their own purposes (data analysis, or data visualization, and so on).
APP components also submit commands to GWs for controlling actuators. As shown in Figure 1, APP1
and Storage1 can handle sensors/actuators attached to GW1. APP2 and Storage2 can handle
sensors/actuators attached to GW2. Remote APP5 can access Tenant1 with authority to handle
sensors/actuators attached to GW1.
4

ISO/IEC/IEEE
IEEE 18883:2016(E)
Std 1888.3™-2013
IEEE Std 1888.3-2013
IEEE
Std 1888.3™-2013
Figure 1 —Potential security threats in an IEEE 1888 system
As depicted in Figure 1, potential security threats in an IEEE 1888 system can be listed from Case A to
Case H:
Case A: A malicious APP (Mal-APP) may intentionally fetch data from GWs (FETCH) or submit
control commands to GWs (WRITE).
Case B: A Mal-APP may intentionally fetch data from remote/local storage (FETCH) or overwrite
data onto storage (WRITE).
Case C: An APP may unintentionally get data that are not bound to their users from GWs or
storage (FETCH). For example, APP2 may obtain data from GW1, which is not within the same
tenant .
Case D: An APP may control facilities beyond its authority (WRITE). For example, APP5 may
send commands to GW2, trying to control actuators connected to GW2.
Case E: Data saved in storage may be mistakenly overwritten by GWs or APPs. For example, data
saved in Storage2 may be overwritten by GW1 or APP5.
Case F: A GW may push data to a Mal-APP without knowing it is a Mal-APP, resulting in data
disclosure.
Case G: A wire tapper may capture communications between components in IEEE 1888 systems,
eavesdropping the status of facilities, application data, and so on.
Case H: An invader can alter messages exchanged among components, causing unintentional
behavior of facilities.
For a comprehensive IEEE 1888 system deployed and operated, the whole field of security is both complex
and far-reaching. Considering characteristics of IEEE 1888 system applications and mature security
protocols, some security issues are outside the scope of this specification, as follows:
5

IEEE Std 1888.3-2013

a) Physical security issues, such as cut wires, server and device destruction by physical attacks,
blackouts, and so on, shall be considered during the deployment and operational phase.
b) Leak of certificate key pairs shall be detected and renewed by other frameworks and protocols.
c) It is assumed that every entity possesses a certificate that is distributed and maintained in a
proper/secure manner. The assumptions are implemented by other frameworks and protocols.
d) The trust process of IEEE 1888 products shall be performed by IEEE 1888 system integrators in
case some products might be false when purchased.
e) This specification describes the approach to configure transport layer security (TLS) related
security parameters. However, different IEEE 1888 applications should define and describe the
contents of security policies on their own, such as mutual authentication or one-way authentication.
f) Denial of service (DoS) and distributed denial of service (DDoS) shall be detected and securely
processed by other mechanisms.
4.2 Security requirements
4.2.1 Comprehensive security protection
The security defined in this standard should cover all functions and procedures in the IEEE 1888 protocol,
including information retrieval, information storage, information transmission, integrated utilization of
information, remote control, registration, and so on.
4.2.2 High efficiency with low cost
The security methods and protocols defined in this standard shall limit the additional time cost,
communication resources consumption, and computational resources consumption within a reasonable and
acceptable range.
4.2.3 Confidentiality of the IEEE 1888 exchanging message
Confidentiality is the security service that protects data from unauthorized disclosure. The goal is to protect
information from passive threat.
4.2.4 Integrity of the IEEE 1888 exchanging message
Integrity means to protect information, data, and other resources from being unintentionally altered during
the transmission procedures. 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.
6

ISO/IEC/IEEE
IEEE 18883:2016(E)
Std 1888.3™-2013
IEEE Std 1888.3-2013
IEEE
Std 1888.3™-2013
4.2.5 Access control of components
Access control provides the capability to verify access right to a certain resource from a certain component.
IEEE 1888 security shall deal with the access control for pointIDs in IEEE 1888 components to which
other IEEE 1888 components have access.
4.2.6 Mutual authentication between components
Matched requesters and responders are called “peers.” Mutual authentication enables both peers to
authenticate each other. IEEE 1888 security shall help enable a client to connect to the intended server
(e.g., storage) and a server to know which client (e.g., an APP) is connected. This protects them from
mistakenly sending or receiving IEEE 1888 messages between a malicious or unintended IEEE 1888
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. IEEE 1888 security allows those cases
by its configuration.
4.2.7 Scalable authentication and access control mechanisms
IEEE 1888 security shall be applied to various types of IEEE 1888 systems because IEEE 1888 would be
used in wide varieties of system scalability and in several types of management formation. Even when an
IEEE 1888 system deploys millions of devices, the authentication and access control mechanisms shall
scale easily.
4.3 Design principles
4.3.1 Reuse existing technologies
Applications of standardized and widely used security technologies are adopted. IEEE 1888 security can
inherit the basic properties by using standard interfaces and software libraries. Since IEEE 1888 is designed
over hypertext transfer protocol (HTTP), this standard employs TLS-based HTTP (HTTPS). TLS is widely
used for mutual authentication, data integrity, and confidentiality. By adopting HTTPS, IEEE 1888 can
easily take these properties. To satisfy the authentication requirement, X.509 is employed in this standard.
This is because X.509 is widely deployed and TLS can handle it.
4.3.2 Separate certificate management and access control management functionality
In order to meet the scalability requirement of IEEE 1888 security, certificate management and access
control management are separated as independent functions in this standard.
4.3.3 Compatibility
The security architecture should introduce modifications to IEEE 1888 architecture and functional entities
as little as possible.
7

IEEE Std 1888.3-2013

5. Security architecture
5.1 System architecture
The goal of an IEEE 1888 security system is to protect an IEEE 1888 system against security threats
described in 4.1. Figure 2 shows the system architecture of IEEE 1888 security system. An IEEE 1888
system takes TLS (HTTPS instead of plain HTTP) to protect communication among components and
registries. The IEEE 1888 system shall be cognizant of application requirements before initiating the TLS
procedure. Components and registries should have a certificate to identify their identifiers (IDs) over the
TLS connection.
Figure 2 —IEEE 1888 security system architecture
As shown in Figure 2, the components (APP, storage, and GW) and the registry are typically defined in
IEEE 1888. The authentication, authorization, and accounting (AAA) function has three functionalities:
TLS configuration manager (TCM), authentication manager (AM), and access control manager (ACM).
The TCM manages and maintains TLS parameters configuration depending on application requirements.
The TCM enforces some TLS configuration, such as encryption algorithms, key length, and so on
(CipherSuite parameters). See 6.3.1 for details.
The AM has two functions: certificate verification (CV) and ID verification (IV). CV checks the certificate
posted from the TLS client or TLS server and provides the answer whether the certificate is trustworthy or
not. CV verifies the certificate based on the list of trust anchors pre-installed in itself. IV handles peer
authentication. See 6.3.2 for details.
8

ISO/IEC/IEEE
IEEE 18883:2016(E)
Std 1888.3™-2013
IEEE Std 1888.3-2013 IEEE Std 1888.3™-2013

The ACM replies whether the connected TLS client has 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 a pre-
configured access control list (ACL). See 6.3.3 for detail.
5.2 Initiator and responder
IEEE Std 1888 defines components and registries as 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 IEEE 1888 entities. This concept corresponds to “TLS client”
and “TLS server” defined in the TLS specification (RFC 5246).
 An initiator is a security-enabled IEEE 1888 component (e.g., a GW, storage, or an APP) that
initiates TLS communication as the role of TLS client. For a communication between components,
the initiator calls a query or data method at the IEEE 1888 component contained in the responder
(see below). For communication between an IEEE 1888 component and registry, the initiator calls
registration or lookup method at the registry contained in the responder.
 A responder is a security-enabled IEEE 1888 component or registry that responds to setup a TLS
session between the initiator and carries out query/data or registration/lookup requests posted from
the IEEE 1888 initiator.
5.3 Identifier
5.3.1 How to assign an identifier (ID) for IEEE 1888 entities
An original IEEE 1888 component or registry (hereafter, referred to simply as an “entity”) itself does not
have an ID—it only has an access uniform resource identifier (URI) in the Internet space. In the context of
IEEE 1888 security, each component and registry shall have an 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 IEEE 1888 entity.
 The initiator and responder shall contain only one IEEE 1888 component or registry.
 The initiator or responder shall have a globally unique name and put its name in a subject
alternative name (SAN) section in X.509 certificate format (RFC 5280 Section 4.2.1.6). This
globally unique name is an ID.
5.3.2 Format of the subject alternative name (SAN)
The SAN format of each certificate type is as follows:
 The host-role certificate shall have either a fully qualified domain name (FQDN)-formatted ID
(see RFC 1035) or an Internet Protocol Version 4 (IPv4) address (see RFC 791) or Internet
Protocol Version 6 (IPv6) address (see RFC 2460). The ID is stored in the sole SAN [i.e., type:2 –
dNSName (see RFC 5280 section 4.2.1.6)]. The access URI of the responder shall contain the
FQDN or internet protocol (IP) address. In addition, if the ID uses FQDN format, it shall be
resolved by some name resolution systems, typically by the domain-name system (DNS).
9

IEEE Std 1888.3-2013

 The client-role certificate shall have an e-mail-formatted ID (see RFC 5322 Section 3.4.1) and
stores the ID in their sole SAN [i.e., type:1 – rfc822Name (see RFC 2459 Section 4.2.1.7)]. The e-
mail address does not have to be reachable (as an e-mail address).
5.3.3 “Anonymous” identifier (ID)
If a component cannot be identified, the component can be handled as a component that has the ID
“anonymous.” In other words, the ID “anonymous” is reserved and shall not intentionally be assigned to
any components.
6. Security protocols
6.1 Communication sequence
The typical communication sequences among IEEE 1888 components, registry, and AAA functions
(Figure 3) are described here. IEEE 1888 entities supporting security (including both initiator and
responder) interact with the AAA functions described in 5.1 (for details on the AAA function definition,
see 6.3):
Figure 3 —Communication sequence
10

IEEE Std 1888.3™-2013
IEEE Std 1888.3-2013
Figure 3 illustrates the communication sequence among those initiators, responders, the TLS configuration
manager, the AM, and the ACM. The communication roughly consists of two phases:
 TLS session establishment

 IEEE 1888 message exchange
The first phase is logically separated into two parts. The first part is the “TLS Handshake,” involving
establishment of a TLS session. The handshake shall be conformed to RFC 5246. The second part is
“Mandatory Verification Procedures,” involving the following three procedures:
a) To check the connection parameters for the established TLS session

b) To verify the certificate from the peer
c) To identify and authenticate the peer
This specification itself does not define the order of those procedures in the first phase. For example, a
responder can inquire the AM (this is one of the mandatory verification procedures) during the part of the
TLS handshake. Both initiator and responder shall execute all the procedures before the TLS session is
established. At the second phase, the responder inquires the access permission of the initiator to the ACM.
The certificates exchanged between initiator and responder during the TLS session initiation may be
securely installed at the “key store” in both sides. The key store would be typically implemented in the
initiator and the provider locally, e.g., in a key store file. However, another possible implementation of the
key store would be a smart card; users may have their keys in their smart card and use their certificates for
AAA.
This specification does not actually define the authentication scheme between users and IEEE 1888
components. This is because the interaction between a user and a component shall be made on a user
interface (UI) and is out of the scope of IEEE 1888. Some implementations would take username/password
authentication on the UI, and others would take smart-card-based authentication just as described above. If
the security implementers need to control users according to the role for the IEEE 1888 system, one of the
implementations would be:
a) Prepare several IDs (see 5.3) that represent the role of users
b) Make authentication of users at the UI secure
c) Map the user to the corresponding ID, the role and access policy of which are managed in the AAA
functions.
In this way, IEEE 1888 security indirectly enables user authentication, authorization, and access control.
Figure 3 only shows the success case of mutual authentication between initiator and responder. If this
system requires mutual authentication as its security policy, the TLS session shall terminate before
exchanging IEEE 1888 messages if one of the CVs or authentications has failed, for example. If an IEEE
1888 system allows either one-way authentication or no authentication as its security policy, this procedure
may continue. For more details, see 6.3.2.
6.2 Interface definition
The software architecture of IEEE 1888 security is described here, and the definition of the interfaces is
provided in more detail (Figure 4).
11

IEEE Std 1888.3-2013

Figure 4 —Security-enabled IEEE 1888 software architecture and interfaces
6.2.1 IF1: TLS Handshake
IF1 is an interface between the initiator and responder, which exchanges TLS parameters to establish a
secure channel that protects the IEEE 1888 message. IEEE 1888 security imports TLS for IF1, thus the
implementer shall apply the TLS mechanism.
Since this specification requires mutual authentication between initiator and responder, the responder shall
send the server certificate message defined by RFC 5246 Section 7.4.2, and shall also send the certificate
request message defined by RFC 5246 Section 7.4.4. If the initiator does not intend that the server handles
the client access as an anonymous, the initiator should send the client certificate message defined by RFC
5246 Section 7.4.6. If the initiator does not send any certificates, the responder shall not handle it as a fatal
handshake_failure alert and shall continue the handshake and designate the client as anonymous.
The initiator shall send Server Name Indication Extension (See RFC 6066) in order to support multiple
component instances that share a single IP address (i.e., virtualhost).
6.2.2 IF2: TLS Configuration
IF2 is an interface between the TLS configuration manager and the initiator/responder. The initiator shall
inquire supported TLS parameters. The responder shall post the TLS connection parameters, such as Cipher
12

IEEE Std 1888.3™-2013
IEEE Std 1888.3-2013
Suite, received from the connecting remote peer to the TCM. The TCM shall answer accept or reject for the
connection.
IF2 may provide “peer-specific connection parameters.” The initiator/responder may post ancillary data
(e.g., the peer’s ID, access URI, etc.). Then, the TCM answers the TLS connection parameters (e.g., an
encryption algorithm, a key length, etc.) corresponding to the given ancillary data.
This specification does not specify a concrete protocol, interface, or configurable parameters for this
configuration. Depending on system requirements, including performance, scale of the system, and the
scheme of operation, IEEE 1888 security architecture shall use different styles of implementation. For
example,
a) File-based implementation would work efficiently for small-scale systems.
b) Server-oriented implementation may reduce the cost of TLS configuration management operation
for large-scale systems
6.2.3 IF3: Authentication
IF3 is an interface between the AM and the initiator/responder. IF3 provides:
 CV function
 IV function
For CV, the initiator/responder shall post the list of the certificate chain of the peer’s certificate (i.e., the
certificate for the initiator or responder). Then, the AM shall reply the result of the validation. This
specification does not specify any protocol to exchange the parameters. An implementer should use online
certificate status protocol (OCSP) (see RFC 6277), or an offline embedded validation module, such as
OpenSSL.
For IV, only the initiator shall post:
 The ID of the responder in the SAN of the responder’s certificate

 The FQDN (or IP address) of the connecting peer, i.e., the host part of the access URI
The AM compares them by consulting the binding cache to verify if the ID is on the binding information
cache. The AM shall reply the result of the IV.
This specification does not specify a concrete protocol or interface for CV and IV. Depending on system
requirements, including performance, scale of the system, and the scheme of operation, IEEE 1888 security
architecture shall use different styles of implementations. For example
b) Server-oriented implementation may reduce the cost of certificate management operation and ID
management operation for large-scale systems.
6.2.4 IF4: Access control
IF4 is an interface between an ACM and a responder. A responder asks permission from the initiator
(whether the request of the initiator is allowed or not) to its ACM. Then, the ACM replies the result. In this
specification, at least, the following parameters shall be exchanged via IF4:
13

IEEE Std 1888.3-2013

 ID of the initiator
 ID of the responder
 The list of target pointIDs
 The name of the method (i.e., query/data/registration/lookup)
 The type of query (i.e., storage/stream) if the method is query
The list of the certificate chain may be added optionally. The list of the certificate chain allows group
permission. The ACM may use the intermediate certificate authority (CA) to judge the access right of the
initiator. For example, it can permit any initiators signed by a particular CA.
Depending on the security policies, system operators would apply other information (e.g., the IP address of
the initiator) for access control. However, because the goal of IEEE 1888 security is to enable “access
control by IEEE 1888 component,” such additional information remains optional in this specification. Such
optional information could include the following:
 IP address of the initiator (for access control by IP)
 Result of the DNS reverse lookup from the IP address (for access control by DNS zone or host
name)
 The access time to the responder (for access control by access time)
 The time of values (for access control by measurement time)
 The list of target componentIDs if the method is registration
This specification does not specify a concrete protocol or interface for access control verification.
Depending on system requirements, including performance, scale of the system, and the scheme of
operation, IEEE 1888 security architecture shall use different style of implementations. For example:
b) Server-oriented implementation may reduce the cost of ACL management operation for large-scale
systems.
6.3 Authentication, Authorization, and Accounting (AAA) Function definition
6.3.1 TLS configuration manager (TCM)
The TLS configuration manager (TCM) manages TLS configurable connection parameters. For example,
TCM may enforce use of a specific encryption algorithm for any connections or a specific connection that
is categorized by peer IDs, or the access URI, and so on.
The TCM shall provide two functions:
 For initiators (TLS Client), TCM provides candidate TLS parameter suites.
 For responders (TLS Server), the TCM allows or rejects given parameter suites from the
communication peer initiator (TLS Client).
14

IEEE Std 1888.3™-2013
IEEE Std 1888.3-2013
TCM may provide a function that returns a connection parameter for a given peer ID of a domain name or
an IP address.
6.3.2 Authentication manager (AM)
The AM shall provide at least two functions: CV and 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 CV
should be guided by RFC 5280. The role of IV is the identification of the responder; i.e., it enables an
initiator to connect the correct peer. In order to verify the identity of the responder, IV in an AM (at the
initiator side) shall
a) Compare the ID specified in the SAN of the responder’s certificate with the FQDN or the IP
address of the peer, or
b) Look up the binding information cache (see 6.3.2.2).
6.3.2.1 Anonymous peer
An IEEE 1888 system may reject connections that cannot be authenticated. However, the component may
accept such connections for some reasons. For example, a constraint sensor that cannot run a TLS wants to
write its data to storage and storage wants to allow it. Thus, a security-enabled IEEE 1888 system may
configure security policies as allowing a connection without peer authentication in the following:
 The connection does not use a TLS (raw HTTP).
 The connection uses a TLS, but the initiator does not send its client certificate.
In this case, the peer shall be handled as a component whose ID is “anonymous,” which is defined in
section 6.3.3, and the responder shall consult the ACM for the connection from the peer.
6.3.2.2 Responder with client-role certificate
The client-role certificate is basically intended for initiator use. For example, a component that has a client-
role certificate only fetches data from storage, then analyzes the data and visualizes it for users. In other
words, there is a problem when a responder uses a client-role certificate.
For an initiator, authentication of a responder is done by comparing the ID in the SAN of the responder's
certificate to the host part of the responder's access URI in a typical case of TLS use. However, an ID of a
client-role certificate is not formatted as FQDN or an IP address; the initiator cannot authenticate the
responder in that way when the responder has a client-role certificate.
In order to resolve this problem, this specification introduces the concept of “binding information.”
Binding information is the association of the ID of a client-role certificate of the responder with an access
URI for the responder along with the remaining lifetime of that association.
This specification also introduces a concept of “binding information cache,” that holds binding information
in the AM.
15

IEEE Std 1888.3-2013

Binding information conceptually contains following fields:
 An ID of the client-role certificate for the (potential) responder

 An access URI of the responder that uses the client-role certificate above
 A lifetime value indicating the remaining lifetime for this information
If an operator wants to permit a component that uses a client-role certificate to become a responder, the
operator shall provide the binding information of the responder. The method to provide this binding
information to components or registries is a local matter of implementation.
An initiator shall accept the TLS session when the responder's ID and access URI matches with a binding
information entry in the binding information cache. When the lifetime of the binding information expires, a
component shall delete the entry from its binding information cache.
For example, assume that component X can be accessed via access URI "https://TEST.EXAMPLE.COM/",
but X has a client-role certificate and its ID in SAN is "X@EXAMPLE.COM", and component Y (an
initiator) wants to connect to component X (a responder), and the operator allows this until 2012-12-
31T00:00:00+00:00. In this case, the operator has to provide Y (initiator) with <"X@EXAMPLE.COM",
"https://TEST.EXAMPLE.COM/", "until: 2012-12-31T00:00:00+00:00">.
When initiator Y connects to X, i.e., https://TEST.EXAMPLE.COM/, Y receives identifier=

"X@EXAMPLE.COM". In a typical case, this session is not authenticated in the TLS because the identifier
("X@EXAMPLE.COM") does not match with the host part of the access URI ("TEST.EXAMPLE.COM").
However, now Y has binding information <"X@EXAMPLE.COM", "https://TEST.EXAMPLE.COM/",
"2012-12-31T00:00:00+00:00"> in its binding information cache, thus Y accepts this session.
6.3.2.3 Initiator with client-role certificate and the TRAP protocol
IEEE 1888 provides the TRAP protocol, which requests a provider to perform the WRITE protocol to a
specified component (called “callback”) when a specified condition is met. TRAP also allows the requester
and the callback component to be the same component. This means that a requester, the initiator of the
TRAP protocol, can be a responder later. In this case, the provider needs binding information for the
requester. This association is a dynamic one, so it is possible to manage by operators.
In order to address this issue, this specification introduces a following procedure. When a provider gets a
TRAP request and the requester uses a client-role certificate, the provider should make binding information
for the requester with a lifetime that equals the time at the query validity time [time to live (TTL)] in the
TRAP request expires. This procedure is called “dynamic binding information update.”
In addition, the provider may mark the binding information as "BY_TRAP", and the provider enforces that
the marked binding information is used only for the WRITE protocol that is caused by the TRAP protocol.
The provider may remember the points requested by the TRAP and confirm that all of the points in the
WRITE request that the provider is going to send are included in the points that are requested in the TRAP
protocol.
16

IEEE Std 1888.3™-2013
IEEE Std 1888.3-2013
Figure 5 —Binding information example
For example, assume that component X can be accessed via the access URI "https://TEST.EXAMPLE
.COM/", but X has a client-role certificate with its ID in SAN "X@EXAMPLE.COM", and component X
sends a TRAP request with callback="https://TEST.EXAMPLE.COM/" and point="/foo/bar" to component
Y. Component Y receives this request and performs a dynamic binding information update, i.e., component
Y makes binding information <"X@EXAMPLE.COM", https://TEST.EXAMPLE.COM/", "until: the
TRAP expires (by TTL in the request)", marked as "BY_TRAP"> in its binding information cache. When
the value for point "/foo/bar" is updated, Y starts to initiate a TLS session for a WRITE request to the X,
i.e., http://TEST.EXAMPLE.COM/, and Y receives the certificate of X with identifier=
"X@EXAMPLE.COM". In a typical case, this session is not authenticated in the TLS because the identifier
("X@EXAMPLE.COM") does not match the host part of the access URI ("TEST.EXAMPLE.COM").
However, as Y has cognized that binding information marked as "BY_TRAP" exists, it performs the next
step. Y confirms:
a) The purpose of this session is to send the WRITE request caused by the TRAP protocol
b) The point "/foo/bar" whose value is going to be sent is included in the TRAP request of the
component X
If the session is not for a WRITE request caused by the TRAP that is requested by X@EXAMPLE.COM,
or the point "/foo/bar" is not included in the TRAP request, Y shall terminate the session.
17

IEEE Std 1888.3-2013

6.3.3 Access control manager (ACM)
The ACM compares the ACL with the parameters posted through the interface defined in 6.2.4.
The ACM returns accept or denial for each request.
6.4 Rejecting connection
IEEE 1888 security has two levels of connection rejection:
a) TLS handshake abort

b) IEEE 1888-level rejection (with error messages in 6.4.1)
An initiator shall abort the TLS handshake if any errors are detected during the TLS handshake and shall
follow the definition of Section 7.2.2 in RFC 5246, sending a TLS error alert (which is not in the scope of
this standard). An initiator shall not send any IEEE 1888 error messages and shall close the connection if
any errors are detected after the TLS handshake.
A responder may abort the TLS handshake if any errors are detected during TLS session establishment, and
the responder shall follow the definition of the section 7.2.2 in RFC 5246, sending TLS error messages (the
sending of which is not in the scope of this standard). If the responder does not abort the TLS handshake, it
shall listen to an IEEE 1888 request message from the initiator but shall reject with errors on the response
of the IEEE 1888 message. The error should follow the definition of 6.4.1.
6.4.1 Error messages
An error message shall be a valid IEEE 1888 response message. It shall only have a header with an error
object and any body presented shall be ignored.
The text string for the “type” attribute in an error object is summarized in Table 1. The detailed human-
readable reason should also be included in the text element of the error object.
Table 1 —Error type and the reason description

Type Reason
Authentication CV rejected the peer’s certificate.
Authorization ACM rejected the peer’s certificate.
TLS TCM rejected the peer’s connection.
Other Unable to accept the connection for some other reasons.
18

ICS 35.110
ISBN (PDF) 978-0-7381-8725-9; ISBN (Print) 978-0-7381-87269-6
Price based on 18 pages

This page deliberately left blank
NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW
British Standards Institution (BSI)

BSI is the national body responsible for preparing British Standards and other
standards-related publications, information and services.
BSI is incorporated by Royal Charter. British Standards and other standardization
products are published by BSI Standards Limited.
About us Revisions
We bring together business, industry, government, consumers, innovators Our British Standards and other publications are updated by amendment or revision.
and others to shape their combined experience and expertise into standards We continually improve the quality of our products and services to benefit your
-based solutions. business. If you find an inaccuracy or ambiguity within a British Standard or other
The knowledge embodied in our standards has been carefully assembled in BSI publication please inform the Knowledge Centre.
a dependable format and refined through our open consultation process.
Organizations of all sizes and across all sectors choose standards to help Copyright
them achieve their goals. All the data, software and documentation set out in all British Standards and
other BSI publications are the property of and copyrighted by BSI, or some person
Information on standards or entity that owns copyright in the information used (such as the international
We can provide you with the knowledge that your organization needs standardization bodies) and has formally licensed such information to BSI for
to succeed. Find out more about British Standards by visiting our website at commercial publication and use. Except as permitted under the Copyright, Designs
bsigroup.com/standards or contacting our Customer Services team or and Patents Act 1988 no extract may be reproduced, stored in a retrieval system
Knowledge Centre. or transmitted in any form or by any means – electronic, photocopying, recording
or otherwise – without prior written permission from BSI. Details and advice can
Buying standards be obtained from the Copyright & Licensing Department.
You can buy and download PDF versions of BSI publications, including British
and adopted European and international standards, through our website at Useful Contacts:
bsigroup.com/shop, where hard copies can also be purchased. Customer Services
If you need international and foreign standards from other Standards Development Tel: +44 845 086 9001
Organizations, hard copies can be ordered from our Customer Services team. Email (orders): orders@bsigroup.com
Email (enquiries): cservices@bsigroup.com
Subscriptions
Subscriptions
Our range of subscription services are designed to make using standards
Tel: +44 845 086 9001
easier for you. For further information on our subscription products go to
Email: subscriptions@bsigroup.com
bsigroup.com/subscriptions.
With British Standards Online (BSOL) you’ll have instant access to over 55,000 Knowledge Centre
British and adopted European and international standards from your desktop. Tel: +44 20 8996 7004
It’s available 24/7 and is refreshed daily so you’ll always be up to date. Email: knowledgecentre@bsigroup.com
You can keep in touch with standards developments and receive substantial
Copyright & Licensing
discounts on the purchase price of standards, both in single copy and subscription
format, by becoming a BSI Subscribing Member. Tel: +44 20 8996 7070
Email: copyright@bsigroup.com
PLUS is an updating service exclusive to BSI Subscribing Members. You will
automatically receive the latest hard copy of your standards when they’re
revised or replaced.
To find out more about becoming a BSI Subscribing Member and the benefits
of membership, please visit bsigroup.com/shop.
With a Multi-User Network Licence (MUNL) you are able to host standards
publications on your intranet. Licences can cover as few or as many users as you
wish. With updates supplied as soon as they’re available, you can be sure your
documentation is current. For further information, email bsmusales@bsigroup.com.
BSI Group Headquarters

389 Chiswick High Road London W4 4AL UK

BS Iso Iec Ieee 18883-2016

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BS Iso Iec Ieee 18883-2016

Uploaded by

Copyright:

Available Formats

BS ISO/IEC/IEEE 18883:2016

BSI Standards Publication

Information technology — Ubiquitous

COPYRIGHT PROTECTED DOCUMENT

ii © IEEE 2013 – All rights reserved

© IEEE 2013 – All rights reserved iii

IEEE Standard for Ubiquitous Green

IEEE-SA Board of Governors

IEEE Std 1888.3™-2013

IEEE Standard for Ubiquitous Green

Corporate Advisory Group

Approved 31 October 2013

IEEE-SA Standards Board

© IEEE 2013 – All rights reserved

Keywords: access control, authorization, certificate, confidentiality, IEEE 1888™,

The Institute of Electrical and Electronics Engineers, Inc.

Copyright © 2013 by The Institute of Electrical and Electronics Engineers, Inc.

PDF: ISBN 978-0-7381-8725-9 STD98436

IEEE prohibits discrimination, harassment, and bullying.

© IEEE 2013 – All rights reserved

IEEE Std 1888.3™-2013

Important Notices and Disclaimers Concerning IEEE Standards Documents

© IEEE 2013 – All rights reserved

Comments on standards should be submitted to the following address:

Secretary, IEEE-SA Standards Board

Laws and regulations

© IEEE 2013 – All rights reserved

IEEE Std 1888.3™-2013

Updating of IEEE Standards documents

© IEEE 2013 – All rights reserved

Dong Liu, Chair

Changhe Du Huiling Zhao Shoichi Sakane

Beijing Jiaotong University Cisco Systems, Inc. NXP Semiconductors

John Kulick, Chair

Masayuki Ariyoshi Mark Halpin Ron Petersen

© IEEE 2013 – All rights reserved

IEEE Std 1888.3™-2013

Richard DeBlasio, DOE Representative

© IEEE 2013 – All rights reserved

This document is organized as follows:

 Clause 4 specifies security requirements and design principles.

© IEEE 2013 – All rights reserved

IEEE Std 1888.3™-2013

3. Definitions, abbreviations, and acronyms .................................................................................................. 3

4. Security requirements and design principles .............................................................................................. 4

5. Security architecture ................................................................................................................................... 8

6. Security protocols ......................................................................................................................................10

© IEEE 2013 – All rights reserved

© IEEE 2013 – All rights reserved

IEEE Std 1888.3™-2013

IEEE Standard for Ubiquitous Green

© IEEE 2013 – All rights reserved

IEEE Std 1888.3-2013

2.1 Normative references

RFC 791, Internet Protocol, J. Postel, Ed., September 1981. 4

RFC 1035, Domain Names—Implementation and Specification, P. Mockapetris, November 1987.

RFC 5322, Internet Message Format, P. Resnick, Ed., October 2008.

2.2 Additional references

The OpenSSL Project website. 5

© IEEE 2013 – All rights reserved

IEEE Std 1888.3-2013 IEEE Std 1888.3™-2013

3. Definitions, abbreviations, and acronyms

3.2 Abbreviations and acronyms