EN IEC 62351-4:2018/A1:2020

SLOVENSKI STANDARD
01-november-2020
Upravljanje elektroenergetskega sistema in pripadajoča izmenjava informacij -
Varnost podatkov in komunikacij - 4. del: Profili, vključno z MMS in izpeljankami -
Dopolnilo A1
Power systems management and associated information exchange - Data and
communications security - Part 4: Profiles including MMS and derivatives
Energiemanagementsysteme und zugehöriger Datenaustausch - IT-Sicherheit für Daten
und Kommunikation - Teil 4: Profile einschließlich MMS und Ableitungen
Gestion des systèmes de puissance et échanges d'informations associés - Sécurité des
communications et des données - Partie 4 : Profils comprenant MMS
Ta slovenski standard je istoveten z: EN IEC 62351-4:2018/A1:2020
ICS:
29.240.30 Krmilna oprema za Control equipment for electric
elektroenergetske sisteme power systems
35.240.50 Uporabniške rešitve IT v IT applications in industry
industriji
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN IEC 62351-4:2018/A1

NORME EUROPÉENNE
EUROPÄISCHE NORM
September 2020
ICS 33.200
English Version
Power systems management and associated information
exchange - Data and communications security - Part 4: Profiles
including MMS and derivatives
(IEC 62351-4:2018/A1:2020)
Gestion des systèmes de puissance et échanges Energiemanagementsysteme und zugehöriger
d'informations associés - Sécurité des communications et Datenaustausch - IT-Sicherheit für Daten und
des données - Partie 4: Profils comprenant le MMS et ses Kommunikation - Teil 4: Profile einschließlich MMS und
dérivés Ableitungen
(IEC 62351-4:2018/A1:2020) (IEC 62351-4:2018/A1:2020)
This amendment A1 modifies the European Standard EN IEC 62351-4:2018; it was approved by CENELEC on 2020-08-21. CENELEC
members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this amendment the
status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This amendment exists in three official versions (English, French, German). A version in any other language made by translation under the
responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as
the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN IEC 62351-4:2018/A1:2020 E

European foreword
The text of document 57/2217/FDIS, future IEC 62351-4/A1, prepared by IEC/TC 57 "Power systems
management and associated information exchange" was submitted to the IEC-CENELEC parallel vote
and approved by CENELEC as EN IEC 62351-4:2018/A1:2020.
The following dates are fixed:
• latest date by which the document has to be implemented at national (dop) 2021-05-21
level by publication of an identical national standard or by endorsement
• latest date by which the national standards conflicting with the (dow) 2023-08-21
document have to be withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.

Endorsement notice
The text of the International Standard IEC 62351-4:2018/A1:2020 was approved by CENELEC as a
European Standard without any modification.
In the official version, for Bibliography, the following notes have to be added for the standards
indicated:
IEC 61850-8-1:2011 NOTE Harmonized as EN 61850-8-1:2011 (not modified)
IEC 61850-8-2:2018 NOTE Harmonized as EN IEC 61850-8-2:2019 (not modified)

Annex ZA
(normative)
Normative references to international publications with their
corresponding European publications
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments)
applies.
NOTE 1  Where an International Publication has been modified by common modifications, indicated by (mod),
the relevant EN/HD applies.
NOTE 2  Up-to-date information on the latest versions of the European Standards listed in this annex is available
here: www.cenelec.eu.
Replace the existing reference to ISO/IEC 9594-8 with the following reference:
Publication Year Title EN/HD Year
ITU-T X.509 - Information technology - Open systems - -
interconnection - The Directory: Public-key
and attribute certificate frameworks

IEC 62351-4 ®
Edition 1.0 2020-07
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
A MENDMENT 1
AM ENDEMENT 1
Power systems management and associated information exchange – Data and

communications security –
Part 4: Profiles including MMS and derivatives

Gestion des systèmes de puissance et échanges d'informations associés –

Sécurité des communications et des données –

Partie 4: Profils comprenant le MMS et ses dérivés

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 33.200 ISBN 978-2-8322-8520-6

– 2 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
FOREWORD
This amendment has been prepared by working group 15: Data and communication security, of
IEC technical committee 57: Power systems management and associated information
exchange.
The text of this amendment is based on the following documents:
FDIS Report on voting
57/2217/FDIS 57/2233/RVD
Full information on the voting for the approval of this amendment can be found in the report on
voting indicated in the above table.
The committee has decided that the contents of this amendment and the base publication will
remain unchanged until the stability date indicated on the IEC website 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.
_____________
2 Normative references
Replace the existing reference to ISO/IEC 9594-8 with the following new reference:
ISO/IEC 9594-8:2020 | Rec. ITU-T X.509 (2019), Information technology – Open Systems
Interconnection – The Directory: Public-key and attribute certificate frameworks
3 Terms and definitions
3.2.2
Replace the existing text:
[SOURCE: ISO/IEC 7498-1:1994 | Rec. ITU-T X.200:1994, 7.1.1.2]
with the following new text:
[SOURCE: ISO/IEC 7498-1:1994 | Rec. ITU-T X.200 (1994), 7.1.1.2]
Add, after 3.2.2, the following new definition and renumber subsequent subclauses accordingly:
3.2.3
alarm
security event that might be caused by an adversary

IEC 62351-4:2018/AMD1:2020 – 3 –
© IEC 2020
3.2.7
Replace the existing text:
[SOURCE: Rec. ITU-T X.217:1995, 3.5.1]
with the following new text:
[SOURCE: Rec. ITU-T X.217 (1995), 3.5.1]
3.2.11
Replace the existing text:
[SOURCE: ISO/IEC 9594-8:2017 | Rec. ITU-T X.509 (2016), 3.5.14]
with the following new text:
[SOURCE: ISO/IEC 9594-8:2020 | Rec. ITU-T X.509 (2019), 3.5.14]
3.2.12
Replace the existing text:
[SOURCE: ISO/IEC 9594-8:2017 | Rec. ITU-T X.509:2016, 3.5.21]
with the following new text:
[SOURCE: ISO/IEC 9594-8:2020 | Rec. ITU-T X.509 (2019), 3.5.21]
3.2.18
Replace the existing text:
[SOURCE: ISO/IEC 9594-8:2017 | Rec. ITU-T X.509:2016, 3.5.31]
with the following new text:
[SOURCE: ISO/IEC 9594-8:2020 | Rec. ITU-T X.509 (2019), 3.5.31]
Add, after 3.2.20, the following new definition and renumber subsequent subclauses
accordingly:
3.2.21
error
security event that is caused by bad implementation behaviour resulting in disruption of
communication
Add, after 3.2.27, the following new definition and renumber subsequent subclauses
accordingly:
3.2.28
protocol control information
information exchanged between entities of a given layer, via the service provided by the next
lower layer, to coordinate their joint operation

– 4 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
3.2.29
Replace the existing text:
[SOURCE: ISO/IEC 9594-8:2017 | Rec. ITU-T X.509:2016, 3.5.57]
with the following new text:
[SOURCE: ISO/IEC 9594-8:2020 | Rec. ITU-T X.509 (2019), 3.5.58]
3.2.34
Replace the existing text:
[SOURCE: ISO/IEC 9594-8:2017 | Rec. ITU-T X.509:2016, 3.5.71]
with the following new text:
[SOURCE: ISO/IEC 9594-8:2020 | Rec. ITU-T X.509 (2019), 3.5.72]
3.3 Abbreviated terms
Add the following new abbreviation:
PCI Protocol Control Information
4.2 Security for application and transport profiles
Table 1 – Relationship between security and security measure combinations
Remove the end parenthesis in the first column, first row of Table 1.
4.5.3 Attacks countered in native mode
In the second set of bullet items, replace the existing text:
– Man-in-the-middle: This threat is countered through the use of authentication during end-
to-end association by use of digital signature and during data transfer by use of ICV.
with the following new text:
– Man-in-the-middle: This threat is countered through the use of authentication during end-
to-end association establishment by use of digital signature and during data transfer by use
of ICV.
6.2.6 Public-key certificate size
Replace the existing text of the first paragraph of 6.2.6 with the following new text:
An implementation that claims conformance to this document shall support a public-key
certificate size of minimum and maximum 8192 octets. It is a local issue if larger public-key
certificates are supported.
Add, after the first paragraph of 6.2.6, the following new paragraph:
In order to achieve interoperability of public-key certificates, it is necessary to set a maximum
allowed size for the public-key certificates exchanged by ACSE. This size shall be limited to a
maximum encoding size of 8192 octets.

IEC 62351-4:2018/AMD1:2020 – 5 –
© IEC 2020
6.3.4.1 General
Replace the existing text of the second paragraph of 6.3.4.1 with the following new text:
TLS prioritizes the proposed cipher suites in the TLS handshake according to the order in the
proposed cipher suite list in the ClientHello message. To accommodate a security policy it is
strongly recommended to have the order of proposed cipher suites according to the local
security policy. Cipher suites marked as mandatory shall be stated in the proposal list of the
ClientHello message.
6.3.4.2 Mandatory and recommended cipher suites for compatibility mode
Replace the existing text of the first paragraph of 6.3.4.2 with the following new text:
All implementations that claim conformance to IEC TS 62351-4:2007 shall support
TLS_DH_DSS_WITH_AES_256_CBC_SHA at a minimum.
Replace existing Table 2 with the following new table:
Table 2 – Commented recommended cipher suites from IEC TS 62351-4:2007
Key exchange Encryption Hash IANA Value Source Support
Algorithm Signature
TLS_RSA_ WITH_RC4_128_ SHA 0x00,0x05 RFC 2246 Disallowed (RC 4
(TLS 1.0) considered weak)
TLS_RSA_ WITH_3DES_ede_CBC_ SHA 0x00,0x0A RFC 2246 o
(TLS 1.0)
TLS_DH_ DSS_ WITH_3DES_ede_CBC_ SHA 0x00,0x0D RFC 2246 o
(TLS 1.0)
TLS_DH_ RSA_ WITH_3DES_ede_CBC_ SHA 0x00,0x10 RFC 2246 o
(TLS 1.0)
TLS_DHE_ DSS_ WITH_3DES_ede_CBC_ SHA 0x00,0x13 RFC 2246 o
(TLS 1.0)
TLS_DHE_ RSA_ WITH_3DES_ede_CBC_ SHA 0x00,0x16 RFC 2246 o
(TLS 1.0)
TLS_DH_ DSS_ WITH_AES_128_CBC_ SHA 0x00,0x30 RFC 4346 o
(TLS 1.1)
TLS_DH_ DSS_ WITH_AES_256_CBC_ SHA 0x00,0x36 RFC 4346 m
(TLS 1.1)
TLS_DH_ WITH_AES_128_CBC SHA 0x00, 0x34 RFC 4346 Disallowed
(TLS 1.1) (anonymous)
TLS_DH_ WITH_AES_256_CBC SHA 0x00, 0x3A RFC 4346 Disallowed
(TLS 1.1) (anonymous)
6.3.4.3 Mandatory and recommended cipher suites for native mode
Replace the existing text of the first paragraph of 6.3.4.3 with the following new text:
All implementations that claim conformance to the native mode shall support the mandatory
cipher suites listed in Table 3.
Replace existing Table 3 with the following new table:

– 6 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
Table 3 – Cipher suites combinations in the context of this document
Key exchange Encryption Hash IANA Value Source Support
Algorithm Signature
TLS_RSA WITH_AES_128_CBC_ SHA256 0x00,0x3C RFC 5246 m
TLS_DH_ RSA_ WITH_AES_128_CBC_ SHA256 0x00,0x31 RFC 5246 o
TLS_DH_ RSA_ WITH_AES_128_GCM_ SHA256 0x00,0xA0 RFC 5288 m
[20]
TLS_DHE_ RSA_ WITH_AES_128_GCM_ SHA256 0xC0,0x9E RFC 5288 m
[20]
TLS_DH_ RSA_ WITH_AES_256_GCM_ SHA384 0x00,0xA1 RFC 5288 o
[20]
TLS_ECDHE_ RSA_ WITH_AES_128_GCM_ SHA256 0xC0,0x2F RFC 5289 [7] o
TLS_ECDHE_ RSA_ WITH_AES_256_GCM_ SHA384 0xC0,0x30 RFC 5289 [7] o
TLS_ECDHE_ ECDSA_ WITH_AES_128_GCM_ SHA256 0xC0,0x23 RFC 5289 [7] m
TLS_ECDHE_ ECDSA_ WITH_AES_256_GCM_ SHA384 0xC0,0x24 RFC 5289 [7] o

7.1 General
Replace the existing text of item b), first bullet, with the following new text:
• Clause 12 defines the overall model or architecture for E2E security, including how E2E
security relates to an operational environment and a protected protocol.
7.2.2 ASN.1 as an XML schema definition
Replace the text EXTENDENDE-XER in item b) with EXTENDED-XER
Replace the existing text of the last sentence of item c) by the following new text:
DER is also specified by ISO/IEC 8825-1 | Rec. ITU-T X.690.
7.2.4 XML namespace
Replace the existing text:
(see 12.1)
with the following new text:
(see 16.5)
8.2 Basic cryptographic definitions
Replace the existing text of the last two paragraphs with the following new text:
A defined set represents a set of cryptographic algorithms relevant for a particular situation.
The extension mark ( . ) will cause an ASN.1 tool to accept any cryptographic object, whether
it identifies a cryptographic algorithm for the specific purpose or not. A referencing specification
or an implementers' agreement may remove the extension mark and/or add additional
algorithms.
IEC 62351-4:2018/AMD1:2020 – 7 –
© IEC 2020
8.4 Hash algorithms
Replace the existing text of the last paragraph of 8.4 with the following new text:
IETF RFC 5754 gives the formal specification for the sha256 hash algorithm.
8.5 Signature algorithms
Replace, in the first paragraph of 8.5, "validating" with "verifying".
8.6 Symmetric encryption algorithms used for encryption only
Replace the existing title of Subclause 8.6 with the following new title:
8.6 Symmetric key algorithms
Delete the last sentence of the last paragraph of 8.6.
8.7 Authenticated encryption algorithms
Replace the existing text of the first paragraph of 8.7 with the following new text:
The AES-GCM authenticated encryption technology is used for encryption, integrity and
authentication or it is used only for integrity and authentication (the latter also known as GMAC).
It is further described in [12].
Replace the existing text of the second paragraph of 8.7 with the following new text:
When used for integrity and authentication only, i.e., as GMAC, it may be combined with AES-
CBC encryption.
9 Object identifier allocation (normative)
Delete the auth-mechanism object identifier and the text above.
10.1 Overview
Replace, in the second paragraph of 10.1, two occurrences of "within" with "in".
10.4.1 Context list
Replace the existing text:
Context-list ::= SEQUENCE SIZE(2) OF SEQUENCE {
with the following new text:
Context-list ::= SEQUENCE SIZE(2.MAX) OF SEQUENCE {

10.4.2 Abstract syntaxes
Replace the last paragraph with the following new text:
Two additional abstract syntaxes should be included for compatibility mode as specified in
11.1.3.
Two additional abstract syntaxes shall be included for native mode as specified in 15.2.1.

– 8 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
10.4.3 Presentation user data
Replace the existing text
User-data::= SEQUENCE SIZE (1) OF SEQUENCE {
presentation-context-identifier Presentation-context-identifier,
single-ASN1-type [0] ABSTRACT-SYNTAX.&Type (CONSTRAINED BY {
-- Type corresponding to presentation context identifier --} ) }
with the following new text
User-data ::= [APPLICATION 1] IMPLICIT SEQUENCE SIZE (1) OF SEQUENCE {
presentation-context-identifier Presentation-context-identifier,
single-ASN1-type      [0] EXPLICIT ABSTRACT-SYNTAX.&Type (CONSTRAINED BY {
-- Type corresponding to presentation context identifier --} ) }
10.5.3 Titles
Replace current Notes 1 and 2 with the following new text:
NOTE 1 The combination of the called-AP-title and the called-AE-qualifier is also an object identifier.
This object identifier is the object identifier that is assigned to the entity that acts as server for the association to be
established.
NOTE 2 The combination of the calling-AP-title and the calling-AE-qualifier is also an object
identifier. This object identifier is the object identifier that is assigned to the entity that acts as client for the
association to be established.
11 A-security-profile (normative)
Replace the existing title of Clause 11 with the following new title:
11 A-security profile (normative)
11.1.2 Additional session protocol requirements
Replace the existing text:
Rec.X.638:1996
with the following new text:
Rec. ITU-T X.638 (1996)
11.1.3 Additional presentation protocol requirement
Replace the current text of 11.1.3 with the following new text:
Special abstract syntaxes for A-security profile and MMS each together with an associated
presentation-context-identifier shall be included in the Contexlist together with the abstract
syntax for ACSE (see 10.4.1 and 10.4.2).
The A-security profile abstract syntax is defined as:
mmsAuthenticationAS OBJECT IDENTIFIER ::= {1 0 840 0 1 1 4 1}
NOTE This object identifier should be equal to the object identifier used for identifying the ASN.1 STASE-
MMSAuthentication-value within IEC TS 62351-4:2007. This OID was incorrectly specified and should have been {1
2 840 0 1 0 1 1}. The original value is kept to ensure backward compatibility.
Some implementation may not include this abstract syntax and may therefore not be able to
receive it.
IEC 62351-4:2018/AMD1:2020 – 9 –
© IEC 2020
An implementation shall be able to accept an otherwise valid association request that does not
include this abstract syntax. In the association accept, it shall in this case not include this
abstract syntax.
An implementation that is able to include this abstract syntax in an association request may
keep records of communication partners that does accept an association request with this
abstract syntax included and then in its communication with such partners exclude this abstract
syntax. Alternatively, an implementation may always exclude this abstract syntax in its
association request even when it is able to receive it.
When an implementation that supports this abstract receives an association request with this
abstract included, it shall include this abstract syntax in the association accept.
The MMS abstract syntax is defined in 24.11 of ISO 9506-2:2003 as:
id-mmsAS OBJECT IDENTIFIER ::=
{ iso(1) standard(0) iso9506(9506) part(2) mms-abstract-syntax-version1(1) }

11.1.4.2 Application context
Replace the existing text:
basic-AC OBJECT IDENTIFIER ::= { iso(1) standard(0) iso9506(9505) part(2) mms-
application-context-version1(3) }
with the following new text:
basic-AC OBJECT IDENTIFIER ::= { iso(1) standard(0) iso9506(9506) part(2) mms-
application-context-version1(3) }
11.1.4.3 Authentication mechanism
Replace the existing text of 11.1.4.3 with the following new text:
The mechanism-name component of the AARQ-apdu or AARE-apdu shall be present and shall have
the following value:
{ 1 0 840 0 1 0 1 1 }
11.1.4.4 Authentication value
Replace the second occurrence of the Authentication-value ASN.1 specification with the
following new specification:
Authentication-value ::= CHOICE {
external      [2] IMPLICIT SEQUENCE {
identification     CHOICE {
indirect-reference  INTEGER } OPTIONAL, -- for the mmsAuthenticationAS
encoding       CHOICE {
single-ASN1-type [0] MMS-Authentication-value } } }
Replace the existing penultimate paragraph with the following new text:
An implementation that includes the mmsAuthenticationAS abstract syntax in an association
request or accept shall also include the identification component. Otherwise, the
identification component shall be absent.
11.2.1 General
Replace the existing note in 11.2.1 with the following new text:

– 10 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
NOTE As this module specifies IMPLICIT TAG, implicit tagging is assumed anywhere it is relevant. It is not
necessary to use the IMPLICIT lexical item in the MMS_Authentication-value data type, but it is retained to be
consistent with IEC TS 62351-4:2007.
11.2.2 MMS-Authentication value data type
Replace in 11.2.2 the existing MMS-Authentication-value data type with this new specification:
MMS-Authentication-value ::= CHOICE {
certificate-based     [0] IMPLICIT SEQUENCE {
authentication-Certificate [0] IMPLICIT SignatureCertificate,
time            [1] IMPLICIT GeneralizedTime,
signature         [2] IMPLICIT SignedValue,
... },
... }
In item a) replace the word "evaluating" with the word "verifying".
Replace the existing text of item b) with the following new text:
The accuracy of this time is a local issue but shall be as accurate as possible. It is equally valid
to determine the value of the time parameter during the invocation of the MMS Initiate. Request
service, Initiate Response service, or during the encoding of the ACSE PDUs for those services.
12.1 Introduction and general architecture
Replace, in the fourth paragraph of 12.1, "might" with "may".
Delete, in the fifth paragraph, the word "mutual".
Replace, in NOTE 2, the word "SecPDU" by "SecPDUs".
Replace, in the ninth paragraph, the word "of" with "for".
13.1.2 UTC time specification
Add, in item b) of 13.1.2 "in" before "24-hour clock system".
13.1.3 Handshake request
Replace the existing text of item a) of 13.1.3 with the following new text:
a) The pp component specifies the identity of the application that shall be protected by E2E
security. It shall be the nomination for the protected protocol as follows:
1) for IEC 60870-6-503 [2] the value shall be "IEC 60870-6-503";
2) for IEC 60870-6-702 [3] the value shall be "IEC 60870-6-702";
3) for IEC 60870-6-802 [4] the value shall be "IEC 60870-6-802";
4) for IEC 61850-8-1 [20] the value shall be "IEC 61850-8-1"; and
5) for IEC 61850-8-2 [21] the value shall be "IEC 61850-8-2".
Other values may be added as required in the future.
Replace the existing text of item c) of 13.1.3 with the following new text:
c) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.

IEC 62351-4:2018/AMD1:2020 – 11 –
© IEC 2020
13.1.4 Handshake accept
Replace the existing text of item b) of 13.1.4 with the following new text:
b) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.
13.1.5 Association reject by the protected protocol
Replace the existing text of the first paragraph of 13.1.5 with the following new text:
A protected protocol may cause an association request to be rejected by use of the
ApplicationReject SecPDU.
Replace the existing text of item b) of 13.1.5 with the following new text:
b) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.
13.1.6 Association reject due to security issues
Replace, in point 2) of 13.1.6, "a security event" with "an alarm event".
Replace the existing text of point 3) with the following new text:
3) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.
13.1.8 Data transfer security abort
Replace the existing text of the first paragraph 13.1.8 with the following new text:
A DtSecAbort SecPDU is issued when a security problem is encountered within the E2E security
protocol control information during the data transfer phase. Integrity and authentication are
provided by a digital signature rather than an ICV.
Replace, in point a)2) of 13.1.8 "a security event" by "an alarm event".
Replace the existing text of point b) of 13.1.8 with the following new text:
b) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.
13.1.9 Abort by protected protocol
Replace the existing text of point b) of 13.1.9 with the following new text:
b) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs

– 12 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.
13.1.10 Association release request
Replace the existing text of point b) of 13.1.10 with the following new text:
b) The sign component shall hold a Signature data value as specified in 13.4.1. The signature
shall be generated over the content of the tbs component. In the BER encoding, the tbs
start tag and the following length field shall not be included. If indefinite length encoding is
used, trailing zeros shall be included. In the XML encoding, the tbs start tag and the tbs
end tag shall not be included.
13.2.2 Clear data transfer
Replace the existing text of items a) and b) of 13.2.2 with the following new text:
a) The tbp component includes the part of the ClearTransfer SecPDU that shall be protected
by an ICV.
1) The token2 component shall hold a ClearToken2 data value as specified in 13.3.2.
2) The applData component shall hold a PrPDU specified by the protected protocol.
b) The auth component shall hold the integrity check value (ICV) as defined in 13.4.2. The ICV
shall be generated over the value of the tbp component. In the BER encoding, the tbp start
tag and the following length field shall not be included. If indefinite length encoding is used,
trailing zeros shall be included. In the XML encoding, the tbp start tag and the tbp end tag
shall not be included.
13.2.3 Encrypted data transfer
Replace the existing ASN.1 specification with the following new specification:
EncrTransfer ::= SEQUENCE {
tbp SEQUENCE {
token2  ClearToken2,
applData Encrypted-ApplData,
... },
auth   Authenticator OPTIONAL}

Replace the existing text of item a) of 13.2.3 with the following new text:
a) The tbp component includes the part of the EncrTRansfer SecPDU that shall be protected
by an ICV.
Number the current text of item a) to item a)1) and renumber current item a)1) as item a)2) and
at the end of the third bullet, add the following new text:
The ClearToken2 shall be the additional authenticated data as specified in IETF RFC 5084. In
the BER encoding, additional authenticated data shall include the start tag of ClearToken2 data
value. In the XML encoding the start tag and the end tag of ClearToken2 data value shall be
included.
Replace the existing text of item b) of 13.2.3 with the following new text:
b) The auth component, when present, shall hold information needed for generating the
integrity check value (ICV) as defined in 13.4.2. When authenticated encryption is used, this
component shall be absent, as the ICV is part of the encrypted value. Otherwise, it shall be
present. The ICV shall be generated over the value of tbp component after the encryption.
In the BER encoding, the tbp start tag and the following length field shall not be included. If
indefinite length encoding is used, trailing zeros shall be included. In the XML encoding, the
tbp start tag and the tbp end tag shall not be included.

IEC 62351-4:2018/AMD1:2020 – 13 –
© IEC 2020
13.3.1 The ClearToken1 data type
13.3.1.1 General Syntax
Replace the existing text of the first paragraph of 13.3.1.1 by the following new text:
A ClearToken1 data value provides information about the security context required for secure
communication between two communicating application entities. It is included in an association
request and accept.
Replace the existing ASN.1 for ClearToken1 with the following new text:
ClearToken1 ::= SEQUENCE {
sigAlg     AlgorithmIdentifier {{SupportedSignatureAlgorithms}},
pkCert     PKCert,
certPath    CertPath OPTIONAL,
version    Version (v1),
assoID     AssoID,
dHKey     DiffieHellmanSet,
hmac      AlgorithmIdentifier {{SupportedHmacAlgorithms}},
time      TimeStamp,
encr-mode   CHOICE {
aea      SEQUENCE SIZE (1.MAX) OF
algo      AlgorithmIdentifier {{Supported-AEA-algorithms}},
non-aea  [0] SEQUENCE {
encr    [0] SEQUENCE SIZE (1.MAX) OF
algo      AlgorithmIdentifier {{Supported-encrypt-algorithms}} OPTIONAL,
icvAlgID  [1] SET SIZE (1.MAX) OF
algo      AlgorithmIdentifier {{Supported-ICV-Algorithms}} },
... },
confParams   ConfidentialityParms,
attCert    ACert OPTIONAL,
... }
Add the following new text after the ClearToken1 data type:
SupportedSignatureAlgorithms ALGORITHM ::= { . }
NOTE 1 The SignatureAlgorithm data type requires a parameter that species the cryptographic algorithms that
are supported. The { . } specification indicates that any algorithm may be supported. By not hard coding the
supported algorithms into the formal specification makes future migration to stronger algorithms less cumbersome
for both the ASN.1 specification and the equivalent XSD W3C specification.
SupportedHmacAlgorithms ALGORITHM ::= { . }

Supported-AEA-algorithms ALGORITHM ::= { . }

Supported-encrypt-algorithms ALGORITHM ::= { . }

Supported-ICV-Algorithms ALGORITHM ::= { . }

Replace the existing text of the third paragraph of 13.2.3 with the following new text:
The ClearToken1 data type has the following components:
a) The sigAlg component shall hold the signature algorithm to be used for the digital signature
to be included in the sign component of the Signature data value (see 13.4.1).
The signature algorithms specified in 8.5 shall be supported:
The inclusion of the signature algorithm within the integrity-protected area serves two
purposes. It allows the signature algorithm to be protected by the signature and by placing
it near the start of the protected area makes it possible to generate the hash for signature
verification during the first pass of the SecPDU.

– 14 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
b) The pkCert component shall hold the end-entity public-key certificate of the sender imbedded
in an octet string. It shall be DER encoded.
c) The certPath component, when present, shall hold a CertPath data value as specified in
13.3.1.5. It may be absent, if the sequence of CA certificates are provided by other means
or if the end-entity public-key certificate is directly issued by a trust anchor recognized by
the recipient. Otherwise, it shall be present.
d) The version component, when included in a HandshakeReq SecPDU, shall specify the E2E
security version(s) supported by the client. The version component is a bit-string that allows
the client to set multiple bits, if it supports multiple versions.
The version component, when included in a HandshakeAcc SecPDU shall specify exactly one
version that is supported by the server. It shall be selected among those suggested in the
corresponding HandshakeReq SecPDU.
NOTE 2 Currently, only version 1 is defined.
e) The assoID shall indicate the identity of an association. Each running association shall have
a unique ID within the context a client/server pair. It allows assigning a SecPDU to a
particular association.
The client shall generate a unique ID consisting of one to three numeric characters. The
server shall generate a similar unique ID and append it to the client identifier separated by
a colon (':'). This pair of identifiers separated by a colon forms the assoID, which shall then
be part of all exchanged messages between the two associated entities.
In an XMPP environment this value shall be the same as specified in b) of 16.2.
f) The time component shall be the UTC generalized time at which the HandshakeReq or the
HandshakeAcc SecPDU was created (see 13.1.2 for details).
g) The dHKey component shall specify the use of the Diffie-Hellman algorithm as specified in
13.3.1.2.
h) The hmac component shall specify the HMAC algorithm to be used for the shared key
derivation as specified in 13.3.1.3.
The hash algorithm specified in 8.4 shall be supported
i) the encr-mode component is a choice between two alternatives:
1) The aea alternative is used when the client wants to take advantage of the performance
benefits of using an authenticated encryption (AE) algorithm for both encryption and
integrity protection in a single operation. When this alternative is chosen, two symmetric
keys shall be generated, one for each direction, using the technique specified in
13.3.1.3. The alternative allows the client to specify several AE algorithms. The client
shall list the algorithms according to its preference by having the most preferred
algorithm as the first one in the sequence-of. If a HandshakeAcc SecPDU is to be returned,
the server shall take the same alternative and specify the first AE algorithm it supports
of the suggested algorithms.
Authenticated encryption algorithms are discussed in 8.7. The encr-mode.aea.algo
comment shall not include the aes-nonce of the GCMParameters data type
This alternative may only be selected if encryption is selected for E2E security
2) The non-aea alternative is taken when the client suggests that encryption is not used or
the client for different reasons wants the added flexibility by using separate symmetric
key and ICV algorithms.
NOTE 3 An implementation may want to apply an extended model, where the encryption option is changed
by some intermediate entity. Such an extended model is not defined by this document.
This alternative has two components:
i) In the encr component, when present, the client shall suggest a sequence-of one or
more symmetric key algorithms that shall be listed according to its preference by
having the most preferred algorithm as the first one in the sequence-of. If a

IEC 62351-4:2018/AMD1:2020 – 15 –
© IEC 2020
HandshakeAcc SecPDU is to be returned, the server shall specify the first symmetric
key algorithm it supports of the suggested algorithms.
This component shall be present if encryption is selected for E2E security.
Otherwise, it shall be absent.
The symmetric key algorithms specified in 8.6 shall be supported.
The encr-mode.aea-non.encr.algo component shall not include the AES-
InitializationVector.
ii) In the icvAlgID component, the client shall suggest a sequence-of one or more ICV
algorithms listed according to its preference by having the most preferred algorithm
as the first one in the sequence-of. If a HandshakeAcc SecPDU is to be returned, the
server shall specify the first ICV algorithm it supports of the suggested algorithms.
The ICV algorithms specified in 8.8 shall be supported.
j) The confParams component shall hold ConfidentialityParms data value as specified in
13.3.1.4.
k) The attCert component, when present, shall hold an attribute certificate providing access
control information. It shall be imbedded in an octet string and be DER encoded.
13.3.1.3 Shared keys derivation
Replace, in item a) 4), "tbs" by "tbp".
13.3.2 The ClearToken2 data type
Replace, in item a), "(see b) of 13.3.1.1)" by "(see d) of 13.3.1.1)".
Replace, in item b), "(see c) of 13.3.1.1)" by "(see e) of 13.3.1.1)".
Replace the existing text of the first paragraph of item f) with the following new text:
f) The rekey component shall only be present in a SecPDU issued by the client and shall then
only be present, when refreshment of the shared keys Is required.
The time maximum between key refreshments shall be configurable from a minimum of 15
minutes to a maximum of 24 hours. The actual value is determined by local security policy.
When key refreshment is required, the client shall generate a new Diffie-Hellman private/
Diffie-Hellman public key pair. A new, shared secret Z is then generated as follows:
1) The client generates a new value of the shared value Z by its generated new DH private
key and the retained Diffie-Hellman public key of the server (see 13.3.1.2).
2) The server generates the same value Z by using its retained private key and the Diffie-
Hellman public key of the client received in the transmission.
13.3.3 The ClearToken3 data type
Replace the existing text of the first paragraph of 13.3.3 with the following new text:
A ClearToken3 value provides security information as necessary when rejecting an association
request (using either ApplicationReject or HandshakeSecReject SecPDU) and for an abort. It
provides sufficient information for authenticating the issuer of the reject or abort.
Replace, in item b), "(see b) of 13.3.1.1)" by "(see d) of 13.3.1.1)".
Replace, in item c), "(see c) of 13.3.1.1)" by "(see e) of 13.3.1.1)".
Add, in item c), the word "is" before "without adding a local value".

– 16 – IEC 62351-4:2018/AMD1:2020
© IEC 2020
13.4.1 The Signature data type
algorithm by algo.
Replace, in item a),
Replace, in item b), signature by sign.
13.4.2 The authenticator data type
Replace the existing ASN.1 specification of 13.4.2 with the following new specification:
Authenticator ::= SEQUENCE {
nonce  [0] OCTET STRING OPTIONAL,
algorithm   AlgorithmIdentifier{{ Supported-ICV-Algorithms }},
icv   [1] OCTET STRING,
... }
Replace the existing text of item b) of 13.4.2 with the following new text:
b) The algorithm component shall specify the algorithm used for generating ICV. The algorithm
shall be the one selected by the server in in the HandshakeAcc SecPDU (see item ii) of
13.3.1.1 i) 2)).
Replace the existing text of item c) of 13.4.2 with the following new text:
c) The icv component shall hold the calculated ICV code.
14.1 General
Replace the existing text of the first paragraph of 14.1 with the following new text:
This Clause on error handling considers the type of errors that might occur within E2E security.
It is here assumed that checking for errors occurring within the operational environment in
question has been done.
14.2.1 Handshake diagnostics
Replace in item 4 of the HandshakeDiagnostics data type "client or the server" with "recipient".
Add, after item 16 of the HandshakeDiagnostics data type, the following new codes:
encr-mode-aea-not-supported   (17),
ae-is-required          (18),
aea-select-but-encryp-not-supp  (19),
invalid-ae-algorithm       (20),
single-ae-algorithm-required   (21),
ae-not-used           (22),
invalid-encryption-algorithm   (23),
single-encrypt-algo-required   (24),
single-icvt-algo-required    (25),
Replace the existing text of item 6 of the HandshakeDiagnostics data type with the following
new text:
6) The hmac-algorithm-not-supported diagnostic code shall be selected if the HMAC algorithm
specified in the ClearToken1 data value is not supported.
Add, at the end of 14.2.1, the following new text:
18) The encr-mode-aea-not-supported diagnostic code shall be selected if the server does not
support authenticated encryption.
19) The ae-is-required diagnostic code shall be selected if the server requires authenticated
encryption.
IEC 62351-4:2018/AMD1:2020 – 17 –
© IEC 2020
20) The aea-select-but-encryp-not-supp diagnostic code shall be selected if the server does
not support or do
...