IEC 62351-3:2014
(Main)Power systems management and associated information exchange - Data and communications security - Part 3: Communication network and system security - Profiles including TCP/IP
Power systems management and associated information exchange - Data and communications security - Part 3: Communication network and system security - Profiles including TCP/IP
IEC 62351-3:2014 specifies how to provide confidentiality, integrity protection, and message level authentication for SCADA and telecontrol protocols that make use of TCP/IP as a message transport layer when cyber-security is required. Although there are many possible solutions to secure TCP/IP, the particular scope of this part is to provide security between communicating entities at either end of a TCP/IP connection within the end communicating entities. This part of IEC 62351 reflects the security requirements of the IEC power systems management protocols.
Gestion des systèmes de puissance et échanges d'informations associés - Sécurité des communications et des données - Partie 3: Sécurité des réseaux et des systèmes de communication - Profils comprenant TCP/IP
L'IEC 62351-3:2014 spécifie comment garantir la confidentialité, la protection de l'intégrité et l'authentification des niveaux des messages pour les protocoles SCADA (système de commande, de surveillance et d'acquisition de données, Supervisory Control And Data Acquisition) et de téléconduite qui utilisent les protocoles TCP/IP comme couche transport des messages lorsque la cybersécurité est exigée. Bien qu'il existe de nombreuses solutions permettant de sécuriser les protocoles TCP/IP, le domaine d'application de la présente partie est de sécuriser la communication entre des entités, à l'une ou l'autre extrémité de la connexion TCP/IP, dans les limites des entités communicantes. La présente partie de l'IEC 62351 présente les exigences de sécurité des protocoles de la gestion des systèmes de puissance de l'IEC.
General Information
Relations
Standards Content (Sample)
IEC 62351-3 ®
Edition 1.0 2014-10
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
Power systems management and associated information exchange – Data and
communications security –
Part 3: Communication network and system security – Profiles including TCP/IP
Gestion des systèmes de puissance et échanges d'informations associés –
Sécurité des communications et des données –
Partie 3: Sécurité des réseaux et des systèmes de communication – Profils
comprenant TCP/IP
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 IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.
IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing more than 30 000 terms and
Technical Specifications, Technical Reports and other definitions in English and French, with equivalent terms in 14
documents. Available for PC, Mac OS, Android Tablets and additional languages. Also known as the International
iPad. Electrotechnical Vocabulary (IEV) online.
IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a More than 55 000 electrotechnical terminology entries in
variety of criteria (reference number, text, technical English and French extracted from the Terms and Definitions
committee,…). It also gives information on projects, replaced clause of IEC publications issued since 2002. Some entries
and withdrawn publications. have been collected from earlier publications of IEC TC 37,
77, 86 and CISPR.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.
A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.
Catalogue IEC - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
Application autonome pour consulter tous les renseignements
Le premier dictionnaire en ligne de termes électroniques et
bibliographiques sur les Normes internationales,
électriques. Il contient plus de 30 000 termes et définitions en
Spécifications techniques, Rapports techniques et autres
anglais et en français, ainsi que les termes équivalents dans
documents de l'IEC. Disponible pour PC, Mac OS, tablettes
14 langues additionnelles. Egalement appelé Vocabulaire
Android et iPad.
Electrotechnique International (IEV) en ligne.
Recherche de publications IEC - www.iec.ch/searchpub
Glossaire IEC - std.iec.ch/glossary
Plus de 55 000 entrées terminologiques électrotechniques, en
La recherche avancée permet de trouver des publications IEC
en utilisant différents critères (numéro de référence, texte, anglais et en français, extraites des articles Termes et
comité d’études,…). Elle donne aussi des informations sur les Définitions des publications IEC parues depuis 2002. Plus
projets et les publications remplacées ou retirées. certaines entrées antérieures extraites des publications des
CE 37, 77, 86 et CISPR de l'IEC.
IEC Just Published - webstore.iec.ch/justpublished
Service Clients - webstore.iec.ch/csc
Restez informé sur les nouvelles publications IEC. Just
Published détaille les nouvelles publications parues. Si vous désirez nous donner des commentaires sur cette
Disponible en ligne et aussi une fois par mois par email. publication ou si vous avez des questions contactez-nous:
csc@iec.ch.
IEC 62351-3 ®
Edition 1.0 2014-10
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
Power systems management and associated information exchange – Data and
communications security –
Part 3: Communication network and system security – Profiles including TCP/IP
Gestion des systèmes de puissance et échanges d'informations associés –
Sécurité des communications et des données –
Partie 3: Sécurité des réseaux et des systèmes de communication – Profils
comprenant TCP/IP
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
PRICE CODE
INTERNATIONALE
CODE PRIX N
ICS 33.200 ISBN 978-2-8322-1900-3
– 2 – IEC 62351-3:2014 © IEC 2014
CONTENTS
FOREWORD . 3
1 Scope . 5
1.1 Scope . 5
1.2 Intended Audience . 5
2 Normative references . 5
3 Terms, definitions and abbreviations . 6
3.1 Terms, definitions and abbreviations . 6
3.2 Additional abbreviations . 6
4 Security issues addressed by this standard . 6
4.1 Operational requirements affecting the use of TLS in the telecontrol
environment . 6
4.2 Security threats countered . 7
4.3 Attack methods countered . 7
5 Mandatory requirements . 7
5.1 Deprecation of cipher suites . 7
5.2 Negotiation of versions . 8
5.3 Session resumption . 8
5.4 Session renegotiation . 8
5.5 Message Authentication Code . 9
5.6 Certificate support . 9
5.6.1 Multiple Certification Authorities (CAs) . 9
5.6.2 Certificate size . 10
5.6.3 Certificate exchange . 10
5.6.4 Public-key certificate validation . 10
5.7 Co-existence with non-secure protocol traffic . 12
6 Optional security measure support. 12
7 Referencing standard requirements . 12
8 Conformance . 13
Bibliography . 14
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION
EXCHANGE – DATA AND COMMUNICATIONS SECURITY –
Part 3: Communication network and system security –
Profiles including TCP/IP
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62351-3 has been prepared by IEC technical committee 57: Power
systems management and associated information exchange.
This standard cancels and replaces IEC TS 62351-3:2007.
The text of this standard is based on the following documents:
FDIS Report on voting
57/1498/FDIS 57/1515/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
– 4 – IEC 62351-3:2014 © IEC 2014
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts in the IEC 62351 series, published under the general title Power systems
management and associated information exchange – Data and communications security, can
be found on the IEC website.
The committee has decided that the contents of this publication will remain unchanged until
the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data
related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION
EXCHANGE – DATA AND COMMUNICATIONS SECURITY –
Part 3: Communication network and system security –
Profiles including TCP/IP
1 Scope
1.1 Scope
This part of IEC 62351 specifies how to provide confidentiality, integrity protection, and
message level authentication for SCADA and telecontrol protocols that make use of TCP/IP
as a message transport layer when cyber-security is required.
Although there are many possible solutions to secure TCP/IP, the particular scope of this part
is to provide security between communicating entities at either end of a TCP/IP connection
within the end communicating entities. The use and specification of intervening external
security devices (e.g. “bump-in-the-wire”) are considered out-of-scope.
This part of IEC 62351 specifies how to secure TCP/IP-based protocols through constraints
on the specification of the messages, procedures, and algorithms of Transport Layer Security
(TLS) (defined in RFC 5246) so that they are applicable to the telecontrol environment of the
IEC. TLS is applied to protect the TCP communication. It is intended that this standard be
referenced as a normative part of other IEC standards that have the need for providing
security for their TCP/IP-based protocol. However, it is up to the individual protocol security
initiatives to decide if this standard is to be referenced.
This part of IEC 62351 reflects the security requirements of the IEC power systems
management protocols. Should other standards bring forward new requirements, this standard
may need to be revised.
1.2 Intended Audience
The initial audience for this specification is intended to be experts developing or making use
of IEC protocols in the field of power systems management and associated information
exchange. For the measures described in this specification to take effect, they must be
accepted and referenced by the specifications for the protocols themselves, where the
protocols make use of TCP/IP security. This document is written to enable that process.
The subsequent audience for this specification is intended to be the developers of products
that implement these protocols.
Portions of this specification may also be of use to managers and executives in order to
understand the purpose and requirements of the work.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC TS 62351-1:2007, Power systems management and associated information exchange –
Data and communications security – Part 1: Communication network and system security –
Introduction to security issues
IEC TS 62351-2:2008, Power systems management and associated information exchange –
Data and communications security – Part 2: Glossary of terms
– 6 – IEC 62351-3:2014 © IEC 2014
IEC TS 62351-9, Power systems management and associated information exchange – Data
and communications security – Part 9: Key Management
ISO/IEC 9594-8, Information technology – Open Systems Interconnection – The Directory:
Public-key and attribute certificate frameworks
RFC 4492:2006, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS)
RFC 5246:2008, The TLS Protocol Version 1.2
RFC 5280:2008, Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile
RFC 5746:2010, Transport Layer Security (TLS) Renegotiation Indication Extension
RFC 6066:2006, Transport Layer Security Extensions
RFC 6176:2011, Prohibiting Secure Sockets Layer (SSL) Version 2.0
3 Terms, definitions and abbreviations
3.1 Terms, definitions and abbreviations
For the purposes of this document, the terms, definitions and abbreviations given in IEC
TS 62351-2, Glossary, apply .
3.2 Additional abbreviations
CRL Certificate Revocation List
DER Distinguished Encoding Rules
ECDSA Elliptic Curve Digital Signature Algorithm
ECGDSA Elliptic Curve German Digital Signature Algorithm (see ISO/IEC 15946-2)
OCSP Online Certificate Status Protocol (see RFC 6960)
PIXIT Protocol Implementation eXtra Information for Testing
4 Security issues addressed by this standard
4.1 Operational requirements affecting the use of TLS in the telecontrol environment
The IEC telecontrol environment has different operational requirements from many
Information Technology (IT) applications that make use of TLS in order to provide security
protection. The most differentiating, in terms of security, is the duration of the TCP/IP
connection for which security needs to be maintained.
Many IT protocols have short duration connections, which allow the encryption algorithms to
be renegotiated at connection re-establishment. However, the connections within a telecontrol
environment tend to have longer durations, often “permanent”. It is the longevity of the
connections in the field of power systems management and associated information exchange
that give rise to the need for special consideration. In this regard, in order to provide
protection for the “permanent” connections, a mechanism for updating the session key is
specified within this standard, based upon the TLS features of session resumption and
session re-negotiation while also considering the relationship with certificate revocation state
information.
Another issue addressed within this standard is how to achieve interoperability between
different implementations. TLS allows for a wide variety of cipher suites to be supported and
___________
Under consideration.
This is typically referred to as SSL/TLS.
negotiated at connection establishment. However, it is conceivable that two implementations
could support mutually exclusive sets of cipher suites. This standard specifies that referring
standards must specify at least one common cipher suite and a set of TLS parameters that
allow interoperability.
Additionally, this standard specifies the use of particular TLS capabilities that allow for
specific security threats to be countered.
Note that TLS utilizes X.509 certificates (see also ISO/IEC 9594-8 or RFC 5280) for
authentication. In the context of this specification the term certificates always relates to public
key certificates (in contrast to attribute certificates).
NOTE It is intended that certificate management necessary to operate TLS be specified in compliance with IEC TS
62351-9.
4.2 Security threats countered
See IEC TS 62351-1 for a discussion of security threats and attack methods.
TCP/IP and the security specifications in this part of IEC 62351 cover only to the
communication transport layers (OSI layers 4 and lower). This part of IEC 62351 does not
cover security for the communication application layers (OSI layers 5 and above) or
application-to-application security.
The specific threats countered in this part of IEC 62351 for the transport layers include:
– Unauthorized modification or insertion of messages through message level authentication
and integrity protection of messages.
Additionally, when the information has been identified as requiring confidentiality protection:
– Unauthorized access or theft of information through message level encryption of the
messages
4.3 Attack methods countered
The following security attack methods are countered through the appropriate implementation
of the specifications and recommendations in this part of IEC 62351.
– Man-in-the-middle: This threat is countered through the use of a Message Authentication
Code mechanism specified within this document.
– Replay: This threat is countered through the use of specialized processing state machines
specified by the normative references of this document.
– Eavesdropping: This threat is countered through the use of encryption.
NOTE The actual performance characteristics of an implementation claiming conformance to this standard are
out-of-scope of this standard.
5 Mandatory requirements
5.1 Deprecation of cipher suites
Any cipher suite that specifies NULL for encryption shall not be used for communication
outside the administrative domain, if the encryption of this communication connection by other
means cannot be guaranteed.
NOTE 1 This standard does not exclude the use of encrypted communications through the use of cryptographic
based VPN tunnels. The use of such VPNs is out-of-scope of this standard.
If the communication connection is encrypted the following cipher suites may be used:
– TLS_RSA_NULL_WITH_NULL_SHA
– TLS_RSA_NULL_WITH_NULL_SHA256
NOTE 2 The application of no-encryptng cipher suites allows for traffic inspection while still retaining an end-to-
end authentication and integrity protection of the traffic.
– 8 – IEC 62351-3:2014 © IEC 2014
Implementations allowing TLS cipher suites with NULL encryption claiming conformance to
this part shall provide a mechanism to explicitly enable those TLS cipher suites. Per default,
non-encrypting TLS cipher suites are not allowed.
The list of deprecated suites includes, but is not limited to:
– TLS_NULL_WITH_NULL_NULL
– TLS_RSA_NULL_WITH_NULL_MD5
5.2 Negotiation of versions
TLS v1.2 as defined in RFC 5246 (sometimes referred to as SSL v3.3) or higher shall be
supported. To ensure backward compatibility implementations shall also support TLS version
1.0 and 1.1 (sometimes referred to as SSL v3.1 and v3.2). The TLS handshake provides a
built-in mechanism that shall be used to support version negotiation. The IEC 62351 peer
initiating a TLS connection shall always indicate the highest TLS version supported during the
TLS handshake message. The application of TLS versions other than v1.2 is a matter of the
local security policy. Proposal of versions prior to TLS 1.0 shall result in no secure connection
being established (see also RFC 6176).
The proposal of versions prior to TLS 1.0 or SSL 3.1 should raise a security event ("incident:
unsecure communication"). Implementations should provide a mechanism for announcing
security events.
NOTE The option to remotely monitor security events is preferred.
5.3 Session resumption
Session resumption in TLS allows for the resumption of a session based on the session ID
connected with a dedicated (existing) master secret, which will result in a new session key.
This minimizes the performance impact of asymmetric handshakes, and can be done during a
running session or after a session has ended within a defined time period (TLS suggests not
more than 24 hours). This specification follows this approach. Session resumption should be
performed in less than 24 hours, but the actual parameters should be defined based on risk
assessment from the referencing standard. Session resumption is expected to be more
frequent than session renegotiation.
Implementations claiming conformance to this standard shall specify that the symmetric
session keys to be renewed within the maximum time period and maximum allowed number of
packets/bytes sent. These resumption maximum time/bytes constraints are expected to be
specified in a PIXIT of the referencing standard. The maximum time period for session
resumption shall be aligned with the CRL refresh time.
Session resumption intervals shall be configurable, so long as they are within the specified
maximum time period.
Session resumption may be initiated by either side, so long as both the client and server, are
allowed to use this feature by their security policy. In case of failures to resume a session, the
failure handling described in TLS v1.2 shall be followed.
5.4 Session renegotiation
Session renegotiation in TLS requires a complete TLS handshake where all asymmetric
operations and certificate checks must be performed. Session renegotiation will result in a
completely new session based upon both a freshly negotiated master key and a new session
key. During the TLS handshake phase, the certificates are also checked for their validity and
their revocation state. Hence, the timeframe for session renegotiation should be chosen in
accordance to the refresh of the revocation state information (CRL) as described in 5.6.4.4.
Implementations claiming conformance to this standard shall specify that the master secret
shall be renegotiated within a maximum time period and a maximum allowed number of
packets/bytes sent. These renegotiation maximum time/bytes constraints are expected to be
specified in a PIXIT (Protocol Implementation eXtra Information for Testing) of the referencing
standard.
Session renegotiation intervals shall be configurable so long as they are within the specified
maximum time period, and shall be aligned with the CRL update period. If the Online
Certificate Status Protocol (OCSP) is used for certificate revocation checks instead of using
CRLs, session renegotiation shall be performed at least every 24 hours for long lasting
connections to enforce the certificate validity check. Shorter intervals may be defined by the
referencing standard.
The initiation of the TLS (renegotiation) handshake sequence shall be the responsibility of the
TCP entity that receives the TCP-OPEN indication (e.g. the called entity). A request to change
the cipher, issued from the calling entity (e.g. the node that issued the TCP-OPEN) shall be
ignored.
There shall be a timeout associated with the response to a change cipher request. A timeout
of the change cipher request shall result in the connection being terminated. The timeout
value shall be configurable.
To avoid weaknesses in session renegotiation, the session renegotiation extension defined in
RFC 5746 shall be used.
5.5 Message Authentication Code
The Message Authentication Code shall be used. TLS has this capability specified as an
option. This standard mandates the use of this capability to aid in countering and detecting
man-in-the-middle attacks.
5.6 Certificate support
5.6.1 Multiple Certification Authorities (CAs)
An implementation claiming conformance to this standard shall support more than one
Certificate Authority. The actual number is expected to be declared in the implementation’s
PIXIT statement.
The criteria and selection of a CA is out-of-scope of this standard.
In scenarios where more than one X.509 certificate (and corresponding private key) is
available on an IED, it may be desirable to enable the requester to choose a certificate on the
IED side that matches the trusted anchor (root CA) certificates available at the requester side.
The Trusted CA Indication extension specified in RFC 6066 allows a TLS client to provide
information about locally supported CA certificates since the root CA of the utilities may not
be public. The extension allows the requesting party to influence the selection of the X.509
certificate on the IED side for the server side authentication to enable the verification of the
used X.509 certificate on the requestor side.
The Trusted CA Indication is contained in the client hello message. A TLS server receiving a
Trusted CA Indication may use this information to guide its selection of an appropriate
certificate chain to return to the client. According to RFC 6066 in this event, the server shall
include an extension of type "trusted_ca_keys" in the (extended) server hello. The
"extension_data" field of this extension shall be empty.
The support of this extension may be applicable in scenarios where IEDs are accessed by
different administrative domains, e.g., two utilities with an own public key infrastructure. If
different administrative domains are to be supported, the TLS Trusted CA Indication extension
shall be used.
Implementations claiming conformance to this standard using this extension shall specify the
selection of the requested CA issued certificates on the TLS server side. This needs to be
specified for the success and failure case of a matching CA issued certificate. It is a PIXIT
issue, of the referencing standard, to specify the constraints on the Trusted CA Indication
handling.
The failure of a matching CA issued certificate should raise a security event ("incident: CA not
found"). Implementations should provide a mechanism for announcing security events.
– 10 – IEC 62351-3:2014 © IEC 2014
NOTE The option to remotely monitor security events is preferred.
5.6.2 Certificate size
A protocol specifying the use of this standard shall specify the maximum size of certificate
allowed to be used. It is recommended that this size shall be less than or equal to 8 192
octets.
NOTE 1 The certificate may also carry role information according to IEC TS 62351-8, which influences its final
size.
NOTE 2 The certificate size may be influenced by the careful selection of names in issuer and subject field and
supported extensions, etc.
5.6.3 Certificate exchange
The certificate exchange and validation shall be bi-directional. If either entity does not provide
its certificate, the connection shall be terminated.
The connection termination due to the lack of a certificate of either side should raise a
security event ("incident: certificate unavailable"). Implementations should provide a
mechanism for announcing security events.
NOTE The option to remotely monitor security events is preferred.
5.6.4 Public-key certificate validation
5.6.4.1 General
Certificates shall be validated by both the calling and called nodes. There are two
mechanisms that shall be configurable for certificate verification.
– Acceptance of any certificate from an authorized CA
– Acceptance of individual certificates from an authorized CA
5.6.4.2 Verification based upon CA
An implementation claiming conformance to this standard shall be capable of being
configured to accept certificates from one or more Certificate Authorities without the
configuration of individual certificates.
5.6.4.3 Verification based upon individual certificates
An implementation claiming conformance to this standard shall be capable of being
configured to accept specific individual certificates from one or more authorized Certificate
Authorities (e.g. configured).
5.6.4.4 Certificate revocation
Certificate revocation shall be performed as specified in ISO/IEC 9594-8.
The management of the Certificate Revocation List (CRL) is a local implementation issue.
Discussion of the management issues regarding CRLs can be found in IEC TS 62351-1.
Alternatively to local CRLs, OCSP may be used to check the revocation state of applied
certificates. The application of OCSP is outlined in IEC TS 62351-9.
An implementation claiming conformance to this standard shall be capable of checking the
local CRL at a configurable interval. The process of checking the CRL shall not cause an
established session to be terminated. An inability to access the CRL shall not cause the
session to be terminated.
Revoked certificates shall not be used in the establishment of a session. An entity receiving a
revoked certificate during session establishment shall refuse the connection.
The revocation of a certificate shall terminate any session established using that certificate.
Other standards referencing this standard shall specify recommended default evaluation
intervals. The referencing standard shall determine the action that shall be taken if a
certificate, currently in use, has been revoked.
Note that through the normal application/distribution of CRL(s), connections may be
terminated, thus creating an inability to perform communications. Therefore system
administrators should develop certificate management procedures to mitigate such an
occurrence.
The refusal / termination of a connection due to a revoked certificate should raise a security
event ("incident: revoked certificate"). Implementations should provide a mechanism for
announcing security events.
NOTE The option to remotely monitoring security events is preferred.
5.6.4.5 Expired certificates
The expiration of a certificate shall not cause connections to be terminated.
An expired certificate shall not be used or accepted during connection establishment or a
session renegotiation.
The refusal of a connection due to a expired certificate should raise a security event ("warning:
expired certificate"). Implementations should provide a mechanism for announcing security
events.
NOTE The option to remotely monitoring security events is preferred.
5.6.4.6 Signing
Signing through the use of RSA or DSS algorithms shall be supported. Other algorithms, e.g.,
those based on elliptic curve cryptography like ECDSA or ECGDSA may be specified in
standards that reference this document.
For RSA-based signatures, the following key length shall be supported:
– Optional: Signature-operation: RSA with a key length of 1 024 Bits (legacy mode);
– Mandatory: Signature-operation: RSA with a key length of at least 2 048 Bits (modern
mode).
The optional support of RSA with 1 024 bit keys is intended for backward compatibility and
affects mainly the receiver side. RSA with 2 048 bit keys must be supported and is the
preferred signature algorithm to be used.
1 024 bits RSA is no longer recognized as secure with respect to the key length and it is
therefore strongly recommended to perform a risk assessment before using these keys. If
longer keys than 1 024 bits cannot be used, it is also recommended that additional security
measures be taken. The usage of 1 024 bit RSA will be deprecated in the next edition of this
standard. IEC/TS 62351-9 will provide further information on the life cycles of cipher strengths.
NOTE Recommendations regarding required key length for signature algorithms are reviewed constantly and can
be found in NIST SP800-57, BnetzA (BSI), or the NSA Suite B.
Optional Signature-operation: Elliptic curves defined over finite prime fields with signature
algorithm ECDSA or ECGDSA (for ECGDSA, see ISO/IEC 15946-2). The recommended
minimum key length is 256 bits (in combination with SHA-256). The OID to for ecdsa-with-
SHA256 to be used is: iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 2. Cipher suites for TLS, which utilize ECDSA are defined in RFC 4492
as well as in RFC 5246.
The curve to be used for ECDSA shall be secp256r1. The OID for this curve is: iso(1)
member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 7.
5.6.4.7 Key exchange
Public key mechanisms as well as Diffie-Hellman and ephemeral Diffie-Hellman mechanisms
shall be supported. For the key exchange algorithms, the following key length shall be
supported:
– Optional: Minimum key length of 1 024 Bit (legacy mode);
– Mandatory: Recommended key length of at least 2 048 Bit (modern mode).
– 12 – IEC 62351-3:2014 © IEC 2014
The optional support for 1 024 bit key length is intended for backward compatibility. 2 048 bit
key length must be supported and is the preferred key length to be used.
1 024 bit key length for the key exchange is no longer recognized as secure and it is therefore
strongly recommended to perform a risk assessment before using these keys. If a longer key
length than 1 024 bits cannot be used, it is also recommended to take additional security
measures. The usage of 1 024 bit key length will be deprecated in the next edition of this
standard. IEC TS 62351-9 will provide further information on the life cycles of cipher strengths.
5.7 Co-existence with non-secure protocol traffic
Referencing standards shall provide a separate TCP/IP port through which to exchange TLS
secured traffic. This will allow for the possibility of un-ambiguous secure and non-secure
communications simultaneously.
6 Optional security measure support
In certain deployments, additional support is necessary to further restrict the usage of
certificates based on their serial numbers and issuers. This restriction is known as certificate
white listing or certificate pinning, and is currently being defined in the IETF. Certificate white
listing can be optionally supported. If an implementation supports certificate white listing, a
white list shall be built by stating the serial number and the issuer of the allowed certificates.
As this approach is not restricted to the usage of certificates in TLS, it is further specified in
IEC TS 62351-9.
7 Referencing standard requirements
Other standards referencing this standard shall specify:
– The mandatory TLS cipher suites to be supported.
– The recommended time period in which encryption keys are to be exchanged (session key
update).
– The recommended specification in regards to resumption of keys based upon protocol
traffic and/or session run-time. This shall specify the mechanism to measure the traffic
(e.g. packets sent, bytes sent, etc.) and the recommended metric upon which session
resumption should be performed.
– The recommended specification in regards to the renegotiation of keys based upon
protocol traffic and/or session run-time. This shall specify the mechanism to measure the
traffic (e.g. packets sent, bytes sent, etc.) and the recommended metric upon which
session renegotiation should be performed. Session renegotiation should always be
aligned with the CRL refresh time to avoid unnecessary certificate revocation checks.
– Individual certificate fields, if the certificate validation shall be restricted to only dedicated
certificates from an authorized CA (instead of allowing all certificates).
– The recommended number of CAs to be supported.
– The TCP port to be used in order to differentiate between secure (e.g. using TLS) and
non-secure communication traffic.
– The maximum certificate size.
– The recommended default CRL evaluation period.
– In case of using OCSP for certificate revocation checks, the handling of failures to access
the OCSP responder.
– The handling of certificate revocation actions with respect to certificates used in the
context of TLS. Revoking a certificate influences the security of the connection.
Appropriate measures shall be specified to ensure service and system availability.
– The handling of security events defined in this part.
– The required conformance to this standard.
8 Conformance
Conformance to this part of IEC 62351 shall be determined by the implementation of all parts
of Clause 5.
– 14 – IEC 62351-3:2014 © IEC 2014
Bibliography
ISO/IEC 15946-2, Information technology – Security techniques – Cryptographic techniques
based on elliptic curves – Part 2: Digital signatures (withdrawn)
IEC TS 62351-8:2011, Power systems management and associated information exchange –
Data and communications security – Part 8: Role-based access control
RFC 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP
NIST SP-800-57 Part 1 Rev. 3, Recommendations for Key Management, July 2012
BNetzA, BSI, Algorithms for Qualified Electronic Signatures, 02/2013.
NSA Suite B, Suite B Cryptography / Cryptographic Interoperability
_____________
– 16 – IEC 62351-3:2014 © IEC 2014
SOMMAIRE
AVANT-PROPOS . 17
1 Domaine d'application . 19
1.1 Domaine d'application . 19
1.2 Utilisateurs prévus . 19
2 Références normatives . 20
3 Termes, définitions et abréviations . 20
3.1 Termes, définitions et abréviations . 20
3.2 Autres abréviations . 20
4 Problèmes de sécurité couverts par la présente norme . 21
4.1 Influence des exigences fonctionnelles sur l'utilisation de la TLS dans
l'environnement de téléconduite . 21
4.2 Menaces à la sécurité contrées .
...
IEC 62351-3 ®
Edition 1.1 2018-05
CONSOLIDATED VERSION
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Power systems management and associated information exchange – Data
and communications security –
Part 3: Communication network and system security – Profiles including TCP/IP
Gestion des systèmes de puissance et échanges d'informations associés –
Sécurité des communications et des données –
Partie 3: Sécurité des réseaux et des systèmes de communication – Profils
comprenant TCP/IP
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 IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.
IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing 21 000 terms and definitions in
Technical Specifications, Technical Reports and other English and French, with equivalent terms in 16 additional
documents. Available for PC, Mac OS, Android Tablets and languages. Also known as the International Electrotechnical
iPad. Vocabulary (IEV) online.
IEC publications search - webstore.iec.ch/advsearchform IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a 67 000 electrotechnical terminology entries in English and
variety of criteria (reference number, text, technical French extracted from the Terms and Definitions clause of
committee,…). It also gives information on projects, replaced IEC publications issued since 2002. Some entries have been
and withdrawn publications. collected from earlier publications of IEC TC 37, 77, 86 and
CISPR.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: sales@iec.ch.
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.
A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.
Catalogue IEC - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
Application autonome pour consulter tous les renseignements
Le premier dictionnaire en ligne de termes électroniques et
bibliographiques sur les Normes internationales,
électriques. Il contient 21 000 termes et définitions en anglais
Spécifications techniques, Rapports techniques et autres
et en français, ainsi que les termes équivalents dans 16
documents de l'IEC. Disponible pour PC, Mac OS, tablettes
langues additionnelles. Egalement appelé Vocabulaire
Android et iPad.
Electrotechnique International (IEV) en ligne.
Recherche de publications IEC -
Glossaire IEC - std.iec.ch/glossary
webstore.iec.ch/advsearchform
67 000 entrées terminologiques électrotechniques, en anglais
La recherche avancée permet de trouver des publications IEC et en français, extraites des articles Termes et Définitions des
en utilisant différents critères (numéro de référence, texte, publications IEC parues depuis 2002. Plus certaines entrées
comité d’études,…). Elle donne aussi des informations sur les antérieures extraites des publications des CE 37, 77, 86 et
projets et les publications remplacées ou retirées. CISPR de l'IEC.
IEC Just Published - webstore.iec.ch/justpublished Service Clients - webstore.iec.ch/csc
Restez informé sur les nouvelles publications IEC. Just Si vous désirez nous donner des commentaires sur cette
Published détaille les nouvelles publications parues. publication ou si vous avez des questions contactez-nous:
Disponible en ligne et aussi une fois par mois par email. sales@iec.ch.
IEC 62351-3 ®
Edition 1.1 2018-05
CONSOLIDATED VERSION
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Power systems management and associated information exchange – Data
and communications security –
Part 3: Communication network and system security – Profiles including TCP/IP
Gestion des systèmes de puissance et échanges d'informations associés –
Sécurité des communications et des données –
Partie 3: Sécurité des réseaux et des systèmes de communication – Profils
comprenant TCP/IP
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 33.200 ISBN 978-2-8322-5756-2
IEC 62351-3 ®
Edition 1.1 2018-05
CONSOLIDATED VERSION
REDLINE VERSION
VERSION REDLINE
colour
inside
Power systems management and associated information exchange – Data
and communications security –
Part 3: Communication network and system security – Profiles including TCP/IP
Gestion des systèmes de puissance et échanges d'informations associés –
Sécurité des communications et des données –
Partie 3: Sécurité des réseaux et des systèmes de communication – Profils
comprenant TCP/IP
I IEC 62351-3:2014-10+AMD1:2018-05 CSV(en-fr)
– 2 – IEC 62351-3:2014+AMD1:2018 CSV
© IEC 2018
CONTENTS
FOREWORD . 3
1 Scope . 5
1.1 Scope . 5
1.2 Intended Audience . 5
2 Normative references . 5
3 Terms, definitions and abbreviations . 6
3.1 Terms, definitions and abbreviations . 6
3.2 Additional abbreviations . 6
4 Security issues addressed by this standard . 6
4.1 Operational requirements affecting the use of TLS in the telecontrol
environment . 6
4.2 Security threats countered . 7
4.3 Attack methods countered . 7
5 Mandatory requirements . 7
5.1 Deprecation of cipher suites . 7
5.2 Negotiation of versions . 8
5.3 Session resumption . 8
5.4 Session renegotiation . 9
5.5 Message Authentication Code . 10
5.6 Certificate support . 10
5.6.1 Multiple Certification Authorities (CAs) . 10
5.6.2 Certificate size . 10
5.6.3 Certificate exchange . 11
5.6.4 Public-key certificate validation . 11
5.7 Co-existence with non-secure protocol traffic . 14
6 Optional security measure support. 14
7 Referencing standard requirements . 14
8 Conformance . 15
Bibliography . 16
© IEC 2018
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION
EXCHANGE – DATA AND COMMUNICATIONS SECURITY –
Part 3: Communication network and system security –
Profiles including TCP/IP
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
This consolidated version of the official IEC Standard and its amendment has been prepared
for user convenience.
IEC 62351-3 edition 1.1 contains the first edition (2014-10) [documents 57/1498/FDIS and
57/1515/RVD] and its amendment 1 (2018-05) [documents 57/1976/FDIS and 57/1990/RVD].
In this Redline version, a vertical line in the margin shows where the technical content is
modified by amendment 1. Additions are in green text, deletions are in strikethrough red text.
A separate Final version with all changes accepted is available in this publication.
– 4 – IEC 62351-3:2014+AMD1:2018 CSV
© IEC 2018
International Standard IEC 62351-3 has been prepared by IEC technical committee 57: Power
systems management and associated information exchange.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts in the IEC 62351 series, published under the general title Power systems
management and associated information exchange – Data and communications security, can
be found on the IEC website.
The committee has decided that the contents of the base publication and its amendment will
remain unchanged until the stability date indicated on the IEC web site under
"http://webstore.iec.ch" in the data related to the specific publication. At this date, the
publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
© IEC 2018
POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION
EXCHANGE – DATA AND COMMUNICATIONS SECURITY –
Part 3: Communication network and system security –
Profiles including TCP/IP
1 Scope
1.1 Scope
This part of IEC 62351 specifies how to provide confidentiality, integrity protection, and
message level authentication for SCADA and telecontrol protocols that make use of TCP/IP
as a message transport layer when cyber-security is required.
Although there are many possible solutions to secure TCP/IP, the particular scope of this part
is to provide security between communicating entities at either end of a TCP/IP connection
within the end communicating entities. The use and specification of intervening external
security devices (e.g. “bump-in-the-wire”) are considered out-of-scope.
This part of IEC 62351 specifies how to secure TCP/IP-based protocols through constraints
on the specification of the messages, procedures, and algorithms of Transport Layer Security
(TLS) (defined in RFC 5246) so that they are applicable to the telecontrol environment of the
IEC. TLS is applied to protect the TCP communication. It is intended that this standard be
referenced as a normative part of other IEC standards that have the need for providing
security for their TCP/IP-based protocol. However, it is up to the individual protocol security
initiatives to decide if this standard is to be referenced.
This part of IEC 62351 reflects the security requirements of the IEC power systems
management protocols. Should other standards bring forward new requirements, this standard
may need to be revised.
1.2 Intended Audience
The initial audience for this specification is intended to be experts developing or making use
of IEC protocols in the field of power systems management and associated information
exchange. For the measures described in this specification to take effect, they must be
accepted and referenced by the specifications for the protocols themselves, where the
protocols make use of TCP/IP security. This document is written to enable that process.
The subsequent audience for this specification is intended to be the developers of products
that implement these protocols.
Portions of this specification may also be of use to managers and executives in order to
understand the purpose and requirements of the work.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC TS 62351-1:2007, Power systems management and associated information exchange –
Data and communications security – Part 1: Communication network and system security –
Introduction to security issues
IEC TS 62351-2:2008, Power systems management and associated information exchange –
Data and communications security – Part 2: Glossary of terms
– 6 – IEC 62351-3:2014+AMD1:2018 CSV
© IEC 2018
IEC TS 62351-9, Power systems management and associated information exchange – Data
and communications security – Part 9: Cyber security key management for power system
equipment
ISO/IEC 9594-8:2017, Rec. ITU-T X.509 (2016), Information technology – Open Systems
Interconnection – The Directory – Part 8: Public-key and attribute certificate frameworks
RFC 4492:2006, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS)
RFC 5246:2008, The TLS Protocol Version 1.2
RFC 5280:2008, Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile
RFC 5746:2010, Transport Layer Security (TLS) Renegotiation Indication Extension
RFC 6066:2006, Transport Layer Security Extensions
RFC 6176:2011, Prohibiting Secure Sockets Layer (SSL) Version 2.0
3 Terms, definitions and abbreviations
3.1 Terms, definitions and abbreviations
For the purposes of this document, the terms, definitions and abbreviations given in IEC
TS 62351-2, Glossary, apply .
3.2 Additional abbreviations
CRL Certificate Revocation List
DER Distinguished Encoding Rules
ECDSA Elliptic Curve Digital Signature Algorithm
ECGDSA Elliptic Curve German Digital Signature Algorithm (see ISO/IEC 15946-2)
OCSP Online Certificate Status Protocol (see RFC 6960)
PIXIT Protocol Implementation eXtra Information for Testing
4 Security issues addressed by this standard
4.1 Operational requirements affecting the use of TLS in the telecontrol environment
The IEC telecontrol environment has different operational requirements from many
Information Technology (IT) applications that make use of TLS in order to provide security
protection. The most differentiating, in terms of security, is the duration of the TCP/IP
connection for which security needs to be maintained.
Many IT protocols have short duration connections, which allow the encryption algorithms to
be renegotiated at connection re-establishment. However, the connections within a telecontrol
environment tend to have longer durations, often “permanent”. It is the longevity of the
connections in the field of power systems management and associated information exchange
that give rise to the need for special consideration. In this regard, in order to provide
protection for the “permanent” connections, a mechanism for updating the session key is
specified within this standard, based upon the TLS features of session resumption and
session re-negotiation while also considering the relationship with certificate revocation state
information.
___________
Under consideration.
This is typically referred to as SSL/TLS.
© IEC 2018
Another issue addressed within this standard is how to achieve interoperability between
different implementations. TLS allows for a wide variety of cipher suites to be supported and
negotiated at connection establishment. However, it is conceivable that two implementations
could support mutually exclusive sets of cipher suites. This standard specifies that referring
standards must specify at least one common cipher suite and a set of TLS parameters that
allow interoperability.
Additionally, this standard specifies the use of particular TLS capabilities that allow for
specific security threats to be countered.
Note that TLS utilizes X.509 certificates (see also ISO/IEC 9594-8 or RFC 5280) for
authentication. In the context of this specification the term certificates always relates to
public-key certificates (in contrast to attribute certificates).
NOTE It is intended that certificate management necessary to operate TLS be specified in compliance with IEC TS
62351-9.
4.2 Security threats countered
See IEC TS 62351-1 for a discussion of security threats and attack methods.
TCP/IP and the security specifications in this part of IEC 62351 cover only to the
communication transport layers (OSI layers 4 and lower). This part of IEC 62351 does not
cover security functionality specific for the communication application layers (OSI layers 5 and
above) or application-to-application security.
NOTE The application of TLS as profiled in this document supports the protection of information sent over the
TLS protected connection.
The specific threats countered in this part of IEC 62351 for the transport layers include:
– Unauthorized modification or insertion of messages through message level authentication
and integrity protection of messages.
Additionally, when the information has been identified as requiring confidentiality protection:
– Unauthorized access or theft of information through message level encryption of the
messages
4.3 Attack methods countered
The following security attack methods are countered through the appropriate implementation
of the specifications and recommendations in this part of IEC 62351.
– Man-in-the-middle: This threat is countered through the use of a Message Authentication
Code mechanism or digital signatures specified within this document.
– Replay: This threat is countered through the use of specialized processing state machines
specified by the normative references of this document.
– Eavesdropping: This threat is countered through the use of encryption.
NOTE The actual performance characteristics of an implementation claiming conformance to this standard are
out-of-scope of this standard.
5 Mandatory requirements
5.1 Deprecation of cipher suites
Any cipher suite that specifies NULL for encryption shall not be used for communication
outside the administrative domain, if the encryption of this communication connection by other
means cannot be guaranteed.
NOTE 1 This standard does not exclude the use of encrypted communications through the use of cryptographic
based VPN tunnels. The use of such VPNs is out-of-scope of this standard.
If the communication connection is encrypted the following cipher suites may be used:
– TLS_RSA_NULL_WITH_NULL_SHA
– TLS_RSA_NULL_WITH_NULL_SHA256
– 8 – IEC 62351-3:2014+AMD1:2018 CSV
© IEC 2018
NOTE 2 The application of no-encryptng cipher suites allows for traffic inspection while still retaining an end-to-
end authentication and integrity protection of the traffic.
Implementations allowing TLS cipher suites with NULL encryption claiming conformance to
this part shall provide a mechanism to explicitly enable those TLS cipher suites. Per default,
non-encrypting TLS cipher suites are not allowed.
The support of SHA-1 is intended for backward compatibility. SHA-256 shall be supported and
is the preferred signature algorithm to be used.
SHA-1 is no longer recognized as secure with respect collision resistance and it is therefore
strongly recommended to perform a risk assessment before using this algorithm. If SHA-256
cannot be used, it is also recommended that additional security measures be taken. The
usage of SHA-1 will be disallowed in the next edition of this standard.
NOTE Recommendations regarding hash signature algorithms are reviewed constantly and can be found in NIST
SP800-57, BNetzA (BSI), or the NSA Suite B.
The list of deprecated disallowed suites includes, but is not limited to:
– TLS_NULL_WITH_NULL_NULL
– TLS_RSA_NULL_WITH_NULL_MD5
5.2 Negotiation of versions
TLS v1.2 as defined in RFC 5246 (sometimes referred to as SSL v3.3) or higher shall be
supported. To ensure backward compatibility implementations shall also support TLS version
1.0 and 1.1 (sometimes referred to as SSL v3.1 and v3.2). The TLS handshake provides a
built-in mechanism that shall be used to support version negotiation. The IEC 62351 peer
initiating a TLS connection shall always indicate the highest TLS version supported during the
TLS handshake message. The application of TLS versions other than v1.2 is a matter of the
local security policy. Proposal of versions prior to TLS 1.0 shall result in no secure connection
being established (see also RFC 6176).
The proposal of versions prior to TLS 1.0 or SSL 3.1 should raise a security event ("incident:
unsecure communication"). Implementations should provide a mechanism for announcing
security events.
NOTE The option to remotely monitor security events is preferred.
The proposal of versions TLS 1.0 or TLS 1.1 should raise a security warning ("warning:
insecure TLS version"). Implementations should provide a mechanism for announcing security
warnings.
5.3 Session resumption
Session resumption in TLS allows for the resumption of a session based on the session ID
connected with a dedicated (existing) master secret, which will result in a new session key.
This minimizes the performance impact of asymmetric handshakes, and can be done during a
running session or after a session has ended within a defined time period (TLS suggests not
more than 24 hours in RFC 5280). This specification follows this approach suggestion.
Session resumption should be performed in less at least every 24 hours for active sessions or
not later than 24 hours for sessions that have ended, but. The actual parameters should be
defined based on risk assessment from the referencing standard. Session resumption is
expected to be more frequent than session renegotiation.
Implementations claiming conformance to this standard shall specify that the symmetric
session keys to shall be renewed within the maximum time period and maximum allowed
number of packets/bytes sent. These This resumption maximum time/bytes constraints are
constraint is expected to be specified in a PIXIT of the referencing standard. The maximum
time period for session resumption shall be aligned with the CRL refresh time.
Session resumption intervals shall be configurable, so long as they are within the specified
maximum time period.
© IEC 2018
Clients shall initiate session resumption using the ClientHello message. A server initiated
update of session parameter shall use the HelloRequest message to trigger the client to send
a ClientHello message on the currently active connection.
NOTE According to RFC 5246 the HelloRequest is an optional message that the server may send to a client.
Session resumption may be initiated by either side, so as long as the security policies for both
the client and the server, are allowed to use this feature by their security policy permit this. In
case of failures to resume a session, the failure handling described in TLS v1.2 shall be
followed.
Session resumption may be done based on the session identifier (native TLS according to
RFC 5246). Alternatively, session resumption may be done based on session tickets (RFC
5077). The latter option allows for avoiding server-side state for sessions, which can be
resumed. This option may apply for constraint devices to avoid a larger session cache.
NOTE Application of session tickets to avoid the session specific storage on the server side provides the benefit
in environments that tear down a connection and reconnect after a specific time. If session resumption is used to
update the session key of an ongoing session, there may be no benefit.
The session resumption approach may be specified by the referencing standard.
5.4 Session renegotiation
Session renegotiation in TLS requires a complete TLS handshake where all asymmetric
operations and certificate checks must be performed. Session renegotiation will result in a
completely new session based upon both a freshly negotiated master key and a new session
key. During the TLS handshake phase, the certificates are also checked for their validity and
their revocation state. Hence, the timeframe for session renegotiation should be chosen in
accordance to the refresh of the revocation state information (CRL) as described in 5.6.4.4.
Session renegotiation intervals shall be configurable so long as they are within the specified
maximum time period, and shall be aligned with the CRL update period. If the Online
Certificate Status Protocol (OCSP) is used for certificate revocation checks instead of using
CRLs, session renegotiation shall be aligned with the OCSP response cache time. In any
case, for long lasting connections renegotiation shall be performed at least every 24 hours for
long lasting connections to enforce the certificate validity check. Shorter intervals may be
defined by the referencing standard.
NOTE An example alignment is ½ CRL refresh time or ½ OCSP response caching time to limit the possibility of
undetected revoked certificates.
Implementations claiming conformance to this standard shall specify that the master secret
shall be renegotiated within a maximum time period and a maximum allowed number of
packets/bytes sent. These This renegotiation maximum time/bytes constraints are is expected
to be specified in a PIXIT (Protocol Implementation eXtra Information for Testing) of the
referencing standard.
The initiation of the TLS (renegotiation) handshake sequence shall be the responsibility of the
TCP entity that receives the TCP-OPEN indication (e.g. the called entity). A request to change
the cipher, issued from the calling entity (e.g. the node that issued the TCP-OPEN) shall be
ignored.
TLS Clients shall initiate session renegotiation using the ClientHello message. A TLS server
initiated update of session parameter shall use the HelloRequest message to trigger the TLS
client to send a ClientHello message on the currently active connection.
NOTE According to RFC 5246 the HelloRequest is an optional message that the server may sent to a client.
Session renegotiation may be initiated by either side, so long as both the TLS client and TLS
server are allowed to use this feature by their security policy. In case of failures to renegotiate
a session, the failure handling described in TLS v1.2 shall be followed.
The calling entity is responsible for verifying that the TLS session renegotiation takes place at
the expected intervals. If the calling entity does not receive a TLS session renegotiation
request from the called entity at the expected interval, then the calling entity shall terminate
the connection. The termination of a connection due to a missed session renegotiation should
– 10 – IEC 62351-3:2014+AMD1:2018 CSV
© IEC 2018
raise a security event ("incident: session renegotiation interval expired"). Implementations
should provide a mechanism for announcing security events.
NOTE It is expected that client and server are configured with the same TLS security policy.
There shall be a timeout associated with the response to a change cipher request. A timeout
of the change cipher request shall result in the connection being terminated. The timeout
value shall be configurable.
To avoid weaknesses in session renegotiation, the session renegotiation extension defined in
RFC 5746 shall be used.
5.5 Message Authentication Code
The Message Authentication Code shall be used. TLS has this capability specified as an
option. This standard mandates the use of this capability to aid in countering and detecting
man-in-the-middle attacks. The specific algorithm is indicated by the cipher suite.
5.6 Certificate support
5.6.1 Multiple Certification Authorities (CAs)
An implementation claiming conformance to this standard shall support more than one
Certificate Authority related trust anchor. The actual number is expected to be declared in the
implementation’s PIXIT statement.
The criteria and selection of a CA is out-of-scope of this standard.
In scenarios where more than one X.509 certificate (and corresponding private key) is
available on an IED, it may be desirable to enable the requester to choose a certificate on the
IED side that matches the trusted anchor (root CA) certificates available at the requester side.
The Trusted CA Indication extension specified in RFC 6066 allows a TLS client to provide
information about locally supported CA certificates since the root CA of the utilities may not
be public. The extension allows the requesting party to influence the selection of the X.509
certificate on the IED side for the server side authentication to enable the verification of the
used X.509 certificate on the requestor side.
The Trusted CA Indication is contained in the client hello message. A TLS server receiving a
Trusted CA Indication may use this information to guide its selection of an appropriate
certificate chain to return to the client. According to RFC 6066 in this event, the server shall
include an extension of type "trusted_ca_keys" in the (extended) server hello. The
"extension_data" field of this extension shall be empty.
The support of this extension may be applicable in scenarios where IEDs are accessed by
different administrative domains, e.g., two utilities with an own public key infrastructure. If
different administrative domains are to be supported, the TLS Trusted CA Indication extension
shall be used.
Implementations claiming conformance to this standard using this extension shall specify the
selection of the requested CA issued certificates on the TLS server side. This needs to be
specified for the success and failure case of a matching CA issued certificate. It is a PIXIT
issue, of the referencing standard, to specify the constraints on the Trusted CA Indication
handling.
The failure of a matching CA issued certificate should raise a security event ("incident: CA not
found"). Implementations should provide a mechanism for announcing security events.
NOTE The option to remotely monitor security events is preferred.
5.6.2 Certificate size
A protocol specifying the use of this standard shall specify the maximum size of certificate
allowed to be used. It is recommended that this size shall be less than or equal to 8 192
octets.
NOTE 1 The certificate may also carry role information according to IEC TS 62351-8, which influences its final
size.
© IEC 2018
NOTE 2 The certificate size may be influenced by the careful selection of names in issuer and subject field and
supported extensions, etc.
5.6.3 Certificate exchange
The certificate exchange and validation shall be bi-directional to achieve mutual
authentication. If either entity does not provide its certificate, the connection shall be
terminated.
NOTE 1 The server certificate is conveyed in the ServerHello message. The client certificate is conveyed in the
Certificate message.
The connection termination due to the lack of a certificate of either side should raise a
security event ("incident: certificate unavailable"). Implementations should provide a
mechanism for announcing security events.
NOTE 2 The option to remotely monitor security events is preferred.
5.6.4 Public-key certificate validation
5.6.4.1 General
Certificates shall be validated by both the calling and called nodes. There are two
mechanisms that shall be configurable for certificate verification.
– Acceptance of any certificate from an authorized CA
– Acceptance of individual certificates from an authorized CA
5.6.4.2 Verification based upon CA
An implementation claiming conformance to this standard shall be capable of being
configured to accept certificates from one or more Certificate Authorities without the
configuration of individual certificates.
5.6.4.3 Verification based upon individual certificates
An implementation claiming conformance to this standard shall be capable of being
configured to accept specific individual certificates from one or more authorized Certificate
Authorities (e.g. configured).
5.6.4.4 Certificate revocation
Certificate revocation shall be performed as follow the mandatory parameters and procedures
specified in ISO/IEC 9594-8.
The management of the Certificate Revocation List (CRL) is a local implementation issue.
Discussion of the management issues regarding CRLs can be found in IEC TS 62351-1.
Alternatively to local CRLs, OCSP may be used to check the revocation state of applied
certificates. The application of OCSP is outlined in IEC TS 62351-9.
An implementation claiming conformance to this standard shall be capable of checking the
local CRL at a configurable interval. The process of checking the CRL shall not cause an
established session to be terminated. An inability to access the CRL shall not cause the
session to be terminated.
Revoked certificates shall not be used in the establishment or renegotiation of a TLS session.
An entity receiving a revoked certificate during session establishment shall refuse the
connection. An entity receiving a revoked certificate during session renegotiation shall
terminate the connection.
The revocation of a certificate shall terminate any session established using that certificate.
Other standards referencing this standard shall specify recommended default evaluation
intervals. The referencing standard shall determine the action that shall be taken if a
certificate, currently in use, has been revoked.
Note that through the normal application/distribution of CRL(s), connections may be
terminated, thus creating an inability to perform communications. Therefore system
administrators should develop certificate management procedures to mitigate such an
– 12 – IEC 62351-3:2014+AMD1:2018 CSV
© IEC 2018
occurrence (see also IEC 62351-9). Also, it is expected that there is a security management
process in place to evaluate the CRL before distribution to avoid an invalid teardown of the
communication connection, which may influence the reliability. There may also be support for
multiple certificates per device to switch on the fly to another (valid) certificate.
The refusal / termination of a connection due to a revoked certificate should raise a security
event ("incident: revoked certificate"). Implementations should provide a mechanism for
announcing security events.
NOTE The option to remotely monitoring security events is preferred.
5.6.4.5 Expired certificates
The expiration of a certificate shall not cause connections to be terminated.
An expired certificate shall not be used or accepted during connection establishment or a
session renegotiation.
Expired certificates shall not be used in the establishment or renegotiation of a TLS session.
An entity receiving an expired certificate during session establishment shall refuse the
connection. An entity receiving an expired certificate during session renegotiation shall
terminate the connection.
Note that it is expected that there is a security management process in place to initiate a
timely certificate renewal procedure (see also IEC 62351-9). An example time frame may be a
month. There may also be support for multiple certificates per device to permit the switch to
another (valid) certificate.
The refusal of a connection due to an expired certificate should raise a security event
("warning: expired certificate"). Implementations should provide a mechanism for announcing
security events.
NOTE The option to remotely monitoring security events is preferred.
5.6.4.6 Signing
Signing through the use of RSA or DSS algorithms shall be supported. Other algorithms, e.g.,
those based on elliptic curve cryptography like ECDSA or ECGDSA may be specified in
standards that reference this document.
For RSA-based signatures, the following key length shall be supported:
– Optional: Signature-operation: RSA with a key length of 1 024 Bits (legacy mode);
– Mandatory: Signature-operation: RSA with a key length of at least 2 048 Bits (modern
mode).
The optional support of RSA with 1 024 bit keys is intended for backward compatibility and
affects mainly the receiver side. RSA with 2 048 bit keys must be supported and is the
preferred signature algorithm to be used.
1 024 bits RSA is no longer recognized as secure with respect to the key length and it is
therefore strongly recommended to perform a risk assessment before using these keys. If
longer keys than 1 024 bits cannot be used, it is also recommended that additional security
measures be taken. The usage of 1 024 bit RSA will be deprecated in the next edition of this
standard. IEC/TS 62351-9 will provide further information on the life cycles of cipher strengths.
...
IEC 62351-3 ®
Edition 1.2 2020-02
CONSOLIDATED VERSION
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Power systems management and associated information exchange – Data
and communications security –
Part 3: Communication network and system security – Profiles including TCP/IP
Gestion des systèmes de puissance et échanges d'informations associés –
Sécurité des communications et des données –
Partie 3: Sécurité des réseaux et des systèmes de communication – Profils
comprenant TCP/IP
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 IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.
IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.
IEC publications search - webstore.iec.ch/advsearchform Electropedia - www.electropedia.org
The advanced search enables to find IEC publications by a The world's leading online dictionary on electrotechnology,
variety of criteria (reference number, text, technical containing more than 22 000 terminological entries in English
committee,…). It also gives information on projects, replaced and French, with equivalent terms in 16 additional languages.
and withdrawn publications. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Glossary - std.iec.ch/glossary
details all new publications released. Available online and 67 000 electrotechnical terminology entries in English and
once a month by email. French extracted from the Terms and definitions clause of
IEC publications issued between 2002 and 2015. Some
IEC Customer Service Centre - webstore.iec.ch/csc entries have been collected from earlier publications of IEC
If you wish to give us your feedback on this publication or TC 37, 77, 86 and CISPR.
need further assistance, please contact the Customer Service
Centre: sales@iec.ch.
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.
A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.
Recherche de publications IEC - Electropedia - www.electropedia.org
webstore.iec.ch/advsearchform Le premier dictionnaire d'électrotechnologie en ligne au
La recherche avancée permet de trouver des publications IEC monde, avec plus de 22 000 articles terminologiques en
en utilisant différents critères (numéro de référence, texte, anglais et en français, ainsi que les termes équivalents dans
comité d’études,…). Elle donne aussi des informations sur les 16 langues additionnelles. Egalement appelé Vocabulaire
projets et les publications remplacées ou retirées. Electrotechnique International (IEV) en ligne.
IEC Just Published - webstore.iec.ch/justpublished Glossaire IEC - std.iec.ch/glossary
Restez informé sur les nouvelles publications IEC. Just 67 000 entrées terminologiques électrotechniques, en anglais
Published détaille les nouvelles publications parues. et en français, extraites des articles Termes et définitions des
Disponible en ligne et une fois par mois par email. publications IEC parues entre 2002 et 2015. Plus certaines
entrées antérieures extraites des publications des CE 37, 77,
Service Clients - webstore.iec.ch/csc 86 et CISPR de l'IEC.
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-nous:
sales@iec.ch.
IEC 62351-3 ®
Edition 1.2 2020-02
CONSOLIDATED VERSION
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Power systems management and associated information exchange – Data
and communications security –
Part 3: Communication network and system security – Profiles including TCP/IP
Gestion des systèmes de puissance et échanges d'informations associés –
Sécurité des communications et des données –
Partie 3: Sécurité des réseaux et des systèmes de communication – Profils
comprenant TCP/IP
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 33.200 ISBN 978-2-8322-7772-0
IEC 62351-3 ®
Edition 1.2 2020-02
CONSOLIDATED VERSION
REDLINE VERSION
VERSION REDLINE
colour
inside
Power systems management and associated information exchange – Data
and communications security –
Part 3: Communication network and system security – Profiles including TCP/IP
Gestion des systèmes de puissance et échanges d'informations associés –
Sécurité des communications et des données –
Partie 3: Sécurité des réseaux et des systèmes de communication – Profils
comprenant TCP/IP
– 2 – IEC 62351-3:2014+AMD1:2018
+AMD2:2020 CSV © IEC 2020
CONTENTS
FOREWORD . 3
INTRODUCTION to Amendment 2 . 5
1 Scope . 6
1.1 Scope . 6
1.2 Intended Audience . 6
2 Normative references . 6
3 Terms, definitions and abbreviations . 7
3.1 Terms, definitions and abbreviations . 7
3.2 Additional abbreviations . 7
4 Security issues addressed by this standard . 7
4.1 Operational requirements affecting the use of TLS in the telecontrol
environment . 7
4.2 Security threats countered . 8
4.3 Attack methods countered . 8
4.4 Handling of security events . 8
5 Mandatory requirements . 9
5.1 Deprecation of cipher suites . 9
5.2 Negotiation of versions . 9
5.3 Session resumption . 10
5.4 Session renegotiation . 11
5.5 Message Authentication Code . 12
5.6 Certificate support . 12
5.7 Co-existence with non-secure protocol traffic . 16
6 Optional security measure support. 16
7 Referencing standard requirements . 17
8 Conformance . 17
8.1 General . 17
8.2 Notation . 17
8.3 Conformance to selected cipher suites . 18
8.4 Conformance to selected TLS versions . 18
8.5 Conformance to selected TLS protocol features . 18
8.6 Conformance to certificate support . 19
8.7 Conformance to cryptographic algorithm support . 19
Bibliography . 20
Table 1 – Conformance to TLS cipher suites . 18
Table 2 – Conformance to TLS versions . 18
Table 3 – Conformance to TLS protocol features . 18
Table 4 – Conformance to certificate support . 19
Table 5 – Conformance to cryptographic algorithm support . 19
+AMD2:2020 CSV © IEC 2020
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION
EXCHANGE – DATA AND COMMUNICATIONS SECURITY –
Part 3: Communication network and system security –
Profiles including TCP/IP
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
This consolidated version of the official IEC Standard and its amendments has been
prepared for user convenience.
IEC 62351-3 edition 1.2 contains the first edition (2014-10) [documents 57/1498/FDIS and
57/1515/RVD], its amendment 1 (2018-05) [documents 57/1976/FDIS and 57/1990/RVD]
and its amendment 2 (2020-02) [documents 57/2149/FDIS and 57/2167/RVD].
In this Redline version, a vertical line in the margin shows where the technical content
is modified by amendments 1 and 2. Additions are in green text, deletions are in
strikethrough red text. A separate Final version with all changes accepted is available
in this publication.
– 4 – IEC 62351-3:2014+AMD1:2018
+AMD2:2020 CSV © IEC 2020
International Standard IEC 62351-3 has been prepared by IEC technical committee 57: Power
systems management and associated information exchange.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts in the IEC 62351 series, published under the general title Power systems
management and associated information exchange – Data and communications security, can
be found on the IEC website.
The committee has decided that the contents of the base publication and its amendments will
remain unchanged until the stability date indicated on the IEC web site under
"http://webstore.iec.ch" in the data related to the specific publication. At this date, the
publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
+AMD2:2020 CSV © IEC 2020
INTRODUCTION to Amendment 2
This amendment to International Standard IEC 62351-3 has been prepared in order to
address the following issues:
– Support for TLS versions 1.1 and 1.0 is made optional instead of mandatory to address
known weaknesses. This is aligned with the defined security warnings for TLS versions
1.1 and 1.0.
– Update of TLS version handling during renegotiation and resumption to avoid TLS version
downgrade/upgrade within a same session.
– Updated explanatory text for session renegotiation to make the communication relations
clearer.
– Deprecation of RSA1024 and SHA-1 algorithms. This underlines the desire to disallow
them in the next edition.
– Inclusion of PICS section for mandatory and optional settings in TLS.
– Updated text for and enhancements of security events to better align with IEC 62351-14
– Inclusion of general remarks for the security event handling.
– Update of references.
Moreover, explanatory text has been included to better describe certain options as well as an
adjustment to the requirements for referencing standards.
– 6 – IEC 62351-3:2014+AMD1:2018
+AMD2:2020 CSV © IEC 2020
POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION
EXCHANGE – DATA AND COMMUNICATIONS SECURITY –
Part 3: Communication network and system security –
Profiles including TCP/IP
1 Scope
1.1 Scope
This part of IEC 62351 specifies how to provide confidentiality, integrity protection, and
message level authentication for SCADA and telecontrol protocols that make use of TCP/IP
as a message transport layer when cyber-security is required.
Although there are many possible solutions to secure TCP/IP, the particular scope of this part
is to provide security between communicating entities at either end of a TCP/IP connection
within the end communicating entities. The use and specification of intervening external
security devices (e.g. “bump-in-the-wire”) are considered out-of-scope.
This part of IEC 62351 specifies how to secure TCP/IP-based protocols through constraints
on the specification of the messages, procedures, and algorithms of Transport Layer Security
(TLS) (defined in RFC 5246) so that they are applicable to the telecontrol environment of the
IEC. TLS is applied to protect the TCP communication. It is intended that this standard be
referenced as a normative part of other IEC standards that have the need for providing
security for their TCP/IP-based protocol. However, it is up to the individual protocol security
initiatives to decide if this standard is to be referenced.
This part of IEC 62351 reflects the security requirements of the IEC power systems
management protocols. Should other standards bring forward new requirements, this standard
may need to be revised.
1.2 Intended Audience
The initial audience for this specification is intended to be experts developing or making use
of IEC protocols in the field of power systems management and associated information
exchange. For the measures described in this specification to take effect, they must be
accepted and referenced by the specifications for the protocols themselves, where the
protocols make use of TCP/IP security. This document is written to enable that process.
The subsequent audience for this specification is intended to be the developers of products
that implement these protocols.
Portions of this specification may also be of use to managers and executives in order to
understand the purpose and requirements of the work.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC TS 62351-1:2007, Power systems management and associated information exchange –
Data and communications security – Part 1: Communication network and system security –
Introduction to security issues
IEC TS 62351-2:2008, Power systems management and associated information exchange –
Data and communications security – Part 2: Glossary of terms
+AMD2:2020 CSV © IEC 2020
IEC 62351-7, Power systems management and associated information exchange – Data and
communications security – Part 7: Network and System Management (NSM) data object
models
IEC TS 62351-9, Power systems management and associated information exchange – Data
and communications security – Part 9: Cyber security key management for power system
equipment
ISO/IEC 9594-8:2017, Rec. ITU-T X.509 (2016), Information technology – Open Systems
Interconnection – The Directory – Part 8: Public-key and attribute certificate frameworks
RFC 4492:2006, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS)
RFC 5246:2008, The TLS Protocol Version 1.2
RFC 5280:2008, Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile
RFC 5746:2010, Transport Layer Security (TLS) Renegotiation Indication Extension
RFC 6066:2006, Transport Layer Security Extensions
RFC 6176:2011, Prohibiting Secure Sockets Layer (SSL) Version 2.0
3 Terms, definitions and abbreviations
3.1 Terms, definitions and abbreviations
For the purposes of this document, the terms, definitions and abbreviations given in IEC
TS 62351-2, Glossary, apply .
3.2 Additional abbreviations
CRL Certificate Revocation List
DER Distinguished Encoding Rules
ECDSA Elliptic Curve Digital Signature Algorithm
ECGDSA Elliptic Curve German Digital Signature Algorithm (see ISO/IEC 15946-2)
OCSP Online Certificate Status Protocol (see RFC 6960)
PIXIT Protocol Implementation eXtra Information for Testing
4 Security issues addressed by this standard
4.1 Operational requirements affecting the use of TLS in the telecontrol environment
The IEC telecontrol environment has different operational requirements from many
Information Technology (IT) applications that make use of TLS in order to provide security
protection. The most differentiating, in terms of security, is the duration of the TCP/IP
connection for which security needs to be maintained.
Many IT protocols have short duration connections, which allow the encryption algorithms to
be renegotiated at connection re-establishment. However, the connections within a telecontrol
environment tend to have longer durations, often “permanent”. It is the longevity of the
connections in the field of power systems management and associated information exchange
that give rise to the need for special consideration. In this regard, in order to provide
protection for the “permanent” connections, a mechanism for updating the session key is
specified within this standard, based upon the TLS features of session resumption and
___________
Under consideration.
This is typically referred to as SSL/TLS.
– 8 – IEC 62351-3:2014+AMD1:2018
+AMD2:2020 CSV © IEC 2020
session re-negotiation while also considering the relationship with certificate revocation state
information.
Another issue addressed within this standard is how to achieve interoperability between
different implementations. TLS allows for a wide variety of cipher suites to be supported and
negotiated at connection establishment. However, it is conceivable that two implementations
could support mutually exclusive sets of cipher suites. This standard specifies that referring
standards must specify at least one common cipher suite and a set of TLS parameters that
allow interoperability.
Additionally, this standard specifies the use of particular TLS capabilities that allow for
specific security threats to be countered.
Note that TLS utilizes X.509 certificates (see also ISO/IEC 9594-8 or RFC 5280) for
authentication. In the context of this specification the term certificates always relates to
public-key certificates (in contrast to attribute certificates).
NOTE It is intended that certificate management necessary to operate TLS be specified in compliance with IEC TS
62351-9.
4.2 Security threats countered
See IEC TS 62351-1 for a discussion of security threats and attack methods.
TCP/IP and the security specifications in this part of IEC 62351 cover only to the
communication transport layers (OSI layers 4 and lower). Specifically, TLS protects the
transported messages from OSI layer 5 and above in a transparent way. This part of
IEC 62351 does not cover security functionality specific for the communication application
layers (OSI layers 5 and above) or application-to-application security.
NOTE The application of TLS as profiled in this document supports the protection of information sent over the
TLS protected connection.
The specific threats countered in this part of IEC 62351 for the transport layers include:
– Unauthorized modification or insertion of messages through message level authentication
and integrity protection of messages.
Additionally, when the information has been identified as requiring confidentiality protection:
– Unauthorized access or theft of information through message level encryption of the
messages
4.3 Attack methods countered
The following security attack methods are countered through the appropriate implementation
of the specifications and recommendations in this part of IEC 62351.
– Man-in-the-middle: This threat is countered through the use of a Message Authentication
Code mechanism or digital signatures specified within this document.
– Replay: This threat is countered through the use of specialized processing state machines
specified by the normative references of this document.
– Eavesdropping: This threat is countered through the use of encryption.
NOTE The actual performance characteristics of an implementation claiming conformance to this standard are
out-of-scope of this standard.
4.4 Handling of security events
Throughout the document security events are defined as warnings and alarms. These security
events are intended to support the error handling and thus to increase system resilience.
Implementations should provide a mechanism for announcing security events.
It is recommended that the security warning and alarms throughout the document are
implemented by cyber security events as specified by IEC 62351-14 or by monitoring objects
as specified by IEC 62351-7.
+AMD2:2020 CSV © IEC 2020
Note that warnings and alarms are used to indicate the severity of an event from a security
point of view. The following notion is used:
– A warning was intended to raise awareness but to indicate that it may be safe to proceed.
– An alarm is an indication to not proceed.
In any case, it is expected that an operator’s security policy determines the final handling
based on the operational environment.
5 Mandatory requirements
5.1 Deprecation of cipher suites
Any cipher suite that specifies NULL for encryption shall not be used for communication
outside the administrative domain, if the encryption of this communication connection by other
means cannot be guaranteed.
NOTE 1 This standard does not exclude the use of encrypted communications through the use of cryptographic
based VPN tunnels. The use of such VPNs is out-of-scope of this standard.
If the communication connection is encrypted the following cipher suites may be used:
– TLS_RSA_NULL_WITH_NULL_SHA
– TLS_RSA_NULL_WITH_NULL_SHA256
– TLS_RSA_WITH_NULL_SHA
– TLS_RSA_WITH_NULL_SHA256
NOTE 2 The application of no-encryptng cipher suites allows for traffic inspection while still retaining an end-to-
end authentication and integrity protection of the traffic.
Implementations allowing TLS cipher suites with NULL encryption claiming conformance to
this part shall provide a mechanism to explicitly enable those TLS cipher suites. Per default,
non-encrypting TLS cipher suites are not allowed.
The support of SHA-1 is deprecated. Its use is limited to backward compatibility. SHA-256
shall be supported and is the preferred hash algorithm to be used.
SHA-1 is no longer recognized as secure with respect collision resistance and it is therefore
strongly recommended to perform a risk assessment before using this algorithm. If SHA-256
cannot be used, it is also recommended that additional security measures be taken. The
usage of SHA-1 will be disallowed in the next edition of this standard.
NOTE Recommendations regarding hash signature algorithms are reviewed constantly and can be found in NIST
SP800-57, BNetzA (BSI), or the NSA Suite B.
The list of deprecated disallowed suites includes, but is not limited to:
– TLS_NULL_WITH_NULL_NULL
– TLS_RSA_NULL_WITH_NULL_MD5
The failure in finding a matching cipher suite during the TLS handshake shall raise a security
event ("alarm: no matching TLS cipher suites”).
5.2 Negotiation of versions
TLS v1.2 as defined in RFC 5246 (sometimes referred to as SSL v3.3) or higher is the default
version that shall be supported. Higher versions may be supported.
NOTE 1 This document refers to features defined for TLS 1.2. Higher versions of TLS, like TLS 1.3, do not
necessarily support all features listed in this document.
It is recommended that the TLS client initiating a TLS connection indicates the highest TLS
version supported in the ClientHello message of the TLS handshake. The receiving TLS
server may accept higher versions if functional supported and allowed by the security policy
of the operating environment.
– 10 – IEC 62351-3:2014+AMD1:2018
+AMD2:2020 CSV © IEC 2020
To ensure backward compatibility implementations shall also may optionally support TLS
version 1.0 and 1.1 (sometimes referred to as SSL v3.1 and v3.2). The TLS handshake
provides a built-in mechanism that shall be used to support version negotiation. The
IEC 62351 peer initiating a TLS connection shall always indicate the highest TLS version
supported during the TLS handshake message. The application of TLS versions other than
v1.2 is a matter of the local security policy. Proposal of versions prior to TLS 1.0 shall result
in no secure connection being established (see also RFC 6176).
NOTE 2 For TLS 1.0 and TLS 1.1 certain security issues are known, The optional support is only intended for
backward compatibility and it is strongly recommended to switch to TLS 1.2.
The proposal of versions prior to TLS 1.0 or SSL 3.1 should shall raise a security event
("incident: unsecure communication") ("alarm: unsecure communication"). Implementations
should provide a mechanism for announcing security events.
NOTE 3 The option to remotely monitor security events is preferred.
The proposal of versions TLS 1.0 or TLS 1.1 shall raise a security event ("warning: insecure
TLS version").
If the negotiated TLS version from the initial TLS handshake changes in an ongoing TLS
session during a TLS session renegotiation or a session resumption handshake from either
side the TLS session shall be terminated. The termination of the session should raise a
security event ("alarm: TLS Version change detected").
5.3 Session resumption
Session resumption in TLS allows for the resumption of a session based on the session ID
connected with a dedicated (existing) master secret, which will result in a new session key.
This minimizes the performance impact of asymmetric handshakes, and can be done during a
running session or after a session has ended within a defined time period (TLS suggests not
more than 24 hours in RFC 5246). This specification follows this approach suggestion.
Session resumption should be performed in less at least every 24 hours for active sessions or
not later than 24 hours for sessions that have ended, but. The actual parameters should be
defined based on risk assessment from the referencing standard. Session resumption is
expected to be more frequent than session renegotiation leading to a smaller session
resumption interval than the session renegotiation interval. (0 < session resumption interval <
session renegotiation interval <= 24h).
Implementations claiming conformance to this standard shall specify that the symmetric
session keys to shall be renewed within the maximum time period and maximum allowed
number of packets/bytes sent. These This resumption maximum time/bytes constraints are
constraint is expected to be specified in a PIXIT PICS of the referencing standard. The
maximum time period for session resumption shall be aligned with the CRL refresh time.
Session resumption intervals shall be configurable, so long as they are within the specified
maximum time period.
Clients shall initiate session resumption using the ClientHello message. A server initiated
update of session parameter shall use the HelloRequest message to trigger the client to send
a ClientHello message on the currently active connection.
NOTE According to RFC 5246 the HelloRequest is an optional message that the server may send to a client.
Session resumption may be initiated by either side, so as long as the security policies for both
the client and the server, are allowed to use this feature by their security policy permit this. In
case of failures to resume a session, the failure handling described in TLS v1.2 shall be
followed.
Session resumption may be done based on the session identifier (native TLS according to
RFC 5246). Alternatively, session resumption may be done based on session tickets (RFC
5077). The latter option allows for avoiding server-side state for sessions, which can be
resumed. This option may apply for constraint devices to avoid a larger session cache.
+AMD2:2020 CSV © IEC 2020
NOTE Application of session tickets to avoid the session specific storage on the server side provides the benefit
in environments that tear down a connection and reconnect after a specific time. If session resumption is used to
update the session key of an ongoing session, there may be no benefit.
The session resumption approach may be specified by the referencing standard.
NOTE An informative example regarding the configuration is provided at the end of Subclause 5.4.
5.4 Session renegotiation
Session renegotiation in TLS requires a complete TLS handshake where all asymmetric
operations and certificate checks must be performed. Session renegotiation will result in a
completely new session based upon both a freshly negotiated master key and a new session
key. During the TLS handshake phase, the certificates are also checked for their validity and
their revocation state. Hence, the timeframe for session renegotiation should be chosen in
accordance to the refresh of the revocation state information (CRL) as described in 5.6.4.4.
Session renegotiation intervals shall be configurable so long as they are within the specified
maximum time period, and shall be aligned with the CRL update period. If the Online
Certificate Status Protocol (OCSP) is used for certificate revocation checks instead of using
CRLs, session renegotiation shall be aligned with the OCSP response cache time. In any
case, for long lasting connections renegotiation shall be performed at least every 24 hours for
long lasting connections to enforce the certificate validity check. Shorter intervals may be
defined by the referencing standard.
NOTE An example alignment is ½ CRL refresh time or ½ OCSP response caching time to limit the possibility of
undetected revoked certificates.
Implementations claiming conformance to this standard shall specify that the master secret
shall be renegotiated within a maximum time period and a maximum allowed number of
packets/bytes sent. These This renegotiation maximum time/bytes constraints are is expected
to be specified in a PIXIT (Protocol Implementation eXtra Information for Testing) PICS of the
referencing standard.
The initiation of the TLS (renegotiation) handshake sequence shall be the responsibility of the
TCP entity that receives the TCP-OPEN indication (e.g. the called entity). A request to change
the cipher, issued from the calling entity (e.g. the node that issued the TCP-OPEN) shall be
ignored.
TLS Clients shall initiate session renegotiation using the ClientHello message. A TLS server
initiated update of session parameter shall use the HelloRequest message to trigger the TLS
client to send a ClientHello message on the currently active connection.
NOTE According to RFC 5246 the HelloRequest is an optional message that the server may sent to a client.
Session renegotiation may be initiated by either side, so long as both the TLS client and TLS
server are allowed to use this feature by their security policy. In case of failures to renegotiate
a session, the failure handling described in TLS v1.2 shall be followed.
The calling (TLS client) and the called (TLS server) entity are responsible for verifying that the
TLS session renegotiation takes place at the expected intervals. If the calling entity does not
receive a TLS session renegotiation request (HelloRequest) from the called entity at the
expected interval, then the calling entity shall initiate the TLS renegotiation itself using a
ClientHello. If the called entity does not receive a TLS renegotiation (ClientHello) in
response to a HelloRequest, the called entity shall terminate the connection. The
termination of a connection due to a missed TLS session renegotiation should raise a security
event ("alarm: session renegotiation interval expired").
NOTE It is expected that client and server are configured with the same TLS security policy.
There shall be a timeout associated with the response to a change cipher request. A timeout
of the change cipher request shall result in the connection being terminated. The timeout
value shall be configurable.
To avoid weaknesses in session renegotiation, the session renegotiation extension defined in
RFC 5746 shall be used.
– 12 – IEC 62351-3:2014+AMD1:2018
+AMD2:2020 CSV © IEC 2020
The following Informative example is provided:
– The assumed CRL refresh time (or OCSP response validity) is 24h.
– Session renegotiation involves the validation of the peer certificates including the
revocation check. Session renegotiation involving the peer certificates for authentication
may be performed at least every 12 hours.
– To allow for a session key update during the 12-hour session renegotiation interval
session resumption is performed every 2 hours during the session. The maximum time to
resume a previously ended session is 24 hours.
5.5 Message Authentication Code
The Message Authentication Code shall be used. TLS has this capability specified as an
option. This standard mandates the use of this capability to aid in countering and detecting
man-in-the-middle attacks. The specific algorithm is indicated by the cipher suite.
5.6 Certificate support
Multiple Certification Authorities (CAs)
An implementation claiming conformance to this standard shall support more than one
Certificate Authority related trust anchor. The actual number is expected to be declared in the
implementation’s PIXIT statement.
The criteria and selection of a CA is out-of-scope of this standard.
In scenarios where more than one X.509 certificate (and corresponding private key) is
available on an IED, it may be desirable to enable the requester to choose a certificate on the
IED side that matches the trusted anchor (root CA) certificates available at the requester side.
The Trusted CA Indication extension specified in RFC 6066 allows a TLS client to provide
information about locally supported CA certificates since the root CA of the utilities may not
be public. The extension allows the requesting party to influence the selection of the X.509
certificate on the IED side for the server side authentication to enable the verification of the
used X.509 certificate on the requestor side.
The Trusted CA Indication is contained in the client hello message. A TLS server receiving a
Trusted CA Indication may use this information to guide its selection of an appropriate
certificate chain to return to the client. According to RFC 6066 in this event, the server shall
include an extension of type "trusted_ca_keys" in the (extended) server hello. The
"extension_data" field of this extension shall be empty.
The support of this extension may be applicable in scenarios where IEDs are accessed by
different administrative domains, e.g., two utilities with an own public key infrastructure. If
different administrative domains are to be supported, the TLS Trusted CA Indication extension
shall be used.
Implementations claiming conformance to this standard using this extension shall specify the
selection of the requested CA issued certificates on the TLS server side. This needs to be
specified for the success and failure case of a matching CA issued certificate. It is a PIXIT
issue, of the referencing standard, to specify the constraints on the Trusted CA Indication
handling.
The failure of selecting a matching CA issued certificate should shall raise a security event
("incident: CA not found") ("alarm: CA certificate not found"). Implementations should provide
a mechanism for announcing security events.
NOTE The option to remotely monitor security events is preferred.
Certificate size
A protocol specifying the use of this standard shall specify the maximum size of certificate
allowed to be used. It is recommended that this size shall be less than or equal to 8 192
octets.
+AMD2:2020 CSV © IEC 2020
NOTE 1 The certificate may also carry role information according to IEC TS 62351-8, which influences its final
size.
NOTE 2 The certificate size may be influenced by the careful selection of names in issuer and subject field and
supported extensions, etc.
Exceeding the maximum size of a certificate during a TLS handshake shall raise a security
event ("alarm: TLS certificate size exceeded”).
Certificate exchange
The certificate exchange and validation shall be bi-directional to achieve mutual
authentication. If either entity does not provide its certificate, the connection shall be
terminated.
NOTE 1 The server certificate is conveyed in the ServerHello message. The client certificate is conveyed in the
Certificate message.
The connection termination due to the lack of a certificate of eith
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...